Ron R is half of the well known duo also comprised of Andrea R, the team behind WPMU Tutorials – James.

This week James announced the first WPMU plugin competition and included an offer to express interest in sponsoring and/or judging. Andrea & I discussed it briefly and decided that we would like to be a sponsor for the event. Because I do most of the custom coding, I tend to pay more attention to how well a plugin is written while Andrea is interested in whether it meets the need of the client.

If I were looking for a well written plugin, I would base my assessment on the following 4 things:

Loops: Loops are what make programming practical. They are used everywhere: database engines, string processing functions, capturing keystrokes, etc. Almost all processing time is consumed within loops. One of the keys to good programming is to only include code inside of a loop that needs to be in the loop. For example, if you were outputting a number of items from a blog that use the blog’s url:

foreach($items as $item) {
echo '<a href=”'. get_option('siteurl') . “path/{$item}\”>description</a> “;
// more code
}

Instead of calling the get_option function inside the loop, call it first and store the results in a variable

$siteurl = get_option('siteurl');
foreach($items as $item) {
echo “<a href="\”{$siteurl}path/{$item}\”">description</a> “;
// more code
}

Efficient queries: Databases are the heart of most content management systems. WordPress and WordPress MU are no different. A plugin that uses the database(s) poorly can substantially eat away at site performance. Here are some simple guidelines that can be used when writing database queries:

• Don’t use SELECT * unless you need all of the columns in the table(s). Only retrieve the columns you need. Yes, it takes more time to write the query but resources are chewed up retrieving and including the unused columns in the result set.
• Use the LIMIT clause to select only the rows you need. The reasoning is the same as for selecting only the columns you need.
• Use aggregate functions to reduce processing. If you want a count of something, you could retrieve a column from the table and use the php count() function. But, there is a MySQL COUNT function which will do this. The MySQL engine is optimized to do this type of processing and the result set that it creates to return to WPMU is a single value.
• When creating tables include a PRIMARY KEY index on each table at a minimum. Depending on the content of a table, other indexes may be appropriate.
• Try to use as few queries as possible while maintaining query efficiency. This is a cost/benefit type of deal that can be worked through by trying different variations and seeing how it affects processing time. JOINs enable a query to retrieve data from more than 1 table. If matching rows are required from 2 tables, a JOIN can eliminate a second query.

Short: Development for WPMU has never been a far step from development for the WP Standalone. The standalone version is forgiving of poorly written code due to the difference in the number of page loads and it can absorb cut and paste code. But, if a WPMU install is parsing and tokenizing an extra few hundred lines of code 10, 20, 50 or 100,000 times a day, it adds up. Write reusable functions to reduce the size of the code.

Simple: I include this to balance what I said in the previous item. The pendulum can swing to far the other way. Reducing the footprint of the code shouldn’t be taken to the extreme of making the code hard to read. Code should be readable without requiring detailed comm ents explaining what the code is doing.

In summary, sometimes LESS is better. When I sit down to do some programming I don’t think of these as hard and fast rules, but a good basis to start with.

Would you like to share your WPMU story on WPMU.org? Register and let us know!