datakick

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.

This special url is called web beacon, and its purpose is to track email delivery and interaction. It's the same technology that mailchimp and any other mail marketing software is using. At the moment the data are only collected (see tb_revws_email table), but I plan to add some nice visualization later

When ajax call returns 500 error code, then there's really nothing (at the moment) javascript ajax handler can display, only a generic message that something went wrong. Frontend doesn't know any details, since server did not provide it. We can format the error message to be more user friendly thant Details: Error thrown: [object Object] Text status: error, but it will still have the same amount of information. If the 500 error page is generated by thirtybees error handler, then we could potentially do something about it in the future. If it's an ajax request that EXPECTS json response, we could format error message to some json object and return it. This would required assistance from front-end javascript, though -- it would have to somehow advice server that it can process this new json error response. If it's 500 error page generated by your server (apache, ngingx), that means that there is some fundamental error that terminated script execution. For example syntax error. We can't do anything in these cases, but to display generic 'Something went wrong' message.

BTW, this error is very often displayed when debug mode is enabled, and there is some (sometimes even unimportant) warning on the page. These notices or warnings were printed into standard output. If the client expects json response, these messages effectively destroyed it. Response like this is not a valid json, and can't be parsed by front end javascript: PHP Deprecated: The each() function is deprecated. This message will be suppressed on further calls {"hasErrors": false} Because javascript code fails to parse this response, error handler is shown, resulting in the error message you have seen. Note that the source of this notice/warning might not even be in thirtybees core. Any installed module can caused this. That's one of the reason we have revamped error reporting mechanism, and no longer print php error messages into the standard output.