Hi,
I think it is time to write about the presentations we (the developers) gave at Londonvasion revealing the planned features in the upcoming version of phpBB – codenamed Ascraeus.
Please do not take anything mentioned within this blog post as guaranteed. There may be changes, some things may not evolve at all, some may be changed completely. But yeah, this is the current state of planning.
Requirement Changes:
Because the 3.0.x requirements were written a few years back, we had to look at the requirements again and decide how far back we want to support software.
For the programming language (PHP) we decided to drop PHP4 support altogether, mainly because by the time we anticipate the release, PHP4 will no longer exist (and is already deceased) and most likely PHP6 already released. At the time of writing, we expect the minimum requirement for Ascraeus to be PHP 5.2.0+.
For database backends, we will drop support for versions no longer supported by their vendors. For example support for MySQL 3.x and 4.x has ended – hence we will only support 5.x and 6.x.
There may be other products within the phpBB stack for which we might have to raise the requirements, but this also depends on the market situation at the time of the first public release.
Significant framework enhancements:
The goal for these enhancements is to separate phpBB into independent parts for better code abstraction, unit testing, ease of use and re-use, single point of entries and removing spaghetti code.
The layout of our filesystem structure will see general changes. At the moment, files are not named consistently, nor are they grouped consistently. We will try to solve this by introducing an easy-to-follow filesystem structure. At the same time we will refrain from changing it too excessively to retain some backward compatibility.
Static phpbb class for creating a global namespace and for grouping our most-used globals
For our “main classes” ($db, $user, etc.) we will use a static class, generally mimicking a global namespace. Referenced through phpbb::$db, phpbb::$user, etc.
The static class will have a register call to be able to register objects for handling through this new static class.
The benefit is the removal of most objects and due to singleton usage the ease of getting the correct instance of the object the developer wants to use.
Due to our main objects being referenced through a static class, the global namespace will remain unpolluted.
Class name changes to prevent conflicts with third party products/code
Class names will change a bit, all our own will be prefixed by phpbb_, interfaces by phpbb_interface, abstracts by phpbb_abstract, and so forth…
Examples of extending our framework
At the moment, some files do not call common.php to initialize everything, forcing us to duplicate code from common.php. Attachment delivery is an example for such a case. To be able to only have one entry point and code for this, we will add a new “init file” which will be responsible for setting the required parts of the “base” with minimal effort. This file will be called from within common.php, but could also be called by other files who need the framework, but do not need the full setup.
So, basically, this splits two use-cases. The first to make the framework available to the script and the second to initialize phpBB-specific settings.
Moreover, our filter functions, namely our validate_* functions and our parameter handling function request_var() will be collected for easy (re-)use.
Our URL handling and redirect functionality will undergo the same changes.
Ascraeus will also use more hooks, directly embedded into objects which are defined as “hookable”. This will allow third-party applications to introspect and alter the script’s state, for an even easier integration into existing code.
Cache Systems:
We recently added new cache systems supporting APC, Xcache, shmop and others. Also, the db based cache will be revived. Furthermore, we will change the underlying cache structure.
We will introduce cache containers – the actual cache type will be configurable on a per-container basis. Say, one wants to use the file cache to store templates, the db to store global data and memcache to store sql queries – that will be very easy to set up. This is one example for the flexibility we will gain by implementing the framework enhancements.
New BBCode Parser:
The new BBCode parser will not suffer from the problems we faced previously within 2.0.x and 3.0.x. It is already committed to the repository and will completely replace and enhance the old BBCode system. We learned from 2.0.x and introduced a new BBCode parser for 3.0.x. This parser had its own problems, but not as many as in 2.0.x, especially regarding security. Now that we identified the issues, we can make sure that the BBCode parser for 3.2.x will not suffer from unexpected limitations.
Some features the new BBCode parser has:
- stack-based parsing
- ability to use BBCodes for any text-column
- ability to parse BBCodes on demand
for example BBCodes possible in word censors - no separation between custom and built-in BBCodes
- Custom BBCodes regular expression support
- Change storage mechanism for BBCodes (separating entered text and parsed text)
Planned Features:
Following is a list of the planned features we have for Ascraeus. These are the bigger ones. If you want, you can call it our milestone list (Of course, we have a more detailed one… but it has a lot of nonsense not required here).
- New MCP
- Complete overhaul of moderation capabilities
- add inline moderation capability
- ability to add user notes while performing several moderation actions
- allow moderation tools in search results
- Canned Responses
- More control over Warnings
- AJAX
- Server-side library
- Implement in some ACP pages
- progress bars
- configuration dependant pages/content
- Used for the inline moderation tools
- Not used everywhere, but where applicable and helpful
- Event System – Trigger-based event system
- Trigger: configurable trigger defines an entry point, for example post new
topic for post event - Condition: Condition need to evaluate to true for the event to be triggered
and action to be executed. For example: user reaches 20 posts. - Action: Action to be executed if Condition is true within the triggered event. For example: add user to group X
- Callback: Callback for notification methods of triggered events
- Trigger: configurable trigger defines an entry point, for example post new
- RSS
- Custom Profile field changes
- new types (image, floating point, etc.)
- All in-built profile fields incorporated into custom profile fields
- PM System Enhancements
- read receipt request
- remove outbox and instead show message status
- user-based option to include the message text into the PM notification
- proper report PM’s
- Authentication System (auth)
- Add support to update profile data/additional profile fields in external tools to the authentication system
- Extend to a system able to handle profile data, a tool able to be used by others too.
- OpenID support
Some smaller planned features:
- Styles System no longer attempt to store templates and themes within the DB. The system will be backwards compatible, but we want to have the filesystem as the primary location for templates, themes and images. Changes from the ACP can be transferred to the filesystem.
- Topic Title Prefixes
- Special maintenance forums (Trash Can, Archiving)
- Soft Delete
- CAPTCHA plugins
- Sessions workflow simplifications
- support for queued edits
- extend cron to be able to define the times for execution
- improve error logging by adding additional notification possibilities
- Editable FAQ and Board Terms
- Help System to support the Admins and Moderators (little help icon with inline layer)
- Ability to adjust default user preferences/options
- We may add support for services such as Akismet.
- Use default language variables as a fallback if something language-dependant is not available
- allow IDN+IRI domain names
- Full Multi-Language support by allowing certain texts to be defined in several languages (for example forum names and forum descriptions)
- proper DST handling (automatic DST switching)
Events → Plugins → Hooks → API → code
On the developer side of things, Ascraeus will consist of many mechanisms meant for different use-cases.
Events:
Used by developers/admins to define special actions triggered by events.
Example: Place user into group X if his post count reaches 10 posts
Plugins:
Used by developers to drop in new functionality into main areas.
Example: Adding a new ACP page with more detailed statistics.
Hooks:
Used by vendors to integrate phpBB into their application/product.
Example: Joomla! Bridge
The API:
Used by developers to use the framework to achive certain goals.
Example: add user to group by calling the API
Example call: phpbb::$api::$user->add_to_group(’ADMINISTRATORS’)
The Code:
Used by developers/core developers and only touched by core devs.
Example: the function append_sid()
Conclusion:
There is much to do. 
As you can see, we basically started planning what we want to see. We also need to take into account that we want to retain some sort of backward compatibility – in the sense of not rewriting everything. 
subsilver2 will most likely be dropped though.
At the moment our main focus is still on Olympus. Bug fixing and managing the product in it’s full entity takes still the most time.
If you want to see the presentations, please go to our Londonvasion page and view them online or download the videos and view them offline.
Thanks for reading,
Meik
That was very interesting and informative. Thank you for taking the time to put all that information together!