Ian Ashton

Had a support chat session with my ISP. The engineer supplied credentials of a SMTP server that didn't use authentication or ssl or tls. And guess what - emails sending again! So his conclusion was So once they've sorted out their internal communication problems I'll be back to normal. Thanks for your input.

Yes - the shop can't send any emails at the moment. Which is causing an internal error when TB tries to change the order status without having send the confirmation email. Just noticed the timeout message in the error log so the two messages I see on failure are [Thu Nov 13 14:56:34.288173 2025] [fcgid:warn] [pid 98322] [client 2.126.40.62:53215] mod_fcgid: read data timeout in 60 seconds, referer: https://ashtonjones.uk/adminXXXXX/index.php?controller=AdminEmails&token=9b2bb752062e6115d9196c18d56792bc [Thu Nov 13 14:56:34.288230 2025] [core:error] [pid 98322] [client 2.126.40.62:53215] End of script output before headers: php82-cgi, referer: https://ashtonjones.uk/adminXXXXX/index.php?controller=AdminEmails&token=9b2bb752062e6115d9196c18d56792bc The SMTP settings in the configuration all work for my mail clients on MacOS, iOS and iPADOS When I click send test email on the Advanced Parameters/Email page I get the rotating arrows in the top LH corner of the window then after a minute or so the Internal server error message below the Send Test Email box. So I'm inferring there's a problem contacting the SMTP server. So the problem is communication between TB and the SMTP server so I should be talking to my ISP? If there was a config problem I'd get a password invalid message etc.

Something has changed on my email settings and I'm not sure if its at the ISP end or my end. Was using PHPMailer successfully until a few days ago ssl_errors.log message is [Thu Nov 13 12:43:51.909043 2025] [core:error] [pid 55714] [client 2.126.40.62:15399] End of script output before headers: php82-cgi, referer: https://ashtonjones.uk/admin0XXX87n/index.php?controller=AdminEmails&token=9b2bb752062e6115d9196c18d56XXXXX Does this give anyone a clue as to where I should be looking?

Just had a customer report the polyfill.io malware problem on my site. We're running TB 1.4.0 under PHP 8.1 I ran core updater ( 1.6.8 ) and it reported all OK. I checked header.tpl in the community theme and there's a reference to polyfill.io on line 62. Do I just have to delete this line as a quick fix? Anyone know what the above malware actually does?

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?