datakick

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.

I agree it's terrible error message, and it should definitely be fixed. Do you, by any chance, have nocaptcharecaptcha module installed?

Most certainly not. If there's a bug, it's been introduced sometime between Jan 21 - Mar 21. You never answered my question - where did you encounter this problem? Was it on front end? One page / every pages? Have you tried disabling non-thirtybees modules?

That's not good, we should definitely find out root cause for this problem, so it won't get into the next release. Unfortunately I can't reproduce it locally, so it's probably caused by some module / theme interference (which does not mean that module / theme is the culprit, they may just use the system in a way that triggers this error). Has anyone else encountered similar problem(s) on bleeding edge?

@smarterweb have you also cleaned cache? Even if you have all cache disabled, smarty can still compile and cache templates in /cache/smarty directory. (btw, you can safely delete this directory using ftp / ssh)

For me, the image is displayed correctly on both blog post detail and blog category pages

Where do you get this error? I've just updated my demo account to bleeding edge, and it works ok for me, so I'm not sure where the problem might be.

The core updater **DOES NOT** work against thirtybees git repository. That's because tb repository contains source code, but core updater needs *compiled* code. I know... in php there is no such thing as compiled code. But there is a build process. To put it simply - if you were to download code from tb repository and uploaded it to your server, it would not work. You need to build it first. So there is another (private) repository, which contains *compiled* code -- result of build process. Core updater communicates with this repository. The problem is that there is not yet any automated mechanism to build thirtybees git repository and publish it to private repo. This is done by hand at the moment, and that's the reason why you don't see the changes very often. This automation is under construction, though, so very soon this will be solved, and Bleeding edge will truly bleed 🙂 BTW, I've just updated the private repo, so you should be able to update to *new* bleeding edge

Should be fixed now

Look into: 1. Advanced Parameters > E-mail -- to verify that the email wasn't really send. It's quite possible that your server actually sends it, but it gets dropped somewhere along the way. 2. Advanced Parameters > Logs -- if the email is not send, there should be some hint in the system logs. For example information about missing template. Note that these email error log entries are logged only once, the first time thirtybees see it. That means that it may be buried somewhere deep in the log list. So look carefully. Alternatively, you can truncate tb_log table to start with clean slate. truncate tb_log;

I think that this affects users that were migrated to new forum. Newly registered users should see signatures by default. I'm sure @lesley knows more