(2018-01-05, 06:34 PM)Euan T Wrote: [ -> ]It is planned that 1.9.0 will be available at least as a beta verison within the first quarter (Q1) of 2018, though obviously the sooner the better.
(2022-07-19, 06:05 AM)wamp Wrote: [ -> ]Whether or not my work is ultimately adopted, potentially with amendments, remains to be seen, but it's at least something.
I wouldn't dare to hazard a guess at a release date though.
it's about 8 years (2878 days) since MyBB has released 1.8, after that no major version yet 
Euan, you probably meant to say that MyBB 1.9 will be available in the year 3018 because Q1 of 2018 happened 4 years ago
(2022-07-19, 10:48 AM)Matt Wrote: [ -> ] (2022-07-19, 02:21 AM)xXMoeXx Wrote: [ -> ]But I am starting to feel like there is going to be some very angry clients and customers if mybb 1.9 takes place.
What do you mean by clients and customers? I didn't realise MyBB was paid software or the MyBB Group services clients?
My apologies, I was referring to those developers that create projects for mybb like plugins and themes.
Does mybb want to go a purchase route in the future? Like VB...
I'm sorry, guys; I know this is a voluntary development, and my opinion indeed counts as very little as I don't get involved in the development; many guys forums owe their existence because of the excellent work here, and I can't thank you enough for everything you have done to this point. However, something has gone wrong in the approach taken, and now it's important to step back and review.
1.8 is no longer developed beyond security updates, 2.0 was abandoned despite being developed, and 1.9 has all but stalled. This situation you have placed the software in means that MyBB has stalled whilst other services continue to build on their platforms. It is very apparent that the implementation of Twig has obliterated development and probably killed off any realistic chance of 1.9 any light of day (or at least, the light of day with any fanfare)
Sometimes hard decisions must be made - ask yourself if what is being achieved in the background is worth it. because I think it's time to review exactly what you guys want and what's best for the platform
If MyBB 1.9 turns out to be the new Facebook when everyone loved Myspace (For its custom css Profiles) I'm going to be pissed.
(2022-07-24, 11:16 AM)NotAdmin Wrote: [ -> ]It is very apparent that the implementation of Twig has obliterated development and probably killed off any realistic chance of 1.9 any light of day (or at least, the light of day with any fanfare)
Their argument is that Twig is necessary for security on third party templates.
Yet, there are many lighter, easier, and much faster solution to improve security, for example:
Solution 1. Create an approved template repository where only known-good templates would be stored. All other templates would be offered at user's own choice and risk.
Solution 2. It would be relatively easy to write a simple parser which would check if all echo() and print() functions in a template were properly escaped with htmlspecialchars() when template is installed. Such parser would run only once during the initial installation of a template and if the template fails the parser's check then MyBB would refuse to install it.
I can probably think of several other simple solutions that take much less time and effort than implementing the Twig bloatware.
(2022-07-24, 11:16 AM)NotAdmin Wrote: [ -> ]It is very apparent that the implementation of Twig has obliterated development and probably killed off any realistic chance of 1.9 any light of day (or at least, the light of day with any fanfare)
I don't know where you got that from. Major parts of the conversion to Twig have already been completed in 2019:
https://github.com/mybb/mybb/issues/2972
(2022-07-26, 05:25 AM)jimski Wrote: [ -> ]Solution 1. Create an approved template repository where only known-good templates would be stored. All other templates would be offered at user's own choice and risk.
Thoroughly reviewing an theme that may contain thousands of lines of code can take hours. It's unrealistic that the small team can handle it. Also it would have a negative effect on all the 3rd party sites offering themes.
(2022-07-26, 05:25 AM)jimski Wrote: [ -> ]Solution 2. It would be relatively easy to write a simple parser which would check if all echo() and print() functions in a template were properly escaped with htmlspecialchars() when template is installed. Such parser would run only once during the initial installation of a template and if the template fails the parser's check then MyBB would refuse to install it.
It depends on the context whether a variable or function can be harmful or not. A simple parser can hardly check without the risk of serious security problems slipping through or false positives.
(2022-07-26, 05:25 AM)jimski Wrote: [ -> ]I can probably think of several other simple solutions that take much less time and effort than implementing the Twig bloatware.
So writing a security critical parser by themselves is simpler than implementing a proven library that is maintained by somebody else?
(2022-07-26, 07:55 PM)StefanT Wrote: [ -> ]Thoroughly reviewing an theme that may contain thousands of lines of code can take hours. It's unrealistic that the small team can handle it. Also it would have a negative effect on all the 3rd party sites offering themes.
Oh, please you don't need to look through thousands of lines of code. You only need to look at the content of PHP tags.
(2022-07-26, 07:55 PM)StefanT Wrote: [ -> ]It depends on the context whether a variable or function can be harmful or not. A simple parser can hardly check without the risk of serious security problems slipping through or false positives.
The solution which I presented is not full-proof, but neither is Twig.
https://snyk.io/vuln/composer:twig%2Ftwig
(2022-07-26, 07:55 PM)StefanT Wrote: [ -> ]So writing a security critical parser by themselves is simpler than implementing a proven library that is maintained by somebody else?
I didn't say "security critical" as no such thing exists. Yes, a parser to screen for just two PHP functions [echo() and print()] is very simple. One could probably write a Regular expression to do that. And you can add screeneing for additional PHP functions over time. We managed without Twig for the entire life of MyBB so we can handle gradual security improvement over time.
Every system can be penetrated. The question is what is the price you pay for improved security.
In case of Twig it is:
1. Major performance degaradation.
2. Lack of backwards compatibility.
3. Major delay in development (YEARS of DELAY).
4. Extra difficulty during debug.
5. Additional complication during deployment.
6. Additional library to keep up to date (for the sake of security
)
7. Many dissatisfied former users.
For me this tradeoff is not worth it. For the Dev taem it apparently is, and that's probably one of the reasons why MyBB is loosing users as well as developers.
The Dev team didn't listen when I was warning you six years ago the about idiocy of Laravel bloatware.
I will check back with you in six years.
(2022-07-27, 02:03 AM)jimski Wrote: [ -> ] (2022-07-26, 07:55 PM)StefanT Wrote: [ -> ]Thoroughly reviewing an theme that may contain thousands of lines of code can take hours. It's unrealistic that the small team can handle it. Also it would have a negative effect on all the 3rd party sites offering themes.
Oh, please you don't need to look through thousands of lines of code. You only need to look at the content of PHP tags.
(2022-07-26, 07:55 PM)StefanT Wrote: [ -> ]It depends on the context whether a variable or function can be harmful or not. A simple parser can hardly check without the risk of serious security problems slipping through or false positives.
The solution which I presented is not full-proof, but neither is Twig.
https://snyk.io/vuln/composer:twig%2Ftwig
(2022-07-26, 07:55 PM)StefanT Wrote: [ -> ]So writing a security critical parser by themselves is simpler than implementing a proven library that is maintained by somebody else?
I didn't say "security critical" as no such thing exists. Yes, a parser to screen for just two PHP functions [echo() and print()] is very simple. One could probably write a Regular expression to do that. And you can add screeneing for additional PHP functions over time. We managed without Twig for the entire life of MyBB so we can handle gradual security improvement over time.
Every system can be penetrated. The question is what is the price you pay for improved security.
In case of Twig it is:
1. Major performance degaradation.
2. Lack of backwards compatibility.
3. Major delay in development (YEARS of DELAY).
4. Extra difficulty during debug.
5. Additional complication during deployment.
6. Additional library to keep up to date (for the sake of security )
7. Many dissatisfied former users.
For me this tradeoff is not worth it. For the Dev taem it apparently is, and that's probably one of the reasons why MyBB is loosing users as well as developers.
The Dev team didn't listen when I was warning you six years ago the about idiocy of Laravel bloatware.
I will check back with you in six years.
It has already been said that the theme conversion for Twing ended in 2019...
The development of 1.9 has finally started to move after years of rebasing.
I can't believe you're proposing something that will throw all the mybb developers' years of work down the drain.
It's too disrespectful.
And apparently you haven't followed the development of mybb these last few years. The downtime most of the time wasn't because of Twing. But rebase that never seemed to end.
If you don't want Twing at all then why don't you make the conversion for your system and show with work that what you are proposing is better than what has been done so far.
(2022-07-27, 11:49 AM)martec Wrote: [ -> ]If you don't want Twing at all then why don't you make the conversion for your system and show with work that what you are proposing is better than what has been done so far.
Like I've said before, because it's easier for people to go on about how they don't agree with a decision and how they'd do it differently than it is to put their money where their mouth is and actually do it.
https://github.com/mybb/mybb/fork
If people want to take the project in a different direction, the fork button is right here. If it's so easy and people have the capital to invest in either their own time or other people's, I don't know why nobody has (successfully) done so by now. If people have heavily modified sites and the money to invest in the project itself, there's nothing really stopping them investing the money in their own site and developing what they need. Any free software is what it is, you can either use it as-is or build what you need on top of it, like literally any other free software.
Also, for what it's worth, after a quick Google search, phpBB also internally uses Twig syntax and also has plans to use it in future, and in fact has users who actively want to use it, so if it's suitable for the most popular free forum software, I don't see the issue. There's a reason modern applications lean heavily on purpose-built libraries maintained by other people, there's no point in reinventing the wheel and doing everything manually.
(2022-07-27, 11:49 AM)martec Wrote: [ -> ]I can't believe you're proposing something that will throw all the mybb developers' years of work down the drain.
It's too disrespectful.
Disrespectful ???
There is nothing more disrespectful for the Dev team than ignoring wishes of MyBB users who were telling you 8 years ago that maintaining backward compatibility is very important to them as they invested years of work into their forums.
But you told the users to take a hike and first messed up version 2.0 on Laravel and then you got fixated on Twig and demolished backward compatibility.
And now you wonder why people don't want to contribute to the development and users are switching to other BBs.