datakick

That's because the combination link is constructed using hash parameters instead of query parameters. Hash parameters are ignored by servers, browser actually never sends them. If the url looks like this: https://domain.com/en/category/product#attribute-color=blue Browser will send only request for https://domain.com/en/category/product , and server does not know about attribute-color. Currently, combination selection is done only in browser javascript code, on page load. And that is, of course, not performed by facebook crawler. Facebook sees only the default page, with default image and default combination.

403 is not 404. Looks like thirty bees generated the url correctly, but your server refused do return the content. Maybe some .htaccess rule or nginx settings blocks it. Or the file itself can have file permissions not accessible by your php or proxy server. Or it can be browser "security" extension, or whatnot.

This message is governed by your theme. What theme do you use?

Works fine for me on all sites I've tested. Look into network tab in your browser console to see the ajax response. That might help you figure out what is wrong

Thanks for reporting this. Actually, this particular issue is already fixed, and will be part of the next version of paypal module, when released

it can be... a lot if things. I dont think this is application issue, looks like env misconfiguration problem. For example: https://hpduy17.wordpress.com/2019/01/29/deal-with-swift-transportexception-when-sending-gmail-from-laravel-application/

reusability, single point of configuration, browser compatibility, .... You can, of course, build your own theme with vanilla css.

You have override for Configuration class that changes the object model definition. Check the $definition static property in the override file, and adjust it to match the expected core definition

It must be in the core updater Database Schema. If not, please show screenshot, and also try to run this query: SHOW CREATE TABLE tb_feature;

probably store misconfiguration. Look into your db: select name, value from tb_configuration where name like 'PS_OS_%' This will show you mapping for hard-coded/build-in order states. In my case, it says that PS_OS_PAYMENT = 1 Modules and core will use order state with id 1 when the order is paid. Now check that this ID value matches the correct order state. In my case it matches, id 1 == Payment accepted. I assume in your case it will point to the wrong status. The fix is to update data in tb_configuration table.

ouch, it's a temp table, created specially for every request. That's gonna be hard to investigate. You will need to simulate the process of BlockLayered::getProductByFilters method. That's probably too advanced, though.

This sql takes the most time: SELECT SQL_NO_CACHE p.*, product_shop.*, product_shop.id_category_default, pl.*, image_shop. `id_image` id_image, il.legend, m.name manufacturer_name, product_attribute_shop.id_product_attribute id_product_attribute, DATEDIFF(product_shop. `date_add`, DATE_SUB("2022-09-28 00:00:00", INTERVAL 210 DAY)) > 0 AS new, stock.out_of_stock, IFNULL(stock.quantity, 0) AS quantity, product_attribute_shop.minimal_quantity AS product_attribute_minimal_quantity FROM tb_cat_filter_restriction cp LEFT JOIN `tb_product` p ON p. `id_product` = cp. `id_product` INNER JOIN tb_product_shop product_shop ON (product_shop.id_product = p.id_product AND product_shop.id_shop = 1) LEFT JOIN `tb_product_attribute_shop` product_attribute_shop ON (p. `id_product` = product_attribute_shop. `id_product` AND product_attribute_shop. `default_on` = 1 AND product_attribute_shop.id_shop = 1) LEFT JOIN tb_product_lang pl ON (pl.id_product = p.id_product AND pl.id_shop = 1 AND pl.id_lang = 1) LEFT JOIN `tb_image_shop` image_shop ON (image_shop. `id_product` = p. `id_product` AND image_shop.cover = 1 AND image_shop.id_shop = 1) LEFT JOIN `tb_image_lang` il ON (image_shop. `id_image` = il. `id_image` AND il. `id_lang` = 1) LEFT JOIN tb_manufacturer m ON (m.id_manufacturer = p.id_manufacturer) LEFT JOIN tb_stock_available stock ON (stock.id_product = p.id_product AND stock.id_product_attribute = 0 AND stock.id_shop = 1 AND stock.id_shop_group = 0) WHERE product_shop. `active` = 1 AND product_shop. `visibility` IN("both", "catalog") ORDER BY pl.name ASC, cp.id_product LIMIT 0, 60 You need to investigate why. You should connect to your database and execute the query manually. Look how many rows are in individual tables. use EXPLAIN sql command to figure out why the hell it takes so much time. There will be either data issue How many rows are in tb_cat_filter_restriction table? How many products do you have? Does it correlate with product_shop / product_lang table? or schema issue missing indexes, maybe Nobody without access to your db can help you more now.

Most of the time is spent on database queries. Look for the long running db queries.

edit this line https://github.com/mollie/PrestaShop1.6/blob/a6a4602d0901c050d509acc18664de2a1ea91e3b/src/Builder/FormBuilder.php#L15 and change it from use AttributeCore as Attribute; to use ProductAttribute as Attribute;

You should enable profiling, that will tell you the bottlenecks.

Indeed vies server is very unreliable. It often reply with transient error responses (like too many requests, try later), and sometimes with hard errors when their server just crashes. Current tb module handles these situation silently, with only a log entry inside Logs messages. Which can very easily lead to wrong taxes being applied and collected. What we want to do is extend current module, and implement retry mechanism. Basically, when we fail to validate VAT number during checkout (caused by server issue), we would move the order into some special order status (like Pending VAT number validation), and try later. Module would try to validate missing VAT numbers on regular basis, and switch order to either 'VAT Validation Failed' status, or to normal status like 'Payment Accepted' or 'Awaiting Bank Wire Transfer'. Employee would have to manually handle the 'VAT Validation Failed' situation -- adjust order, and optionally request payment for missing VAT amount. That's the plan. Now we need the time 🙂

This has nothing to do with nginx, that's just a proxy server. It does support PHP8 - bleeding edge works with PHP8 quite it nicely. We will soon release it officially as 1.4. Meanwhile, you can download code from github and use that one.

You are trying to install tb 1.3.0 or older on php8. Not compatible. Use php7.4, or install bleeding edge.

Probably nothing here, as the newest error log is from 2020. Look inside your php server logs.

Advanced Parameters > Logs

There must be some error / exception during order validation process. Look into server error logs and inside /logs directory in thirty bees itself.

Very unlikely they will remove this anytime soon. But you are right, we should prepare for this, and fixed the code, so it works both with stringified and native values. It's very hard to find all the places in the core that depends on this stringification functionality, though

Yes. Fortunately we can force the original behaviour by enabling the PDO::ATTR_STRINGIFY_FETCHES option. This is already in bleeding edge: https://github.com/thirtybees/thirtybees/commit/1acfeebbe3959daefe05e805fd47371ae4b31a29

I've reproduced this. Nasty issue, actually. This is caused by https://www.php.net/manual/en/migration81.incompatible.php#migration81.incompatible.pdo.mysql DB driver in php8.1 returns integer and decimal number values from database as integers and floats. In previous php versions, the return values were simple strings. So, sql query SELECT * FROM tb_access WHERE id_tab = 1 AND id_profile = 2 used to return data [ 'view' => '1', 'add' => '1', 'delete' => '1', 'edid' => '1' ] But in PHP8.1 it returns [ 'view' => 1, 'add' => 1, 'delete' => 1, 'edid' => 1 ] Couple this change with strict comparison operator: if ($access['view'] === '1') { // ... } And we have a huge problem.

I'll check