(2018-10-02, 10:03 PM)lomazzo Wrote: [ -> ]Guys please, I'm dying for mybb 1.9. Surely you can release it by November? 
What will happen to you if MyBB 1.9.xx is not released in November?
We're already trying to move all JS into external files, the only thing that may be problematic there is accessing language strings and settings from JS. There are ways around that, we just need to decide what we're going to do about it really.
(2018-10-02, 10:03 PM)lomazzo Wrote: [ -> ]Guys please, I'm dying for mybb 1.9. Surely you can release it by November?
Given the alpha is not yet available it is not so likely but who knows.
plugin "structure" will have big changes?
(2018-10-05, 11:19 AM)Supryk Wrote: [ -> ]plugin "structure" will have big changes?
Plugins will need to be updated to account for the new theme/template structure; however, no major changes to the way plugins are structured are planned for 1.9. Changes to plugin structure are planned for a future 1.x release (e.g. 1.10 or later).
Any thoughts on removing the code in htaccess that turns off ModSecurity by default, in the next versions? That does not look like a great idea, and I might be wrong but it pretty much "smells" from a security point of view. I don't know of any other popular web applications that need to turn off ModSecurity by default in order to work. By the way, I only started to use MyBB recently, but I haven't had any problems with ModSecurity on (MyBB 1.8.x). IMO you shouldn't disable ModSecurity for every user by default if the issues arise only for some people on some occasions.
(2018-10-06, 08:03 PM)reed Wrote: [ -> ]Any thoughts on removing the code in htaccess that turns off ModSecurity by default, in the next versions? That does not look like a great idea, and I might be wrong but it pretty much "smells" from a security point of view. I don't know of any other popular web applications that need to turn off ModSecurity by default in order to work. By the way, I only started to use MyBB recently, but I haven't had any problems with ModSecurity on (MyBB 1.8.x). IMO you shouldn't disable ModSecurity for every user by default if the issues arise only for some people on some occasions.
We would, if we could rely on hosts to have sane mod_security setups. Unfortunately, that is not the case.
MyBB itself works with mod_security on, but we have seen many cases where poorly configured servers block posts containing things like the "[php]" code tags or a snippet of some SQL query (such as you might see on these boards when providing support). We ended up recommending people turn it off after having dealt with quite a large number of support queries that boiled down to being caused by the module and its configuration (something that isn't always obvious at first glance).
What makes MyBB different from other popular web application (Wordpress, Joomla, Magento, etc.)? I've never seen other web applications try to disable ModSecurity. I guess they probably have the same problems, potentially, with ModSecurity, yet they don't try to disable it. That's the point I really don't understand. If ModSecurity can cause some problems on some occasions, it's up to the user (or the sysadmin or the hosting provider) to deal with it. It would be like disabling HTTPS by default and forcing HTTP, only because some users sometimes have trouble with expired or untrusted certificates or badly configured hosting providers.
ModSecurity has a purpose, and I believe it can be pretty useful even without a specific configuration for MyBB (default rules). I believe most users, if not all, would prefer to leave it enabled, or at least be aware that it will be disabled. In fact, I would never have known it was going to be disabled if I hadn't looked at the code in the htaccess file. That file is provided for enabling "better URLs" (rewriting), and a user would expect that enabling such file would just do that, but instead it also tries to disable ModSecurity. That's what kind of pissed me off. If I hadn't looked at the code, I would have thought I was just enabling "better URLs", and ModSecurity would suddenly have been disabled for no related reason and without my consent. So, in conclusion, that code shouldn't be there. It does something that most users would not want to do, and it does it secretly and unexpectedly as a result of something totally unrelated (enabling "better URLs"). This has no sense at all. A solution might be to leave it there but comment it out by default, or move it to a different htaccess file (named for example "htaccess-modsecurity.txt") or something like that.
