datakick

this is my nginx.conf: server { listen 80; index index.php index.html; server_name localhost; root /var/www/default; # use original IP address changed by cloudflare set_real_ip_from 103.21.244.0/22; set_real_ip_from 103.22.200.0/22; set_real_ip_from 103.31.4.0/22; set_real_ip_from 104.16.0.0/12; set_real_ip_from 108.162.192.0/18; set_real_ip_from 131.0.72.0/22; set_real_ip_from 141.101.64.0/18; set_real_ip_from 162.158.0.0/15; set_real_ip_from 172.64.0.0/13; set_real_ip_from 173.245.48.0/20; set_real_ip_from 188.114.96.0/20; set_real_ip_from 190.93.240.0/20; set_real_ip_from 197.234.240.0/22; set_real_ip_from 198.41.128.0/17; set_real_ip_from 2400:cb00::/32; set_real_ip_from 2606:4700::/32; set_real_ip_from 2803:f800::/32; set_real_ip_from 2405:b500::/32; set_real_ip_from 2405:8100::/32; set_real_ip_from 2c0f:f248::/32; set_real_ip_from 2a06:98c0::/29; real_ip_header CF-Connecting-IP; location / { try_files $uri $uri/ /index.php?$args; index index.php; } location ~* \.(eot|gif|ico|jpg|jpeg|otf|pdf|png|svg|swf|ttf|woff|webp)$ { rewrite ^/([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ /img/p/$1/$1$2$3.jpg break; rewrite ^/([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ /img/p/$1/$2/$1$2$3$4.jpg break; rewrite ^/([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ /img/p/$1/$2/$3/$1$2$3$4$5.jpg break; rewrite ^/([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ /img/p/$1/$2/$3/$4/$1$2$3$4$5$6.jpg break; rewrite ^/([0-9])([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ /img/p/$1/$2/$3/$4/$5/$1$2$3$4$5$6$7.jpg break; rewrite ^/([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ /img/p/$1/$2/$3/$4/$5/$6/$1$2$3$4$5$6$7$8.jpg break; rewrite ^/([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ /img/p/$1/$2/$3/$4/$5/$6/$7/$1$2$3$4$5$6$7$8$9.jpg break; rewrite ^/([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ /img/p/$1/$2/$3/$4/$5/$6/$7/$8/$1$2$3$4$5$6$7$8$9$10.jpg break; rewrite ^/c/([0-9]+)(\-[\.*_a-zA-Z0-9-]*)(-[0-9]+)?/.+\.jpg$ /img/c/$1$2$3.jpg break; rewrite ^/c/([a-zA-Z_-]+)(-[0-9]+)?/.+\.jpg$ /img/c/$1$2.jpg break; rewrite ^/([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.webp$ /img/p/$1/$1$2$3.webp break; rewrite ^/([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.webp$ /img/p/$1/$2/$1$2$3$4.webp break; rewrite ^/([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.webp$ /img/p/$1/$2/$3/$1$2$3$4$5.webp break; rewrite ^/([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.webp$ /img/p/$1/$2/$3/$4/$1$2$3$4$5$6.webp break; rewrite ^/([0-9])([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.webp$ /img/p/$1/$2/$3/$4/$5/$1$2$3$4$5$6$7.webp break; rewrite ^/([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.webp$ /img/p/$1/$2/$3/$4/$5/$6/$1$2$3$4$5$6$7$8.webp break; rewrite ^/([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.webp$ /img/p/$1/$2/$3/$4/$5/$6/$7/$1$2$3$4$5$6$7$8$9.webp break; rewrite ^/([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.webp$ /img/p/$1/$2/$3/$4/$5/$6/$7/$8/$1$2$3$4$5$6$7$8$9$10.webp break; rewrite ^/c/([0-9]+)(\-[\.*_a-zA-Z0-9-]*)(-[0-9]+)?/.+\.webp$ /img/c/$1$2$3.webp break; rewrite ^/c/([a-zA-Z_-]+)(-[0-9]+)?/.+\.webp$ /img/c/$1$2.webp break; allow all; } location ~ \.php$ { try_files $uri $uri/ /index.php?$args; index index.html index.htm index.php; fastcgi_param PATH_INFO $fastcgi_path_info; fastcgi_param PATH_TRANSLATED $document_root$fastcgi_path_info; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_pass php:9000; fastcgi_index index.php; fastcgi_split_path_info ^(.+\.php)(/.+)$; fastcgi_intercept_errors on; fastcgi_read_timeout 360s; include fastcgi_params; } }

@Script-Fu thirtybee core is fully compatible. I'm running my production site on 7.2 without any problems,... the only minor issue is some notices and warnings in error logs, but these are safe to ignore

Also, make sure your server supports this. I had to recompile my php gd extension to include webp support, and also adjust my nginx setup to properly handle .webp extension

I have created github issue to track this one: https://github.com/thirtybees/thirtybees/issues/912

also coreupdater can be used to fix this

This problem has been discussed and answered several times on this forum

I believe you can use coreupdater module to update to 1.0.8 directly from 1.0.3

@Jonny I'm sorry, but I don't think this is the right answer. If the module is using system cache in a wrong way, then the solution should be to fix the module, not to disable system cache. In other words -- if cached content contains customer personal information, then cache key must be based on customer id. If this would result in too many entries in cache, then the module might decide to not use cache for logged-in customers. But disabling cache at system level is not a solution.

It looks like full page cache is disabled (unless you use multistore, and the settings for other store is different). That would suggest that the issue is not in thirtybees core, but in the module's caching, if it use any.

Only you can, as it is encrypted using your server's private key. Go to Advanced Parameters > Logs, there's a feature for this

Very strange. I can't reproduce this problem -- I run this module on my demo account, in production on store, and on localhost without any issues or problems. I guess there must be some settings or module you guys are using that interfere with the module. Is anyone willing to give me back office access so I could investigate more?

@spidawebs that looks like some rewriting issue -- my module's controller is never triggered, there seems to be conflict in thirtybees routing. Could you give me access to your back office, so I could investigate?

Oh, that will be the the case. You should be able to access the checkout page by entering this to browser nav www.yourdomain.com/index.php?fc=module&module=chex&controller=checkout

That is weird. Do you have temporary license key in License tab?

Nowhere. This fixes the bug with thirtybees translation. Once this bug is fixed, you can go to Localizatio > Translations > PDF Translations, and change the text.

you need to add your IP address to whitelisted IP addresses:

Yeah, this was *almost* completed for a few months now, and I finally put aside some time to finish it 🙂 I'd like to implement some more features to this module, however I will wait to see how many merchants are interested in this... Unlike my other modules, this is tb/ps16 only, so I guess sales / usage will be significantly lower.

I've just completed this module for production mode. You can download trial version on my store

This seems to be issue with thirtybees translation tool. It's tracked here: https://github.com/thirtybees/thirtybees/issues/898 It will be fixed in the next version of thirtybees. If you need fix now, you can apply the fix manually

There is Edit: I should maybe mention that it's necessary to look at page source. If you use chrome/firefox inspect mechanism, you are looking at current page DOM structure, and that can be very different from the page served (all the jquery and other javascript DOM modification stuff)

Missing item reviewed is not problem with my module, but rather with your theme. More specifically, layout of your product page, and the placement where review widget is located. You can check that results for my demo page are just fine: https://search.google.com/test/rich-results?id=HLbwUbGKze0FoB1ZZAh3hg revws module is NOT responsible for emitting metadata about product, that is theme's job. Most themes, of course, output product metadata to the page. And I'm sure your theme does as well. The problem problably is that review widget is not placed inside <div> element that describes product. Valid example -- rating metadata are within <div> with with itemtype=https://schema.org/Product, so google can associate reviews / ratings with this particular product. <div itemscope itemtype="https://schema.org/Product"> <!-- html markup for product detail --> <h1 itemprop="name">Product name</h1> ... <!-- html markup for review widget --> <div itemprop="aggregateRating" itemscope itemtype="http://schema.org/AggregateRating"> <span itemprop="ratingValue">3.92</span> <span itemProp="worstRating">1</span> <span itemprop="bestRating">5</span> <span itemprop="reviewCount">7</span> </div> </div> Invalid example -- rating metadata are not within Product div, so google have problems linking these two information together. Note that there may be multiple Products on one page, or other metadata elements like Offer or Job, so google can't and don't automatically associate these two distinct set of metadata <div itemscope itemtype="https://schema.org/Product"> <!-- html markup for product detail --> <h1 itemprop="name">Product name</h1> </div> <!-- html markup for review widget --> <div itemprop="aggregateRating" itemscope itemtype="http://schema.org/AggregateRating"> <span itemprop="ratingValue">3.92</span> <span itemProp="worstRating">1</span> <span itemprop="bestRating">5</span> <span itemprop="reviewCount">7</span> </div> Revws module let you choose one of the two hooks to render widget into. But where in the page are these hooks rendered is sole responsibility of theme.

There's no such option in the module, you would have to make modification

It's unlikely that it would take weeks, but I guess it's possible in case that the dns records had large TTL before. But usually dns propagation take hours/days at most. Good news is that it's possible to resolve the dns records from my location now. So maybe the dns propagated, or the tech support did something that fixed that (I would bet on this one). So maybe the integration with your carrier will now work.

I would contact your host and ask them how it's possible that the dns records can't be resolved from some locations. It is quite likely that they have some firewall in front of *name servers* that blocks requests from certain locations, making your website non-existent for part of the internet. If they can't fix this, change nameservers. For example, go for cloudflare.

btw, it's not possible to resolve your dns address edit: I've just run some tests on your domain: u-bolts-r-us.co.uk 1) domain name can't be resolved to IP address from my location (Czech republic) 2) domain name can be resolved from my VPS located in Frankfurt 3) domain name can be resolved from my VPS located in New York That's quite weird, and should not happen.