Development Wiki

Developing Extensions

From phpBB Development Wiki

Revision as of 16:56, 7 January 2013 by Imkingdavid (Talk | contribs)

phpBB 3.1 "Ascraeus" introduces extensions as another way to add new community-contributed features into a phpBB installation. Extensions are different from MODs in that they do not make any file modifications to the core phpBB files. Instead, extensions are entirely contained in their own directories within the ./ext/ directory in the phpBB root.

Getting Started

For an example extension package, please view the following repository:

Extensions should be located in the phpBB directory as follows: phpBB/ext/<vendor>/<ext>

<vendor> is the author or group of authors of the extension. Note that vendor and extension directory names may ONLY contain numbers and letters. Underscores, dashes, and other characters are NOT permitted. It is perfectly fine to have an extension named iamanextension.


This file is the metadata file containing specific information about your extension. For information on what information goes into the file, please view extension_meta_data.


Each extension should have a file called ext.php at phpBB/ext/<vendor>/<ext>/ext.php. Here is an example file from an example extesnion phpBB/ext/example/foobar/ext.php:

class phpbb_ext_example_foobar_ext extends phpbb_extension_base

The class is required in order for phpBB to identify your extension as an extension. It also may contain any special (un)installation commands in the methods enable_step(), disable_step() and purge_step(). As it is, these methods are defined in phpbb_extension_base, which this class extends, but you can overwrite them to give special instructions for those cases.

Front-facing Files

While, some extensions perform only background tasks or simply modify a pre-existent page, other extensions may require the inclusion of a front-facing file, which the user is able to access to view information and perform tasks related to the extension. For example, a blog extension needs to display one or more blog entries. To achieve this, we use classes, which are called "controllers". All controllers are mapped with their own routes in the config/routing.yml file. There is one in the main phpBB config directory, but extensions wishing to include a controller must have their own config directory and routing.yml file.


The first step in creating your front-facing pages is to decide what routes you will need. For instance, a blog extension might want the route /blog for its main page, and /blog/{id} for viewing an individual blog article. The route definition is contained in your extension's routing.yml file, in the config directory. The .yml extension signifies that the file uses the YAML (Yet Another Markup Language) syntax. A routing.yml file containing a single route definition might look like this:

: { _controllerblog_service:controller_method }

What that says is that a route named "blog_front" will match the pattern "blog" in the URL. When that URL is matched, the method "controller_method", which is a method of the class defined by the service "blog_service", is run (@todo: link to services documentation). This method must return a Response object. (@todo: explain more about this, including use of the helper class.)

You can also specify that you want to ask for a blog ID so that the user can view a specific blog.

defaults: { _controllerblog_service:view_articleid}
id: \d+

The {id} in the pattern is called a "slug". The value directly following "blog/" in the URL will be placed into a variable called $id and passed to the controller method. As such, your controller method MUST have a parameter called $id. The "id: \d+" line is a match requirement. \d+ is regex for "one or more numbers". Because that requirement is in place, "blog/foo" and "blog/number1" would not match the pattern, but "blog/1" and "blog/10003423423490" would. Note that the "id: 0" bit in the defaults simply states that if no value is given for id (i.e. the route is "blog"), 0 is passed as the default value to the controller parameter $id.

The Controller

The controller itself is simply a method that returns a Response object. The way things are set up in phpBB, the method must be tied to a class that is defined as a service. The method must contain at least as many parameters as there are slugs route pattern. In other words, if the route pattern is "blog/{id}", the method must at least contain an $id parameter. The method may not contain any more required parameters than there are slugs in the URL. In other words, if your method signature requires a parameter $foo without providing a default value, and neither a slug nor a default are given by the route, an error will be thrown. The only exception is when a parameter type hints "Symfony\HttpFoundation\Request". In this case, the Symfony Request object will be automatically injected into the method by the controller framework. Note that the Symfony Request object is separate from the phpbb_request object. It is recommended that you only use the Symfony Request object if you absolutely need to.

Accessing Common phpBB Variables

Because controllers are methods within a service, they can gain access to the commonly used phpBB objects (such as phpbb_template, phpbb_user, phpbb_db_driver, etc.) by specifying them in the service definition and then assigning them to class properties. Then, instead of using a locally scoped $db variable, you would instead use something like $this->db to access the database object.


Currently, all routing passes through the "app.php" file. For example, a route with the pattern "foo/bar/baz" would be accessed by the URL
. The goal for future versions is to shorten that to
and even