datakick

First of all - you should update to bleeding edge, and install maxmindgeoip2 module that can handle new version of database. But back to your question - smarty variable geolocation_country is available only in restricted mode -- when tb blocked access to the store based on ip location. If user is not blocked, this variable is not populated. So you can't access it in any way. For testing purposes you can simply modify the frontcontrolelr and always populate the geolocation_country smarty variable.

you don't have installer or enabled zip php extension https://www.digitalocean.com/community/questions/php-7-0-ziparchive-library-is-missing-or-disabled

Is it tb error page, or web generic server error page? If it's tb error page, then enable debug mode, ale post here the root cause. If it's the server error page, look into server's error log.

Looks like execution flow goes through different code branch for different users. In the context of one user RockPos module was probably not loaded. PHP did not know/found the constant this module defines, and the code in override failed terribly. Let's blame RockPos module for this 🙂 All overrides should check if the module is enabled and loaded. If not, they should NOT do anything - they should fallback to overridden method. Since you are customer of RockPos please file an issue for this, and let them fix it. Meanwhile, you should figure out why one user has different context than other. I would guess this to be related to Customer Groups -- modules can be disabled per group, so check this settings. But of course, it can be different issues

When you enable the module (and overrides), does it fix the problem?

This looks like a remnant of RockPOS module. Are you using this module right now? If not, delete the overrides.

If you want to use php 7.4 please update to 1.1.x.

disable debug mode

Almost there 🙂 What I'm interested in is not response headers and cookies, but response content. Look into Preview or Response tab:

Please click to network tab, look up this failed request, and look into the response. There might be some helpful text. Also, enable debug mode

Did you look into javascript console? Are there any errors?

If there are no errors on javascript console or in server error log then there is not much to suggest. I can investigate for you, if you send me back office and ftp credentials.

I would go to V1.1.x 🙂

It looks like you might be right -- I just encountered the same problem on my demo server. Will investigate

Many merchants run on pretty good servers, so they were lucky enough to never experience this problem. But there are a lot of them that did, unfortunately. If you search for this error message on ps forum you will find countless threads dealing with this issue, such as this one: https://www.prestashop.com/forums/topic/633811-warning-your-php-configuration-limit/. Or another one here on thirtybees forum: https://forum.thirtybees.com/topic/2317-2317/solved-warning-your-php-configuration-limits-the-maximum-number-of-fields-allowed-in-a-form-1000-for-max_input_vars/ Thanks to the fix, thirtybees is in better shape than it was before. We used to have merchants reporting issues like "I can't use translation tool". Now we have requests like "I would like to save more translations strings at once". The first one was a bug, the later is the feature request. Hopefully we will be able to implement it soon 🙂

Or you can use my datakick data export and import module 🙂 Just a shameless plug

If you have installed and enabled module 'Data mining for statistics' then IP address is already stored. The IP address is stored in tb_connections table. You can access it using this query: SELECT INET_NTOA(c.ip_address) FROM tb_connections c INNER JOIN tb_guest g ON (c.id_guest = g.id_guest) INNER JOIN tb_cart cc on (cc.id_guest = g.id_guest) WHERE cc.id_cart = <cart_id>

Can you upload and install module zip file from your back office Modules page? That's quick test to check if your permissions are ok

The translation page used to submit *all* translation strings, which could be a lot. This often caused server issues with max_input_vars php settings: Warning! Your PHP configuration limits the maximum number of fields allowed in a form to 1000 Please ask your hosting provider to increase this limit to 2266 at least, or you will have to edit the translation files. On many shared servers this parameter could not be changed, which made the translation process totally unusable. Even if it was possible to change this php configuration parameter, this was still a nasty UX issue - translation functionality was not readily available for many users. In thirtybees 1.1.0 this was 'fixed' by submitting single section only. This fix was definitely not optimal. First of all, it's not a real fix -- if one section contains more than max_input_vars strings then users will still encounter the same issue. There are other ways to bypass this php limitations and keep the option to submit more than one section at the time. Maybe in the future such solution will be implemented. Until then you will have to save each and every translation section separately.

The update process works for me without any problems. This looks like a permissions issue on your server. Make sure that your web user has write access to the /modules/<module> directory, and all its parent directories

I have created similar rule on my demo server, and it works fine. You can test your rule on my demo server, just to see if it's environment specific problem. If the rule works on my server, then you might have some "other" issues on your server (similar to this Link). http://demo.getdatakick.com/admin561wkvz9k Anyway, you should run core updater to see what other core files has been modified.

Do you have override for core Link class? If not, did you modify this class yourself?

What tb version are you running? I have a feeling this might be already fixed in 1.1.x

That's not possible at the moment. It would be quite hard to implement dynamic restriction form, so I don't plan to do that. I could steal @wakabayashi's idea from his excellent krona module, and implement new action that would just 'clone' existing cart rule. The existing cart rule would act as a template only --> newly created cart rule would contain the same settings as the template, only code and customer would be changed. Would that work for you?

Your email client is probably configured to not show images