Background of the issue:
I am trying to render archive pages for custom post types using WPML. We build archive pages as block-based pages and use the Redirection plugin to pass the CPT archive URL to the template page. After updating WPML from 4.6.15 to 4.7.4 and the WPML string translation plugin from 3.2.18 to 3.3.3, we noticed issues. We use Redis as a backend for object caching, along with Pantheon’s WP Redis plugin and the PhpRedis extension. Here is the link to the Redirection plugin: https://wordpress.org/plugins/redirection/. We flush the object cache using `wp cache flush --all --network`.
Symptoms:
After the WPML updates, archive pages started returning 404 errors. The first page load returns a 200 response, but subsequent loads return a 404. Flushing the object cache temporarily resolves the issue, but it reoccurs. This behavior is isolated to the WPML updates, as the same codebase behaves differently with different WPML versions.
Questions:
Can you help identify the root cause of the issue with WPML updates affecting object caching?
What steps can we take to resolve the 404 errors occurring after the first page load?
I can confirm that the issue remains after the proposed workaround of adding counts, plugins, themes and terms as non-persistent groups in our object caching layer.
The issue remains, and the behaviour is the same as described initially.
Thank you for the updates. Can you please consider a staging site (clone copy of the live) for troubleshooting this bug? It will be very helpful because of the WordPress Multisite setup, and we can troubleshoot the bug without affecting the live site. Please let us know your feedback.
> Can you please consider a staging site (clone copy of the live) for troubleshooting this bug?
Unless we go through a lengthy and tiresome approval process that includes you signing NDAs and other agreements, granting access to any environment is unfortunately against corporate policy.
We can provide insights into our setup, as well as run any troubleshooting steps which you suggest instead - but we would have to be the intermediary here. We are entirely willing to do this.
Sorry for the late response due to the weekend. I have consulted with our team, and it is difficult to suggest specific troubleshooting steps in this case because we have made significant changes in the WPML 4.7 series for various improvements.
As a result, the team has requested to escalate the ticket for further investigation. To proceed, it would be very helpful if you could consider setting up a staging site for our testing. Please let us know your thoughts.
> I have consulted with our team, and it is difficult to suggest specific troubleshooting steps in this case because we have made significant changes in the WPML 4.7 series for various improvements.
Understandable.
> As a result, the team has requested to escalate the ticket for further investigation.
Great to hear! Let us know if we can help out.
> To proceed, it would be very helpful if you could consider setting up a staging site for our testing. Please let us know your thoughts.
I will check internally and see what we would need signed for this and get back to you on this. In the meantime, we can help debug the issue with your proposed debugging steps.
While I do this, what kind of access would you require? Is a WordPress account and wp-admin access enough? Which capabilities would it require? Note that we have DISALLOW_FILE_EDIT and DISALLOW_FILE_MODS set to true in our codebase, meaning that you wouldn't have access to the codebase from the admin panel nor the ability to update anything.
Thank you for the details and your kind understanding. A staging site (either a clone of the live site or a simple installation where we can reproduce the issue), along with FTP credentials, will be sufficient for our debugging.
I am enabling the private reply option for your next response. Please check.
