Documentation

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?:

Template

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