In WordPress, I think utilities should be categorized and placed in a different location than plug-ins.  The difference between the two is, of course, they’re installed like plug-ins but a utility does not affect the processing of content to live pages, plug-ins do.  Often, these routines you run as utilities don’t affect anything else until they are actually run.

Then they lay dormant again, taking up space in your plug-in list, subjecting you to the ridicule of “Whoa, another plug-in, I see.  Do you web developers even write code anymore?”  Funny, you wouldn’t ask the car engineers to build the tires to test the design, but often those who don’t understand web development, the process, the tools and available frameworks and libraries readily available would ask web developers essentially to “build the tires” to go on the car each and every time.

The next time a non-developer wants to perhaps pass judgement or criticize their web development team, someone should ask them if the car design team at Toyota should allocate any of their time and talent dedicated to working on things that are unnecessary, like making tires for the new car?!  That would be absurd, right?

Why?  When you take time away from your web development team to work on things where solutions are already available, you take time and energy away from allowing them to focus on solving actual challenges unique to your company.

Also, criticizing others about their work is never a good idea, you are welcoming closer scrutiny of your own, this applies to any workplace environment.  So, unless you have a firm grasp and understanding of the technical aspects of the tasks involved, perhaps instead of assuming your web development team is incompetent, think about how you will feel when others judge your work without knowing all the facts or understanding what you do.  It’s never a good idea to criticize, especially openly, your co-workers, but in this market especially, perhaps trying to ask, learn and understand the work involved in web development will perhaps give those non-developers a better understanding and appreciation of the web development teams’ skills, knowledge, and experience.

If you have a team of content contributors, users who are also posting content as authors, your WordPress post database will likely fill up with more records storing these revisions that will probably never see the light of day.  I can see keeping the revisions for pages around, maybe up to 5 revisions back, but the auto save feature in WordPress is often a little too vigilant in my opinion.

That’s where the “Optimize Database After Deleting Revisions” plug-in comes in.  It’s a great utility.  There are plenty of useful options to automatically empty trashed items, schedule running this optimization at time intervals, and even keeping a specified number of revisions.

You know, sometimes I think WordPress should keep plug-ins separate from these type of utilities.  Utilities like this may not be used everyday and are independent of your site’s functions of delivering content to the public.

Which leads me to a separate article:  So, why not separate plug-ins and these type of utilities?

Sometimes you will need to alter your WordPress site to accommodate custom behaviors, custom folders, and rewrite handlers for certain scripts.  Things might start acting weird, so what do you do?  You, or someone from your team has probably altered something in the .htaccess file.  Rename the existing one to “htaccess.txt” then create a new file called .htaccess and paste these lines in the file and reupload it to your web root folder (usually in /public_html/):

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

When you get the “white screen of death” on a WordPress site, this is one of your usual suspects.  Often, when someone runs WordPress from a subfolder instead of the root of your website (like installing WordPress in /public_html/wordpress/) some developers may believe they need to alter the .htaccess in order for WordPress to operate, be seen, and show files to omit the /wordpress/ trailing path.  This is not the case, however, the handling of paths and sub paths all go back to the fact that WordPress, like many frameworks and websites designed with the MVC pattern, all run off a single index.php that is located in the root directory.  No matter what pages or scripts you run, WordPress treats them as if they are being run from the web root.

Here is a diagram that may help you understand the basic structure of WordPress code.  It is oversimplified but it should help you visualize how WordPress is organized under the hood:

Open the index.php file WordPress runs on, notice in the configuration instructions you have to update the path to wp-blog-header.php by prepending it with the subfolder WordPress is contained in?  That’s why.  Since the index.php file in your web root folder is the file that loads all other files, your code always knows where “root” and “home” is.  This makes it much easier to navigate and organize your code without worrying about sub paths and relative paths.  If you imagine your code is organized much like a pyramid where, at the top is always this main index.php file handler, you will be able to better understand how WordPress works so you can more effectively troubleshoot problems later.