Background of the issue:
I am trying to edit a page, save using the autosave feature, and preview the changes using the WordPress preview feature on a site that has been published in multiple languages. After debugging, I found that the behavior is triggered through the 'parse_query' hook action defined in 'sitepress-multilingual-cms/sitepress.class.php': <code> add_action( 'parse_query', array( $this, 'parse_query' ) ); </code> Commenting out this line leads to the preview being loaded correctly, but it also disables most of the routing functionality of WPML, so translated sites are not displayed correctly anymore on the published site.
Symptoms:
The preview of the page is heavily outdated, showing a version from two years ago instead of the latest changes. The query used with WPML has a hardcoded ID, which always returns the post/page with ID 44, not the latest revision.
Questions:
Why does the preview show an outdated version of the page?
How is the ID 44 determined in the query with WPML?
How can I fix the preview issue without disabling WPML's routing functionality?
thanks for your response. I tried to reproduce the issue on your site. Sadly I was not able to. One main difference I see is that on our site we are using the WP Bakery Plugin in combination with WPML. I was not able to install that plugin on your site though.
I actually provided detailed steps on reproducing the issue in this support request initially but the AI summary feature of this forum stripped all that away...
I will try to give a more detailed view here again:
The issue happens when editing a translated page and clicking the "Preview Changes" in the classic (non-gutenberg) editor. Debugging it shows that there is an autosaved revision created correctly when editing the page. Performing the query to fetch the latest revision on the database gives the correct content.
However the preview page calls the 'parse_query' hook of the WPML plugin. This hook somehow determines that the preview should show an outdated version of the page and attaches the id of that revision into the query parameters. That leads to the lookup of the latest version be useless as it already includes the hardcoded id of the revision.
The SQL Query without the WPML plugin looks lilke this:
SELECT
sg9014_posts.ID
FROM
sg9014_posts
WHERE
1 = 1
AND sg9014_posts.post_parent = 2745
AND sg9014_posts.post_type = 'revision'
AND ((sg9014_posts.post_status = 'inherit'))
ORDER BY
sg9014_posts.post_date DESC
The SQL Query WITH the WPML plugin (and therefore parse_query hook) looks like this:
SELECT
sg9014_posts.ID
FROM
sg9014_posts
WHERE
1 = 1
AND sg9014_posts.ID = 4469
AND sg9014_posts.post_parent = 2745
AND sg9014_posts.post_type = 'revision'
AND ((sg9014_posts.post_status = 'inherit'))
ORDER BY
sg9014_posts.post_date DESC
Notice that in the second query the posts.ID is already set. I am assuming this information is coming from some internal cache that WPML is using to determine the revision. Do you have some more information on whats the mechanism there so I can further debug? Maybe you can tell me how I can reset the internal cache if there is something like that?
Actually I just tried to clear the WMPL cache and any other cache I could think of but this didn't resolve the issue. Would be glad for further ideas on how to debug this.
Hi, we have the same setup (WPBakery and WPML) and have the same problem: previews of translated pages refuse to show the latest changes.
Here's what I gathered before I found this post:
- WordPress 6.8 made changes to the wp_get_post_autosave-function in `wp-includes/revision.php`: hidden link
- Preview in WordPress 6.7.2 worked
- WPML makes adjustments to the query in the `parse_query`-function in `classes/query-filtering/class-wpml-query-parser`
- it happens in line 380 when $this->maybe_adjust_name_var is called
After that I gave up and found this here...
Right now we downgraded WordPress to 6.7.2 to have at least a functioning workflow, but that can only be temporarily!
Since the issue is not happening with the sandbox site, To debug this issue further, I would need to check your site settings once, for this I would need temporary access (wp-admin and ftp) to your site.
So could you please provide me with those details, you will find the needed fields for this below the comment area when you log in to leave your next reply. hidden link
I set up a test site with a test user where you can see the problem:
login: hidden link
You only have restricted access to the site. I can't give you more. And definitely no ftp access.
Check the problem on this site: hidden link
Make some changes and click on preview.
The preview doesn't work. If you deactivate WPML, it works.
Check my former comment, it details where the problem occurs in the plugin code. On the live site I hacked the wordpress-core and downgraded the changes in "wp-includes/revision.php" to the version in 6.7.2. then it also works with the plugin.
Ok... I was stupid - please contact me for the credentials to the test site.