Function Documentation

WordPress Function Documentation Progress

wp-config.php Settings: Part 2


In WordPress 2.5, a new hard coded setting is added, which allows for increasing the memory limit. Few people always seem to have a problem where PHP exhausts all of the memory (usually 8MB) and PHP crashes, bringing down WordPress in the process.

By default, the memory is increased to 32MB, which is conservative or liberal depending on your hosts setting. Dreamhost has 128MB for PHP5, which is pretty crazy, but if a PHP program takes up all of that, then there is something seriously wrong with the application. WordPress should be able to run within 32MB on small and medium sized blogs with just the default caching.

This won’t solve all of the problems, because some hosts do not have memory limit setting enabled. In order for the increase to work, --enable-memory-limit had to be set during PHP installation and ini_set() has to be enabled (not part of the disabled_functions PHP INI setting). Nothing that WordPress, nor the user has control over. If --enable-memory-limit was not used, then the host can’t even increase the memory limit. Some hosts do disable the ini_set() function for security and PHP configuration purposes.

However, the good news is that unless you screwed up your PHP installation (and should reinstall and upgrade anyway) or on a crappy host, you should be okay and the increase will take affect.

Note: Don’t worry about the constant lowering the memory limit, because it won’t try to set the memory limit if the defined constant is less than what is already set in PHP.


In your wp-config.php file, insert the following:

define('WP_MEMORY_LIMIT', '32MB');

Just basically copy the above and the memory limit will be attempted to be set to ’32MB’. You can change ’32MB’ to any number of MiB in the format of a number, followed immediately by ‘MB’. So other examples are ’16MB’ (PHP5 default), ’64MB’

define('WP_MEMORY_LIMIT', '16MB'); // PHP5 default
define('WP_MEMORY_LIMIT', '67MB'); // Larger Blogs using default object cache. Just in case.


WordPress continues to work on improving the amount of memory that is required. It is impossible to optimize the WordPress Object Cache on large blogs and may never be. It is with that reasoning that the above addition is justified. If 32MB isn’t enough, just increase the memory limit and let the WordPress team know it failed.


January 31, 2008 Posted by | Advanced User Manual | , , , | 1 Comment

Replacing WordPress Object Caching

The WordPress Object Cache changed in WordPress 2.5 and removed a lot of file support from the code. This means that the Object Cache in WordPress 2.5 is completely dependent on memory and will not be saved to disk for retrieval later. The constant WP_CACHE also changed its meaning.

WP_CACHE Constant

In WordPress versions prior to 2.5 release, there were two constants that were used. One always enabled the cache and the other always disabled the cache. However, confusion was caused by both the constant values being booleans. In WordPress 2.5, those old constants were removed and a new one is used instead.

Normally, the WP_CACHE constant does not exist in wp-config.php. If it does exist, then it means that there is a file in wp-content folder named advanced-cache.php. This file, if it exists will be included (not to be confused with required, meaning that if it isn’t there and you remove it, it won’t halt the WordPress execution) and a function called wp_cache_postload(), if it exists.

The way to disable the WordPress cache is to define another cache, also in the wp-content folder, called object-cache.php. However, the functions that are used by WordPress still need to be defined in the file. Mostly, if you return false, then WordPress will just retrieve from the database, which will decrease performance.

When you write a plugin which uses advanced-cache.php, make sure you include code which writes the WP_CACHE constant to the wp-config.php file for the user, in case they don’t have enough experience manipulating files themselves.

Note: the value inside of WP_CACHE is not important, what is important is that the constant is defined. So in theory, you can use:

define('WP_CACHE', '');

But in practice, it is better to set the value to true instead:

define('WP_CACHE', true);

advanced-cache.php File

In theory, the advanced-cache.php file is useful if you wish to save the output of the WordPress pages through the use of wp_cache_postload() function. There are other purposes that can be handled through the wp_cache_postload() function, but that is up to you the plugin developer to decide.

This file is optional, only the next file is required to replace the internal WordPress Object Cache.

object-cache.php File

You are replacing a file that has definitions used by WordPress, so you must also define those functions in your file and handle the cache using whatever method that you will be using the same way that the internal WordPress cache does.

This means that when wp_cache_get() is called, if the cached object does not exist, then you return false. If it does exist, then you return the object. The same way with other replaced functions.

What you would put in this file is Memcache implementation, or file based caching, or some other custom solution. The full implementation should go in this file and there can only be one caching implementation used at a time.

January 30, 2008 Posted by | Writing Plugins Series | , , , | 1 Comment

wp-config.php Settings: Part 1

The wp-config.php file contains all of the major settings that WordPress will use during execution. There are differences between the settings in the wp-config.php file and those that are set in the database. The major difference is that you have to manually change the settings in the wp-config.php file and the ones in the database you don’t always have to manually change.

The wp-config.php requires user proficiency in FTP and editing PHP files to edit correctly. If you do not know what you are doing, then there are plenty of resources to teach you or you can get someone else to do it. The instructions on editing and adding settings will be basic and the file consists of mostly string and boolean values.

The article will be split into two sections, on this blog: settings that are set when WordPress is installed and settings which have to be manually added and changed by the user. These settings will be split up into multiple parts, the first one being the introduction and will be combined (excluding this paragraph), when all parts are finished.

Installation Settings

These settings you can set during the installation and not worry about them, unless you move your WordPress folder to a new host. WordPress will write these settings for you, so you don’t actually have to create the file, but if you do, then WordPress will use the settings during installation and during execution. You can find all of these settings in wp-config-sample.php file and can copy and rename to fill out the information, if you desire.

The settings covered in WordPress 2.5:

  • Database Settings
  • Base WordPress Folder
  • Locale
  • Database Table Prefix
  • Secret Key

Manual Settings

These settings are added by you, the user and will be used by WordPress in different areas, if they exist. You can mostly find these settings in wp-settings.php, but other files have other special hard coded settings that will be used. The areas covered are below.

  • Debugging
  • Plugin Directory
  • Memory Limit
  • Blog ID
  • Language Directory
  • Cookies
  • External Cache
  • List others when found

The behavior of the WordPress caching plugins has changed, as well as what the constants mean. More on the caching changes later.

January 29, 2008 Posted by | Advanced User Manual | , | Leave a comment

Writing Plugins: Including an Uninstaller

I think the central issue is that, plugin developers think writing an uninstaller is difficult, but it is not. I’ve been doing it for quite a while in my private WordPress plugins. It was quite easy. I think that the few plugins which do implement it, do so in a way that over complicates it for other novice users.

  1. Activation Step

    The core simple concept is to have an option that tells your plugin whether the plugin should be uninstalled or not. If you add options anyway, then this isn’t to difficult.

  2. Deactivation Step

    The second concept is to check that option during the deactivation and then if it is set to true, then you remove everything that you added in the activation step.

  3. Plugin Option Administration

    I think this is where novice plugin authors get tripped up and most other people. If you already have an options page, then it should be simple to add a checkbox that states whether the user wants to uninstall the plugin when it is deactivated.

    If you don’t have an options page, then let me walk you through that.

Activation Step

The code is pretty much uniform for all of my plugins and most plugins that I see.

function myplugin_activation()
    $option = get_option('myplugin_option');

    if( false === $option )
        // Install tables and setup options

        $option = array();
        $option['uninstall'] = false;
        // Other options
        add_option('myplugin_option', $option);

register_activation_hook(__FILE__, 'myplugin_activation');

And that implements the entire step for adding the uninstall option. Not to difficult, I don’t think. If you have any questions, then feel free to ask.

Deactivation Step

The deactivation step is as easy as the activation step (and I think the only difficult part is creating the administration page).

What you do is get the options and test to see if the options exist (should always exist, but you never know if the user deleted your options for you). Then you test to see if the uninstall option is true and remove everything.

function myplugin_deactivation()
    $options = get_option('myplugin_option');

    if( is_array($options) && $options['uninstall'] === true)
        // Remove other tables and installed items.

register_deactivation_hook(__FILE__, 'myplugin_deactivation');

That is it! Quite easy, I believe. The hard part is creating the administration page, until you get used to doing them.

Administration Page Alternative

You do have an alternative, if you don’t want to create an administration page. What I’ve done, was test to see if an constant is defined and if it is, I run the uninstall in the deactivation hook. This will require manual work on the user’s part, and instructions on your part. Quite frankly this is only useful for testing of your uninstaller, and for personal projects where you don’t really need an administration page. However, if you plan on placing your plugin in the open, it will be a good idea to use the other method.

function myplugin_deactivation()
    if( defined('UNINSTALL_MYPLUGIN') )
        // Remove other tables and installed items.

register_deactivation_hook(__FILE__, 'myplugin_deactivation');

Administration Step

The administration creation is not difficult, just time consuming. When you have it set up, it is fairly straight forward. I would also suggest that if you are just going to include the uninstaller option that you have your plugin page in the plugin page.

I’ll post the administration creation step in a later step. If you need more information then the WordPress codex has all that you need for creating administration pages.

January 24, 2008 Posted by | Writing Plugins Series | , , , | Leave a comment

Writing Plugins: Writing Maintainable Procedural Plugins

  1. Don’t use Globals.

    Okay, so WordPress uses globals and that is okay, so why can’t you use globals? If you know what you are doing then by all means, ignore this suggestion, because this does not apply to you. For all of the others, the suggestion to put logic in functions applies.

    If you place variables in main(), then they automatically become global to the execution process. If you don’t use naming convention practice, then your global variable could clash with another plugin.

    It is not that you shouldn’t use globals, with procedural programming, there is no way around using globals. However, declare and set the globals up in functions, instead of setting them at the top of the plugin execution path.

  2. Use naming conventions

    And whatever you do, don’t start your functions with “wp_”. Choose a function prefix that no one (that you know of) uses yet, which could be your company or your name (although, it just doesn’t seem right to start functions using human names, since author information is better located elsewhere), the plugin name, or something you just make up.

    As long as you use it throughout the plugin, call it whatever. Consistency is key, and with naming conventions and coding standards, no one can tell you that you are wrong, as long as you are consistent. Most developers do conform to the WordPress coding standards, but use whatever naming convention pleases you.

  3. Split duplicated logic into functions.

    Are you writing the same lines of code, over and over again? How about you split that chunk of code into its own function and call that function in different places. The goal is to only write code once and reuse it in many different locations.

    This also allows you to fix a bug in one location and not have to track where similar lines of code is located. It saves time, reduces the chances of defects, and increases the maintainability of the code. Also, since most of the time, when code is split it usually increases the ability of others to grasp the full purpose of one of your functions.

    For completeness, it will be pointed out, that by splitting logic into functions does increase the overhead (where opcode caching is not used), so it will decrease the performance of your plugin. Not by much, however, it is something to look at when optimizing and is a counter suggestion to this suggestion for optimization.

    However, the optimization arguments, that I’ve seen have not convinced me that the sacrifice of maintainability and clarity is worth a few milliseconds (if even that). If your plugin is hurting, it is most likely not, because you one or two large functions into four or five smaller ones.

  4. Keep the branches and functions to a minimum

    I’ve seen plugins where there were foreach loops within if statements within foreach loops within if statements. Besides optimization complaints, I would probably say that the function needs to be simplified somewhere, so that someone like me would even want to read it to understand what it was trying to do.

    There are metrics that will inform you of how difficult a function or method is, but any function more than 25 lines is pushing the barrier of complexity. The other index for branches, is a little bit more difficult to recommend. However, try not to have more than 5 branches or like the above example. Most of the time, something like that can be split into its own function and called, if only for the sake of sanity when reading through the function.

    By keeping the complexity of functions to a minimum you increase the chances of a user coming and finding an issue and making a modification that won’t break anything. You also increase the odds that you won’t create something so complex that even you don’t understand what is happening, “Yeah, it works, just don’t breath on it!” Statements like that, should be avoided, because something will break, and you won’t be able to fix it.

  5. Keep the base plugin file length short.

    Again, this recommendation is arguable, so you can choose to have all of your functions in one file or split them into multiple logically named files. It is up to you. The argument for why you should keep functions in a single file is for optimization and there is enough optimization evidence for having PHP functionality in one file. However, I believe in maintainability, and I don’t like scrolling up and down in one massive file.

    My recommendation is that when your plugin becomes large enough, that you split it into logical portions. Usually, what I will see for classes, is a block that checks for whether the class exists and if not then it will define the class. I think just having the class in its own file and using require_once() makes more sense. You gain nothing in optimization over require_once(), because opcode caching won’t cache the class until it knows it needs it and the if statement will prevent it from doing so.

    My base plugin usually only have the activation, deactivation, and init hooks and everything else is in other files. I also split my administration files into their own files separate from other plugin functionality.

  6. Have HTML, place them in their own template file.

    I admit I do place HTML into functions myself, as it is quick and easy method. I think placing HTML in functions is not hackish or dirty at all, since it is practically the same as placing them in its own file.

    Where I don’t do this, is for administration HTML, because it is much bigger than a snippet of HTML and requires other actions. You must protect your administration files, so test for ABSPATH before outputting HTML.

January 22, 2008 Posted by | Writing Plugins Series | , , , , , | Leave a comment

How to Patch the WordPress Core

This document will combine several external sources into one long informative document. Some of the contents will describe how to create a patch, how to create a Trac ticket, and finally what can be done to move the process along to get the patch into the core of WordPress.

Disclaimer: Some of the contents in this article are from the codex, since this blog is GPL also, no violations were made. Other contents are inspired by external sources, which are not GPL, but none of non-GPL contents were used to prevent plagiarism and so that GPL license could be applied to all of the contents in this article.

The Process

The process to get a patch into the core can be a long one. However, you do have to complete some steps and stay on top of the patch to ensure several objectives before it can be committed. Be aware however, that without a Trac ticket, there is no hope for your patch ever getting into the core. If the commit team does not know of your patch and does not have access to your patch and purpose, then they won’t apply it. Be sure to create a Trac ticket and upload the patch file. The WP-Hackers list is not for posting patches to, even if it is likely that a helpful person will probably create the ticket and add the patch for you.

Lets say you are using WordPress and something that you didn’t expect happens. You then check the forums and try to get help there first. After confirming that the issue is a bug in WordPress, you can decide two things. You can either file a Trac ticket, and after you can choose to provide a patch which fixes the issue. The last part is optional, but it would move the issue ahead of the queue to be in the next release if there is a patch for the ticket.

For the sake of this article, lets say you decide to provide a patch along with the ticket. The following can also apply, if you decide to provide a patch for an existing ticket with no patch.

  1. Checkout WordPress Trunk Repository.
  2. Make changes to the core.
  3. Save the changes to a file, in the form of a diff.
  4. Create the ticket (if it doesn’t exist already) and fill in the details.
  5. Upload the patch
  6. Stick around to keep on track of any comments, suggestions, and to keep the commit team interested.

Now that the process is available, lets go step by step through the each process in more detail.

1. Checkout the WordPress Repository

“Checkout” is a term to describe the process of downloading the contents of a repository. In this case, it is the WordPress repository and the “trunk” folder. In Windows, this is a very easy process, made possible by TortoiseSVN. Windows does not come with Subversion, like most Linux distributions do, so you will need to install TortoiseSVN manually.

You can download TortoiseSVN from the web site and after you download it. Click on the installation to install it. After you install it, it will ask you to restart. After you have restarted, you can begin using the functionality.

How TortoiseSVN works, is it adds a context menu to the right click. So if you right click on a folder, it will have new options. One of these options is “SVN Checkout”, but you should only do that in an empty folder that you created.

  1. Create a new folder, call it “WordPress”
  2. Right click on the folder name or if in the folder view, then right click in the window.
  3. In the menu, click on “SVN Checkout”
  4. When the box comes up, type in “”

That now describes the process of checking out the WordPress repository in Windows, using TortoiseSVN.

The has a section for downloading WordPress using Subversion. That page also describes how to create patches for WordPress using the command line.

2. Making Changes to the Core

You can use any editor to change the files in the repository. Subversion does not have or need any special editor, so you can use your favorite or Notepad.

When you make changes to the files in that folder that you used to checkout the WordPress repository, they will show up differently (on Windows). On Linux, you can use the command “svn status” to find which files you changed.

Unless you are a member with commit access, which is only a handful of people, you will not be able to commit the changes. Therefore, it will be futile to try to click on “SVN Commit” on Windows or type “svn commit” on Linux command line.

3. Creating a Patch File

Creating a patch file on Windows involves has two options. Either creating a patch for a single file, or creating a patch which includes more than one file. The steps are similar for both, but there are several differences when creating a patch for a few files.

  1. Single File

    1. Right clicking on a file.
    2. Hover over the “TortoiseSVN” menu text
    3. Click on “Create patch”
    4. Click “Ok” because there will only be one file and that is the file you right clicked on.
    5. Save the file using the file extension of either “.diff” or “.patch”
  2. Multiple Files

    1. Right click on the folder area, not on a file, in the folder where wp-settings is located.
    2. Hover over the “TortoiseSVN” menu text
    3. Click on “Create patch”
    4. Choose the changed files you want to be part of the patch.
    5. Click “Ok”
    6. Save the file using the file extension of either “.diff” or “.patch”

When saving patch files, save them with the file extension of either “.diff” or “.patch”, so that Trac and display the DIFF on the site. It helps with the ability to review the changes and it is difficult to read diff files to understand the context of the changes if you don’t.

4. Create a Trac Ticket

  1. Go to WordPress Trac site
  2. Log in or create a new account and then log in.
  3. Click on “New Ticket”
  4. Fill in a descriptive title which summarizes the defect or feature and will provide interest in the ticket.

    The title is what the community sees and how the figure out if the ticket is worth checking or not. If a bad or non-descriptive title is given, then it might be passed over as being uninteresting and hinder someone who might otherwise be interested from providing a patch sooner.

  5. Fill in as much details about the ticket defect or feature request as possible.

    The more details, the more chances of someone providing a patch that fixes the defect or can create a patch for a feature request. For defects, have as much system information as needed (no passwords) and for features, describe the purpose as well as the feature details. The more details, the better off and the sooner the ticket might have a resolution.

  6. Choose the correct component, version (if defect), and do not set the milestone (unless you are going to immediately provide the patch).

5. Uploading the Patch

In the Trac ticket page, click on “Attach File” and upload the patch. After adding the patch, add “has-patch” to the keyword field and save the keyword.

6. Keeping on Top of the Patch

Your patch will not get into the core of WordPress until someone with commit access adds it. This can take anywhere from a couple of hours to a few weeks to a few months or in the worse case, never. It can be disheartening to create a patch, spending all of that time and then never have your patch committed. There are several reasons for this, so don’t get mad yet.

  1. Commit team might have higher priorities to complete first.

    The commit team has several priorities and areas they are interested in first. They should also be given enough time to review the patch, review the ticket, and whether the severity warrants the resolution of the defect or feature. It might be that a member of the commit team is taking the time to clean up the patch code, so that it is up to WordPress standards.

  2. Defect or feature does not provide enough rationale or interest from the commit team.

    There have been several times, when developers just aren’t interested or know enough of the problem to realize whether the patch provides the best solution. If that is the case, then provide explanations and rationale for why the patch should be committed. Keep on top of the issue, whether it is a defect or feature, because sometimes the commit team forgets that there is a patch and what the issue is. They might have been wanting to commit the patch, but it left their minds as other issues more important were bought up before they could.

  3. Clearly define, explain and demonstrate your problem or feature request.

    The more details the commit team has on the defect or feature, the better they can decide whether the patch (if any) is worthy of inclusion in the core or some extraneous problem that can be solved using a plugin. Do not be mad, if the commit or community members state that the solution could be better solved using a plugin. Also provide further rationale and explanations that might be needed to provide reasoning to why the patch should be included.

    If the solution adds extra configuration options, then you can pretty much count on your patch never being committed. The WordPress commit team does not like patches and solutions which add extra options. Any patch would need to make due without them. A solution would to use apply_filters() to pull in options, that would allow for plugins to be made instead of adding additional options to in the administration.

  4. Carefully consider, and take into account advice and feedback given on trac.

    Be aware, that if your patch is not committed in a reasonable amount of time for a defect, that it might be that you didn’t provide the best solution for the problem. If that is the case, then take in account the suggestions made by the community and commit team alike. If you disagree with the community members, then explain why your method is better and debate the issue. The WordPress community wants to have the best and better solution in the core, and not something they don’t agree with. Debating the point might also provide the rationale for the commit team to bring your patch into the core.

    There are quite a few veterans in the WordPress community that have some pull (karma, if you will), so their opinion/reasoning might trump yours. Use the recommendation that every suggestion should be considered, no matter who the person is that is making the suggestion. The goal is to have the best solution, so work with the community and commit team, so that the best solution can be bought into the core.

  5. Write easily understandable, documented code.

    The requirement standards for new functions inclusion into the core has been increased. New functions MUST be documented using the Inline Documentation standards. Not having that documentation may hinder the inclusion depending on the severity of the defect. For features, document the code, even if you are unsure that it will be included into the core. That way, the patch won’t be rejected, even if the commit member wants to include it.

    Follow the WordPress coding standards as much as possible to get the code included in to the core. You might want to profile the code to make sure that it doesn’t create any unwarranted bottlenecks in the code. Simple is better, try not to create complex code where simplified code would work. It is difficult to give an example, but most people will know it when they see it.

  6. Consider writing a plugin instead.

    There are moments, when the only way to prove whether or not a feature request should be added to the core, is by proving that enough people want to have the feature. If it is possible to make a plugin, then the suggestion will be that you make one. If enough people use the plugin, then you can come back with the proof to have the feature added. If the feature is not possible without modification of core files, then create a patch which allows for your plugin to work that implements the rest of the functionality.

  7. Appropriate tags in Trac help attract attention.

    After you add a patch, add the keyword “has-patch” in the keyword field of the Trac ticket. This will tell developers and the WordPress community that the ticket is ready to be reviewed for possible inclusion into the core.

    If enough time has past and you are wanting to know why the patch still hasn’t been committed, then add “dev-feedback” to the keyword field (remember, commas are not used to separate keywords, spaces are).


  1. “How does code make it into WordPress.” WordPress codex.

January 21, 2008 Posted by | Quality Assurance Series | , , | 2 Comments

Writing Plugins: Directory Structure

If you plugin is fairly simple and small, you can contain your plugin in one file and have translations in the same directory. However, if you ever plan to extend your plugin and create more complex and feature complete, then you’ll want to rethink the single file method.

The only reason you would not use this method, is if you have optimization in mind and include all the library code in one file to prevent file access overhead. However, in most instances, if your library is massive, it is probably better to have the files separated for maintainability.

Separate Translated Files (.mo) Directory

It would serve your plugin better, if translated files were in their own directory, that way, when you setup the plugin textdomain, you can reference that one directory for WordPress to look into. Also, it would allow for easy management and cleaner plugin root structure.

Third Party or External Library Directory

For third party libraries that are used, it is better to place them all in another folder and could call it third-party/. This will create a separate from your plugin’s code and code that is external from your code. When people go to file bug reports you don’t want them to file bug reports with you that they should be filing with the respective library maintainer.

Using that name will give a hint that the files are not maintained by you and should have the defects filed elsewhere. It may not stop everyone from reporting the defects to you, but if you keep notes, it should be more informative to most WordPress power users.

Library Directory

The idea is to have at most two files in the root, a readme and your base plugin file. The readme to inform users on how to use your plugin, how to uninstall your plugin, and other information about your plugin. Your base plugin file has the WordPress required comment with your plugin data, so that WordPress knows about your plugin and can activate it. The base file will set up all of the plugin variables and include the required files.

The rest of your library will be contained in a folder in your plugin’s directory. You can use one file for optimization or for maintainability, separate the functionality out into logically named files.

Public CSS/JavaScript Directory(-ies)

If you plugin also has public CSS and JavaScript files, it is better to have them in their own directory. It allows for quick access to all of the individual files for CSS and JavaScript. It creates a separation, so that users know where to look for your CSS and JavaScript. Another advantage is for permissions, but those might need to be set by the user.


The idea is to create a separation of content, so that your plugin is more maintainable for both yourself and others. It is a suggestion and developers have their own style. I have no complaints other than you should be consistent. That is not to say that if you have one plugin with directories like the above that all of your plugins should be that way. No, it is to say that if you use directories for one thing, then you should split all of your content into directories.

January 20, 2008 Posted by | Writing Plugins Series | Leave a comment

The Automated Testing Methods

There are quite a few testing techniques and ways to implement test cases for an automated test system. A few that should be implemented for WordPress are listed, but there are others and with better details on other web sites. I’m not the authority on unit testing and I don’t pretend to be. However, what I do know is detailed below and take my word with a grain of salt. I will say that the details are in general what can be applied when coding test cases.

  1. Unit Testing

    Unit testing is quite what it says, you are testing a single unit or component of the library. This can be function or method. This method usually makes use of mock objects for classes to correctly test the behavior of an individual unit.

    This method has the advantage of allowing for testing code coverage and finding out just how accurate your tests are.

  2. Regression Testing

    I would argue that this is the easiest of the methods, since all you are doing is checking the current behavior and writing tests to make sure that the current behavior continues in later versions.

    You’re not actually getting down into the source code and making sure that all of the branches are covered and that the correct results are covered. You are also not always checking that incorrect data has a fallback in place to prevent failures.

  3. Functional Testing

    Functional Testing is a step up from unit testing, where you are testing a component within the software environment. This is more how the Automattic Automated Testing suite is set up. It does not allow you to test the code coverage, because since the entire software environment is running it will skew the code coverage results.

    The primary difference between unit testing and functional testing is that with unit testing, every test in unit testing is self contained and does not interfere with the other tests. With functional tests, you have to be careful, because the tests are not contained and will affect other areas. Other than that, it would be easy to switch from unit testing to functional testing and back again.

  4. Acceptance Testing

    Users do this already, but this method is more about automating the process of what users do. It doesn’t completely replace user testing, but it does complement it. It reduces the tedious tasks of inserting content and does that and returns the results. For known problems, it is very useful in order to prevent presentational regressions.

    It is also quite frankly, in my humble opinion, one of the most difficult to accomplish for browser based acceptance testing. Selenium is very helpful, but setting that up has been difficult for me. If you can get it set up then PHPUnit can talk to it and it would be as easy as writing any unit or functional test.

January 19, 2008 Posted by | Quality Assurance Series | , , , , | 2 Comments

Protected: Talk Draft

This content is password protected. To view it please enter your password below:

January 18, 2008 Posted by | WordPress | Enter your password to view comments.

What is Quality Assurance?

Quality Assurance is ensuring the quality of a product. It is an ongoing process that never ends, or at least not during the life of the product. Quality Assurance in open source is a more open process and anyone can help.

It involves testing, documentation, and automated testing. Testing is the most important factor, but documentation is equally important. Actually, Software Quality Assurance is a paradigm that involves a great deal more, but for the purpose of this discussion, I’m going to limit this to just the above three.

What it means to the User

When you commit to Software Quality Assurance, you are telling the customer and user that you have a policy in place that will hopefully prevent a majority of preventable bugs from occurring before the product is released. In the likely event that a bug is found, there is a policy in place that ensures that it will be fixed and prevented (in most cases) from occurring again in the future.

It also says that there is detailed documentation for both the users and developers which extensively covers the topics that both groups will want to know. Extensively covers the known areas and areas that have been questioned about in previous versions. Covers the more difficult areas better and with more details than “simpler” topics that users and developers should not have any problems with.

Solving Issues

Users, testers, and developers all help with the process. The user can make a request for a new feature that will improve the product or report a problem in the product. The testers will usually beta test and test versions of the product before it is released reporting any issues that come up. Developers will take the reports and create patches that fix the issues for the next version.

Developers will also write test cases that check whether the problem is fixed and if the problem reoccurs in a later version. If the problem does reoccur then the problem is immediately known and can be rechecked until the regression is corrected. If the regression was intentional, then documentation would have to be updated and other developers updated on the change.

Writing Documentation

Writing documentation should be concise, tutorial type explanations in language that an user and/or a developer will understand. For open source, I would just recommend writing something as close as possible to this style as you can get and cut the extraneous details (ex, I don’t want to know about how you used it in your project and the history, unless it further explains the purpose of the function, sometimes it is useful, other times it is not).

Not everyone is a professional writer (myself included), but there are enough people who are that if you give them enough information, they can edit it to where it is better. I write with the assumption that someone is going to look at what I wrote and point out mistakes and hopefully, instead of cussing me, will actually move to fix the mistakes. On Wikis, this is very simple process, on this post however, they would have to send it to be me personally or export it to their blog or wiki.

Testing Software

You are testing that the software works (well, yes you are for those who are disagreeable), you are trying to test whether the software breaks. Therefore it makes more sense to input invalid data to see if what is expected happens or not. Developers (indeterminate amount, I have this problem, so I only speak of myself and the general stereotype of developers with testing their software) have a habit of only using valid data.

You only know that the software works if you enter something invalid and it didn’t break on that input. If it breaks on invalid input, then there should be a check in place that either automatically the problem or informs the user of their mistake. There is also automated testing, which automates the lower level testing and higher level testing which automates some of what users do.

January 18, 2008 Posted by | Quality Assurance Series | , , | Leave a comment