datakick

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.

Look into your server's access log and search for access to webservice endpoint. If there are no entries, then the problem is most probably at carrier side.

Yep, bleeding edge / 1.0.x / release preview are just different names for the same 🙂

it is already solved in the upcoming version. If you don't want to wait, use coreupdater do forward your site to release preview

@Binder are there any error messages listed in /logs directory (located in thirtybees root) ?

Do you have delivery delay(days) option set to non-zero value? If so, then the email will be send +N days after the order is marked as 'shipped'. If you don't want this feature, simply set this option to zero...

That's definitely a bug, thanks for reporting this. I've filled github issue to track this: https://github.com/thirtybees/thirtybees/issues/895

I personally think that @Scully is right, device type should definitely be in page key dimension, because server *can* generate different content for different devices. Caching mechanism should not change rendering logic in any way, it should only cache the output. It should be consistent - the server should return the same page with or without cache being enabled. And that's not the case when device type does not take any part in decision process. We could be smart about this, and consider different device types only when there is *some* module that is not enabled on some device.

Maybe you have revws module disabled on mobile devices?

- https://www.paypalobjects.com/ - https://www.paypal.com/ - localhost / loopback

PageCacheKey is using following properties as a slicing dimension: public function getHash() { return Tools::encrypt('pagecache_public_' .$this->url .$this->idCurrency .$this->idLanguage .$this->idCountry .$this->idShop .$this->idGroup .$this->idCustomer ); } If any property differs, then the new page cache entry is created. I guess that the $url or $idCustomer is responsible for these extra entries. Don't forget that https://www.domain.com/en/ is different resource than https://www.domain.com/en/?whatever. Even though `whatever` parameter does not affect page generation in any way, thirtybees core doesn't know this. We don't know if this parameter targets some module behaviour, etc... So it must be considered important for caching purposes. The reason why id customer is in slicing dimension is to prevent data leakage. Without this, page cache could quite easily cache customer's private data and show them to different visitors. I believe that it's probably good idea to disable the full page cache for logged in customers altogether.

@schmuck-checker the error message says it clearly: cURL error 28: connection timed out after 60001 milliseconds This means that your server is trying to talk to third party server (paypal) using curl library. Your server is trying to open http connection but is not able to connect within 60 seconds. This really means some infrastructure problem between your server and paypal server. It's definitely not an application issue. Could be anything from DNS or router misconfiguration, to enabled firewall on your webserver. The firewall, or similar security measure that prevents curl library to communicate with outer world, is the most probable cause. Like in 95% of the cases it's this. You should talk to your hosting provider once more, and ask them if there is any firewall installed. The mere fact that others don't have problems with paypal doesn't mean that the problem does not exists on your webserver configuration.

@Bulik I can look into this for you. I would need credentials for ftp access, and credentials for back office. PM me if you want my help

This timeout error is not something that can be fixed in thirtybees core. It means that your server is trying to contact external server, but is unable to do so. In most cases, this is caused by firewall or similar security restrictions applied on your server.

Edit paypal.php file and remove or comment out line 292

Looks like a good start. If it works, please make pull request so everyone can benefit from this improvement.

@jfnewell1965 pm me access credentials to your back office, I'll have a look

You need to replace PREFIX_ with your database prefix, and execute the resulting sql script using sql client on correct database (phpmyadmin, for example)

It's not really necessary, your thirtybees will work just fine even without applying this particular sql script

@jfnewell1965 I have reproduced the problem, and found a solution. Go to your modules page, and delete Bees Blog Recent Posts module. Not the Bees Blog itself. After you delete it, you will notice that it will immediately reinsert itself into the module list. That's because Bees Blog modules contains different version of this module as a submodule, and immediately copies its own version thirtybees module directory. So by removing the module, you are actually performing module update 🙂 funny, isn't it... Now, install this module, and it should start to work.