General
FluxBB versions
Appendix
Table of Contents
FluxBB v2.0 development roadmap
Components
API
- The API should have private ownership of the database instance - i.e. accessing the database should only be possible via the API. Alternatively have it public but attempt to discourage direct access.
- Should be extensible in some way, possibly using __call(), but it will depend on how hooks work.
- Should be tied to a specific session and permissions automatically handled.
Database
- Requirements: Query builder (extensible), SQL abstraction, parameter sanitizing, driver abstraction.
- Support: MySQLi (MySQL is for PHP < 5 and MySQL < 4.1.3, no need), SQLite3 (what about SQLite2? - nuke it from orbit apparently), PgSQL. Leave others (OCI8, MSSQL, Firebird) to community?
- Use PDO for driver abstraction?
- We should do benchmarks to see if caching of SQL is actually worth it - where is the performance hit.
- Prepared statements for parameter sanitizing. Slight performance hit, but probably a good idea…
Cache
- Requirements: driver abstraction.
- Support: File, XCache, APC, Memcached. Include others, or leave as extras in resources area?
- Filters allow compression, encryption, etc. Strip them out since FluxBB wouldn’t use them by default?
- How aggressively should we cache? Maybe depends on the type of cache in use?
Language
- Format: INI, Gettext, XML.
- Neutral key or English fallback? French community didn’t seem to like the idea of English keys - why not?
- Cached so performance of parsing the original format isn’t an issue.
- Should we worry about proper support for plurals?
- If using the PHP extension (function _) then xgettext should work.
- Should the language be inside or outside the API? I would argue outside is cleaner, but then how do we handle returning error messages? What about email templates?
- If we use gettext the API can simply call _(‘…’) and translation will be automatically handled.
- If we were to scrap email templates and use translated strings instead it would make life easier - is there a downside?
- Best approach seems to be gettext - wordpress (IIRC) uses __ and a native PHP implementation instead of the extension. It’s probably worth checking why?
- Existing libraries we could maybe make use of?:
- https://github.com/dsp/PHP-Gettext - Looks relatively simple and more our style. Keeps the implementation in its own class and could easily be cached.
- https://github.com/voda/php-gettext - Looks good, though rather complicated.
- https://github.com/fligtar/faketext - only supports loading from .po files rather than .mo files (this isn't necessarily bad). Provides gettext when no extension exists rather than own version so would need some modification.
- https://github.com/wordpress/wordpress/blob/master/wp-includes/l10n.php - Wordpress specific and overly complicated looking. We could potentially use parts in our own implementation, but couldn't use the library on it's own.
Template
- twig? (no idea what it is - look into it? - http://fabien.potencier.org/article/35/templating-engines-in-php-follow-up)
- paul's stuff
Parser
- Support: BBCode. Leave others (Textile) to community?
- ridgerunners rewrite for bbcode
- Also responsible for censoring and smilies.
Authentication
- Fully session based
- Passwords: BCrypt+repeated hashing fallback (phpass/own implementation?)
- Have some form of AuthenticationHandler, and a way for extensions to register new handlers (allowing multiple).
- csrf tokens for forms
Extensions
- Wordpress-ish?
- actions (something is happening, let me do something) and filters (some data is being used, let me change it)
- hook identifiers as string constants → PHP notice on invalid hook name rather than hard to debug “doing nothing”. Also provides a list of all valid hook names.
Search engine
- Modular part of the API.
- Support: MySQL fulltext (does SQLite or PgSQL have an equivalent?), Sphinx?
URL routing
- Single entry point - index.php
- without url rewriting index.php/some-nice-url
Features
Syndication
- Could be done by adding special templates for certain pages.
- Support: Atom, RSS.
Anti-spam
- honeypot
- official SFS extension
- official captcha extension
Read-topic tracking
- Full tracking using a RDBMS isn't likely to work well.
- Maybe something non-relational would work better?
- Check what phpBB, SMF, etc, do.
Roadmap
2.0-alpha1
- Port to Laravel framework
2.0-alpha2
- API, OOP
- Template
- Front controller
2.0-alpha3
- Parser
- Search engine
2.0-alpha4
- Extensions
2.0-alpha5
- Feature changes
2.0-beta1
- First beta release of FluxBB 2