datakick
-
Posts
3,137 -
Joined
-
Last visited
-
Days Won
496
Content Type
Profiles
Forums
Gallery
Downloads
Articles
Store
Blogs
Everything posted by datakick
-
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)}
-
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.
