MyBB Community Forums

As the owner of the largest MyBB forum I can say that performance-wise for the templates in the database it's not really an issue. And exactly what tables that may not have primary keys are a problem?

Quote:So my question is to the copyright holder(s) if he/she/they will be willing to issue a separate MIT license.

Now you're just being a troll. Seriously, you have no need for this.

Quote:I would love to see a continuation of the 1.X series (since I'm invested in that ecosystem) but I totally understand why we're not going to get it. I'm really grateful for the work the team has done and continues to do on 1.8.

Pretty sure the same day that MyBB announces the end of 1.8x support that forks will open.

FYI, just noticed this is a semi-old thread.

Quote:Going to Laravel will take the project towards more OOP and entangle it into more complexity . Yes, I know that the whole world is writing OOP but there s a small albeit growing number of programmers who view OOP as a form of disease. I'm one of them :

I tend to agree but that's a separate discussion.

Quote:1. Unlike the include() the eval() function can't be cached by built-in PHP OPcache. Also there are some difficulties with the debugging

$templates is grabbed from a cache by a single database query. It's fairly effiicient as it is.

Quote:MyBB 1.8 is made a lot more flexible with plugins

Agreed that it's flexible and partially that's due to the ease of having them in the database. I remember dealing with phpBB when they had them stored in files and what a pain in the butt that was when creating custom code.

Quote:Releasing another version and then 2.0 would mean more fragmentation and something else to support. The thing is we could ask 10 different people their opinion and get 10 different responses, 10 different frameworks to use, 10 different design methodologies, etc etc. We're using established frameworks, libraries and methodologies so there is some sort of familiarity for the wider PHP community, rather than coming up with our own frameworks (that was the original 2.0 plan), own way of doing things, or re-hashing decade-old code into new structures.

You make a valid point about 10 different responses. Which is why I think the direction 2.0 is taking is a mistake. MyBB is a success based on the current code structure. The team is the one making a change. While using new standards might be appealing you should respect the fact that you will be starting from scratch and thus forcing each of your MyBB admins to also start from scratch. You think you're the only guys that have to code and keep MyBB updated. What about the hundreds or thousands of admins running MyBB with an incredible amount of custom plugins (the #1 feature of MyBB) being told they either have to wait for the plugin to be updated, update it themselves, not upgrade, or remove the plugin.

Honestly, I'll go with XenForo before I go MyBB 2.0. If I'm forced to start over I may as well go with a code-base that's years old with huge 3rd party support.

I understand MyBB wants to keep their code base current. And I think MyBB chose the best Framework. But if it ain't broke, don't fix it...that does apply here.

Quote:From that time I've created few hundreds different themes for a various CMS (mostly WordPress) and changed my point of view. Yes, in some cases the full system rewrite with modern tools is reasonable and necessary, but in a lot of others cases this is not a good idea. The main problem is the complexity of this task. If the system is large and complicated its rewrite will require a lot of working hours. If the team is small and resources are limited the continious partial refactoring will be the best solution.

I've always held the view that changing MyBB to a 3rd party framework wasn't necessary. I believe MyBB 1.8x is a framework itself which should be built upon not trashed. Any effort into 2.0 could be instead placed into making 1.8x bug free and feature rich. I'd much rather see development from the team of full mobile support.

Quote:While it indeed takes much time to rewrite the whole software we've reached a point where maintaining the old legacy code is not reasonable. It's simply not possible to replace the template system or the database abstraction without rewriting major parts of the existing code.

Yes, pretty much the decision to use a framework made it immediately clear that all current MyBB code is going to be trashed.

Caveat: None of this is meant to attack the project or besmirch efforts of the team. I'm just expressing my view of the direction MyBB it taking.

Quote:I've always held the view that changing MyBB to a 3rd party framework wasn't necessary.  I believe MyBB 1.8x is a framework itself which should be built upon not trashed. Any effort into 2.0 could be instead placed into making 1.8x bug free and feature rich.  I'd much rather see development from the team of full mobile support.

Yes, pretty much the decision to use a framework made it immediately clear that all current MyBB code is going to be trashed.  

Caveat: None of this is meant to attack the project or besmirch efforts of the team.  I'm just expressing my view of the direction MyBB it taking.

Maybe the team somehow able to make the 1.8x plugins usable on 2.0, but since the progress is worrying, they might just dump every possibility that further holds them behind time.

(2016-11-09, 01:11 AM)fallr Wrote: [ -> ]Maybe the team somehow able to make the 1.8x plugins usable on 2.0, but since the progress is worrying, they might just dump every possibility that further holds them behind time.

And why would they do that? It would require re-programming them.

(2016-11-09, 01:30 AM)Ben Cousins Wrote: [ -> ]And why would they do that? It would require re-programming them.

Because anyone can develop the plugins. However, the mybb developers always sounded like they would make the plugins compatible with 2.0, what I said was "might".

(2016-11-09, 06:56 AM)fallr Wrote: [ -> ]

(2016-11-09, 01:30 AM)Ben Cousins Wrote: [ -> ]And why would they do that? It would require re-programming them.

Because anyone can develop the plugins. However, the mybb developers always sounded like they would make the plugins compatible with 2.0, what I said was "might".

"Might" suggests that they have the possibility. I'm leaning towards no, given the decisions made for 2.0

We've never said that there's even the remotest possibility that 1.8 plugins will work with 2.0 unfortunately.

(2016-11-08, 09:47 PM)labrocca Wrote: [ -> ]You make a valid point about 10 different responses.  Which is why I think the direction 2.0 is taking is a mistake.  MyBB is a success based on the current code structure.  The team is the one making a change.  While using new standards might be appealing you should respect the fact that you will be starting from scratch and thus forcing each of your MyBB admins to also start from scratch.  You think you're the only guys that have to code and keep MyBB updated.  What about the hundreds or thousands of admins running MyBB with an incredible amount of custom plugins (the #1 feature of MyBB) being told they either have to wait for the plugin to be updated, update it themselves, not upgrade, or remove the plugin.

This is the reason there haven't been major changes to MyBB 1.x. The biggest change in the last 10 years was probably switching to jQuery. Maintaining compatibility was more important than anything else - which comes at a price...

(2016-11-08, 09:47 PM)labrocca Wrote: [ -> ]But if it ain't broke, don't fix it...that does apply here.

While I wouldn't say MyBB 1.x is broken it has some issues we can't address without rewriting major parts. The current code base is prone to SQL injection and XSS vulnerabilities and there have been many compatibility issues with SQLite and PgSQL (this especially applies to plugins). Just to name a few things...

(2016-11-08, 09:47 PM)labrocca Wrote: [ -> ]

Quote:1. Unlike the include() the eval() function can't be cached by built-in PHP OPcache. Also there are some difficulties with the debugging

$templates is grabbed from a cache by a single database query.  It's fairly effiicient as it is.

I spoke about a quite different type of caching. The PHP engine has the built in OPcode caching module since 5.5 version. It allows to compile the code from the included files once and store the it in the OPcache. This optimization significantly increases the script performance. Unfortunately the PHP engine is not able to cache the dynamic generated code in eval statements. The code parse is in 2-10 times slower in this case.

Speaking about performance, I need to mention the Twig templating engine. Yes, it's cool and trendy, but it also brings a big performance overhead. Yes, its templates is compiling in PHP-files, but there are a lot of dynamic not cacheable functions calls like call_user_func_array(). Its performance is comparable to eval.

(2016-11-09, 01:11 AM)fallr Wrote: [ -> ]Maybe the team somehow able to make the 1.8x plugins usable on 2.0, but since the progress is worrying, they might just dump every possibility that further holds them behind time.

Unfortunately, all the current extensions for 1.8 will not work on 2.0. They should be completely rewritten to work on different system.

Quote:The current code base is prone to SQL injection and XSS vulnerabilities and there have been many compatibility issues with SQLite and PgSQL (this especially applies to plugins).

Any figures on how many use something besides MySQL or MariaDB (100% compatible)? Mainly just curious about how important that truly is. I always thought it was a mistake to offer options that were on the fringe. And absolutely the move to Jquery was a good one.

Quote:Speaking about performance, I need to mention the Twig templating engine. Yes, it's cool and trendy, but it also brings a big performance overhead.

MyBB 2.0 is almost certainly going to be less efficient when it comes to performance. That's the nature of using Frameworks. Their main appeal for developers is speed of deployment (development time). Which I think doesn't apply to MyBB. We won't see 2.0 for years still. Which is why I really don't care that it's going to use framework anyways. It's unlikely we'll ever see it and even more unlikely I'll ever upgrade my 1.x brand forums to use it.

(2016-11-11, 11:47 PM)labrocca Wrote: [ -> ]Any figures on how many use something besides MySQL or MariaDB (100% compatible)? Mainly just curious about how important that truly is. I always thought it was a mistake to offer options that were on the fringe.

We do not have figures. MySQL is of course the most important DBMS for us since it's available on almost every shared hosting environment. And even when SQLite or PgSQL is available most use MySQL because a lot of plugins just work with MySQL.

With a proper database abstraction layer supporting multiple DBMS is fortunately much easier. Laravel even supports MS SQL.