datakick

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

You can process payments if you select correct API version in your stripe dashboard. Since there is a workaround for this issue it does not have such priority as other as some other tasks. Believe it or not, there is a ton of more pressing issues we need to work on. Also, since this is an opensource module - feel free to fix it yourself, or hire a developer and pay him to fix this. Then you can share the fixed version with the community for free. After all, that what you expect from us, isn't it?

See this thread:

I double checked the code, but didn't find anything suspicious. What I can do is to implement some stop-gag measure, when I can verify at the very last second that the used address belongs to the customer, and raise an exception if not. Of course, that would prevent checkout completion.

This does not apply anymore, tb 1.4 (bleeding edge) runs quite nicely on php 8.1

look into your server error logs, or into logs directory, to see if there is any error

Disable "Check the IP address on the cookie" option

if you have country id, you can join-in Country collection, and the expose the country code. See attached List template: order-details-vat.json(you can import it to your datakick installation) Regarding shipping costs -- this is stored on order level, so you can create list based on orders, and expose VAT information based on shipping price / shipping price without tax. You can then combine these two lists in excel, and build your pivot table on top of it.

In DataKick module you can create list based on order details, and for each line calculate used tax rate (unit price with tax - unit price without tax). Then you can join-in other collections, like order / delivery address to figure out country code. That is enough information to export to excel, and there generate pivot table with summarized information per country+vat rate

Yeah, I see the problem. vatnumber module parse data from the response using regexp, which is very fragile. The php code you posted uses SoapClient instead. It's probably a good idea to use it instead. Some php servers might not have this extension enabled, though. For them the module will not work properly.

can you PM me vat# and country code?

Looks like the service stopped accepting requests with content type 'application/soap+xml; charset=UTF-8'. Try to apply this fix: https://github.com/thirtybees/vatnumber/commit/e0b2d1f7a67c8a0cdcdfd49f697a2fd71598018e Let me know if it helps. If so, we will release new module version

DataKick module to export transactional/order detail data into CSV, and then pivot table in excel to summarize the information

Look into your php error logs

Module footercustom is not compatible with your php version. Contact its author to fix it

This is probably related to htaccess and rewrite rules for images. Go to Preferences > SEO & URLs and regenerate or fix .htaccess For example, image file exists https://jv74.jv74.se/img/p/3/5/1/1/3511-AngarTheme_thickbox_default.jpg but rewrite / pretty url does not work: https://jv74.jv74.se/3511-AngarTheme_thickbox_default/lyftkloss-efter-bilens-form-mt120x40-mm.jpg

curl php extension not installed?

There you go. Module dualpricedisplay is a culprit

Oh, I just noticed that the profiling info is from your back office 🙂 you need to provide profiling from your front office page that is actually slow.