Replies: 5 comments 28 replies
-
|
I suffered like you with a few extensions that are no longer updated when I installed PHP 7.4 on a machine. I wouldn't worry at the moment as long as you have control of the server. I personally do not consider a major EOL problem of a PHP branch. In the case of a Debian 9 installation I am using 7.0 on an installation and it is periodically updated by the Debian maintenance team, I recently did an update. I have installations that if migrated to M2 would cost enormously. Whoever wants to stay at OpenMage will have to maintain the current installation I think certain modules can be updated. Let's not forget that even now we are on our own, without the Magento team, without many developers. |
Beta Was this translation helpful? Give feedback.
-
|
I had almost zero problems when migrating to 7.4 (well, I've always kept the project maintained with small incremental jumps in php version) but this time the effort seems a bit too much. Maintaining the servers is not a problem cause my customers have quite big custom infrastructures, but that's exactly why I would't stay too long with an unsupported php version, security and legal reasons. |
Beta Was this translation helpful? Give feedback.
-
|
I collected a lot of OpenSource modules under https://github.com/OpenMageModuleFostering as a start. A theoretical way to approach this whole issue of incompatibilities in Modules would be to automate the syntax migration by using https://github.com/rectorphp/rector. An important Requirement for this would be, to know about most of the compatibility issue types, and what the correct alternative syntax would be. |
Beta Was this translation helpful? Give feedback.
-
|
Yes I did @fballiano |
Beta Was this translation helpful? Give feedback.
-
|
@tmotyl thanks a lot for your gist! I could make it work, although at the end of the day I'm still having a lot of issues (the amasty improved navigation stops working, layered navigation is completely empty), the mirasvit sphinx search does has problems, and these are the first two... so... I don't know... php8 seems very hard on a lot of things |
Beta Was this translation helpful? Give feedback.
-
|
Fyi the gist i created is just an example, you have to enable rules you want to apply manually. From my experience most of the issues in migrating code from php 7 to 8 come from accessing unexisting array keys which throws warning in v8 (notice in v7). |
Beta Was this translation helpful? Give feedback.
-
|
@tmotyl sure, I've loaded the PHP8 setlist ecc but your gist was very helpful for the autoloading part, anyway this is mine: https://gist.github.com/fballiano/9b9040355ec05c5e8a0c9377c15c8c13 weirdly I don't get any warnings/errors not either in developer mode. anyways... |
Beta Was this translation helpful? Give feedback.
-
|
Like https://github.com/OpenMageModuleFostering I found Yireo modules: https://github.com/orgs/yireo-magento1/repositories |
Beta Was this translation helpful? Give feedback.
-
|
A golden rule says not to change something that works. There are still tens of thousands of stores that use M1 and I think they will continue to exist for at least 5 years from now. As long as the LAMP/LEMP exist I think it will be possible to make changes, even for a fee, so as to bring up to date certain aspects that will create issues of non-functionality. There is still a real problem with possible security holes, but I know that once a product is replaced the interest of some to break it decreases, I think M2 is a more appropriate target. I did not understand the decision of some developers to eliminate from their offer the extensions for M1 and the technical support. Some did so right after June last year. Until I got to Magento, I contributed quite a lot I say in the X-Cart and CS-Cart communities, almost 10 years. Now the downloadable versions of the two no longer exist. If you don't like M2 then you only have WooCommerce, Prestashop and OpenCart in which you can put your hands. Otherwise, more and more offer turnkey solutions, but with appropriate costs, avoided by small and medium-sized stores. As long as we still have stores based on OpenMage we can correct certain aspects. Unfortunately I see how thee interest decreases over time and how many focus on fixing the code documentation instead of setting a list of priorities and fixing most of the reported issues. There are certain dysfunctions in the code that are too obvious and that deserve attention in my opinion. |
Beta Was this translation helpful? Give feedback.
-
|
They do have a community version, like M1: |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for the information, I will analyze it. The main problem with M1 is that it was so well exploited that you could find just about any extension you wanted, there were communities where most of the issues were answered, plus tons of tutorials. |
Beta Was this translation helpful? Give feedback.
-
|
we at Macopedia.com are moving towards Shopware (from M1 and M2) |
Beta Was this translation helpful? Give feedback.
-
|
The best platform is the one that offers what you are looking for and that you can control a bit. For someone who is used to M1 to make a switch to M2 or Shopware would mean learning new things from scratch. The problem is how long this stage will take. Then how the old website will migrate to the new one. There is a big issue with extensions because if you do not have developers at reasonable costs you will miss the facilities and users will notice these aspects. M2 has been offered as a solution for a long time, but after so many years I don't think it will succeed in M1. I will not go into details because it would be a long discussion. Personally, I did not like the attitude of the Magento development team, there are too many bugs unresolved for a long time, some even reported and with solutions offered. |
Beta Was this translation helpful? Give feedback.
-
|
When I chose Magento 1 a decisive reason was related to its attributes. No other shopping cart has had so many attribute options (scope, type, apply to, use in quick search / advanced search, comparable, and so on). PS - Don't forget to mention WooCommerce. The demand for this shopping cart is growing. |
Beta Was this translation helpful? Give feedback.
-
|
Together we are fighting against the beginning of the end of OpenMage. I encourage you to use theses wonderful modules available for PHP 7.x, some of them for PHP 8.0 💐. |
Beta Was this translation helpful? Give feedback.
-
|
I know variants of Magento 1.7 that still run PHP 5.6. As long as there is the possibility to install on the server variants of PHP and MySQL, I think that the lifespan of the solution can be extended. Making OpenMage 100% compatible with PHP 8.x means giving it a time life of at least 5 years of survival. I know the general opinion that it is not good to continue with a PHP after its EOL but only experienced hackers could create true threats for some old variants. Don't worry OM will survive for a while. |
Beta Was this translation helpful? Give feedback.
-
|
using a EOL infrastructure may have security and legal repercussions, although totally possible. |
Beta Was this translation helpful? Give feedback.
-
|
using a EOL infrastructure may have security and legal repercussions, although totally possible.
Using an EOL Platform should not be considered for OpenMage. At the moment, all projects I am supporting ran quite fine with PHP 7.4. I did not do any tests for PHP8 with these Projects, but I am not generally scared as long as there is no encrypted/obfusicated code used. For the extensions that use these techniques it wil depend on support of the module vendors to support PHP8. I don’t know if there will be any support.
Do we have any kind of list what extensions are known to be PHP8 compatible? Should we as - OpenMage project - supply a space to publish modified versions of popular extensions that will work with future OM Versions and PHP8?
|
Beta Was this translation helpful? Give feedback.
-
|
openmage is already compatible with php8 |
Beta Was this translation helpful? Give feedback.
-
|
Some not maintained community modules could be directly updated at https://github.com/OpenMageModuleFostering. |
Beta Was this translation helpful? Give feedback.
-
|
It would be useful if we had a discussion section where we could show what extensions we use through the online stores we manage. |
Beta Was this translation helpful? Give feedback.
-
|
added a Discussion Category |
Beta Was this translation helpful? Give feedback.
-
|
@Flyingmana I added the post in the new category. |
Beta Was this translation helpful? Give feedback.
-
Hi everybody, I've updated my customers to the latest OM version (which supports php8) so I tried to give it a test and see what could the outcome be.
Well... an awful lot of 3rd party modules are not compatible with php8 (bl custom grids, mirasvit sphinx search, amasty improved layered were just the first 3 that I encounter) and it doesn't seem very very easy to port them so, at the moment, I've decided that my customers will (most probably) stay on 7.4 until it's supported (end of 2022).
Point is, AFAIK almost every shop uses a lot of 3rd party modules, no vendor is really updating the modules for M1 (amasty removed the M1 section from their shop) so... what are we going to do about that?
It kinda feels like it could be the end of the game, in 2023, if we have to use php8 and we lose a huge amount of important modules... who will use openmage?
This doesn't want to be a bad prediction discouraging or anything, I'd just like to know what you think about the kinda far (but not too much) future.
Beta Was this translation helpful? Give feedback.
All reactions