datakick

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.

Not great, but not terrible either. Your php server takes 836ms to respond. But effectively it takes couple seconds for the response to receive. My tests shows 10seconds: > time curl https://jv74.se > /dev/null 0.02s user 0.02s system 0% cpu 10.197 total If it's not PHP server that is slow (at least not terribly), then there is probably some other component in your stack that blocks the response: nginx / proxy server / whatnot.

keys. _COOKIE_KEY_ , _COOKIE_IV_, and _PHP_ENCRYPTION_KEY_. And you should delete _RIJNDAEL_* entries Enable Profiling in Performance. That will tell you more

I can confirm there is infinite loop that exhausts all memory. This is very easy to reproduce -- simply change your db credentials in settings.inc.php. Fix is already in bleeding edge, see commit https://github.com/thirtybees/thirtybees/commit/49ad2f8719255a76f29ba1c6f626491ab21eda8c

Never share content of your settings.php file. Now your encryption keys are leaked and you will have to generate new one. Anyway, try ti surround line 73 of classes/db/DbPDO.php into try { ...orig code here... } catch (Exception $e) { d($e)}