datakick

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

We will do the investigation to see how complicated it will be. If it's simple change, we can roll the update soon. Otherwise this will go to backlog, as there are other tasks with higher priority. Currently the module should continue to work, provided you have selected proper API version in your stripe dashboard.

class 'Attribute' in global namespace is reserved in php8. In order to make tb php8 ready, we had to rename the class Attribute to ProductAttribute. There will be a mechanism that fixes (patches) third party modules automatically, but this mechanism is not yet ready for production -- still lots of bugs. Meanwhile, you have to patch the module code yourself. Replace every reference of Attribute with ProductAttribute. In your case, line 85 should look like this: $att = new ProductAttribute($attribute['id_attribute']); Look for these syntax patterns in the module code: new Attribute(...) Attribute::someMethod() Attribute::$staticProperty

Never played with this one. But I assume cloudflare will modify these nginx headers, since it's caching layer. you can see diffs by requesting curl -I https://www.domain.com/.../file.woff vs curl -I 199.199.199.199/.../file.woff I get HTTP/2 200 date: Wed, 03 Aug 2022 14:32:20 GMT content-type: font/woff content-length: 90412 last-modified: Tue, 19 Feb 2019 13:44:42 GMT etag: "5c6c084a-1612c" cache-control: max-age=31536000 cf-cache-status: HIT age: 3 accept-ranges: bytes expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct" report-to: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report\/v3?s=VUCoNPsUr2WZxf4%2Bsd0XJgcgwMq4y7hqrey0LQG1a9Y2Gtno7j07DYM01T3EeJ9OsEyZp%2BLMbH%2Bwqf03i%2BNN1etvVz6JZ6w61KX1O3G7WhXfPucFeYG9h3SC2Xxdam4%2BMNsowbvT8d0%3D"}],"group":"cf-nel","max_age":604800} nel: {"success_fraction":0,"report_to":"cf-nel","max_age":604800} server: cloudflare cf-ray: 734fc316f984b333-PRG alt-svc: h3=":443"; ma=86400, h3-29=":443"; ma=86400 vs HTTP/1.1 200 OK Server: nginx/1.15.8 Date: Wed, 03 Aug 2022 14:33:17 GMT Content-Type: font/woff Content-Length: 90412 Last-Modified: Tue, 19 Feb 2019 13:44:42 GMT Connection: keep-alive ETag: "5c6c084a-1612c" Accept-Ranges: bytes As you can see, cloudflare adds cache-control header itself.

No, I mean creating orders from back office, either directly by using existing cart, or by recovering abandoned carts