Hi Mateo, I need a but more time. I've started to run into a problem where the regular translation queue also gets "stuck", and the only way to clear it is to use the support option to clear automatic translations jobs, even if there are no automated jobs underway.
I'm able to recreate the problem on a local copy of the site, where there's no Varnish caching.
However, I haven't yet tested locally by removing virtually all third party plugins, to rule out potential plugin conflicts. So I'll work on that, and will be in touch with you when I've narrowed down the problem further.
Mateus, thank you for your patience. As you'll see at the link above, there's a stuck automatic translation.
And the site's page cache (Varnish) is deactivated, as you can confirm if you run this command:
curl -I <em><u>hidden link</u></em>
I sent 10 items for automatic translation, and one of them got stuck.
If it helps, I'm still seeing the following error when I edit some pages on this test site:
Notice: Undefined property: stdClass::$status_id in /code/wp-content/plugins/sitepress-multilingual-cms/classes/ATE/class-wpml-tm-ate.php on line 57
I searched for this error in the WPML support forum, it it seems related to a partly-misconfigured setup that leads to communication issues, so this might be related?
As noted in that post, "for some reason the communication keys between your site and our servers were partially wrong so you could send us information but then never receive any because the security part of the communication was not met."
The post doesn't explain what the solution is, but this seems related.
Languages: English (English )Portuguese (Brazil) (Português )
Timezone: America/Sao_Paulo (GMT-03:00)
Hi Joe,
Thanks for your patience.
First, about the warning you asked previously - this is safe to ignore, and should be not related to the issue here. It is just a result of the communication between ATE/WPML, and in the case of your website, all settings seem correct from our end.
Now, about our main issue here, it seems the stuck job is not stuck anymore. Both in the WP dashboard and in our servers, we can't see it as stuck.
Could you please record another video repeating the steps, and also share the posts/pages having this issue?
At last, we still see that Varnish is active on the site in the response header (hidden link). Please try to disable (and keep) it just for the test site, so that we can see if this is the problem.
Hi Mateus, the link you shared -- hidden link -- indicates that although Varnish exists on this site, it's not actually caching anything.
Were you getting different results?
I can look into whether we might completely remove Varnish from appearing the page headers, but this will have no affect on caching because as you'll see at the site above or if you check page headers via `curl`, Varnish isn't actually caching anything on this site, as you previously requested.
Languages: English (English )Portuguese (Brazil) (Português )
Timezone: America/Sao_Paulo (GMT-03:00)
Hi Joe,
About this:
I can look into whether we might completely remove Varnish from appearing the page headers
Please do that, as this is a test requested by our second tier team in order to move on with the investigation. It should be completely disabled before reproducing the issue again.
Please keep us posted, and thanks in advance for your cooperation.
Hi Mateus, it looks like we cannot stop Varnish from being present at our hosting provider, Pantheon. This is the way that their hosting is configured for all customers.
However, we _can_ deactivate Varnish in a few ways, such as setting the cache ago to zero as we did previously.
We can also set a custom Cache-Control header as another way to bypass Varnish caching.
In this case it's overkill but I've done so anyway to be thorough.
So now if you check this env:
curl -I hidden link
You'll now see this Cache-Control header:
cache-control: no-cache, must-revalidate, max-age=0
Pantheon also allows visitors to bypass the cache on a case-by-case basis by using certain URL parameters such as "nocache".
For example, this URL includes a nocache parameter that bypasses the cache: hidden link
Again, this is overkill because the content is already not being cached by Varnish on this site, as you saw earlier on hidden link
I wish that we could remove Varnish completely as you requested, but the fact that it's not actively caching anything on this site should hopefully be the same thing.
Please let me know if there's anything else that I can do to help troubleshoot this, thank you.
