the.rampage.rado

Did you try clearing your caches?

With this information I managed to reproduce it on my test site just now. Tracked here: https://github.com/thirtybees/thirtybees/issues/1745 EDIT: It is generally good idea to have Standard setting there as it's more user-friendly.

Unfortunately I'm unable to duplicate this issue in any of my setups. 😞 Tried playing with many settings but failed to replicate it. Any specific settings in this demo store?

On 3/20/2023 at 2:24 PM, datakick said: That's strange. Try to manually edit settings.inc.php and change value of _TB_BUILDPHP to 7.4 Then go to core updater and try update. It will probably display something funny (manual modifications warnings, etc), but you can ignore these and perform the update. What happens when you apply this manual fix? As I said the tbmigrator can't update straight to more modern version of thirtybees as those don't work on php5.6 and your PS1.6.1.xx was very unhappy on everything newer than php7 if I remember correctly. The way to update to latest TB is with little patience and core updater will do its job step by step.

First check what version does it say inside. If it's not 7.4 make it be. If it does not work you can try 755, but it should be 644 And as you're inside settings.inc.php check if you have a populated _PHP_ENCRYPTION_KEY_ as it's another nagging bug from past times. (if you have it, don't share it with us 😛 )

Probably you have this error with writing to settings.inc.php

What do you have here: Core updater -> Settings ? It always has to be 'Server PHP version' (if you are not trying to downgrade php or thirtybees.

OK, Could you press F12 in your browser and tell what errors pop there when uploading the picture?

This error might be caused by many factors. Did you make any changes to the core (overrides, etc.)? Is it actually uploading it under this error or not at all?

That's because Core updater is made to guard you against updating TB to version that does not support your current php version. Minimum for 1.5.1 is php7.4 So first update to TB1.4 and php7.3, then switch to php7.4, update to TB1.5.1 and iron out any issues, bugs, warnings, errors with your modules and theme. After that update to php 8.0 - check once again for bugs, if none, update to 8.1 and you're super fast, secure (TB1.5.1 come with many bugfixes and security fixes) and happy.

7.3 to 8.x is quite a big step. Downgrade to 7.4 and fix all errors, exceptions, warnings. The notices you might leave until 8.x because they should not break your shop. Your theme could not support php8 or some of the third party modules. You have collect logs module, right?

Regarding the second error - you can safely uninstall this module (tbupdater, NOT CORE UPDATER, they are 2 different modules) and update to 1.5.1 If doing so does not fix your first error please come back and we will try to help. Regarding the 1.5.1 update - you have to do couple more 'fixes' - you have to install the minify module that comes with this version and also choose, install and configure one of the two email transport modules that take care of email since 1.5.

I had always done my translations in the theme section. I don't know what is the difference other than the front office section but now I'm too old to ask as it works... 🙂

As we're talking in another thread just now - remove image magic module, check if it left it's override in the override folder, remove it, clear your caches and redo all your images again as it's clashing with the webp implementation currently in core and it will not work properly. Glad that you managed to update and now your shop is working again! Monitor for errors and share with us so hopefully the community could help and make your life easier! In general the current thumbnail regeneration process should never timeout but it's speed depends on many factors - number of images, their size, server overhead, etc. Image magic override does not help too.

https://github.com/thirtybees/homeslider this home slider? If so could you push those changes? The community will definitely be grateful.

Regarding modules and webp - you have to customize the module to be able to work with webp images. I did so for Warehouse's lightweight image slider and now it displays web images. Of course no jpeg fallback, etc as it uses the originals that are uploaded.

So basically I was right!? 😛

Currently I'm happy with Litespeed cache with stock hole punching (so only cart). I have free delivery module that's part of Warehouse but I doubt they did something special for it and it's working for now

Regarding that @datakick made a commit (after 1.5 official) and probably could advise if now it's fixed. So now you're running Litespeed cache with 'guest view - yes' setting? Could you share if encounter any issues in future?

By 'cache' you mean the full page cache?

Did you do experiments with "Enable Guest Mode"? If I set "Yes, guest view" the home page loads nearly instantly but sometimes I receive a popup related to product availability (probably it shows some information regarding a previous order in the shop). With First page only it's also fast but not so much. Also the crawler - I'm unable to set it up on my shared hosting, tried on three domains and gave up. It simply does not want to index the pages, but when I open them it ways X-Litespeed-cache miss. If I reload it of course works (hit). Otherwise the cache is definitely working but has it quirks...

My theme also did not create any webp 😄 But the core does since 1.4 so no need for this module. It had some nice features like white background trim, etc. but in my case it was causing exactly the same issue as the topic creator. I also removed the watermark modules from my site - I don't sell unique items so I decided this overhead is not needed too. @movieseals Could you check your jpg and webp files if they are not exactly the same size?

Now I remembered - I had the same but. He's probably using the imagemagic module. Uninstall it (it's not needed in the modern TB1.4-1.5+) and regenerate the images, you'll see a drop in the size.

The target setting in Core updaters points the module to which PHP version of the core files you want to update next, not what version you're currently running on your server at the moment. This is VERY useful you are debugging modules errors moving forward with PHP and you need to roll back to php7.4. You should always set this to 'Server PHP version' if you don't do some changes (updates of the core or testing newer php version). As datakick advised: 1.4 is compatible with php 7.4 1.5 is compatible with php8+ but many modules will not be. It runs on 7.4 also. So first install collectlogs module (or regularly read you error_log manually), roll to php7.4. If you have any issues with your module (errors, warnings, etc - fix them now!). Roll to 1.4 if you're using an older version - fix errors and warnings on php7.4. Make db changes and fixes in Core module. Roll to 1.5, remove tbupdater module (NOT Core updater module, they are different), update all native modules (if update is available), choose, install and configure email transport module (1.5 will not send emails out if this is not done, 3 minutes), install minification module (this was in the core, but was moved to a module for compatibility reasons, check if your code minification settings are proper in the old place where they were before, 1 minute). Make db changes and fixes in Core updater module. Look for new errors with your modules in Collectlogs module (core and native modules should work perfectly on php7.4). Then update to php8.0 - again look for errors, if any - fix them. And proceed to the latest php8 version you wish to use in the same manner. DO NOT UPDATE directly from 7.3 to 8.2 - your shop will crash 99% (99% because of installed 3rd party modules). At each step - make a USEFULL backup of your DB and file system.

This is my config. v.1.4.1 (I used 1.4 for quite a long time and also had no issues (I could find) with my setup). Could you share yours? I use Warehouse and I have no separate mobile view.