I will test it. Maybe it’s really all issue. Problem appear not 100% of time, so need to test it one-two days.
Once you’ve done this, you might also need to do what’s called a “hard refresh” on each post or page in the admin. It simply involves holding down the Shift key while refreshing the page.
No, problem not solved. 5-10 saves all was OK. Than bug returns. Ctrl+Shift+R not helped. Maybe I will investigate it myself in free time. Thank you for help.
Weird. Maybe it’s caused by a plugin. Do let us know if you manage to identify the cause.
Maybe. My pages are complex with TinyMCE rendering hundreds of shortcodes. Sure I will notice you. Thanks for help.
P.S. I recently switched to ClassicPress and can write article about process, pros and cons. But I don’t have personal blog. Will it be useful here on the forum?
Absolutely! Please go ahead.
Investigated more.
We are using cookie ‘wp-saving-post’ adding it on save like this:
wpCookies.set( ‘wp-saving-post’, post_id + ‘-check’, 24 * 60 * 60, false, false, secure );
but on my machine
console.log(wpCookies.get( ‘wp-saving-post’ ));
always return ‘null’ because cookie looks like this:
HttpOnly: true
SameSite: true
So we just can’t acess to this cookie via JS. Cookie on my Wordpress sites or freshly created
wpCookies.set( ‘cp-saving-post’, post_id + ‘-check’, 24 * 60 * 60, false, false, secure );
don’t have such values and works fine. In our case code:
if ( cookie === post_id + ‘-saved’ ) {
wpCookies.remove( ‘wp-saving-post’ );
// The post was saved properly, remove old data and bail.
setData( false );
return;
}
Newer run because cookie = wpCookies.get( ‘wp-saving-post’ ) always return ‘null’. I tried to manually delete it via developers tools. It’s recriates with such values:
HttpOnly: true
SameSite: true
Don’t investigate further. I don’t know much about cookies. Can I somehow help you to fix issue? Maybe test your code on my machine?
The problem is your cookie is missing the last parameter, which sets the httponly property. You need to add , 'false' to your list of parameters.
I just take the code from unminified autosave.js ClassicPress (2.3.1). Maybe it is different in current release from .min file? Really strange.
I migrated my WP site to ClassicPress 2.3.1 via migration tool. In instruction was that I need to pres reinstall. But that button produce error on my site. Something about wrong archive (if needed, I can copy error, when can take my hands on laptop).
Maybe migrated version is different from default?
TL&DR: If my code missing something, so it was missed in ClassicPress autosave.js and probably needs fix.
I realize English might not be your first language, but you said “we”. That makes it sound like you are doing something different from the norm. So I gave you a fix for that.
If you simply meant you have observed this behavior, then the cookie isn’t the cause of this. Otherwise every other user would be reporting the same issue.
Sorry. I’m from Ukraine. I saw a lot when users of specific projects wrote “we” about community. Like “we as users / developers of ClassicPress”. Maybe I just was fascinated and wanted to be part of community and contribute to project.
Now I will know it’s not right in English. Thank you. My English really not so good.
I mean that probably bug is in ClassicPress code. I don’t manually changed anything. Just investigated. And in my case this cookie always returns ‘none’. It sets on post save so code don’t compare saved in browser post vs actual.
As I understand, meaning of this cookie is: “Everything saved properly, don’t check further”. But if cookie unredable, so this code just don’t work.
Reason why every single user don’t have this issue: saved in browser code later compares with actual. And in most cases it’s same, so no notice will showed. I also get this not on all of my pages.
In my case (part of pages) it’s slightly different for two reasons:
- Saving of spaces after links or custom rendered shortcodes.
- For testing I saved fast after edit (I have shortcut for that), so autosave don’t have time to run and update code stored in browser.
If it’s possible, maybe you can check if in your install that cookie also always unreadable? I think I can fix issue. But it’s not right to directly edit core files.
As I understand issue - it’s really bug, that can be easily fixed in one of next releases.
Thank for you patience.
You just need to check if on your machine this code usually work. As I understand, this is standard behaviour on properly saved post.
If not, it’s maybe but, that can be fixed.
@timkaye I too have that bug on fresh installs (all default without installing themes or plugins) but since I am no core wizard I did not inspect that file for the “biscottini” (cookies in Italian, just to lighten the mood).
To be noted I use FireFox that I think does things to cookies in its own way.
If someone tells me where to look to investigate I can help. (I did not because I thought it wasn’t a big issue once I save the post and know it is saved I am ok even if the notice pops up).
@soller the use of “we” is not wrong when used to describe something a group of people is doing (like in we == the ClassicPress Community) - in your case however we meant that you were investigating on behalf of the community and this was “lost in translation” because of the differences in how English and Ukrainian build sentences. We all are aware that the community is diverse and everyone tries to take into account that English might not be the first language.
Thanks for investigating this issue, where do I look to see if the issue I have with that notice comes from cookies too? Do I have to check the same file you mention above in core?
I do not think it is a CP bug really but something on how browsers do handle the biscottini, in that case we might need to check how to correct the code to follow their way of handling them. (I say this considering the fact that browser nowadays have all that stuff to automatically block cookies, beacons and marketing stuff and that could very well be the cause of CP having this issue?)
@Soller No problem about your English. It’s far better than my Ukrainian! I was just explaining why I misunderstood you.
To use a real English colloquialism, I think cookies are a red herring. In other words, what you are reporting about them may be unexpected to you but it’s not the cause of this problem.
This is where the problem lies. The fix we applied to version 2.3.0 of ClassicPress was all about spaces. In order to know whether the current version of a post or page is up to date, CP compares it to what is stored in the browser’s local storage. What we discovered was that the way some browsers (especially Firefox, as @ElisabettaCarrara notes) interpret spaces was not always the same as the way that CP interprets spaces, and so CP sees a difference. Hence the message you are seeing.
It seems this problem still exists where spaces are associated with shortcodes. The difficulty is working out what characters your browser is storing as spaces. If you have any way of working that out, we can come up with a fix.
I’m sorry that I can’t write more clearly. Maybe my English is too bad. Maybe it’s because I’m trying to write it sitting without electricity and with an unstable Internet connection. I just will try one more time.
I downloaded autosave.js from ClassicPress 2.3.1.
On line 437:
wpCookies.set( ‘wp-saving-post’, post_id + ‘-check’, 24 * 60 * 60, false, false, secure);
This code runs on post save and sets cookies, that can’t be readed later via JS. I don’t know why, but it has
httpOnly = true
Let’s investigate function checkPost ():
On line 471 I see:
cookie = wpCookies.get( ‘wp-saving-post’ ),
So the code trying to read the cookie, which can’t be readed. In my case console.log(cookie);
returning ‘null’.
Let’s check the function code. Lines 475-480:
if ( cookie === post_id + ‘-saved’ ) {
wpCookies.remove( ‘wp-saving-post’ );
// The post was saved properly, remove old data and bail.
setData( false );
return;
}
This code checked if the post was saved correctly by reading the cookie in the question. But because of
httpOnly = true
cookie = wpCookies.get( ‘wp-saving-post’ )
always returns ‘null’.
If we fix httpOnly, in most cases future checks will not be needed.
Then on lines 482-484 the code checks if something stored in browser:
if ( ! postData ) {
return;
}
If so, lines 486-494 tries to compare HTML stored in the browser with that saved in the Database:
content = document.getElementById( ‘content’ ).value || ‘’;
post_title = document.getElementById( ‘title’ ).value || ‘’;
excerpt = document.getElementById( ‘excerpt’ ).value || ‘’;
if ( compare( content, postData.content ) && compare( post_title, postData.post_title ) &&
compare( excerpt, postData.excerpt ) ) {
return;
}
You are right, that in an ideal world lines 486-494 will do the job. But why even try, if in the majority of cases we don’t need it? If the post was saved by clicking “Update” button, we will have ‘wp-saving-post’ cookie.
So it’s not hard to fix these false alerts if we fix httpOnly = true on ‘wp-saving-post’ cookie.
I read the code a lot of times. If I’m wrong, please explain to me why the code creates a cookie, that it can’t use and then tries to read it. It will help me to become a better developer.
I checked the behaviour from WordPress. And it can read this cookie. It hasn’t httpOnly = true.
I tried to check utils.js: it’s the same as WordPress. I installed new ClassicPress site. Saved Hello world! post and still get this:
I think it’s some error made when improving security. What is your opinion?
Can you make me the same screenshot from your environment? What returns console.log(cookie); on line 476 of autosave.js?
Thank you one more time for helping me to investigate this issue.
Your English is fine! I understand your analysis. But please compare it with WordPress. I think you will find the same thing.
So I am not saying that you have found nothing significant. What I am saying is that I don’t believe it’s the cause of the problem you initially reported.
Now I understand. I might test this tomorrow morning to confirm since here it’s starting to be evening. What you are saying is that when saving the post/page, that action generates a cookie in the browser that stores the content locally in the browser, and then CP can’t read the same cookie from the browser for an error due to how browser decides to save the cookie, and LATER in the code, when trying to compare what’s in the cookie (that is the content the browser “remembers” and as @timkaye says it interprets as it pleases) with the DB version of it it can’t for the problem of the unreadable cookie.
@Soller this means exactly what was explained, it’s the browser that stores and interprets the cookie the wrong way and stores the data in it as it pleases instead of as it is presented by CP. it is not entirely true that fixing the cookie the error is going to stop happening because browsers do update the way they store content in cookies continuously. But understanding how they do it might bring to the release of a fix.
The issue is browsers, not CP. And the issue I see is that different browsers might treat, store and interpret the cookie differently so that makes it tricky for us to have a comprehensive fix.
I find the bug!!!
It’s in wp-admin/post.php
WordPress 230-232:
if ( isset( $_COOKIE[‘wp-saving-post’] ) && $_COOKIE[‘wp-saving-post’] === $post_id . ‘-check’ ) {
setcookie( ‘wp-saving-post’, $post_id . ‘-saved’, time() + DAY_IN_SECONDS, ADMIN_COOKIE_PATH, COOKIE_DOMAIN,
is_ssl() );
}
ClassicPress 225-234:
if ( isset( $_COOKIE[‘wp-saving-post’] ) && $_COOKIE[‘wp-saving-post’] === $post_id . ‘-check’ ) {
$cookie_options = array(
‘expires’ => time() + DAY_IN_SECONDS,
‘path’ => ADMIN_COOKIE_PATH,
‘domain’ => COOKIE_DOMAIN,
‘secure’ => is_ssl(),
‘httponly’ => true,
‘samesite’ => ‘Strict’,
);
setcookie( ‘wp-saving-post’, $post_id . ‘-saved’, $cookie_options );
}
So someone purposely sets ‘httponly’ => true for the cookie. But it’s wrong as it’s later will be read via JS.
Removed that line. And no more annoying notice. Can you add this fix to the core?
Hello. I find the bug. Not a browser issue. details in previous post.
That’s excellent work! You were correct!
I have been looking at when and why the change got made. It looks like it was changed along with a number of other cookies. I’ll open a PR to get this changed back, but can I ask that you see if the same problem happens at other times? It might be that another cookie needs modifying too.
Thank you!