phpBB

Development Wiki

Difference between revisions of "Developing Extensions"

From phpBB Development Wiki

(Front-facing Files)
(Front-facing Files)
Line 23: Line 23:
 
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.
 
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.
  
=== Routing ===
+
For more information about creating and using a controller for your extension, view the [[Controller]] wiki page.
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:
+
 
+
<php>
+
blog_front:
+
    pattern: blog
+
    defaults: { _controller: blog_service:controller_method }
+
</php>
+
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.
+
 
+
<php>
+
blog_view:
+
    pattern: blog/{id}
+
    defaults: { _controller: blog_service:view_article, id: 0 }
+
    requirements:
+
        id: \d+
+
</php>
+
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.
+
 
+
=== Invoking ===
+
 
+
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 <pre>www.domain.com/app.php?controller=foo/bar/baz</pre>. The goal for future versions is to shorten that to <pre>www.domain.com/app.php/foo/bar/baz</pre> and even <pre>www.domain.com/foo/bar/baz</pre>
+
 
+
[[Category:Extensions]]
+

Revision as of 17:51, 7 January 2013

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: https://github.com/naderman/phpbb3-example-ext

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.

composer.json

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.

ext.php

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.

For more information about creating and using a controller for your extension, view the Controller wiki page.