Ian Ashton

My ISP has declared end of life for PHP 8.0 I'm running TB 1.4.0 / PHP 8.0 So do I Log into TB admin in one window. In another window log into my ISP Control Panel. In the Control Panel window update my scripting preference to PHP 8.1 In the TB window run Core Updater and update TB to 1.4.0 / PHP 8.1 i.e. is it OK to change PHP whilst logged into Thirtybees? In fact is this the only way to do it. I assume if I swap to PHP 8.1 before logging in then TB will complain I'm running the wrong version.

Thanks for looking at this. The fix worked on the virgin install (on my local server) and on my online test service.

FWIW - after more investigation 1. Creating/editing a pack worked with Thirtybees 1.4/PHP 7.4 2. Creating a pack fails on Thirtybees 1.4/PHP 8.0 (see original post) system errorlog message [Thu Aug 31 12:15:06.678767 2023] [fcgid:warn] [pid 98599] [client 2.126.60.141:62483] mod_fcgid: stderr: Tried to use set_time_limit which is a disabled function, this is not allowed., referer: https://ashtonjones.uk/index.php exception log in Thirtybees log folder *ERROR* 2023/08/31 - 12:16:18: Error: Cannot use positional argument after named argument at line 665 in file classes/stock/Warehouse.php 3. Creating a pack of products with products NOT in advanced stack control works. As I'm running a system I ported over from Prestashop 1.6.24 I'm wondering if I'm looking at a Thirtybees problem or one that's specific to my service? So - setup test system from virgin 1.4 release and test data ( on a raspberry pi !! ) edited product to move them to Advanced Stock Management and created a pack. Seemed to work OK but as soon as I add the pack to my default warehouse I get the on screen error on clicking SAVE.

When creating a pack of existing products I get a Quantities (500 error) on clicking Save and Stay. See attached file. I can do this on my local server and get the failure when running at my ISP ( Fasthosts in the UK ) Checked the error log on the server and found an error ( see attached file ) which relates to a disabled function 'set_time_limit'. I assume this is a restriction set by my ISP but not sure if there's a workaround? This is the only time I've come across this error. Anyone any ideas? Thirty bees version: 1.4.0 PHP Build 8.0 MySQL 5.6.51

After migrating to TB 1.4 from PS 1.6.24 I noticed the Sales column in the Back Office Customer display was different from the corresponding Prestashop screen for a subset of customers. The TB total was greater than the PS total. After investigating I noticed the 'problem' customers had split orders in the tb_orders table. i.e. two or more rows with the same order reference. This means that there's a many to many relationship between tb_orders and tb_order_payment using tb_orders.reference and tb_order_payment.order_reference. I'm not exactly sure under what circumstances split orders are created in TB or PS. So is this a 'feature' of the database I've transitioned ( in which case I can live with it ) or does TB also create split orders under some circumstances? And if so will some totals also be wrong? As far as I can see this only affect the Back office displays.

Is there any documentation on the SQL Manager in the Advanced Parameters Back Office menu? Specifically what's allowed and not allowed or other restrictions. I've been developing queries using mySQLWorkbench but failing to port them over to SQL Manager. Simple SELECTS seem to work but soon as I start adding JOINS etc I get errors. Or are there any modules you'd recommend to run SQL against the database? Or what other ways do people use for adding their own queries to their shop? Running ThirtyBees 1.4.0/PHP 8.0

Trying my first upgrade to 1.4.0/PHP 8.0 Does this look like a bug? Is the the right place to report it? This error appears after a Search for a product. TypeError count(): Argument #1 ($value) must be of type Countable|array, bool given when rendering smarty template /home/domains/vol2/033/3247033/user/htdocs/themes/community-theme-default/modules/blockwishlist/blockwishlist_button.tpl Source file: /home/domains/vol2/033/3247033/user/htdocs/themes/community-theme-default/modules/blockwishlist/blockwishlist_button.tpl 1:{if isset($wishlists) && count($wishlists) > 1} 2: <div class="wishlist"> 3: <a class="wishlist_button_list" tabindex="0" data-toggle="popover" data-trigger="focus" title="{l s='Wishlist' mod='blockwishlist'}" data-placement="top"> 4: <i class="icon icon-star-o"></i> {l s='Add to wishlist' mod='blockwishlist'} 5: </a> 6: <div hidden class="popover-content"> 7: <ul class="list-unstyled"> 8: {foreach name=wl from=$wishlists item=wishlist} 9: <li> 10: <a title="{$wishlist.name|escape:'html':'UTF-8'}" value="{$wishlist.id_wishlist}" onclick="WishlistCart('wishlist_block_list', 'add', '{$product.id_product|intval}', false, 1, '{$wishlist.id_wishlist}');"> 11: {l s='Add to %s' sprintf=[$wishlist.name] mod='blockwishlist'} 12: </a> 13: </li> 14: {/foreach} 15: </ul> 16: </div> 17: </div> 18:{else} 19: <div class="wishlist"> 20: <a class="addToWishlist wishlistProd_{$product.id_product|intval}" href="#" rel="{$product.id_product|intval}" onclick="WishlistCart('wishlist_block_list', 'add', '{$product.id_product|intval}', false, 1); return false;"> 21: <i class="icon icon-star-o"></i> {l s="Add to Wishlist" mod='blockwishlist'} 22: </a> 23: </div> 24:{/if} Stack trace PHP version: 8.0.26. Code revision: 1.4.0 build for PHP 8.0

In Prestashop 1.6.24 ( and earlier versions ) it was not possible to delete Shopping Carts that have been converted into orders. Although the Customers/Shopping Carts screen in the BO gives a Delete option in the View dropdown clicking it displays Deleted Selected Item? in an alert box. Selecting OK then produces "An Error Occurred during Deletion" at the top of the screen. ThirtyBees 3.0 seems to have inherited this behaviour. I can't see the need to retain Shopping Carts which have been converted into orders. I've carts going back to 2014. The order details are still available. If there is some hidden technical reason? If there is why show the Delete option? As a test I've manually deleted entries for a customer in tb_cart_product and tb_cart - [ on a test server ] This had the desired tidying up effect but I'm wondering if I could have stored up some future problem?

Starting out on my Thirtybees journey. Did a new install of version 1.3.0 Upgraded Core Updater to 1.6 Configured Core Updater and received Your installation is broken! We have detected some problems with your installation. You should fix them by updating your store. Changed files config/json/files.json modified vendor/composer/ClassLoader.php modified vendor/composer/autoload_classmap.php modified vendor/composer/autoload_real.php modified vendor/composer/autoload_static.php modified vendor/composer/installed.json modified Extra files vendor/composer/InstalledVersions.php vendor/composer/installed.php vendor/composer/platform_check.php I obviously haven't changed any files ( other than by running the install ) so Is this behaviour expected. Is it OK to continue with the upgrade

Thanks for your reply. I like the idea of starting from a clean install. Which data migrator module did you use?

I've a local version of my shop and am trying to test the ThirtyBees migrate module on it to see if I can get past the problem above. Loaded the migration module OK ( version 2.1) but After configuring it I get Going to migrate to thirty bees version: Nothing available Under the Migrate button. I was expecting to see Going to migrate to thirty bees version: 1.0.8 Obviously I've made a mistake somewhere but can't spot it.

The TB migration process on the website upgrades to 1.0.8 first of all. I'm at the Core Updater step.

This is my first Thirty Bees post. I've arrived here as once again my ISP is forcing me to move to PHP 7.4 and a move to Thirty Bees was suggested by someone in the Prestashop forum - rather than continually trying to manually fix 1.6.24. So I'm trying a migration from my Prestashop installation to ThirtyBees and I've set up a test site to try this on. This is running PHP 7.4. I've got as far as installing TB 1.0.8 following the migration guidelines. On running the Core Updater to move the installation on to TB 1.3 I get the 'You have local changes' message ( attached ). However there's nothing under the headings 'Changed Files', 'Missing Files', 'Extra Files' so I'm not sure which are the problem files. Confession - my version of Prestashop 1.6.24 was created from the released version and modified to work under PHP 7.2 by manually incorporating the mods from GITHUB to make 1.6.24 PHP 7.2 compatible - https://github.com/PrestaShop/PrestaShop-1.6/pull/4 It looks like these mods were going to be incorporated into a 1.6.25 release which never happened. Is this what's causing the Core Updater message? Should I revert to a 'vanilla' 1.6.24 and do the migration again? If I simply reinstated the changed files ( which I saved before updating ) would this be enough for TB Core Updater to work?