phpBB • Free and Open Source Forum Software

This article was written primarily for MOD writers interested in ways to optimise testing. Everyone has their own style of testing which works for them, and this is only one such style.

A good way to test MODs is by using a local setup. A local setup is an installation on your own computer or network, as opposed to a remote setup which would typically be your website (as it is hosted by another company in a “remote” location). This means that less time is spent uploading and downloading through FTP as any changes you make take effect almost instantly. An added benefit is you can continue developing and testing your modifications when you are without an internet connection.

There are many types of software which will allow you to create a local setup, such as XAMPP and EasyPHP. What these programs do is install PHP, a database like MySQL and Apache in their own sandbox which only runs when you start the program. For the purposes of this article, I will look at EasyPHP.

Installation instructions can be found at http://www.easyphp.org. Once EasyPHP is installed, in Windows Explorer navigate to the local web server directory. In the case of EasyPHP v2.0b (and depending on how you configured the software during installation) then it might be C:\Program Files\EasyPHP 2.0b1\www

Now that EasyPHP is set up, a quick way to install phpBB3 is to use phpBB QuickInstall (by tumba25 and evil<3). Of course, you can simply install phpBB3 as you would normally – but for the purposes of testing MODs by using QuickInstall there is the added flexibility of being able to install multiple boards very quickly (such as if you wanted to have a separate test board for multiple MODs).

QuickInstall is very easy to use, simply download it from http://www.phpbb.com/mods/quickinstall/ and extract the zip file. Create a new directory in the EasyPHP local web space (www) called quickinstall and copy all of the extracted files into this directory. Then in your web browser, go to http://127.0.0.1/quickinstall/index.php – you should see a page like this:

Once you have filled in the forms and pressed submit, QuickInstall is configured and ready to use. This means you can now create test boards. To do this, go to the Main Page tab and fill out the options in the forms provided. When you get to the setting where it asks to install AutoMOD, make sure you select “Yes”.

It will take a few minutes to install and copy the files across to the new directory (in this case “test”).

Once this is has happened, the browser will automatically redirect you to the newly installed phpBB3.

Once this is done, if you have already written (or partially written) a MOD then you can install it on the test board. Installing your MOD is a simple matter of navigating to the Administration Control Panel (ACP) and clicking the AutoMOD tab. From here, providing your MOD is in the correct MODX format and can be read by AutoMOD, the MOD will be installed very quickly.

If the MOD installs correctly, you will see a message like this:

Now your MOD has been installed. If you have yet to start writing your MOD then you can edit the files directly, as mentioned above this is a huge time saver. In this example, the test board is located in C:\Program Files\EasyPHP 2.0b1\www\quickinstall\boards\test – so the files that require editing can all be found in that test directory.

Note: if you ever want to delete a directory this can be done very easily by navigating to the “Manage Boards” tab of QuickInstall and selecting the board, and clicking delete. There is no confirmation message, so be sure that you want to delete it before proceeding.

There are some other useful tips to bear in mind when running a test board.

The easiest way to check the performance of the script (the MOD) is to enable DEBUG and DEBUG_EXTRA in config.php.

@define(‘DEBUG’, true);
@define(‘DEBUG_EXTRA’, true);

QuickInstall enables this by default. To turn this off is as simple as commenting those lines out.

The purpose of DEBUG is to show page load and simple query information in the page footer:

DEBUG_EXTRA is very similar (and only works if DEBUG is enabled), except it shows the explain link:

Clicking the explain link leads to the SQL report page, which lists database query information:

It is worth noting that DEBUG and DEBUG_EXTRA can be used on individual pages. If you don’t want that footer information appearing everywhere, then you can comment out those two lines in config.php but include them at the top of the PHP file for any individual page. For instance, if the lines were commented out of config.php but included under the <?php line of index.php – then the debug information would appear only on the index page.

Another useful benefit of enabling DEBUG is to see PHP notices. For instance, suppose I included the line echo $dog[6]; at the top of index.php. If DEBUG is disabled then the script will run error-free, despite that variable never being defined.

With DEBUG enabled, the PHP notice will be shown. This is important because it does reduce the amount of mistakes and potential bugs in code. (Note: the PHP notices can be shown with DEBUG disabled if you include error_reporting(E_ALL | E_NOTICE); in the file. This is handy if you want to see the notices, but for whatever reason do not want the additions to the page footer).

When dealing with cached database queries, during testing you might want to clear the cache (or at least clear any cached queries relevant to your MOD). You may or may not want to remove this code once testing is complete, depending on the MOD. By including the line $cache->destroy(‘sql’, MOD_TABLE); you can remove any cached queries relating to the specified table (you would change MOD_TABLE to the constant of whichever table you want to clear the cache for).

When making changes to the template, it is very annoying to have to Purge Cache after each change. Fortunately this can be made a lot easier, by going to the Server configuration -> Load settings page in the ACP and setting “Recompile stale style components” to Yes.

Remember to exercise caution when editing templates though. It is always better to edit the html files directly instead of editing the templates from within the ACP. Edits from within the ACP are stored in the database, they don’t physically change the file. Therefore if you have made edits in the ACP to a given file, then if you edit that file directly in the future the changes you made within the ACP will be lost.

I hope this article has been of some help. If you already enjoy writing MODs, now you can enjoy testing them as well!