https://www.opencart.com/index.php?rout ... ad/history
Inside the code we can see that its version is 3.1.1.0 - ok. But why did they release a new semi-major version of an older branch!? It has a lot of syntax changes making many existing ocmod modifications incompatible with 3.0.x.x version. What makes them update the minor PHP version to 8.1? I am really confused. Who is the target audience of that version? I thought Opencart 4.0.x.x. is the bright future.
Many changes itself are very controversial. Why did they change array declaration to its shorter version [], why they changed "else if" to "elseif", etc. Opencart 3 should keep its style and less changes are good for maintenance unless they close Opencart 4 branch and continue development of Opencart 3.1.x.
In my opinion, Opencart 3.x.x.x is stillborn. There are no reasons for regular users to upgrade to this version, but new users will choose Opencart 4.0.1.x probably. What do you think? Please share your thoughts regarding that version. Thank you.
I wasn't even aware this branch was already released. To answer your question, in regard to maintenance, there are more reasons than one believes including the backend of the design itself. I wouldn't suggest quite just 'yet' to upgrade to that version since, obviously, the opencart-3 is still under development.karapuz wrote: ↑Thu Oct 06, 2022 5:00 amOpencart core developers do not stop to surprise me... Yesterday, Opencart 3.x.x.x was released. Yes, they show it without minor version numbers on the downloads page.
https://www.opencart.com/index.php?rout ... ad/history
Inside the code we can see that its version is 3.1.1.0 - ok. But why did they release a new semi-major version of an older branch!? It has a lot of syntax changes making many existing ocmod modifications incompatible with 3.0.x.x version. What makes them update the minor PHP version to 8.1? I am really confused. Who is the target audience of that version? I thought Opencart 4.0.x.x. is the bright future.
Many changes itself are very controversial. Why did they change array declaration to its shorter version [], why they changed "else if" to "elseif", etc. Opencart 3 should keep its style and less changes are good for maintenance unless they close Opencart 4 branch and continue development of Opencart 3.1.x.
In my opinion, Opencart 3.x.x.x is stillborn. There are no reasons for regular users to upgrade to this version, but new users will choose Opencart 4.0.1.x probably. What do you think? Please share your thoughts regarding that version. Thank you.
Dedication and passion goes to those who are able to push and merge a project.
Regards,
Straightlight
Programmer / Opencart Tester
Well, too many are still using OC 3.x (3.0.3.8 should be used) - because 4.x is still not useable (too many bugs).karapuz wrote: ↑Thu Oct 06, 2022 5:00 amOpencart core developers do not stop to surprise me... Yesterday, Opencart 3.x.x.x was released. Yes, they show it without minor version numbers on the downloads page.
https://www.opencart.com/index.php?rout ... ad/history
Inside the code we can see that its version is 3.1.1.0 - ok. But why did they release a new semi-major version of an older branch!? It has a lot of syntax changes making many existing ocmod modifications incompatible with 3.0.x.x version. What makes them update the minor PHP version to 8.1? I am really confused. Who is the target audience of that version?
Should be, but is (currently) not.
There are many reasons why php 8.1.x IS the preferred base for using webistes beginng with the 1st of January 2023-karapuz wrote: ↑Thu Oct 06, 2022 5:00 amMany changes itself are very controversial. Why did they change array declaration to its shorter version [], why they changed "else if" to "elseif", etc. Opencart 3 should keep its style and less changes are good for maintenance unless they close Opencart 4 branch and continue development of Opencart 3.1.x.
In my opinion, Opencart 3.x.x.x is stillborn. There are no reasons for regular users to upgrade to this version, but new users will choose Opencart 4.0.1.x probably. What do you think? Please share your thoughts regarding that version. Thank you.
I am sure (you as developer will know that ..), that php 7.x is dead with the end of this year.
Sorry, but if this is true, those developers offering such extensions should quickly learn how to code for php 8.x.It has a lot of syntax changes making many existing ocmod modifications incompatible with 3.0.x.x version.
Otherwise those extensions should be removed (from anywhere).
Full Stack Web Developer :: Dedicated OpenCart Development & Support DACH Region
Contact for Custom Work / Fast Support.
Personally I recommend 3.0.x.x_Maintenance branch from github, which is like OC 3.0.3.8, with some more bugfixes and support for PHP 8.0 and 8.1.
It will take some time for OpenCart 4 to become stable enough for usage on live sites, especially also for 3rd party extension developers to port their extensions to OpenCart 4.
Export/Import Tool * SpamBot Buster * Unused Images Manager * Instant Option Price Calculator * Number Option * Google Tag Manager * Survey Plus * OpenTwig
They are not talking about changes to PHP 8 but about the changes to OpenCart 3.1.1.x . If you do a file comparison there are too many changes that aren't bug fixes, just changes in coding style.OSWorX wrote: ↑Thu Oct 06, 2022 12:14 pmSorry, but if this is true, those developers offering such extensions should quickly learn how to code for php 8.x.It has a lot of syntax changes making many existing ocmod modifications incompatible with 3.0.x.x version.
Otherwise those extensions should be removed (from anywhere).
That is correct. Those extensions can also be maintained rather than removed, in the meantime, since the scenario will be the same once users will be upgrading to OC 4. At the end of the day, resellers still have a second chance before the PHP deadline arises. While syntaxes might still require changing, we also need to consider the fact that it won't be any different on OC 4 (with the exception of the extension development from the extension folder by design).OSWorX wrote: ↑Thu Oct 06, 2022 12:14 pmWell, too many are still using OC 3.x (3.0.3.8 should be used) - because 4.x is still not useable (too many bugs).karapuz wrote: ↑Thu Oct 06, 2022 5:00 amOpencart core developers do not stop to surprise me... Yesterday, Opencart 3.x.x.x was released. Yes, they show it without minor version numbers on the downloads page.
https://www.opencart.com/index.php?rout ... ad/history
Inside the code we can see that its version is 3.1.1.0 - ok. But why did they release a new semi-major version of an older branch!? It has a lot of syntax changes making many existing ocmod modifications incompatible with 3.0.x.x version. What makes them update the minor PHP version to 8.1? I am really confused. Who is the target audience of that version?
Should be, but is (currently) not.
There are many reasons why php 8.1.x IS the preferred base for using webistes beginng with the 1st of January 2023-karapuz wrote: ↑Thu Oct 06, 2022 5:00 amMany changes itself are very controversial. Why did they change array declaration to its shorter version [], why they changed "else if" to "elseif", etc. Opencart 3 should keep its style and less changes are good for maintenance unless they close Opencart 4 branch and continue development of Opencart 3.1.x.
In my opinion, Opencart 3.x.x.x is stillborn. There are no reasons for regular users to upgrade to this version, but new users will choose Opencart 4.0.1.x probably. What do you think? Please share your thoughts regarding that version. Thank you.
I am sure (you as developer will know that ..), that php 7.x is dead with the end of this year.
Sorry, but if this is true, those developers offering such extensions should quickly learn how to code for php 8.x.It has a lot of syntax changes making many existing ocmod modifications incompatible with 3.0.x.x version.
Otherwise those extensions should be removed (from anywhere).
Dedication and passion goes to those who are able to push and merge a project.
Regards,
Straightlight
Programmer / Opencart Tester
The coding style is not the only thing that's been focused on. What has also been focused are the use of modern arrays instead of the old ways since the compatibility with PHP 8 as OC 4 also has delivered. Based on extensions maintenance, that will also create alleged work for extension developers to follow these arrays as opposed to upgrade to OC 4 straight ahead and convert all these arrays on anyhow. As a result, all roads lead to the same dead-end. It is simply a matter of using the easiest path to get there and, that being, for extension developers to use the most similar codes from the core as they can in order to reduce the workload in the future. At the end of the day, there will also be changes involves. This time, industrial changes also come into play and could only been avoided for a temporary time until now.ADD Creative wrote: ↑Thu Oct 06, 2022 6:56 pmThey are not talking about changes to PHP 8 but about the changes to OpenCart 3.1.1.x . If you do a file comparison there are too many changes that aren't bug fixes, just changes in coding style.OSWorX wrote: ↑Thu Oct 06, 2022 12:14 pmSorry, but if this is true, those developers offering such extensions should quickly learn how to code for php 8.x.It has a lot of syntax changes making many existing ocmod modifications incompatible with 3.0.x.x version.
Otherwise those extensions should be removed (from anywhere).
The code alignment is only from the core as users are already encouraged to use the Event Engine as opposed to the OCMod engine, starting from OC 4, which means that regardless how the core codes will look like, extension developers can still code their own ways with their extensions.
Dedication and passion goes to those who are able to push and merge a project.
Regards,
Straightlight
Programmer / Opencart Tester
Your opencart-3 repository bugfixes and the added support for PHP 8 were useful.
However, most of what you did to the opencart-3 repository where unnecessary coding style and cosmetic changes.
By contrast, it only took a few bugfixes and minor changes to make the stable OC 3.0.3.8 also work for PHP 8. And now many developers are focusing their work on OpenCart 4.
Export/Import Tool * SpamBot Buster * Unused Images Manager * Instant Option Price Calculator * Number Option * Google Tag Manager * Survey Plus * OpenTwig
A few? You can speak for yourself on that. If that'd be the case, even other users on the Pull Requests section of opencart-3 wouldn't need to address their commits. As the commit logs describes, in regard to bug-fixes, I think their efforts also needs to be considered here as opposed to a few. It has been a season maintenance now of what hasn't been taken care of for years. Granted, there were other projects along the way but that does not mean that minimal changes were only required in there, by design. Just to convert all methods into PHP 8 wasn't a small task, but yet, what do we know? It's mostly done. The only problematic that remains is the extensions, such as Amazon Login and Amazon Login Pay, due to undocumented APIs from the models. Fortunately, Daniel is taking care of that since this week on OC 4 on the core models in the needs extension developers requires that information with their local / remote APIs.JNeuhoff wrote: ↑Fri Oct 07, 2022 12:27 am@Straightlight: Long post. The bottom line is this:
Your opencart-3 repository bugfixes and the added support for PHP 8 were useful.
However, most of what you did to the opencart-3 repository where unnecessary coding style and cosmetic changes.
By contrast, it only took a few bugfixes and minor changes to make the stable OC 3.0.3.8 also work for PHP 8. And now many developers are focusing their work on OpenCart 4.
That being said, extension developers are also greatly encouraged to do the same during their development especially if something needs to stick to the core to avoid those kinds of issues in the future. As for extension developers focusing their work on Opencart 4, that is still great news, however.
Dedication and passion goes to those who are able to push and merge a project.
Regards,
Straightlight
Programmer / Opencart Tester
Makes me really laughing when I read something like this - the more when everybody is talking here about php 8.x
The array short notation was introduced with php 5.4: https://www.php.net/releases/5_4_0.php
And this is ages ago - to be more specific: 1st of March 2012
So nothing new - therefore who cares about such nowadays?
OpenCart could (and should) use this short notation since the 1.5.x releases.
Full Stack Web Developer :: Dedicated OpenCart Development & Support DACH Region
Contact for Custom Work / Fast Support.
It's good to know that the short version has been created by the industry since over 10 years ago now. I guess it was more than time to do something about it.OSWorX wrote: ↑Fri Oct 07, 2022 5:56 amMakes me really laughing when I read something like this - the more when everybody is talking here about php 8.x
The array short notation was introduced with php 5.4: https://www.php.net/releases/5_4_0.php
And this is ages ago - to be more specific: 1st of March 2012
So nothing new - therefore who cares about such nowadays?
OpenCart could (and should) use this short notation since the 1.5.x releases.
Dedication and passion goes to those who are able to push and merge a project.
Regards,
Straightlight
Programmer / Opencart Tester
I would say, a "Developer" should know such basics!straightlight wrote: ↑Fri Oct 07, 2022 9:19 amIt's good to know that the short version has been created by the industry since over 10 years ago now. I guess it was more than time to do something about it.
An enduser does not care about, he wants only that everything is fully working.
Full Stack Web Developer :: Dedicated OpenCart Development & Support DACH Region
Contact for Custom Work / Fast Support.
Yes, this is what they should release as a maintenance release, I guess.Personally I recommend 3.0.x.x_Maintenance branch from github, which is like OC 3.0.3.8, with some more bugfixes and support for PHP 8.0 and 8.1.
Exactly.They are not talking about changes to PHP 8 but about the changes to OpenCart 3.1.1.x . If you do a file comparison there are too many changes that aren't bug fixes, just changes in coding style.
It does not matter how long this syntax exists, it is about code compatibility. Opencart 3 modifications are heavily based on ocmod patches that use string comparison. Any ocmod pattern relying on the array( word is broken. And please don't say that Opencart 3 modifications should be based on the events system, they don't in the most cases.And this is ages ago - to be more specific: 1st of March 2012
Regarding php 8.x. It is not a huge problem to switch even a standard Opencart 1.5.x to php 8. The amount of work heavily depends on 3rd party modules installed. The real problem might be when someday php will force using the strict_types syntax where all function parameters and return values have to have their types declared. That will be the time when any old code without that syntax will be dead. In my opinion, this revolution should not happen in any near future (2-4 years), so there were no need to add type declarations to Opencart 3. Most likely Opencart 3 will be retired as soon as Opencart 4 gets more stable (8-16 months).
+ 1 . Totally agree.OSWorX wrote: ↑Fri Oct 07, 2022 5:08 pmI would say, a "Developer" should know such basics!straightlight wrote: ↑Fri Oct 07, 2022 9:19 amIt's good to know that the short version has been created by the industry since over 10 years ago now. I guess it was more than time to do something about it.
An enduser does not care about, he wants only that everything is fully working.
Dedication and passion goes to those who are able to push and merge a project.
Regards,
Straightlight
Programmer / Opencart Tester
It also involves core codes since the returned value types also depends starting with PHP 8. Just yesterday, more bugfixes were added along with the work of the indents that were already declared in the past on Github Opencart and on the forum that were not added on the maintenance branch. For instance, conditional closing IF statement that was missing in a TWIG file. This week, $data from the controller had to be renamed to $post_data because $data is already reserved by the engine and third-party extensions from the core were using the array at their own will.karapuz wrote: ↑Fri Oct 07, 2022 6:29 pmThank you all for participating in the discussion.
Yes, this is what they should release as a maintenance release, I guess.Personally I recommend 3.0.x.x_Maintenance branch from github, which is like OC 3.0.3.8, with some more bugfixes and support for PHP 8.0 and 8.1.
Exactly.They are not talking about changes to PHP 8 but about the changes to OpenCart 3.1.1.x . If you do a file comparison there are too many changes that aren't bug fixes, just changes in coding style.
It does not matter how long this syntax exists, it is about code compatibility. Opencart 3 modifications are heavily based on ocmod patches that use string comparison. Any ocmod pattern relying on the array( word is broken. And please don't say that Opencart 3 modifications should be based on the events system, they don't in the most cases.And this is ages ago - to be more specific: 1st of March 2012
Regarding php 8.x. It is not a huge problem to switch even a standard Opencart 1.5.x to php 8. The amount of work heavily depends on 3rd party modules installed. The real problem might be when someday php will force using the strict_types syntax where all function parameters and return values have to have their types declared. That will be the time when any old code without that syntax will be dead. In my opinion, this revolution should not happen in any near future (2-4 years), so there were no need to add type declarations to Opencart 3. Most likely Opencart 3 will be retired as soon as Opencart 4 gets more stable (8-16 months).
It's these sorts of things that helps the platform to improve. As for the OC 3 retirement, people used to say the same for OC 1.5 and OC 2. Yet, they are still enlisted in the downloads page, however.
Dedication and passion goes to those who are able to push and merge a project.
Regards,
Straightlight
Programmer / Opencart Tester
I agree with all of this. IMO 3.1.x.x should be a 'gold copy' of the 3 series and extends the useful life not an enigma that is another one off. I wouldn't use this new version but WILL use the maintenance branch.JNeuhoff wrote: ↑Thu Oct 06, 2022 6:52 pmWhile there are some valid reasons for a 3.1.x.x series, especially for PHP 8.1 support, the opencart-3 repository upon which it is based, also introduced some unnecessary changes causing some issues with backward-compatibility with 3.0.3.8, which in turn could cause some 3rd party extensions not to work with opencart-3.
Personally I recommend 3.0.x.x_Maintenance branch from github, which is like OC 3.0.3.8, with some more bugfixes and support for PHP 8.0 and 8.1.
It will take some time for OpenCart 4 to become stable enough for usage on live sites, especially also for 3rd party extension developers to port their extensions to OpenCart 4.
Mike
cue4cheap not cheap quality
Up to you. Take note, however, that none of the OC versions, whether it's the old recurring payments, or the new subscription systems, originating from the maintenance branch, oc-3 branch, or the MB branch - all of them don't have the final settlement from the OC admin recurring or from the new subscription system when it comes to the type field as being mandatory from the database, by design. At the end of the road, we're all stuck in until resolved in any case. The oc-3 branch also contains the leftovered bug-fixes that the maintenance branch doesn't have. If you wish to remain behind with the leftover bugs, the choice is yours.Cue4cheap wrote: ↑Fri Oct 07, 2022 9:11 pmI agree with all of this. IMO 3.1.x.x should be a 'gold copy' of the 3 series and extends the useful life not an enigma that is another one off. I wouldn't use this new version but WILL use the maintenance branch.JNeuhoff wrote: ↑Thu Oct 06, 2022 6:52 pmWhile there are some valid reasons for a 3.1.x.x series, especially for PHP 8.1 support, the opencart-3 repository upon which it is based, also introduced some unnecessary changes causing some issues with backward-compatibility with 3.0.3.8, which in turn could cause some 3rd party extensions not to work with opencart-3.
Personally I recommend 3.0.x.x_Maintenance branch from github, which is like OC 3.0.3.8, with some more bugfixes and support for PHP 8.0 and 8.1.
It will take some time for OpenCart 4 to become stable enough for usage on live sites, especially also for 3rd party extension developers to port their extensions to OpenCart 4.
Mike
Dedication and passion goes to those who are able to push and merge a project.
Regards,
Straightlight
Programmer / Opencart Tester
When I have some time, I'll check whether they were all fixed in OpenCart 4 master branch, or in the opencart-3 repository.
Export/Import Tool * SpamBot Buster * Unused Images Manager * Instant Option Price Calculator * Number Option * Google Tag Manager * Survey Plus * OpenTwig
In the pull requests of opencart-3, I could take a look at those that may require adjustments.JNeuhoff wrote: ↑Fri Oct 07, 2022 11:57 pmThere are also some bugfixes in the 3.0.x.x_Maintenance branch which are probably not yet done in the opencart-3 branch. I had a whole lot of them from earlier OpenCart 3.0.3.x and 3.0.2.x releases which were never reported. I just had bugfixes in the form of an OCmod XML file on my clients' sites, and finally submitted them to the 3.0.x.x_Maintenance branch, but I don't know whether they made their way into the opencart-3 repository after the latter was created.
When I have some time, I'll check whether they were all fixed in OpenCart 4 master branch, or in the opencart-3 repository.
Dedication and passion goes to those who are able to push and merge a project.
Regards,
Straightlight
Programmer / Opencart Tester
Users browsing this forum: Semrush [Bot], Shiftcom and 408 guests