The idea of a 1.10.0, that is a major prior to 2.0 and after 1.8, has come up occasionally on here and Discord.
I put together a little plan for what a 1.10.0 might actually look like, although there are *some* snags, so it might not be the most practical plan, but I do think it is the most realistic, if the path was trodden upon.
Goals:
- Rewrite the upgrade system (possibly use 2.0's upgrader? is this possible?), one of the reasons cited by the team for being unable to make certain changes is the upgrader timing out during the upgrade process during really long queries. This would make it very difficult to replace certain components such as the current implementation of the datacaches.
- Replace the queries with prepared statements. We're probably all aware of the current code-base's susceptibility to SQL Injections. This would fix that, but it would require replacing every query in the entire code-base. Perhaps, an ORM could be used here?
- Responsive Design. Whether it uses tables or other constructs (other constructs might make it difficult for people to migrate from 1.8), it would obviously need some sort of responsive design, so that MyBB works seamlessly on both desktop and mobile.
- Datacaches. The datacaches are designed in such a way that they cause a severe performance impact in a few cases for big boards, the feature which was intended to speed up MyBB in many cases has actually ended up making it slower, so I believe this feature should be revisited during 1.10.0's development cycle.
- Data Races. The current code-base is fairly susceptible to data races which can cause random and unpredictable data and state corruption. The Cache Manager helps admins recover from data corruption in some cases, but not others. Transactions and row level locking would help prevent these problems, especially if all the queries are going to be rewritten *anyway*.
Optional Goals:
- Alerts. Alerts allow users to receive notifications without having to open their emails, as they move around the forums. One type of alerts receives messages via AJAX or WebSockets to inform the user of a change without forcing them to refresh the page, the only problem with live alerts is that it may increase the server load of MyBB Forums.
- Likes. A quick and modern way to show your appreciation for someone's post. Unlike traditional reputation systems, there is no negative reputation, and the counter is shown on the post to show it's value to the community. While the removal of negative reputation looks like an overall loss, it is an often abused feature which many disable, however removing functionality might be out of scope for 1.10.0 and require a 2.0.
- PM System Overhaul. This one's difficult, as MyBB currently uses a concept similar to email where a copy of the message is sent to both the sender and the recipient, so it's unknown whether this would make it into a 1.10.0, however a conversation system would allow discussions to be organised into what are essentially private threads rather than each message being a separate entity in and of itself which not only helps organisation, but allows people to respond to them, even if they disable incoming PMs (a problem cited at CodeIgniter's Forums).
Non-Goals:
- Rewrite the template system. While the current implementation of the template system is much to be desired (the use of eval causes big performance drops), replacing it would likely break every theme in existence and cause a number of subtle problems which would delay the delivery of 1.10.0
- Mass Refactoring. Refactoring MyBB to make it a lot more modern would likely break many plugins and would be a huge time sink, so this path would have to be ignored for the most part.
Cons:
- The MyBB Team does not have the resources to undertake a 1.10.0 and would have to rely on the community. I have no clue how many would be willing to help in such an endeavour, but a small handful of community members have expressed interest. This is the main reason which has killed many 1.10.0 proposals in the past and would need some careful consideration.
- 2.0 is under development and it's unknown whether 1.10.0 would ship before it. Two MyBB's being released in parallel would be detrimental to 2.0's adoption.
Feedback is welcome.
I think the cons you mention (lack of resources and time) ensure that any attempt to basically bridge 1.8 and 2.0 (essentially making a MyBB 1.9) is pointless. Especially if the proposed version ends up coming out after the official 2.0 (why even bother then? it'd defeat the purpose and just waste time/energy).
I mean the best course of action would be for the MyBB team (and anyone else skilled and willing to help out) to focus on 2.0. This would effectively get 2.0 done quicker and out into public usage.
If some non-MyBB members wanted to build an unofficial bridge version and possibly get MyBB staff to go over it (to check for issues and whatnot) then maybe it could happen. But even then it's likely still better for all to just have those people help develop MyBB 2.0 instead.
After some discussion (well, quite a lot actually) on Discord, I have some comments.
- I'd rather not detract attention from 2.0 with a new "1.10" version - 1.8 was already meant to be a stopgap between 1.6 and 1.8.
- We already have a lack of people contributing to both 1.8 and 2.0, adding another project to the mix is just going to confuse things.
That said, I do like some ideas such as implementing PDO and a responsive theme. I've thought of a possible good compromise that makes sense to me:
- Do not create a "1.10" version, stick with 1.8. This prevents there being hype for a new version and confusion of "I though 2.0 was the next major version, have they been lying all along?"
- Do incrementally roll in some upgrades:
- Create a new db_mysql_pdo class (and the same for Postgres and SQLite) that uses PDO for the MySQL database class and uses bound parameters for functions such as
insert_query and update_query. We can also expand the DB_Base interface to add new methods for other query types with bound parameters so that we can start implementing them where possible. This transition can happen over several 1.8 releases (1.8.14, 1.8.15, etc) with small units of work well tested during release flows. This way there's less chance of breaking plugins, whilst still getting all of the benefits - have our cake and eat it!
- Create a new official theme for 1.8 that is fully responsive. Market the new theme on the home page and the blog and start shipping it in the core as a secondary theme for a few releases. This gives plugin developers and theme authors time to adapt to the theme and get used to working with it. WordPress currently do something very similar with the yearly themes that they create every year and ship.
If we agree upon a list of clear improvements that aren't too drastic and make sense in 1.8's life cycle (remember: we plan to continue supporting 1.8 for
at least a year after 2.0 ships - we're looking at quite a long life left yet) then it would be awesome for community members to take ownership of these enhancements and start working on them and creating PRs. That way the team can focus on the more boring mundane jobs and upon 2.0, without feeling overly stretched. of course the team can still help out where needed and answer any problems and questions, but a community led initiative would be great - we could also do blog post interviews with community members working on things to help raise awareness and spread the word.
That's just my thoughts, written down in a rush. Hopefully between that and the chat we had on Discord should make it clear that I'm happy to improve 1.8, especially with community help and input. 1.8 doesn't follow semantic versioning and has never pretended to, so we can get away with cheating a little with how much we change (so long as we don't break everybody's sites in the process!).
(2017-09-21, 03:56 PM)Azah Wrote: [ -> ]Rewrite the upgrade system (possibly use 2.0's upgrader? is this possible?), one of the reasons cited by the team for being unable to make certain changes is the upgrader timing out during the upgrade process during really long queries. This would make it very difficult to replace certain components such as the current implementation of the datacaches.
Changes to the upgrade system can be implemented at any time, as long as it remains compatible with old upgrade path scripts that are included. The
recent PR might as well have included pagination, detecting configuration limits, etc., but that was omitted for the sake of simplicity (i.e. fixing most recent 1000 moderator logs that might have been affected by a bug).
(2017-09-21, 03:56 PM)Azah Wrote: [ -> ]Replace the queries with prepared statements. We're probably all aware of the current code-base's susceptibility to SQL Injections. This would fix that, but it would require replacing every query in the entire code-base. Perhaps, an ORM could be used here?
(2017-09-21, 06:16 PM)Euan T Wrote: [ -> ]Create a new db_mysql_pdo class (and the same for Postgres and SQLite) that uses PDO for the MySQL database class and uses bound parameters for functions such as insert_query and update_query. We can also expand the DB_Base interface to add new methods for other query types with bound parameters so that we can start implementing them where possible. This transition can happen over several 1.8 releases (1.8.14, 1.8.15, etc) with small units of work well tested during release flows. This way there's less chance of breaking plugins, whilst still getting all of the benefits - have our cake and eat it!
We should avoid reinventing the wheel and use the Laravel's
Database component that already supports complex queries, with the added benefit of refactoring current code with what will be used in the future. MyBB's current query builder would then only work as a layer for compatibility with plugins and remaining core parts (if any).
Implementing an ORM for core structures would probably introduce design changes without providing many benefits (whereas changes to how queries are executed will be constrained).
(2017-09-21, 03:56 PM)Azah Wrote: [ -> ]Responsive Design. Whether it uses tables or other constructs (other constructs might make it difficult for people to migrate from 1.8), it would obviously need some sort of responsive design, so that MyBB works seamlessly on both desktop and mobile.
(2017-09-21, 06:16 PM)Euan T Wrote: [ -> ]Create a new official theme for 1.8 that is fully responsive. Market the new theme on the home page and the blog and start shipping it in the core as a secondary theme for a few releases. This gives plugin developers and theme authors time to adapt to the theme and get used to working with it. WordPress currently do something very similar with the yearly themes that they create every year and ship.
The easiest path would be to:
- take minor PRs that allow for more flexible theming (element placement, order, availability across all pages) while reducing number of breaking changes to existent themes,
- take PRs for theming tools that don't affect the frontend (so they wouldn't cause compatibility issues),
- make sure old and new patterns that use the default theme's CSS are appropriately styled to reduce plugin compatibility issues (possibly with CSS hacks to make <table> elements responsive)
Expecting functionality like Alerts on modern forums is reasonable, but it's probably better to focus on implementing it in 2.0; plugins have been supplementing core features for years and there's already a level of compatibility established (e.g. plugins that create new events pass data to
MyAlerts).
Other changes that were mentioned would require much more effort to introduce and maintain - the point of creating new major version is to fix design flaws that reach too deep (both in the code and Extend community) to be fixed one by one.
A possibly breaking change that could be shipped along with such modifications is bumping version requirements, mainly of PHP as 1.8 contains numerous tradeoffs to maintain compatibility reaching PHP 5.2.
Regarding the DB, moving to use Laravel's DB classes would certainly need a minimum PHP version bump - whether that's acceptable or not definitely needs discussing.
I think it would be much better to continue in development of MyBB 1.8 - adding new features, rewrite bugged/uncompleted parts of the core, iron out bugs etc. MyBB team lacks devs for MyBB 2.0 development.
Look at phpBB - they didn't release phpBB v4.0 as they planned (small dev team, a lot of work). They started to rewrite and improve phpBB v3.0 in a small pieces. They released two "major" updates since that (v3.1 and v3.2) with many improvements, new theme, alert system, core changes etc.
Maybe MyBB team should reconsider and use the same approach as phpBB team did. What do you think?!
Best posts I have seen on the forum in a long time @EuanT @Devilshakerz
Hope the proposals for 1.8 come to fruition sooner rather than later. Please don't be tempted though to use "CSS hacks" on <table> elements, we all know that tables can't be used for responsive design. And then it probably won't be right to market the theme as responsive anyway. The community will take the responsibility of converting plugins to the new standard. Most plugins are not that difficult to convert. The only difficult one I have come across is the Prostats plugin, which has table HTML embedded in the code files.
(2017-09-21, 07:22 PM)Devilshakerz Wrote: [ -> ] (2017-09-21, 03:56 PM)Azah Wrote: [ -> ]Responsive Design. Whether it uses tables or other constructs (other constructs might make it difficult for people to migrate from 1.8), it would obviously need some sort of responsive design, so that MyBB works seamlessly on both desktop and mobile.
(2017-09-21, 06:16 PM)Euan T Wrote: [ -> ]Create a new official theme for 1.8 that is fully responsive. Market the new theme on the home page and the blog and start shipping it in the core as a secondary theme for a few releases. This gives plugin developers and theme authors time to adapt to the theme and get used to working with it. WordPress currently do something very similar with the yearly themes that they create every year and ship.
The easiest path would be to:- take minor PRs that allow for more flexible theming (element placement, order, availability across all pages) while reducing number of breaking changes to existent themes,
- take PRs for theming tools that don't affect the frontend (so they wouldn't cause compatibility issues),
- make sure old and new patterns that use the default theme's CSS are appropriately styled to reduce plugin compatibility issues (possibly with CSS hacks to make <table> elements responsive)
If the end goal is a responsive theme, then this is the wrong path to follow. A Responsive theme will break compatibility with existing themes and plugins. If changes are made with compatibility in mind, then you're going to end up with a product that is not desirable and not truly responsive. A responsive theme cannot accomodate tables.
A responsive theme almost implies that the doctype will be changed to HTML5 right ?
To what extent will the new layout depend on the old MyBB assets - the sprites and graphics ? In some cases these won't be able to be accomodated in a responsive layout.
What about adding a font set like Fontawesome as standard ?
Since we are not into reinventing wheels, many big projects like MyBB and big corporates use frameworks like Bootstrap - is the team willing to give this any consideration ?
(2017-09-21, 07:40 PM)Eldenroot Wrote: [ -> ]Look at phpBB - they didn't release phpBB v4.0 as they planned (small dev team, a lot of work). They started to rewrite and improve phpBB v3.0 in a small pieces. They released two "major" updates since that (v3.1 and v3.2) with many improvements, new theme, alert system, core changes etc.
Maybe MyBB team should reconsider and use the same approach as phpBB team did. What do you think?!
While I'd love to see certain features on MyBB 1.x, I think our users will prefer one major update breaking all plugins and themes over several smaller updates still breaking a lot of plugins and themes.
Would not complete focus on 2.0 be more appropriate? I think the faster MyBB moves away from the old codebase the better. The reason 1.8 wasn't even larger than it could have been was due to the fact we wanted to work on 2.0 ASAP but didn't want to leave the community waiting for it. Of course, bugs should still be fixed, but 2.0 needs to be a priority if it's ever going to be released.
Team, I'd recommend reading over Tim's internal thread about 1.8 (I remember it vaguely) and what we wanted to achieve with it.
(2017-09-22, 11:29 AM)Nathan Malcolm Wrote: [ -> ]Would not complete focus on 2.0 be more appropriate? I think the faster MyBB moves away from the old codebase the better. The reason 1.8 wasn't even larger than it could have been was due to the fact we wanted to work on 2.0 ASAP but didn't want to leave the community waiting for it. Of course, bugs should still be fixed, but 2.0 needs to be a priority if it's ever going to be released.
Team, I'd recommend reading over Tim's internal thread about 1.8 (I remember it vaguely) and what we wanted to achieve with it.
You're entirely right that focusing on 2.0 is important and needs to be done. A new theme for 1.x is a fairly simple task, however, and should really be done. Focusing on 2.0 is better for the team and future MyBB users, but there are still lots of people relying on 3rd party developers for a mobile layout for their forum, and even people still not using one. I think that is the more immediate problem (Along with the security issues that Azah mentioned).
That's my opinion on the matter, and after discussing it in Discord I believe that a new theme should be created with disregard for plugin compatibility, and be shipped alongside the default MyBB theme. This will allow technical users to have a solid theme base to work off of, and still leave beginners with an option that will retain all compatibility.