Cannot update php above 7.4 - site crashes

[chan]

I got it working stable on php 7.4 TB 1.6 (stable)

If I update the php version to anything from 8 up, I receive an error 500 on all pages (back and front office).

If I first change the "target php version" to the one I want to change to, save, and then update the php version - the same.

If after setting the option to php8.xx, then check for updates under core updater I get "your installation is broken" with a list of files that need to be updated. If I update them, I receive an error that "Composer detected issues in your platform: Your Composer dependencies require a PHP version ">= 8.0.0".
And the site becomes completely broken - I then need to delete all files by ftp and upload them again from a backup.

This is very tedious and the main thing is, that I can't seem to find a way to get free of this vicious circle of updates - nothing works.

So how should I update the php to 8.3 without destroying the installation?

[the.rampage.rado]

In order to update php versions you have to follow "strict" procedure which is described here:
 

This applies for vanilla thirty bees and Niara or Community theme. If you use another 3rd party theme (ones inherited from PS) they WILL not work on php8 straight out the box. 99.99% theme has issue with block cart override in the theme itself which leads to Error 500. You have to run your shop on 7.4, fix all notices for such issues then update to 8.0. Again fix all notices and warnings and then update to 8.1, etc.

The update procedure is not vicious its strict and it's made that way because thirty bees dependencies sometimes work on 7.4 but not on 8+ and vice versa.

[chan]

Thanks for the quick reply! I indeed use an old PS default theme (slightly modified css). But the problem is that the BO becomes error 500 or the other error as well. I cannot do anything once I start the update process.

When I run on 7.4 I don't see any notices - where did you mean I should look for them?

After I follow step 2, save and go to update - I receive a whole list of red entries of "changed files", "missing files" and "extra files". If I now update them the site will get stuck on the other error I mentioned ("Composer detected issues in your platform: Your Composer dependencies require a PHP version ">= 8.0.0". ") and changing the php version on the server will not change this and the site is completely broken in the front and back office.

This is exactly the vicious circle I referred to. Or what did you mean I should do differently?

[the.rampage.rado]

So you have some modules that don't play nicely with php8 too. 

Install thirty bees' Collect logs module and look what it gives you as info on 7.4, fix some of those and try again.

The update method is as follows:

1. You are on 7.4 and your site runs without notices, errors, warnings, exceptions, etc.
2. You update using Core updater by pointing it to target version.
3. Your site is now broken because some dependecies don't work on php 8
4. Your switch your server to php8
5. Your site is working again because at step 1 you fixed all stuff that thirty bees has no control over (external theme and modules).

If you want to proceed updating to php8.1:

1. You are on php8 and your site runs without notices, errors, warnings, exceptions, etc. - THERE WILL BE NEW ISSUES in Collect log module 100%.
....
proceed according to the list above.


If you want to downgrade and not use a backup and your BO works after the update of php version (not your case obviously):

1. You are on php 8.x. and your site works
2. In Core updater you put target version 7.4.
3. Update dependencies with Core updater
4. Your site is broken.
5. Downgrade php on your server to 7.4
6. Your site works if it was working before on php 8.x

[nickz]

There is no need for php 8.3 just because it is the newest.
You can run a site with php4 if it works well, you just need to monitor it. Which you also should do when using 8.3.

If you run an old theme its not an issue if you and your clients like it. Most important is that it runs well and everyone is happy.

[chan]

13 minutes ago, nickz said:

There is no need for php 8.3 just because it is the newest.
You can run a site with php4 if it works well, you just need to monitor it. Which you also should do when using 8.3.

If you run an old theme its not an issue if you and your clients like it. Most important is that it runs well and everyone is happy.

well the only thing is that we moved to TB in the first place because php 5.x isn't really supported anymore. So I don't know how much longer will 7.4 be supported. Don't want to have surprises. I also tried 8.0, 8.1 8.2 and all create the same problem and the site is breaking

[the.rampage.rado]

7.4 is not supported version of php (by php developers, not by thirty bees - it supports it!) anymore but you should use it as a stepping stone to update your modules, fix any bugs that are present on 7.4 with your modules and theme and then follow the steps from above.

If your site is not working on php8 it wont magically start working on 8.3 as there even more things that change between those two versions. You (or your developer) should work to iron out the issues with modules/external theme. Thirty bees does not have control and is not to blame if they don't work on 8 or later.

My sites are also on 7.4 but I plan on migrating slowly to later versions in 2025 but for this to be done a developer should make my old theme work first. And this is nothing to do with thirty bees - natively it works on 8.2 (or even 8.3).

[Yabber]

14 hours ago, nickz said:

There is no need for php 8.3 just because it is the newest.
You can run a site with php4 if it works well, you just need to monitor it. Which you also should do when using 8.3.

Such an approach will result in a store with no integration with any external services, and the only payment method in the store will be only traditional bank transfer.
Currently written PHP libraries most often require a minimum of PHP 8+, and no one writes software for such ancient PHP versions as 4, 5 or 7.

[datakick]

If your store runs on PHP7.4 without errors, you can indeed continue running it on that version.

But you should definitely strive for higher PHP version compatibility, and update version once you achieve it. There is no good reason not to do so -- newer versions of PHP are faster, more efficient, and more secure. And of course, you will be able to use modules that are compatible with newer versions of PHP only. For example, I'm not writing new module that implements digital invoices functionality, and because of the library this module uses the minimal supported PHP version will be 8.1.

It's not hard, and quite safe, to achieve higher php compatibility. PHP never introduces a breaking change out of the blue. They raise WARNING / DEPRECATIONS in previous version, and introduce breaking change in the next one. We have a great tool named collectlogs to handle those warnings.

So the process is:

1. install collectlogs module
2. wait for a while, allow the module to collect deprecation warnings
3. look at the warnings, and fix them
4. rinse and repeat 
5. once your store does not generate any warnings for a while, you can safely update your php version

Note: some (well, sometimes a lot) warnings are not caused by php native methods, but by libraries / core itself. These warns you about upcoming breaking changes in the library / core itself, not about PHP breaking changes. You can ignore these for the time being, as they have no impact on PHP update. Example of such warning:

Note 2: if unsure how to handle fixing the issues, you can always hire some dev do to that for you. In my experience, most stores can be 'fixed' in 2-4 hours, as the fixes are usually trivial.

Note 3: there are a lot of fixes described on a forum, especially fixes for themes. Most themes are very similar, so you can apply the same fix to your theme without changes. 

Note 4: you can also look into niara / community theme github history, to find out how some problem was fixed in that theme. For example, if collects logs tells you there is an issue with breadcrumb.tpl, you can go to https://github.com/thirtybees/niara/ , open breadcrumb.tpl file, and look at the history: https://github.com/thirtybees/niara/commits/master/breadcrumb.tpl

 

[chan]

datakick - many thanks for the very detailed reply!

Obviously I do want to move to php 8.x but so far I don't manage. Something is breaking terribly and I don't manage to find what that is. The whole reason to give TB a try was that an old prestashop site that I created years ago became unusable (beside on php 5.6), and we had to find a solution. So basically TB seems like a great solution - forking of the PS 1.6 strain with the possibility of continuity.

With the "collectlogs" module - do you mean the "collect php logs" module? I installed it and so far didn't manage to fix any of the warnings and depracations that were noted there (code noted with line numbers seem to be inaccurate - I don't find that code in the noted files...). One of them had to do with the old paypal module by the way, so I uninstalled it and now there isn't seem to be a current paypal module offered by TB in the module list.

One of the depracations warnings is this:

    Message: Unparenthesized a ? b : c ? d : e is deprecated. Use either (a ? b : c) ? d : e or a ? b : (c ? d : e)
    Location: classes/module/Module.php(871) : eval()'d code line 695

I guess this is a generalized error message since I couldn't find an exact occurrence in all of the files.
Is there a way to find out which modules are incompatible? (I'd kind of expected that thirtybees will be able to point to them...)

Do you think that if I manage to fix all of the errors mentioned in the php logs module the php change will go smoothly? should I do it gradually as some suggested here? (i.e. 8,8.1,8.2,8.3)

Another issue has to do with the theme - the shop used a slightly modified PS default theme. It is working, but if I change theme and try to go back - I get a config.xml error and there is no way to go back to the original theme. I find this weird. Is there any solution? (by the way, the new theme config.xml file is MASSIVE - there is almost no way I could re-create something like this from scratch. Is there some tutorial as to how to do that? What are the minimum requirements for that - do I really have to list all of the modules and hooks in there?

Thanks!

[Yabber]

Adapting the prestashop 1.6 theme to thirtybees with PHP 8.3 is a very simple job.
For example, the original default-bootstrap template has only a few errors, including two critical errors in the “blockcart” module templates.

On the other hand, the modules sold on prestashop addons are a different topic. It can be said that all modules sold there have some major or minor errors. And it doesn't matter the PHP version.
And the Vietnamese and Indian modules sold together with the themes are the ones with millions of bugs 🙂 

[nickz]

On 12/3/2024 at 5:28 AM, Yabber said:

Such an approach will result in a store with no integration with any external services, and the only payment method in the store will be only traditional bank transfer.
Currently written PHP libraries most often require a minimum of PHP 8+, and no one writes software for such ancient PHP versions as 4, 5 or 7.

Many payment services give you a kind of landing page. Paypal does it so does stripe, Klarna I ignore, the trend goes in making your life easier.
It is not too good to rely on 3rd party services anyway. Especially as most shop owners keep just one shop, it's risky.

[datakick]

38 minutes ago, nickz said:

Many payment services give you a kind of landing page. Paypal does it so does stripe, Klarna I ignore, the trend goes in making your life easier.

That's true, but after payment completed, the module still needs to process the payment. Payment providers usually maintain some php library that can be used to access and process data from their API. And those libraries are not PHP 7.4 compatible.

PHP 7.4 is dead. If you are still using it, you will face more and more problems in the future. For example, you won't be able to use to new versions of stripe or paypal module, and ultimately the old versions will stop working after the api endpoints are closes.

If everything works properly on PHP7.4 now, it's the ideal time to slowly fix PHP8 issues on your store, and prepare for update.  

[chan]

22 minutes ago, datakick said:

PHP 7.4 is dead. If you are still using it, you will face more and more problems in the future. For example, you won't be able to use to new versions of stripe or paypal module, and ultimately the old versions will stop working after the api endpoints are closes.

Problem is, I don't manage to fix the errors as I'm in that vicious circle as described. Kind of feel like a dead end with thirty bees for me in this project. As I wrote, we give tb a try since 5.6 was the last version that ps 1.6 supported.

If I don't manage to make the change to php 8.2+ I'll have to recommend to the customer a migration to another platform.

[datakick]

1 minute ago, chan said:

Problem is, I don't manage to fix the errors as I'm in that vicious circle as described. Kind of feel like a dead end with thirty bees for me in this project. As I wrote, we give tb a try since 5.6 was the last version that ps 1.6 supported.

If I don't manage to make the change to php 8.2+ I'll have to recommend to the customer a migration to another platform.

There should be no "vicious circle".

You are supposed to update from php7.4 to php8 only **after** you have fixed all warnings. You can't update before that.

While you are on php7.4, all future errors are displayed in collectlogs module as warnings. 

[the.rampage.rado]

2 hours ago, chan said:

Problem is, I don't manage to fix the errors as I'm in that vicious circle as described. Kind of feel like a dead end with thirty bees for me in this project. As I wrote, we give tb a try since 5.6 was the last version that ps 1.6 supported.

If I don't manage to make the change to php 8.2+ I'll have to recommend to the customer a migration to another platform.

As somebody said - most of those 'issues' are fixed very quickly as they are trivial syntax change. Of course for me this is not the case as I'm a code noob. If you also don't feel secure you can hire a php developer and they will help you out.

I even know a very very good one - datakick. As a bonus - you will work with the project's mantainer, currently there is nobody more experienced with thirty bees' code and inner workings. And of course by hiring a developer fixing your shop they can find some bug and help develop the platform for everybody else! 😉

[DRMasterChief]

Hello, that's exactly what we're going to do. I'm still doing some tests, as mentioned in another topic. Datakick suggested that it could be done in 1-2 hours of work. That's money well spent.

Of course you want to try things out yourself and if you're successful with small changes to the code, that's great. For other things, however, we're at the point where we'll outsource it, which includes the final adaptation for PHP 8.x.

[the.rampage.rado]

3 minutes ago, DRMasterChief said:

Hello, that's exactly what we're going to do. I'm still doing some tests, as mentioned in another topic. Datakick suggested that it could be done in 1-2 hours of work. That's money well spent.

Of course you want to try things out yourself and if you're successful with small changes to the code, that's great. For other things, however, we're at the point where we'll outsource it, which includes the final adaptation for PHP 8.x.

If a merchant is trying to be serious about their shop I don't see any other alternative rather to hire the best person they can find to work on their shop. In our case it's very easy as we know him. 🙂

[chan]

I don't doubt it that datakick is THE person to work on something like this. But the point is that this shouldn't be something that complicated. I mentioned above some specific issues that don't work even while following datakick's instructions. It is a small shop with only few products, so I am not sure that it makes sense to go this route at all. Seems like the old theme is not compatible - the xml config file gives error and I couldn't find any instruction whatsoever regarding this. So if I need to create the theme from scratch, it seems to me that it makes more sense to do it in a more widely supported system.

[nickz]

On 12/4/2024 at 4:52 PM, chan said:

It is a small shop with only few products, so I am not sure that it makes sense to go this route at all

Do you host on a VPS, and do you have a lot of modules? Modules are the ones which make it trickier.

Edited December 14 by nickz

[chan]

6 hours ago, nickz said:

Do you host on a VPS, and do you have a lot of modules? Modules are the ones which make it trickier.

No, it is on a shared hosting, but a reliable one. Probably there are some problems with the modules, but with the theme as well. And it seems much too much work to try to figure that out.

Since the shop is currently running stable PS 1.6 on PHP 5.6, my suggestion to the site owner was to keep it like that for the time being and to start working on a move to Woo. So it seems we will completely skip the Thirtybees experience. Only in case that the hosting company will completely stop support for php 5.6 before we're ready, we will then, as a temporary measure, go to PHP 7.4 and migrate to TB 1.4

Thank you all for the help!

Edited December 15 by chan

[Rhapsody]

Make sure that the necessary PHP installed modules (not the TB modules) are activated on your cPanel.  One easy check is to open two tabs of the cPanel PHP version selector.  Use the older version of PHP in one tab, and the newer version of PHP in the other tab.  Then go through and make sure the same modules are activated in the newer version as the older version.  This approach definitely helped resolve 500 errors when I transitioned to newer versions of PHP.

[nickz]

On 12/15/2024 at 2:04 AM, chan said:

Since the shop is currently running stable PS 1.6 on PHP 5.6, my suggestion to the site owner was to keep it like that for the time being and to start working on a move to Woo.

Well I wouldn't use woo. For me the 3rd party extension, modules, plugins are problematic.
Woo requieres Wordpress, Most newer Themes requiere 5 to 8 plugins