Following the MyBB 1.x and 2.x Development RFC thread, and the recent release of 1.8.13, I think it's time to start discussing exactly what we want to see from the future of MyBB 1.8, heading into 2.0. I decided to start this thread to layout some of my ideas of what Id like to see and how we might approach this future.
This will be a slightly more technical thread, so don't expect screenshots of new themes or features or anything like that. None of this work has started, and the plans will change based upon feedback. Also realise that these are all just things I'd like to see and not the thoughts of the whole team.
Enhancements/Improvements
Approach
Currently the core MyBB repository has two main branches:
One possible new set of branches would be:
Once 1.10 was released, a "master/1.10" branch would be introduced, containing the most recent stable release of 1.10.
One consideration here is whether the "master/1.6" branch is needed at all. All releases are tagged with a release version, so old stable released versions can be downloaded using these tags.
Again, these are all just my current thoughts on the future direction. Some changes are fairly easy to implement (caching system changes, introduction of Swift Mailer), some are more difficult (completely changing the template system for the front-end). Once we reach something resembling an agreement of what we want and how we want to approach it, we can start looking at assigning tasks and starting the development process.
This will be a slightly more technical thread, so don't expect screenshots of new themes or features or anything like that. None of this work has started, and the plans will change based upon feedback. Also realise that these are all just things I'd like to see and not the thoughts of the whole team.
Enhancements/Improvements
- Introduce Composer for 3rd party dependency management. Currently all vendor dependencies are copied into the "inc/3rdparty" folder (such as the 2 factor authentication library). With Composer, we can more easily manage dependency versions and start making use of it's autoloader (and start introducing namespaces and autoloading into future MyBB code).
- With Composer introduced, we can then start looking at 3rd party libraries that could benefit the software. Some of these include:
- A dependency injection container, such as Pimple.
This would go well with introducing other third party components into MyBB, allowing plugins to overwrite and extend defined services easily.
Pimple itself is extremely well tested, has been around for a long time and has a great set of features.
- Twig - a PHP templating language/library. This would provide much more flexibility and power when creating templates - it allos for conditionals within templates, loops within templates, and more.
The introduction of Twig would be phased, with the Administrator Control Panel being the first area of the softwae to have it introduced. In current versions of MyBB, the ACP uses hardcoded HTML inside the PHP files to output content (and a Form/Table class to manage forms and tables). Introducing Twig here would help clean up the ACP and during the introduction we could look at the layout and styling of the ACP to improve it's usability.
After introducing Twig to the ACP and people getting used to the way that it works, we can then start to look at introducing it into the front end of the software. This would obviously be a much bigger job, but would prove worthwhile in my opinion.
- Swift Mailer - a email library for sending emails in both text and HTML formats, with features such as attachment support, better compliance with different email servers and more transport mechanisms.
MyBB 1.8.13 made an effort to fix the way that MyBB sends emails in some places (such as the contact form), but the current mailhandlers could be improved with the introduction of a well tested component such as Swift Mailer.
This should be relatively easy to implement, as all emails within MyBB that I'm aware of are sent using the "my_mail()" function, presenting a single entry point from which we can introduce Swift Mailer.
- A caching library, following the PSR-6 standard. MyBB already features a couple of caching classes in the core, but offering option for more caching systems (such as Redis) could be extremely useful. Rather than reinventing the wheel, using a 3rd party library that follows a defined interface (PSR-6) should offer more flexibility and options.
- A routing library, particularly for the Administrator Control Panel as the first stage. The ACP currently uses it's own front controller style of dipatch to modules based upon the URL. Introducing a proper routing library here would be the easiest place to start. Eventually this routing library could be transitioned into the rest of the software, though that is a much larger goal.
In terms of the actual ruting library, there are many. My preference would be something like FastRoute, which is billed as being fast.
Combining a router with a middleware system such as zend-stratigility would allow us to build composable modules with middleware being easily managed by plugins to provide additional functionality such as easy permission checks.
- A PHP based Command Line Interface for installing, performing ugrades and other maintenance tasks. The Symfony Console component is pretty much the gold standard of libraries for writing command line applications in PHP. The CLI should be easy to extend by plugins to add more commands and options.
- Introduce an internalisation library for handling translations, offering more power to authors of translations. Translations should also be versioned better to allow the easy upgrading of language packs and for users to realise when language packs are out of date.
- A dependency injection container, such as Pimple.
Approach
Currently the core MyBB repository has two main branches:
- master - The code from MyBB 1.6, which hasn't been touched in 2 years.
- feature - the current code for MyBB 1.8, in active development.
One possible new set of branches would be:
- master/1.6 - the code from MyBB 1.6.
- master/1.8 - the code for the most recent stable release of 1.8.
- develop/1.8 - the code for the verison of 1.8 currently in development, but not yet released.
- develop/1.10 - the code for the in development version of 1.10.
Once 1.10 was released, a "master/1.10" branch would be introduced, containing the most recent stable release of 1.10.
One consideration here is whether the "master/1.6" branch is needed at all. All releases are tagged with a release version, so old stable released versions can be downloaded using these tags.
Again, these are all just my current thoughts on the future direction. Some changes are fairly easy to implement (caching system changes, introduction of Swift Mailer), some are more difficult (completely changing the template system for the front-end). Once we reach something resembling an agreement of what we want and how we want to approach it, we can start looking at assigning tasks and starting the development process.
