datakick

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)}

The error location is weird - creation of PDO object should not consume all available memory. One possible reason is some sort of loop, when exception is thrown when trying to establish db connection, and error handler tries to retrieve some data from db, which leads again to attempt to estabilish connection. This kind of loop can consume all memory. Double check your connection settings.

put phpinfo.php file in the root directory of your installation and access it via https://yourdomain.com/phpinfo.php <?php phpinfo(); This will show you your server settings. If you changed your server PHP settings correctly, it will show 512MB somewhere

There you go. Your php server has Memory limit set to 128MB memory, which is not enough in your case. Increase it in php.ini, or via your cpanel or whatever server management tool you are using.

Warnings and notices are not important. Look for errors. If your store throws 500 error page, there must be something there.

We do have such mechanism -- error handler collects 500 errors and saves them inside /log/ directory. As @wakabayashi wrote -- it is usually very easy to fix php8 issues. If the module is not maintained anymore, you can try fix it yourself or hire external help. Any developer should be able to fix these kind of issues in few hours, or even couple of minutes. We offer such services as well, by the way.

Look into your php server error logs

Not possible

I just want to point out that the auto-fix mechanism we are talking here about is only for Attribute class rename. This is indeed backwards compatibility issue caused by tb 1.4.0, albeit forced upon us by PHP8 reserving this name in global space. We have prepared mechanism that parses the module code using PHP parser. That way, we can detect any references to Attribute in global space, and replace it by ProductAttribute. Unfortunately, this parsing is a very slow process, and it can easily time-out. And even if it does not timed-out, it makes module uploading process look very slow and sluggish. We need to work a little bit more on this mechanism to make it usable in real world. There are few things that we need to do -- for example caching of already parsed classes, do not parse files in module 'vendor' directory as it it very unlikely that any composer library is using prestashop/thirtybees Attribute class, test files if they are using Attribute text using string functions, and parse only those that do, etc. We can fix this particular BC problem. But there will be other problems related to PHP8 that can cause serious issues. PHP8 is much more strict than was PHP5 for which those modules were originally written.

New module tbspreadsheetdatasource was just released. This module reintroduces removed functionality to import excel files. You need to install this module only if you are running on bleeding edge (on soon in 1.4.0) and if you need import from excel files. Import from CSV is still supported natively. Note that this module required PHP 7.2 and higher. If you are on PHP 7.0 - 7.1, you are out of luck. You could theoretically create similar module that uses phpoffice/phpexcel library underneath. We will not implement such module, since we are already planning phasing out php 7.0 and php 7.1 support in core anyway.

For live site, PHP 7.4 is optimal (if you are on 1.3.0 / bleeding edge) For test site, please use bleeding edge and PHP8.1