What is the MOD Team? Well first you must know what a MOD, or MODification is — modifying the code of phpBB to add a new feature that doesn’t come with phpBB.
The MOD Team validates the code of MODs submitted to the Customizations Database, to make sure that it’s clean, secure, and functions as advertised.
This presentation is about how the team operates, what tools are available, and how you can get involved.
Paul & Derk to present on the Validation Process:
How you can get your MOD improved…
* Follow the phpBB Coding Guidelines
* Test the MOD to make sure it functions, and with the MOD Pre-Validator and AutoMOD
* Ask the community for feedback and to help test (in the MODs in Development forum)
The MOD Team runs a MOD pre-validation script, which checks for common errors using the MOD Pre-Validator and AutoMOD.
The actual code validation looks through the code of the MOD line-by-line, making sure that the MOD fits the description and the license is compatible with the GPL. The coding guidelines are checked, as is possible security issues (SQL injections, XSS, etc.), and ensuring that the MOD satisfies the MOD Database guidelines. The team also gives suggestions to MOD authors on how they can optimize their code, and follow proper English spelling.
Testing is done by Junior MOD validators (which allows the full team members to be able to do the line-by-line validation on more MODs). This process includes installing with AutoMOD and ensuring that the MOD works as advertised and avoids conflicts with other MODs.
There are a few options for when the MOD is validated: approve it, deny it, insta-deny it (if pre-validation failed), or repack it (if there are only minor issues that need to be fixed). “Anything larger than something small is deny-worthy.” Insta-denying is not automatic, it’s a case-by-case decision
Advantages of using the MOD Database: You get a free security audit of your code, plus phpBB.com is hosting your MOD downloads, Screenshots, FAQ, and Support forum. It’s also the best way to get exposure for your MOD to the phpBB community.
Sam and Igor present on MOD Team Tools:
MODX is a MOD packaging format, originally based on the phpBB2-era text template. The XML-based file contains all of the code and instructions for modifying phpBB. It’s a pain to write by hand, because it’s a machine-readable format, but there are a number of tools for generating it. (Also, MODX 2.0 is coming soon…)
Modxed by APTX is written in C++, plus tumba25 has a Web-Based Creator which is a GUI for creating MODs. These are both creation tools.
There are also generators which create MODX files from a diff between a vanilla phpBB and a modified phpBB. AcydBurn has a MODX Changes Generator, eviL<3 has a Mod_diff tool, nadverman has a Token based version, and tumba25 has a MODX Generator which also supports in-lines and dynamic context.
Another tool is the Unified MOD Install Library (UMIL) which provides abstraction for database changes — 1.0 largely written by EXreaction and Highway of Life. AutoMOD uses it for installation, and it is used and well-accepted within the MODding community. UMIL will be included with phpBB 3.1 (tentative), and UMIL 2.0 is in development. Still accepting ideas for the new version; there’s no ETA for release yet.
phpBB QuickInstall is a tool written by eviL<3 and is now maintained by tumba25. It allows for a quick one-click installation of phpBB3 (for testing purposes), and lets you manage multiple boards, each with its own codeset. phpBB QuickInstall is available in phpBB2 and phpBB3 versions, and also installs AutoMOD by default.
The MOD Pre-Validator (MPV) was written by the MOD Team (smithy_dll, Vic D’Elfant, Paul, eviL<3, and DavidIQ), which originated from an old C# tool called EAL. It provides a static analysis of the MOD files to provide hints on what could be improved. MPV was open-sourced a year and a half ago, plus there’s a hosted version on phpBB.com. Titania (being discussed later today) performs an MPV check automatically.
So how do these tools work together? First you can set up a phpBB QuickInstall, where you can then apply your changes to the phpBB codebase. Then use the MODX Generator to create a diff that you can add to the MODX Creator to add metadata, then use UMIL to prepare the necessary database changes, and finally use AutoMOD to test your MOD to make sure it works properly.
Sam present on Getting Involved, substituting for Jeremy:
The MOD Team exists because of phpBB’s strong MODding community. So how can new users get involved, what can more experienced users do?
Community mainly hangs out in the 3.0.x Modifications Forums, often providing help for each other on developers. New users can get involved by helping users out in the forums, or by posting new MODs in the MODs in Development forum. If you’re a more experienced user, apply to become a Junior Validator. (This is a great path to get on-track to becoming a full MOD Team member.) Simple application to apply for Junior Validator time.
Making your own MOD is much easier thanks to the new Customization Database (more later today) — submit your MOD and hope it gets validated!
Contribute to the Wiki and the MOD Writers Library. (Note: The wiki will be moving back to MediaWiki due to popular demand.)
Finally, help spread the word about the MODding community! Tell people that you write MODs for phpBB.
Want to try something new? Start writing Bridges between phpBB and other platforms — a new section of the Customization Database. (Breaking News: Cullen Walsh (ckwalsh) will be releasing a pre-release version of his Drupal-phpBB bridge later today!)
The phpBB MOD Database has existed since 2001. When phpBB 2.0.0 was release, “hacks” were renamed MODs and were directly integrated into the main phpBB website.
The phpBB3 code-base looks like a bunch of spaghetti code. (Showing a picture of spaghetti on the screen.)
phpBB 3.0 introduced modules (plug-and-play), but were limited to adding pages to the control panels, and is not well understood. There are also plugins, which work for the search, CAPTCHA, auth, and cache. However, the functionality of these varies, there are different non-uniform APIs, and it’s not well adopted. And there are also hooks which alter phpBB’s behavior, but these are mainly intended for wrapping phpBB within other applications. They are rather limited, and by-and-large have not been adopted. Instead, we are using MODs, which are glorified patchfiles, but have excellent adoption.
MODs aren’t necessarily bad. They provide unlimited expressive power, are simple to understand, have a shallow learning curve, have been adopted very well, are a well-documented format, offer good performance, and benefit from MOD Team audits. However, there is a non-uniform codebase, creating difficulties with maintenance, it impedes updating phpBB, can cause conflicts and side-effects, and are difficult to install, among other issues. (Yet another picture of spaghetti on the screen.)
phpBB 3.1 introduces hooks into the system, meaning that the phpBB code will call and run all functions hooked into particular places of execution in the code
In order to do this, the old hook system is going to have to be rewritten. “Hooks have to be fun.” They need to be able to resolve conflicts (within limits), allow for easy placement, and make it easier to implement hooks.
phpBB 3.1 will have “automagic” hooks, using PHP OOP methods. Examples of the under-the-hood code that enables these to work being shown.
Flavors: Injection, Validation, Callback registration, Event, System, Altering, Cron, and many others.
phpBB needs ideas of where to place hooks, help with the MOD installer in hooks, community support for this implementation, and lots of testing of these hooks.
Thanks that won’t happen in phpBB 3.1: Forms not built by any form API, nor will there be pretty URLs (URL rewriting).
Douglas comments that hooks are a big step for making more pluggable MODs, and it’s the main reason why WordPress Plugins are as successful and as plentiful as they are. However, in order for the hooks system to be successful, MOD authors really need to share feedback on where hooks should be added within the phpBB 3.1 core.
Stefan asks about why phpBB isn’t deciding to adopt Symfony’s hooking system within 3.1 to help reduce the spaghetti code and make future transition easier: the main issue is that phpBB 3.1 still needs to support PHP 5.2.x.