MyBB Community Forums

Over the last few days both the Team and Community have been discussing the future direction of MyBB. Current plans are to develop a new version of MyBB -  a complete rewrite - called 2.0. However, the possibility of a version "1.10" have been suggested within the community, across a number of threads. We'd like to collect everyone's thoughts and suggestions on this in order to make sure MyBB is heading in the right direction.

Outcome: MyBB Blog Post "A Fresh Perspective"

Threads:

• [staff discussion] MyBB 1.10 RFC - Euan
  
• 1.10.0 RFC - Azah
  
• Moving Forward: State of MyBB - Ben Cousins
  

Why a new thread?
There have been a few threads recently on the subject, we'd like to keep it in one place, with one original post that contains any decisions or important links. If you've written out a great post in another thread, feel free to just quote it and paste it in here.

Poll Explanation
Here is a brief explanation of each of the poll options:

Current 1.x series: Maintenance and compatible improvements – Make small changes to 1.8 to modernize it a little, but maintain compatibility with plugins & themes, continuing to develop 2.0 as planned – ie: “business as usual”

Current 1.x series: Improved compatible theme – “Responsify Business as Usual” – keep with the current 1.8/2.0 plan, but also make a new theme (possibly an optional non-default theme to begin with, that becomes the main theme, but retains compatibility as much as possible to not break plugins)

Current 1.x series: Update 1.x with new theme system with Twig templates – Overhaul the current theme system, implementing a new theme (default I imagine) that takes advantages of Twig for much more convenient theming, taking this opportunity to go responsive and modernize too.

Current 1.x series: UX feature improvements – add modern features (alerts, conversations etc…) users expect in a modern software to the current 1.x series, on the same codebase, but don’t really worry about breaking changes.

Current 1.x series: strategic 1.x updates to bridge structural changes – multiple updates released for 1.x over time to modernize the core without rewriting large amounts of code, like changing or introducing libraries/modules that would be used in 2.x, making core, plugin & theme developers more familiar with modern concepts to bridge the knowledge gap and major structural differences

Rewritten 2.x series: parallel 2.0 development – parallel development of either 1.8.x (or “1.10” too) while ALSO maintaining the current strategy of performing a full rewrite of MyBB for a few years in the future

Rewritten 2.x series: switching to full 1.x refactoring – instead of a full rewrite in Laravel, abandon that plan, and refactor 1.8.x sufficiently to BECOME “2.0”

I'll just quote my thread you've linked:

I have been pondering the best way to move forward.

As someone who develops their own platform I have about as much influence here as a damp, dead, squid. Awesome for Calamari, but in terms of usefulness, very little. There are reasons I don't submit PRs, and they're unlikely to change, this is not a solution for me.

Instead, I am going to make suggestions about internal policy, and how you guys manage the development process - because there's no illusion; things have trouble getting done around here. One has to look at the commits to 2.0 to see that.

Therefore, my suggestion is threefold:

• Feature Lock 1.8; work solely on security fixes, and that image bug. It is stable enough at this point where it works well enough to soldier on short-to-mid term.
  
• Get cracking on 2.0; because at the rate we are going, we're never getting 2.0. When it was announced, it was spectacular. Now people are leaving because they don't expect to see it in the next year or two, if ever.
  
• Develop KPIs for the team as a whole to work towards. Where do you want to be in 1, 2, 3, 6, 12, 18, 24 months time?
  

- Feature Lock:
I say to feature lock MyBB 1.8 because, realistically, it doesn't need new features at this point. It is stable enough now to last as long as is necessary. Security fixes are a necessary evil; but the bugs that remain are not going to make or break the experience. Yeah, sure, if they start to cause issues, fix them; but don't use "1.8 is broken and needs to be fixed" as an excuse for leaving 2.0 alone.

- Get cracking on 2.0:
I imagine this one is rather self-explanatory. Not going to explain it, but leads into:

- KPIs:
Clearly, MyBB needs a similar approach to the one I have; even if it's my friends ripping on me for not getting things done. By developing KPIs for the team to work towards, you're setting milestones you want to reach by a particular date, and not meeting them - whilst not necessarily a deal breaker - should be seen as a negative.

I am not suggesting creating deadlines for things based on full-time work - I get that this is a volunteer project; I know all too well how that feels - but you have got to be accountable to the larger community for a product that you are providing, rather than the current method of "Well, it's open source, submit a PR". A lot of the webmasters I know, know nothing about design and HTML/CSS, let alone PHP, let alone Object Oriented, let alone however MyBB is coded. They don't want to submit PRs, they want a modern software that works.

I really don't believe that a 1.10 is the best way forward as it will simply create a 1.8 situation. "It's just a stopgap". 1.8 is the stopgap. Like it or lump it.

So, suggested KPIs - no necessity to be bound by them, but for the sake of the argument:

- 1 month:
Release of new MyBB 1.8 version; with the fix for that image issue that shows the timestamp.

- 2 months:
Initial development on 1.8; aim to have at least one element completed. User Authentication/Registration would be an ideal starting point.

- 3 months:
MyBB 2.0 at a point where a development update can be posted, providing an insight into a system that is, actually, being programmed, and is, actually, making progress.

- 6 months:
Alpha for 2.0. Not quite ready for a beta release; but should be able to be previewed in the same way XenForo 2.0 was before being installed on the base forum for them.

- 12 months:
MyBB 2.0 Beta 1. Long shot here, but I imagine that this would be relatively easy to achieve.

- 18 months:
Preperation for the release of 2.0, given that there should have been at least 4 beta releases between Beta 1 and now, working towards gold.

- 24 months:
MyBB 2.0 gold. Move the site over to it, announce 1.8 EOL.

Accountability leads to results.

---- Some other thoughts ----

I don't agree that 1.10 is the right direction to go in with the changes that have been discussed internally. A complete rebuild of MyBB for current standards is well overdue. This should be MyBB 2.0 - as currently planned - and should be pushed to be released in a reasonable timeframe. The problem that you'll face, as you well know, is breaking changes. People that use MyBB want, nay expect, it to work with all plugins on the Mods site currently. I'm skeptical, and not convinced, that you'll be able to maintain that compatibility with a rewrite over time that then leads to a 2.0 release.

I am a firm believer in the band-aid approach, where ripping it off faster (ie: breaking everything at the same time) is more painful, but the longer term benefits can't be overlooked.

The MyBB team really need to get together, work out a timeline for the community and need to be accountable. You can't just hide behind "It's a volunteer project". We get it, we know you do this in your free time, and we know it takes time - but when you say you're going to do something, it has to get done.

In the event that MyBB 2.0 is pushed back and 1.10 happens, it should not be called 2.0 - for reasons of software versioning. Simply put: I believe that while it is still the same core code, it should be 1.x. When a complete rewrite is released, it can then be bumped to 2.0. In the staff thread, discussions were being had as to rewriting large amounts of code - which is what 2.0 is meant to be; and I think it would be beneficial to just do the update once onto 2.0. This is why I'm now working on a 3.0 for my own site; because I wanted to move to a framework and I wanted to write it all again: once. A 1.10 would make the project go around in circles and with already restricted development time, this is not feasible.

Yes, phpBB created a responsive ProSilver; they did a good job. phpBB took the oppourtunity to also update their MODs system and a few other bits and pieces that were painful to use for me - and no doubt others; this is less of a concern with MyBB. You upload, you hit Install and Activate and it just works.

If you intend to develop a responsive theme, this would fall into 1.10 if it is to be a core feature - if it isn't, and you release it as a theme, this would work into 1.8. 1.8 can be made responsive.

Ultimately, I'm all for the planned 2.0, single code breaker, single point of incompatability, etc. I can't see slowly refactoring 1.8 to be beneficial in the short or long term.

re: https://community.mybb.com/thread-213282.html

Quote:The 1.10 RFC has a valid argument in my eyes. I think there might be real merit to pushing 2.0 (as it currently stands - a full rewrite in any case) further out into the future. Instead, we could concentrate our efforts on incrementally improving the 1.8 codebase, and naming it 2.0

It's is a very good thing to consider. A rewrite is great of course, but I think it's more practical with the current pace and team activity to push toward an incremental improvement rather than a completely separate project that takes a totally different setup and mindset to develop on. This way people familiar with 1.8.x could help refactor it toward 2.0, rather than start completely fresh. The improved 1.8 could serve as the foundation for the new 2.0, with a lot more parts being reusable. It seems like the best of both worlds to me.

Quote:Replace our current template system with Twig, using Composer.

Quote:Introduce a new theme, making use of current technologies and approaches - if we're replacing the template engine, there's no worry about plugin support anyway. Whilst we're at it, we can remove tables and such to our heart's content.

Of course the first thing you think with breaking plugins is that it's bad, but with an update like this the amount of control you're giving users, plugin developers and theme developers more than makes up for it I believe. Anyone that's worked with the 1.8 theme/template system knows how much of a pain it is, and the lack of proper responsive and SEO really makes MyBB forums suffer.

Quote:Introducing a core API system.

Again the possibilities this introduces for developers is just great. It would bring MyBB into the current, and we wouldn't have to wait years (hopefully) for it.

Quote:We also have to look at the community activity, which as far as I can see is vastly reduced. In days gone by I'd check the community forums once a day at least using "View New Posts" and find at least a page of results, often several. Now, there's rarely ever even a full page of results when I check.

It's inevitable if we stay the current course, but can be vastly improved with the theme updates. The site is probably dropping way down google results because it isn't mobile friendly. Not to mention word of mouth. Better development technologies would increase 3rd party support and thus bring some more activity. No one wants to develop on an ancient system that isn't very fun.

Quote:This is a much more realistic vision than rebuilding MyBB from scratch. There's so many forum systems out there. We shouldn't be disheartened by how long things have taken, as other systems are taking just as long to catch up on what users want their forum system to do, in an ever more connected world.

Agree completely.

Quote:There would be a lot of breaking changes. Even though updating plugins was usually pretty simple so far it often took months until plugins were updated. Some never have been updated.

This relates back to a previous point, if plugins are more fun to create, and more users are around, these plugin updates would follow suit.

Quote:We can have that while discussing what role 1.x would play in the transition. It can go from only reusing 2.0 modules in 1.8 (which can be the logical conclusion in some 1.8 Issues) to making it structurally compatible with 2.x (these would still be different scripts, but the development gap would be decreased).

Anywhere that these codebases can share code just increases the reasoning for moving 1.8 toward 2.0.

Quote:Unfortunately most of the plugins get abandoned after a while. MyBB 1.8 is out for 3 years and users still ask to use older plugins (and they often work after changing the compatibility flag). It's tricky to find the right way to satisfy the users here. Some users still stay on 1.6 or even older.

This will be worse and worse the longer you let 1.8 stagnate and 2.0 be a pipe dream. The users need some things that they can't realistically wait 2 years for.

Quote:Re-using 2.0 modules and making it structurally compatible over time is pretty much what Tom and I are proposing - rather than a full rewrite, adapt the current software into a more modern piece of software over time. Had we done this from the start, we'd be a lot further ahead than we are now.

This. At some point you have to admit you're wrong for the betterment of the software. It's not too late, but it might be at some point in the future.

-----

I personally believe that a new theme is so overdue, it should be done before the new template system with Twig. It should be top priority and will result in some pretty immediate positive response from Google and users alike. I also think you should run some sort of campaign to promote it, whether through some beta testing social media posts, forum group or however else it'd be best handled. Users want to feel included, like they're helping, even if they aren't overly technical.

Really hope to see the push for this incremental update. Rewriting a whole software isn't just an actual crapton of work, it's a mental load as well. Sometimes it's overwhelming to look at the project and see how much is left. Developers deserve some mental reward for milestones, which can come from these incremental QoL improvements.

I'm in agreement with incremental updates to 1.8 so that it's made more modern rather than trying to build something new from the ground up. while it would be nice to start fresh, it's REALLY not realistic given how small our team is and the lack of time we seem to have.

(2017-10-05, 07:12 AM)andrewjs18 Wrote: [ -> ]I'm in agreement with incremental updates to 1.8 so that it's made more modern rather than trying to build something new from the ground up.  while it would be nice to start fresh, it's REALLY not realistic given how small our team is and the lack of time we seem to have.

If I may.....

Im extremely sceptical as of incremental upgrades.... done wrongly and you will kill every (even bigger than MyBB) project. If you want to follow this path, you need to have your subgoals as well as every step (including even single char (like enter, comma, etc) change) written very clearly and stick to it. Not to mention proficiency with you working tools.

Given the size of the team and their lack of time, incremental updates are doomed for failure here.

This is what I think.

(2017-10-05, 09:49 AM)devs Wrote: [ -> ]

(2017-10-05, 07:12 AM)andrewjs18 Wrote: [ -> ]I'm in agreement with incremental updates to 1.8 so that it's made more modern rather than trying to build something new from the ground up.  while it would be nice to start fresh, it's REALLY not realistic given how small our team is and the lack of time we seem to have.

If I may.....

Im extremely sceptical as of incremental upgrades.... done wrongly and you will kill every (even bigger than MyBB) project. If you want to follow this path, you need to have your subgoals as well as every step (including even single char (like enter, comma, etc) change) written very clearly and stick to it. Not to mention proficiency with you working tools.

Given the size of the team and their lack of time, incremental updates are doomed for failure here.

This is what I think.

Absolutely, if the community and team choose an incremental update path then everything will have to be planned - which components are being updated, what the aim of the change is. I don't agree that we'll have to plan ever comma change though - as that is what the change is xD but planning will be key.

But the main reason for choosing this path, like PHPBB did, is to pull the current codebase into the present while reducing the development cost of a full rewrite.

(2017-10-05, 03:58 AM)Eric J. Wrote: [ -> ]Anywhere that these codebases can share code just increases the reasoning for moving 1.8 toward 2.0.

Some areas of 1.x would be easier to rip out & replace than others, and some to the point of being able to be completed as a result of standard 1.8 maintenance development; making 2.0 completely dependent on 1.x incremental updates is at the opposite end of the spectrum, with maximum overhead.
Decisions in between would include a more or less significant jump between platforms that are currently conceptually incompatible.

As the theme system appears to be the main issue, it's probably better to list changes that will have to be applied to 1.8 that will make it more flexible first before throwing all core improvements over the fence (as it will be much easier to implement them in 2.x).
This would range from 1.8 process-compatible changes:

• improving theme management (versioning, updating) and fixing existing bugs,
  
• implementing updates to CSS files,
  
• making it possible for plugins to recognize 1.8 and 1.8+ themes (the core would include a portion of PluginLibrary to make it easier),
  
• improving theme & stylesheet visual editors,
  
• adjusting element placement, improving availability of modules & variables across templates, improving language strings with flexibility in mind (alternative, short names, available across the system)
  
• making theme variations (colors) possible to be changed on the front-end (user-specific),
  

to possible changes related to Twig implementation - that would have one upside of exposing the new system and syntax to 1.8 users. We could have to e.g. make all variables accessible to avoid adjusting all places where templates are evoked, still making the platform jump less painful.
Any plugins incompatibility would be limited to modifying themes - if the theme system changes prove to be worthwhile then it might be a fair solution.

Internal bits discussed in the staff thread would, in that case, be introduced depending on technical convenience.

(2017-10-05, 02:29 PM)Devilshakerz Wrote: [ -> ]

(2017-10-05, 03:58 AM)Eric J. Wrote: [ -> ]Anywhere that these codebases can share code just increases the reasoning for moving 1.8 toward 2.0.

Some areas of 1.x would be easier to rip out & replace than others, and some to the point of being able to be completed as a result of standard 1.8 maintenance development; making 2.0 completely dependent on 1.x incremental updates is at the opposite end of the spectrum, with maximum overhead.
Decisions in between would include a more or less significant jump between platforms that are currently conceptually incompatible.

Sure, I don't think 1.8 should "become" 2.0, so much as just incorporate any parts that could be in 2.0 and are feasible. That way work is still technically being done on 2.0, but 1.8 gets improved as a result.

(2017-10-05, 02:29 PM)Devilshakerz Wrote: [ -> ]

• improving theme management (versioning, updating) and fixing existing bugs
  

Agreed

(2017-10-05, 02:29 PM)Devilshakerz Wrote: [ -> ]

• implementing updates to CSS files
  

It should use Sass, optimally.

(2017-10-05, 02:29 PM)Devilshakerz Wrote: [ -> ]

• making it possible for plugins to recognize 1.8 and 1.8+ themes (the core would include a portion of PluginLibrary to make it easier)
  

Sure, this would be nice for plugin authors wanting backward compatibility.

(2017-10-05, 02:29 PM)Devilshakerz Wrote: [ -> ]

• improving theme & stylesheet visual editors
  

Yes, we could follow what Shade has been doing with his Fastyle plugin: https://github.com/Shade-/fastyle/tree/development
It will need to be updated style-wise, to fit more in line with the MyBB brand.

(2017-10-05, 02:29 PM)Devilshakerz Wrote: [ -> ]

• adjusting element placement, improving availability of modules & variables across templates, improving language strings with flexibility in mind (alternative, short names, available across the system)
  

If we use Twig that should help a lot. But by default having more variables available will be nice. For example, in 1.8 you cannot currently contextually show a guest information in the footer (That is removed from source for logged in users) without core changes or a plugin.

(2017-10-05, 02:29 PM)Devilshakerz Wrote: [ -> ]

• making theme variations (colors) possible to be changed on the front-end (user-specific),
  

Instead of directly implementing this feature, it would be better to add this capability for theme developers to take advantage of. You will need to be able to read cookies via PHP, and utilize them in the Sass (Or CSS) files. This would mean some sort of PHP parser for Sass with custom additions.

(2017-10-05, 02:29 PM)Devilshakerz Wrote: [ -> ]to possible changes related to Twig implementation - that would have one upside of exposing the new system and syntax to 1.8 users. We could have to e.g. make all variables accessible to avoid adjusting all places where templates are evoked, still making the platform jump less painful.
Any plugins incompatibility would be limited to modifying themes - if the theme system changes prove to be worthwhile then it might be a fair solution.

Twig can use block syntax, which can have things injected into them. This way a plugin author for example could just inject their code into a "main-nav" block, so that unless someone removes that block or changes the name, the actual HTML syntax can change freely with no plugin breakage. It would be great to get both devs and designers familiar with this system if it's planned to be used for the future of MyBB, and of course the huge code quality gain.

{% block main-nav %}
    {{ parent() }}
    {{ customPluginCode() }}
{% endblock main-nav %}

I'm not sure how the plugin developers can take advantage of this, as they'll need to execute this code inside of a Twig template. Something to be figured out I suppose.

----------

Another thing that REALLY needs to be addressed in 1.8 are the JS files. Lots of the code is old and not that well coded. It doesn't need to be typescript with all the bells and whistles, but at least ES6-first, transpiled.

One of the reasons the number of contributors is down is probably because students have a lot of free time and they're probably going to whatever the most hyped platform of the day is. E.g. Node.js

PHP is mostly on a downturn, these days, with the exception of Wordpress.
It's mostly a time thing. If Euan worked on 2.0 full-time, I'd probably be done in six months.

Things go easiest when you're rolling your own software.I can turn it into a little side project to learn a new language or something.

It's just pure gain. And PHP doesn't align with my career trajectory. I did it before. I built a forum software from scratch in PHP superior to 2.0 back in 2013 / 2015 because 1.8 was taking forever. It was ABB. I didn't sit and moan like devs. I just moved and acted.
It had action posts, alerts, widgets, sidebars, quick topic, AJAX Loading (although, it was layered on-top as a bit of sugar, not like the SPAs), etc.

But then, you have to worry about stupid shared hosts, the brands of stupid in PHP including the politics among it's (PHP's not mine, I didn't have any :d) core developers where they're constantly trying to twist each other's arms to get votes to sneak features in (it was like something out of the government), the fact that many are fleeing the language for Node, etc.

So, I just stepped away from that one day, and I could because it was my own project. A community isn't going to collapse because of that.
I could just do things largely at my own pace with no dependants. With MyBB, you can't do that. The team is probably getting stressed all the time from people hollering, "Where's 2.0?! MyBB's going to die at this rate! Save us, Euan!"

(2017-10-05, 10:16 PM)Azah Wrote: [ -> ]One of the reasons the number of contributors is down is probably because students have a lot of free time and they're probably going to whatever the most hyped platform of the day is. E.g. Node.js

I think that's why it's so important for MyBB to have an API.