Here we are. phpBB 3.0.5 got released and work on phpBB 3.0.6 began. Previously, we concentrated on fixing bugs and only introduced tiny new features. This time, phpBB 3.0.6 will be a “feature” release, packed with numerous new, cool, stunning, breath-taking… err, just new features. 😉 We will now tell you which new features are planned for 3.0.6 and what style authors and modders need to take care of.
New CAPTCHA plugins
We will introduce CAPTCHA plugins, a backported Ascraeus feature, to allow admins choose their preferred CAPTCHA. This also allows us to give the admin some more options; one of them being reCaptcha. MOD authors will also be able to utilize this feature to provide their solutions, for example Q&A CAPTCHA.
This new feature has two direct implications. First is style authors need to update their styles to reflect the changes we need to do in prosilver and subsilver2 to let the new options work. Our Styles Team will assist style authors as best as they can. Second is MOD authors need to adjust their CAPTCHA solutions to work with the plugin architecture. Our MOD Team will assist them as best as they can. We will also early provide instructions for both to properly update their styles/MODs.
We will add ATOM Feeds to phpBB. This is an often requested feature and we think it is time to add them. 😉 It will allow forum, topic, per-forum, per-topic and a news feed (for announcements for example). Authentication for private forums will not be supported though (at least this is not planned yet).
For RSS MOD authors this means you need to make sure your Mods do not interfere with this new feature. We decided for a general naming scheme to circumvent any incompatibilities. phpBB will use feed.php and has no template for the feed (the generation only happens within this one file).
We will introduce four new cache plugins + one for no caching at all. The no-cache plugin was something requested by some of our members who run the phpBB software in load-balanced environments. To additionally support them and all others (especially high volume installations, big boards and distributed setups) we also change the mechanism we generate the file-based cache. This module now uses an improved format. In conjunction with the use of other file system functions this approach uses far less disk I/O. As an additional safety feature the files now contain a PHP header to stop information leak by browsers navigating to the cache folder. The files are not included as PHP files by phpBB so as not to fragment opcode caches.
The new additional methods available are:
- XCache – http://xcache.lighttpd.net/
- APC – http://pecl.php.net/package/APC
- eAccelerator – http://eaccelerator.net/
- Memcache – http://php.net/memcache
Exempt group leader permissions for groups
A common setup these days are special groups having NEVER permissions assigned. Admins add trouble users to them to disallow certain functionality. At the moment such groups are basically only manageable by an admin, due to these NEVER permissions also assigned to any group leaders. And you do not really want to assign those permissions to the group leader, you simply want the leader to manage the groups membership.
Therefore phpBB 3.0.6 will see a new group-based setting (which is not adjustable by group leaders) to let group leaders not inherit group permissions.
Group Management changes for post queue (and others)
An additional feature will be the opportunity to define a minimum number of posts the user must have before he can send private messages. The details are still under discussion, but generally we want to syndicate our post queue and other disallowed features into a new “newly registered users” group. New users are automatically put into this group and removed from it once they reach a configurable amount of posts. The admin then could disallow anything he/she likes to disallow for newly registered users (0-poster), for example – but not limited to – viewing other members profiles, sending pm’s, sending emails, looking into certain forums, etc.
With this feature we hope to give admins more freedom in their ability to define certain restrictions and limits on their board, suited to their type of community.
PM Reply/Reply to all
Because users easily get confused by the default PM Reply to all behaviour we will separate this to let the user decide which method to use… if he wants to reply to the original sender of the PM or reply to all recipients of the PM.
Pagination for smilies and icons
We will introduce pagination to the smilies and icons page. We may also add a hard limit to the number of smilies, because too much smilies can consume a lot of resources and makes the board unusable.
Yes… Q U I C K R E P L Y. This little thing most want to have and team members do not want to have. 😉 Actually i think this has gone a bit too far. In the end users did not ask: “What does the development team think about this”. No, they assumed we are automatically against the idea. Of course we think enabling quick reply does not support serious discussions, but not all want serious discussions. 😉 Some may very well want to specifically attract those “thanks!”, “lol” and “yes, i agree” posts.
Well, we will add quick reply as an option. This will be a forum-specific setting and connected to the “can reply to posts” permission. It will only be shown in topics and not used for new topics. The quick reply option will be turned off by default for new forums. Option-wise the quick reply implementation will be a bare-bone text area with no buttons, no options, no smilies. For this the posting page is there – a quick reply feature should be used by people who know how to use BBCode and how to properly format their posts.
Ability to search logs
One thing we will look into is the ability to properly search logs. We previously ourselves had a need for it – and i think it comes in handy quite often. 😉 We still need to determine how we do it – and it may be also the first step to a searchable ACP (which is on our agenda since londonvasion), but at the moment it is an idea we had.
phpBB 3.0.6 will of course see many bugfixes. We also try to release a first RC as soon as possible (predicted are currently 2-3 months). We may also introduce other tiny new features you may like. 😉
Please discuss this blog post on the forums.