skylex69

Ok great, thanks!

I submitted a bug on WP’s trac : https://core.trac.www.ads-software.com/ticket/59094

Well, after a deep dive into WP’s autosave code and many tests in a brand new WordPress install, I can conclude that this is a bug in WordPress Core. When you are editing a post in “Text mode” in the classical editor, the function wp.autosave.server.postChanged() always returns true, even after an autosave was successful.

In fact, it’s very easy to reproduce:
– open the editor on any post
– change the post content in Text (not Visual) mode
– wait for autosave to kick in (watch the editor status bar)
– in the browser console type: wp.autosave.server.postChanged()
– it will return true
– switch to Visual mode editor
– same command will return false (meaning “autosave” is OK)
– switch back to Text mode editor
– same command will return true again, even if you didn’t changed anything more

At least now I know a workaround: use the Visual editor, or if the user is stuck after submitting a revision in Text mode: click on Visual mode then it gets unstuck and immediately submits the revision.

I narrowed down the issue to the line 160 of rvy_post-classic-edit.dev.js :

if (!wp.autosave.server.postChanged()) {

Which returns “true” in my setup if I change any letter in the content. But does always return “false” in a brand new WP setup.

Probably an autosave or heartbeat issue, I’m looking into it.

Well I’ve just tested on a brand new WordPress install and it works fine. I’m gonna dig to find out what’s causing this issue in our main WordPress install.

Thanks I’ve seen your video, but in fact we’re not using the block editor (Gutenberg) but the classic one, we change the post content and date and then click on “Schedule a revision” on the right side menu (the “Publish menu”).

Hi @rizaardiyanto,

The same problem occurs with PHP 8.1.22 as with PHP 8.2.8. I can’t test with PHP <8.1 due to some dependencies requirements.

But I don’t think it’s a PHP related issue as there’s no query going to the server when I click on the button, except for that autosave ajax query which doesn’t throw any PHP error in the logs.

It looks like a javascript bug IMHO. But could be some kind of incompatibility with my WP setup.

Can you confirm that this button is supposed to work fine with the latest version of the plugin? If, so I will dig deeper to find what could cause this in my setup.

Thanks

*I meant updated from 2.6.3

The language is French. Thanks

The date format was the same as this setting indeed, but the months were not translated in the search results, whereas it is everywhere else in this WordPress.

Response to myself, in case somebody else wants to do the same:

new Date(data.post_date).toLocaleDateString("fr-FR", {year: "numeric", month: "long", day: "numeric"})