EosAlpha BBS => EosAlpha Bulletin Board System - development => Topic started by: Nightwish on August 08, 2011, 16:30:06
This is a (probably incomplete) list of things I've planned for the forum backend. There is a lot more to do, but I consider these items the most important ones at the moment.
- New group permission to control availability of a signature. Done
- New setting for pruning spider stats (not spider logs, but the per-spider stats). Done
- Sphinx support - Done
- Easy way to embed Google Analytics, but registered users can opt-out from being tracked with a profile option (yes, I do care about privacy). - Done.
- Planned support for Piwik and OWA - embed tracking code and configure the necessary parameters.
- More explicit control for the caching system (e.g. force it to use a memcached instead of simply auto-detecting the caching method) - Planned.
- Remove caching support for eAccelerator. Doesn't make any sense any longer, because the required functionality has been ripped out of eAccelerator. Done
- Same for Turk MMCache - since this forum software will require PHP 5, supporting the old MMCache doesn't make any sense. Done
Possibly: drop PostgreSQL and SQLite database support. Done
- Drop MySQL fulltext search - we all know how much it sucks. For the vast majority of forums, the custom index can do the job well enough and large boards would want to use Sphinx. Done
- Ad - management. This is a huge item so it will take time. It should allow for easy embedding of ads into header, footer, topic and message index views plus a convenient method to manage these ads. User group permissions will allow to skip the ads for users who are in the right group (i.e. you donate, you won't see ads and stuff like this). Planned for a later development phase, will definitely not go into a first release.
- Remove the option to disable administration security. Who would want to turn that off anyway except for a testing environment. The setting is still available trough a Settings.php option.
- Template evaluation is now OFF by default. Turning it on gives few benefits (unless you are a theme developer) but a significant and negative impact on performance. So, off by default, on when you really need it.
Some more thoughts on the admin area...
Ultimately, I aim for a UI similar to WordPress, allowing administrators to customize the admin panel with widgets for common tasks and organize their workflow more efficiently. Widgets would be used to host important administration areas and content is loaded on demand when a widget is expanded or restored from a minimized state. Widgets can be freely arranged via drag and drop, they can be collapsed, maximized or be arranged in a column layout.
This is a huge task though, lots of work ahead and if I ever get enough time to complete it, it will take a while.