"Page updated" notification should fade as soon as another change is made.

[nthnldtk]

The "Page Updated" notification can be very misleading if you continue to make changes to a page after updating once.

A solution to this problem would be for the "Page Updated" notification to get cleared as soon as another change to the page is detected.

[iseulde]

Thanks for the report and sorry for the late reply.
We have talked about this before. Removing the notification will move the whole page up a bit which would be really annoying if you're interacting with it.

[nthnldtk]

Thank you for your comments.

Is it possible that the problem could be solved in a way that does not create the issue you described?

For example: The notification disappears, but leaves blank space instead of the page jumping up.

OR (my preferred solution): Once the user changes the page, the notification changes from "Page Updated" to "Page changed since last save"

[johnbillion]

I think fading the notice out (without causing a shift in the page layout) once the user has started typing or making other changes would be a really nice addition to the editing screen.

Should be easy enough to accomplish. Let's try it.

[dlouwe]

Fades out Updated message upon making further changes to page/post

[dlouwe]

I'm not sure how I feel about the bit of white space that is left over after the fade - especially as it can't be removed (like how it would when dismissing the update manually).

Perhaps as @nthnldtk suggested there is a suitable way to change the message so that it is distinct from the "Just updated" message.

[juliandoucette]

There are two good solutions to this in my opinion.

1. Change the message

Change the message from Green -> "Page updated. View Page." to Orange -> "Page has changed since last updated. Update Page."

Potential issues:

• The edit page can be modified significantly by themes and plugins. The user experience can be inconsistent if a plugin or theme implements meta boxes or modifications to the edit page that don't trigger this message to change.
• It could be complicated to determine when to change the message. Is it when the user focuses on a field? Is it when the user changes the field? Note: if the user changes the field, and then changes it back, the message is no longer true.

2. Change the notification system

In the long run, I believe it would be a better idea to implement a message tray system for these types of notices.

The system could work like this:

1. A notice appears in a fixed position from the bottom centre of the edit screen
2. The notice remains until it is cleared or a set amount of time passes
3. The notice disappears

Notices stack if more than one are visible at a time.

I believe that these notices are better than the notices currently being used for the purpose of status updates like "Published", "Updated", etc.

This experience should be familiar to (at least) Android users.

[jaragozzine]

A lower tech solution that would eliminate the concern over a fade out leaving white space is to add simple text cues to the display message.

Meaning, change "Page updated. View page" to "Page updated at 2015-11-18 12:56PM - 2 minutes ago", with the latter "minutes ago" ticker updating as time passes.

[nthnldtk]

Replying to jaragozzine:

change "Page updated. View page" to "Page updated at 2015-11-18 12:56PM - 2 minutes ago", with the latter "minutes ago" ticker updating as time passes.

Ding Ding! I think this is a winner. Good thinking.

[sdavis2702]

@jaragozzine @nthnldtk

I feel like we're ignoring what @juliandoucette mentioned as potential issues with live updating the message. https://core.trac.wordpress.org/ticket/32228#comment:5 Those are pretty important concerns in my opinion.

[iambriansreed]

I agree with @jaragozzine @nthnldtk - updating the message with the update time when the form is $dirty is the best solution.

@sdavis2702 I think updating the existing functionality to show when it was last updated is the best next step.

To deal with the good points by @juliandoucette:

Problem:

The edit page can be modified significantly by themes and plugins. The user experience can be inconsistent if a plugin or theme implements meta boxes or modifications to the edit page that don't trigger this message to change.
It could be complicated to determine when to change the message. Is it when the user focuses on a field? Is it when the user changes the field? Note: if the user changes the field, and then changes it back, the message is no longer true.

Proposed solution:

I talked this issue over with @adamsilverstein and we thought we should just use a library like moment.js or timago.js. We don't need to wait for a callback or change to the form. The message you get after save is Page Updated Just Now

Then at a set interval we update Just Now with "1 minute ago", "2 minutes ago".

We have all seen this before in chat or social media comments, etc. Does this make sense?

[iambriansreed]

Message view

[iambriansreed]

Message example

[iambriansreed]

Message timeago. (my first patch)

[sdavis2702]

Nice! I like the time delay idea.

I wasn't able to get the patch to work fully. I tried to apply it from the root of the testing environment (​http://glui.me/?i=gl4m6vldl011tse/2015-12-06_at_5.06_PM.png/) locally and it wouldn't work. It may have something to do with where the patch was created from in your development environment. So I just made the edits manually to see how it works.

While I could get Just Now to show just fine, it didn't seem to update after any amount of time. All that aside, I can still give some feedback:

1. Pages and Posts both would need to be addressed. I'm not sure how this would apply to custom post types but it seems they would need the treatment as well.

2. Text strings should be translation-ready, like the Just Now text and whatever replaces it over time.

[iambriansreed]

This patch uses the jquery plugin timeago (​https://github.com/rmm5t/jquery-timeago). The plugin already has translation support its just a matter of bringing that code in.

Would it makes sense to have a built in shortcode like:
[timeago] or [timeago date="1449504353"] and add these to the strings "Post Updated [timeago]".

So when custom post types update the post_updated_messages they can add these in effortlessly.

Potentially we could make lots of admin notices time relevant with this shortcode as well.

[juanfra]

Nice idea!

I'd use the sprintf() function to format the "Updated Message" string(what you do with $saved_timeago and $messages['post'][1]). You cannot imagine how the sentence structure can vary in many other languages.

Another thing, the strings for the js library must be translated in php and not in js as the library suggest. This would be localizing the js script and sending the variables using the gettext functions.

Still, I'm not sure if including a new library is the best idea. We'll need to, at least, check the strings every time we need to update it.

[Jastuccio]

32228.diff​ Refreshes message-timeago.32228.diff​ relative to the src directory

[italianst4]

I really like this enhancement. I applied the patch to test and similar to @sdavis2702 above, wasn't able to see any updates beyond the initial "Just Now". I noticed a JS file was not pointing to the correct file, which I updated and can now see it working.

I also lowercased "just now" to feel more like a sentence.

I agree that this should be applied to all post types (post, page, custom...), as well as all relevant actions (published, updated, draft updated). I'm going to look a bit further into implementing this.

For now, I've attached a patch to fix the JS error.

[DrewAPicture]

Assigning ownership to mark the good-first-bug as "claimed".

[juanfra]

Nice one!

Please take a look that the "just now" message is not translatable. Also for the "Post updated" message you shouldn't concatenate the strings, you never know how other languages manage the same sentence.

I'd do something like this:

$saved_timeago = ' <em><abbr title="' . date( 'c', current_time( 'timestamp' ) ) . '" class="xwp-ui-text-icon timeago"> . __( 'just now' ) . '</abbr></em>';

Perhaps even using kses, and bringing up that string in a better way.

And then for the $messages['post'] array:

1 => sprintf( __( 'Post updated %s' ), $saved_timeago ) . $view_post_link_html; 

Cheers

[SergeyBiryukov]

#43655 was marked as a duplicate.

[swissspidy]

#44626 was marked as a duplicate.

[andraganescu]

This behaviour is present in the new editor as well. I have opened a similar issue in the Gutenberg repo here ​https://github.com/WordPress/gutenberg/issues/15132.

Given the age of the ticket I am unsure if this still applies so I am closing it here. If I am wrong please open it back :) Thanks!