phpBB Weekly Blog/Episodes

  • Filter By Category:

  • Filter By Month/Year:

    Or, For Further Browsing...


    [Libertyvasion] phpBB “Ascraeus” 3.1: News for MOD Authors

    Session: phpBB “Ascraeus” 3.1: News for MOD Authors by Henry Sudhof
    Date/Time: Saturday 8/21 at 1:30-2:10 PM

    This post contains my rough crib-notes from this presentation at Libertyvasion 2010. The post has not been proof-read for spelling, grammar, or accuracy.

    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.

    Written by Douglas Bell in: Libertyvasion 2010 |

    [Libertyvasion] MODding phpBB

    Session: MODding phpBB by David Colón, Igor Wiedler and MOD Team Members
    Date/Time: Saturday 8/21 at 10:20-11:00 AM

    This post contains my rough crib-notes from this presentation at Libertyvasion 2010. The post has not been proof-read for spelling, grammar, or accuracy.

    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 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 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.

    Summer of MODs
    Winners are Precise Similar Topics II by VSE and Thanks for posts (rating edition) (WordPress can’t display the username of the author).

    Special Announcements
    Rich McGirr (RMcGirr83), a long-time Junior Validator, was surprised with the announcement that he has been promoted to a full member of the MOD Team.

    Written by Douglas Bell in: Libertyvasion 2010 |

    [Libertyvasion] phpBB Development Update & Roadmap

    Session: phpBB Development Update & Roadmap by Nils Adermann and Chris Smith
    Date/Time: Saturday 8/21 at 9:30-10:10 AM

    This post contains my rough crib-notes from this presentation at Libertyvasion 2010. The post has not been proof-read for spelling, grammar, or accuracy.

    Nils to talk about how phpBB development has changed over the past two years, and why these changes have been made.

    In the past, phpBB development was a top-down process, decided by a few people with no outside input. This worked well in the beginning of phpBB when it was smaller, but as the project grew, it outgrew its development process. This caused development to dramatically slow down. Dev Team is now trying to encourage a more open, more democratic process, and get more people involved in development. While not everyone will want to join, Dev Team wants everyone to be represented in the dev process.

    Steps that have been taken:
    * Introducing Git (using GitHub) as version control for phpBB
    * Area51 discussion forums now allow for more discussion of new features, the Request for Comments (RFC) process
    * New bug tracker
    * Bamboo = continuous integration platform (going to be using a lot more in the future)

    Walking Through the Development Process
    1) Someone (a user, MOD author, etc.) has an idea for a change or improvement or new feature
    2) File a ticket on the tracker, which puts it on the radar for development (new tracker is an improvement for the Development Team, easier for them to better manage a larger number of tickets — Dev Team is going to try to improve it for the users side)
    3) RFCs for discussion of these features — this is new to phpBB, process is still being worked out (i.e. the subsilver2 debacle)
    By the way, subsilver2 will still be maintained going forward with a provided upgrade path, but will not be bundled with phpBB 3.1 anymore and will only be downloadable from the Styles DB.
    The goal for RFCs is to reach a consensus for general acceptance of the change.
    4) Patches — While RFCs are for bigger changes, all changes will need to have a patch. Patches can be written by anyone. Anyone can help implement new ideas in phpBB, which is great if Dev Team members don’t want to take time to implement a feature, but a member of the community wants to see it happen.
    Even if the Dev Team members don’t think a feature is important, if the feature does well in the RFC process and a patch is submitted (and works), it will go into the phpBB software.
    5) Merging — This is done by the Development Team, where patches & feature branches are merged into release branches. Using Git helps the Dev Team better manage this model of development.
    6) Releasing — The Dev Team now uses feature freezes to expedite the development process.

    This means that there will be more frequent releases, though they will have fewer features. However hopefully this will end the process of having many years between 3.x releases. The reason it’s been nearly three years since 3.0.0 is because the teams started to fall into the “practically rewriting the entire thing” trap that caught them during the 3.0 development process — last year they decided to scrap that completely and start over with a more realistic goal.

    What’s Coming in 3.1 Ascraeus for Developers
    Chris Smith presents this part.
    * New Coding Guidelines! Classes will be phpbb_ prefixed. Not using eval() anywhere, which will not be permitted by MOD authors. Using newlines at the end of files. Bye bye closing ?&rt; PHP tag, which is not needed in straight-up PHP files.
    * Hooks (to be described later today)
    * New BBCode Engine, stack-based as opposed to a series of regular expressions. All core BBCodes will also be custom BBCodes.
    * New Template Engine, implemented as a PHP string filter, dramatically improving memory consumption when compiling template files. Provides a nice performance improvement.
    * Request Class which replaces the request_var() function. Use to retrieve the $_POST $_GET $_COOKIE superglobal values, since the superglobals themselves will be overwritten. Also compatibility for bridges & wrapping phpBB.
    * Modular Cron allows the cron processes to be extendable by MOD authors. At the moment this is entirely community-developed, no developer has written code for this so far.

    What’s Coming for phpBB Administrators
    * Now supports SQLite 3 (thanks to dropping PHP4 support)
    * Integrating AutoMOD directly into the core (more on that later today)
    * Improved Team page (list of administrators & moderators), whereas this is static in 3.0.x, it will be admin-configurable in 3.1
    * User Pruning — big improvement for pruning out lots of users, i.e. spambots

    Coming for phpBB End-Users
    * Gravatar support built-in (which is great for reducing avatar load on the admin’s server)
    * Soft Delete, so that simply clicking Delete (by a moderator) will preserve posts in a hidden trash can
    * Full timezone support (using PHP datetime functions), including automatic Daylight Savings Time transition
    * Resume downloads of attachments (saving bandwidth for everyone)

    This list is non-exhaustive, Nils recently blogged a more complete list of features coming in 3.1.

    Written by Douglas Bell in: Libertyvasion 2010 |

    [Libertyvasion] Building phpBB4 on Symfony 2

    Session: Building phpBB4 on Symfony 2 by Fabien Potencier
    Date/Time: Saturday 8/21 at 11:10 AM-12:10 PM

    This post contains my rough crib-notes from this presentation at Libertyvasion 2010. The post has not been proof-read for spelling, grammar, or accuracy.

    This presentation will be similar to yesterday’s presentation about Symfony 2, but not as much specific code demos. First, a quick look at Symfony 1 vs. Symfony 2.

    Symfony’s goal is to allow developers to make better applications faster, and has been designed to be the best possible platform to create end-user websites and applications such as phpBB. Symfony uses an MVC (model-view-controller) framework. Symfony has a concept of a “slot” to defined content areas within the layout of your application. PHP can be used for templates, or an end-user templating engine can be used.
    The Routing system in Symfony allows a single PHP file under the front-facing directory to be the front-controller, which provides for a much more user-friendly output of content. Showing an example of URL rewriting with this architecture.
    Configuration in Symfony can be done using YAML, XML, or plain PHP formats.
    The routing system means that templates never have to generate a URL, simply use the built-in routing methods to handle this process.

    Bundles provides flexibility for the routing system — act somewhat like plugins, but Symfony bundles are treated like “first-class citizens.” Everything in Symfony is constructed as a bundle, structured as sets of files.

    Environments allow for different modes/views depending on what process of the site development you’re in (i.e. Development Environment, Staging Environment, and Production Environment). You can also create your own custom environments.

    Symfony provides Developer Tools to help debug problems faster. This includes a logging mechanism, the developer toolbar, etc.

    Security is really important for Symfony (and phpBB), and processes are built-in to protect from XSS, CSRF, and SQL injections using built-in automatic escaping, if you ask for it in the code. Symfony 2 allows for creating an Apache environment variable in a .htaccess or httpd.conf file, which can be accessed in the database configuration file, helping to keep the information in different places for improved security.

    Symfony uses PHPUnit for unit testing (like phpBB), and also provides functional tests to allow for testing your application.

    Caching in Symfony is rather unique — Symfony actually relies on HTTP caching rather than provide its own system. ESI (Edge Side Includes) is a specification from 2001 implemented partially in Symfony 2.

    Last but not least: HttpKernel is the construction kit for the framework and provides a lot of the architecture and building blocks used to create Symfony’s MVC framework. It’s a basic interface with a single handle() method, which can be used to build a framework compatible with Symfony 2. Going a step further by extending the interface provides a lot more power, including features such as the caching, the web developer toolbar, etc. This relies on an event system to roll through the model-view-controller architecture.

    Stefan Koopmanschap is going to talk a bit about the Symfony community and how you can ask questions & get answers about Symfony, knowing that there will be many questions about it as phpBB starts integrating it.
    * #symfony IRC channel on freenode (very friendly for new people, but be clear in what you’re looking for!)
    * Symfony forums (which happen to be powered by phpBB)
    * Symfony Google groups, the most important is the symfony-users group
    * Ask a question about Symfony on Twitter (if you can get your question in 140 characters!)
    * Symfony is probably the best-documented PHP framework right now

    Question to Nils: phpBB decided to start using a framework in order to not have to reinvent the wheel. Allows the development team to focus on actually building the application rather than the underlying framework.
    Why Symfony? A few very technical reasons. phpBB4 wanted to be very future-proof, with a framework that’s not based at all on PHP4 code and was really something new. “If that’s one of your points, then there’s not a whole lot of frameworks left.” A couple of other ideas for phpBB4, some of which are listed on the Development Wiki, meant that the Dev Team decided to choose Symfony 2.
    The benefits here are primarily for developers and MOD authors. MOD authors will see lots of differences because of the improved focus on modularity and extendability. phpBB4 seeks to eliminate having to modify core code, with a true plugin-style architecture that avoids changing lines of core code and prevents MOD conflicts. Also other bundles, not directly related to phpBB (i.e. the Blog MOD) can benefit from much tighter integration with phpBB without having to write them specifically for phpBB.

    Written by Douglas Bell in: Libertyvasion 2010 |

    [Libertyvasion] Doctrine 2

    Session: Doctrine 2 by Jonathan Wage
    Date/Time: Friday 8/20 at 2:00-2:45 PM

    This post contains my rough crib-notes from this presentation at Libertyvasion 2010. The post has not been proof-read for spelling, grammar, or accuracy.

    Jonathan Wage, has been a web developer for over a decade. An Open Source Evangelist and published author, contributes to Doctrine and Symfony, and is employed by Sensio Labs.

    Doctrine started on April 13, 2006 (first commit), and first stable version released September 1, 2008. It was one of the first Object Relational Mapper (ORM) implementations for PHP. Version 1.0, maintained until 3/1/10, has been integrated with a number of popular frameworks, including Symfony.

    What’s an Object Relational Mapper?
    Shows the definition coming straight off of Wikipedia. Essentially it creates a virtual object database for interacting between a database and an object-oriented programming language, such as PHP.

    Jonathan is showing off how Doctrine 1 worked, but pointing out some problems: The domain is bound to the persistence layer, the complexity of domain entities is limited by the persistence layer, $model->save() is a bottle neck for persisting large numbers of objects, and testing your domain model requires mocking the persistence layer.

    Doctrine 2 aims to solve a lot of those problems. No more base class to extend; you’re simply working with regular PHP objects, classes, and properties. Base tables & domain entities no longer bound to the persistence layer. Can specify mapping information with XML, YAML, or DocBlock Annotations in PHP, and Jonathan explains the advantages & disadvantages of each. XML is his preferred method.

    Transparent Persistence is the #1 rule followed in Doctrine 2. No dependencies to the persistence layer should exist, meaning that testing can happen directly with PHPUnit. Doctrine can persist an object simply by passing an instantiated object to a persist() method.

    Why Transparency?
    * Better performance
    * Easier to cache regular PHP objects that are not bound to the persistence layer
    * Easier to test your domain, no mocking required
    * Ultimate flexibility over the complexity of your domain entities without being imposed on by your persistence layer

    Doctrine 1 benefited greatly from using PHP 5.3 in terms of speed & memory usage in testing. Doctrine 2 is about 2-3 times faster than Doctrine 1. Doctrine 2 also fully uses & supports namespaces, making it much easier to combine libraries by virtually eliminating naming conflicts. Doctrine 2 (& Symfony 2) also fully supports PHP 5.3 Interoperability Standards (link coming).

    Doctrine code is divided into a few different packages:
    * Doctrine\Common — Common functionality shared across packages, Events, Annotations Library, Lexer Parser for the Doctrine Query Language (DQL), Other various convenience tools
    * Doctrine\DBAL — Relational database abstraction layer (MySQL, SQLite, PostgreSQL, Oracle, MsSQL), can also write drivers for other databases — DBAL is Standalone, can be used without the ORM
    * Schema Manager — Issue DDL statements through intuitive APIs, introspect your database scheme as well
    * Doctrine\ORM (the “killer feature” of Doctrine) — Built on top of the DBAL

    The architecture of Doctrine 2:
    * The ObjectManager: EntityManager and DocumentManager
    * Object States: Objects can be New, Managed, Detached, or Removed

    The Doctrine Query Language (DQL) is the killer ORM feature. It’s similar to SQL, and is a proprietary object query language. Instead of working with tables and columns, you’re working with objects and fields. Doctrine 2 parses it with a recursive descent parser (giving you good parse errors if you mess up). Doctrine constructs an abstract syntax table (AST) when parsing the DQL query, which generates the full SQL query for the relational database being used. The DQL parser also has every piece of the language represented by its own class in its own file, so it’s easy to discover and learn the language (i.e. OrderByClause.php, SelectClause.php, etc.). Parsing of the DQL is also cached to improve performance.

    Jonathan shows and explains a DQL query, which looks very much like SQL, however he’s pointing out how doing a LEFT JOIN is easier because you don’t need to explain in the query how to map the two together, since Doctrine has already mapped them. Doctrine also has a result cache method so that the results of the query are stored in a cache driver instead of the database. Events can be set up to automatically clear the cache when the data gets changed.

    The Doctrine features are tightly integrated with Symfony 2 — simply enabling the DBAL and ORM services in the Symfony configuration is all that needs to happen.

    In Conclusion: Why use an ORM?
    * Encapsulation of your domain logic in one place
    * This improves Maintainability
    * Testability is improved because of this maintainability
    * Portability for portable & thin application controller code and fat models

    Written by Douglas Bell in: Libertyvasion 2010 |

    Copyright © 2007-2010 phpBB Weekly, some rights reserved under a Creative Commons License. Website powered by WordPress. Theme: TheBuckmaker. Background: Vlad Gerasimov.
    Click here to view full copyright/legal attributions.