Make WordPress Core

Tagged: autosave and post locking Toggle Comment Threads | Keyboard Shortcuts

  • Mike Schroder 7:07 pm on March 6, 2013 Permalink
    Tags: , autosave and post locking   

    Autosave and Post Locking – 3/6 

    Improved user logout notification ( #23295 ) is now in core, and its UI has been tweaked to directly show the login box, rather than prompting first:


    There’s been discussion as to whether it’s better not to block the user’s access to the editor/current page when we detect that you no longer have a login token, since it could stop a user while they’re in the middle of a sentence. Any opinions either way? Feel free to comment either here or on #23295.

    A simple way to test the above is by removing your login cookie while working in WordPress (Firebug works well).

    On local autosaves, there was a decision to pivot from the previous UX posted here, and instead integrate with the new revisions model. This code is still being worked on.

    In the land of post locks, @azaozz posted a patch on #23697, that shows a dialog either when you visit a locked post, or when your post becomes locked. If you are visiting an already locked post, you have the option to break the lock. This is still in need of UX/UI love, but looks like this currently:


    Finally, a patch on #23665 allows for one autosave per user per post, rather than per post, to let us keep an autosave from before you lost a lock. Testing on this, and the rest of the above welcome!

    • Mark Jaquith 8:24 pm on March 6, 2013 Permalink | Log in to Reply

      I think the session expired modal should darken the rest of the page. It kind of blends in as-is.

      • Mike Schroder 10:45 pm on March 6, 2013 Permalink | Log in to Reply

        Agreed. I think that was initially left over from the “let’s let the user continue to work” mentality. If we’re going with “Your only path is to log back in,” then making it darken the rest of the page is appropriate.

      • lessbloat 3:16 pm on March 7, 2013 Permalink | Log in to Reply

        I agree with @MarkJaquith. I took a quick stab at mocking it up:

        • Added a dark fullscreen overlay
        • Added right: 35px; left: 35px; top: 35px; bottom: 35px; to #wp-auth-check
        • Centered the login iframe
        • Removed the “Session expired” title
        • Removed the close link. If the whole point in doing this is to keep users from losing their work, I think we have to force it. The best thing they can do at this point is log back in, and continue on their way. If we do allow them to close it, and they click “publish”, they will be redirected to the login screen anyway, but once they log back in, they’ll discover (tragically) that all of their work has been lost.
        • Tweaked the copy to read: “Oops… Your log in has expired. Please log back in below to avoid losing any of your work.”
        • Andrew Ozz 6:44 pm on March 7, 2013 Permalink | Log in to Reply

          Was testing something similar too and agree it looks better. The only concern is that it will frighten the user when it shows.

          Most commonly this will show on the Add / Edit Post screen (as the users spend most time there). Imagine typing a new post, uploading images, etc. and suddenly the screen with your work disappears and is replaced by the login screen telling you to log in again. I bet two “scary” thoughts would go through your head: “What happened to my post?” and “This asks for my password, is it legit?”. Additionally the screen change will most likely cut you in the middle of a sentence and can literally startle you.

          In the original patch this was a two steps process: a non-modal (position fixed) warning shows first telling the user that the session has expired and asking to log in again. As the rest of the screen is visible this is not that scary (you can still see your work) and won’t startle you as most of the screen doesn’t change. Then clicking a link or a button in the warning opens the actual login screen in a modal.

          Perhaps this is a better solution. Yes, one more click, but better user experience.

          • lessbloat 1:56 pm on March 8, 2013 Permalink | Log in to Reply

            I think we can likely find a way to lessen the fear by getting the copy right. You could also bump the darker outer margin up (maybe double the margin), and perhaps lighten the opacity a tad, so that the user still can see some of the screen behind.

            I prefer the one step (taking them straight to the login form), vs. showing an intermediary step (which looks more suspect than the log in form with the logo above it, to be quite honest). If they’ve saved their login details, they only have to click once (on the “Log in” button), and they are right back to their writing.

    • jltallon 12:52 pm on March 20, 2013 Permalink | Log in to Reply

      +1 — Translucency allowing the user to see that their content is still back there, undisturbed, perfectly conveys the notion that “your session has expired, we need to re-authenticate you so that you can follow working as if nothing had happened”:

      • My content can be seen behind/below -> I haven’t lost my work
      • My *own* content is back there -> legitimate password request

      IMHO, you nailed it.

  • Mike Schroder 6:49 pm on February 13, 2013 Permalink
    Tags: , autosave and post locking   

    Autosave and Post Locking – 2/13 

    This is a rather late update, and will serve for the last two; apologies!

    Last week, we talked about the locks that went in, and @markjaquith suggested that we replace the “lock” with a Gravatar, which I like quite a bit. Will experiment with that to see if it can work.

    Today we chatted about the most recent update to #23220 posted by @azaozz, which integrates the work done by @asannad (AmitSannad on IRC), and adds a UI for selecting which you’d like to restore: localsaves_screenshot

    In addition, if it’s found that you have an autosave that has failed, and have a newer version locally, you’re warned (either on the Posts list or Post itself), and linked to the UI that allows you to restore the content (post content and title only) and save at will:

    It was brought up during the chat by @nacin that the UI included in the patch might be more than we need, and that we should decide what is best for the user regarding restores, and perform it for them. We continue to chat about this, and opinions are welcome!

    Lastly, there is a patch from @mintindeed on #23295 currently waiting for integration! That patch, and the one on #23220 could use some testing — let us know if you run into problems on trac.

    We’ll be meeting again this Friday at 2100 UTC (1pm PST).

    • Gabriel Koen 7:28 pm on February 13, 2013 Permalink | Log in to Reply

      Oops I missed today’s meeting.

      I am working on some revisions to my patch based on feedback from last week’s meeting, unfortunately work is killing me this week so it will probably be the coming weekend (Feb 16–17) before I get a revised patch up there.

  • Mike Schroder 10:47 pm on February 2, 2013 Permalink
    Tags: , autosave and post locking   

    Autosave and Post Locking Update 2/2 

    A quick update on status!

    Earlier this week, the initial run at the Heartbeat API went in. @azaozz is continuing to work on it, and flesh out the API further ( #23216 ).

    Tonight, the initial post lock view for the post listing was committed [23355] along with a temporary icon:

    I took a look over an older version of the NYT plugin kindly contributed on #18515.
    For discussion, I’m including a few examples of the UI/UX from the workflow included in it below.
    We don’t necessarily think everything here is a good idea for core (for instance, the “get me out” buttons wouldn’t be necessary), and will likely go a different route for UI, but hoping to get a bit of discussion going regarding the UI/UX flow for the project.

    Lock table:

    Lock table user mouseover:

    Popup for lock within Post Editor:

    • Ipstenu (Mika Epstein) 7:44 am on February 3, 2013 Permalink | Log in to Reply

      The first icon goes better with the new icon sets that’ve been worked on. Don’t forget to loop back to that group πŸ˜‰

      What user levels can break locks? Is it hierarchical so Admins can break anyone’s locks, but Editors can break admins and so on down the line?

      The alert boxes greying out the screen behind is good, that reinforces ‘Hey! Someone’s in here!’ You could use that extra space to have something like …

      Warning: POSTTITLE is locked

      Other Person is currently editing this post.

      You can view the post as read only, exit out, or unlock the post and take over. If you chose to break the lock, their edits will be lost(?).

    • Alex 8:13 am on February 3, 2013 Permalink | Log in to Reply

      Why not open the edit screen as read-only directly? Greyed out with a warning on the top of the page which contains the “request” and “force” buttons. Content refreshes every 15 seconds and you directly see what the other is working on. Less buttons, less clutter.

      • Mike Schroder 6:44 pm on February 4, 2013 Permalink | Log in to Reply

        Read-only on edit is what we’d initially chatted about, so I’m glad to see you agree! I really like the idea of having the warning within something similar to the current warnings, only with “request” buttons there. Do you think it’s important to be able to force immediately, or only allow that after you’ve requested, and don’t immediately get feedback?

        • Ipstenu (Mika Epstein) 7:19 pm on February 4, 2013 Permalink | Log in to Reply

          I think… people don’t RTFM enough. A splash is annoying, but less likely to miss (never underestimate the ability of people to click on something without reading).

          • Alex 9:49 pm on February 4, 2013 Permalink | Log in to Reply

            Grey everything out and set the input fields to read only. Then refresh them all 15 seconds with auto-save changes from the current editor.

            @Mike Schroder: I think a button to force-get the right for editing would be necessary for people with a higher role. Still, the user currently editing would need to get a warning and a countdown for deciding to save or discard his work.

    • Alex 8:17 am on February 3, 2013 Permalink | Log in to Reply

      And is it already planned to add a “x people are watching you editing this post” notification?

    • Andrew Ozz 6:25 pm on February 4, 2013 Permalink | Log in to Reply

      Yes, we can use a modal to block access to the Edit Post screen when opening a locked post and show a “preview” of the latest content entered by the other user. In that modal we won’t need the “Read Only” button from the above screenshot and the “Get Me Out” would be “Return to [previous page]” or “Go to All Posts”.

      The “Unlock” could be “Request to edit” or “Request the lock” which will pop up a notification on the other user’s screen letting them finish what they are doing and save or perhaps refuse to give up the lock.

      Instead of a modal, this can also be a whole different screen. Then after the lock is transferred, the user will be able to load the post for editing. This way we will be loading everything fresh from the server.

    • Sam Parsons 5:04 pm on February 5, 2013 Permalink | Log in to Reply

      I know this maybe off-topic, but the whole idea of the hearbeat API and even perhaps showing updates from a locked post to an editor who is about to acquire a lock makes me think about perhaps making it a full collaborative editor? Why not go that far? It seems we’re already getting close. It’s a matter of sending/receiving diffs on the long-polling method which was discussed earlier.

  • Mike Schroder 11:17 pm on January 25, 2013 Permalink
    Tags: , autosave and post locking   

    Autosave and Post Locking Update, 1/25 

    We had our scheduled meeting today in IRC to continue planning the feature for this cycle.

    @azaozz noted that he’s continuing work on the Heartbeat API #23216, on schedule for initial commit before next week.

    I am continuing work on an initial pass for the post/page tables to display locks, and properly display edit/bulk edit links when locked. Should have an initial pass ready for view on Monday.

    @mintindeed offered to help port his plugin to core for improved login expiration warnings, which is great! He’s created #23295 to track the efforts.

    @asannad (AmitSannad on IRC) offered to help with localstorage Autosaves, which is being tracked on #23220. Initially, we’ll use a simple schema for storage, but will probably need something more complex later on to avoid collisions where multiple databases are used within the same domain.

    As initial guidance for improved workflow for locks, we’re looking over the plugin mentioned in #18515. @nacin is checking with the authors to see if there’s a new version we can take a look at.

    Our next meeting is on Tuesday, January 29th at 2100 UTC (1pm PST).

  • Andrew Ozz 8:20 pm on January 25, 2013 Permalink
    Tags: , autosave and post locking   

    Agenda for today’s autosave and post locking team meeting at 21:00 UTC:

    • Assign contributors for each component: Autosave in the browser storage, Post locking, Login expiration warning.
    • Further discussion on workflow for post locking, perhaps look at the plugin by jayminkapish on #18515.
    • Free-form Q&A.
  • Mike Schroder 4:53 am on January 23, 2013 Permalink
    Tags: , autosave and post locking,   

    Autosave and Post Locking Update 

    Today we had our first scheduled meeting.

    Consensus was, for a first pass:

    • Display a simple lock/padlock icon next to locked posts within the post list screen, leaving the “Request Lock” button for the post edit screens.
    • When a post is locked, hide the Quick Edit link, and disable batch edit for the post
    • To unlock a post, the user will enter the post edit screen, then click a button to request a lock. Β This will trigger a request to appear for the user with the current lock, where they can decide whether or not to allow the new lock.

    As far as development tasks go, @azaozz is planning on finishing a first run at the “Heartbeat” API to be committed before the end of the week. I’ll begin working on the list table changes for post listings. We’re currently looking for volunteers to aid, as there’s plenty of room for help! Additional tasks will include the UI for handling post lock requests and auto-save to local storage.

    We’ll certainly chat more about this tomorrow in dev chat, and are planning another meeting this Friday (2013–01–25), at 21:00 UTC (the same time as dev chat), unless this doesn’t work for many of you looking to help. Please post here, or come to the chats if you’re interested in helping with this project, and we’ll get in touch with you for further details!

    • John Saddington 12:20 pm on January 23, 2013 Permalink | Log in to Reply

      fantastic. i’m on pins waiting for this implementation. can’t wait!

    • mindctrl 3:25 pm on January 23, 2013 Permalink | Log in to Reply

      The idea for implementing post locking is for a person to manually click a Request Lock button in the edit post screen? Would that show up on all installs or only installs that are multi-author? Why not automatically lock a post when editing it so the workflow is streamlined?

      • Andrew Ozz 4:32 pm on January 23, 2013 Permalink | Log in to Reply

        Good questions. The Request/Take over a lock button will only show when the same post is being edited by another user. Under normal circumstances posts would never be locked on installs with only one user. However if the user opens the same post on two different devices (computers) or in two different browsers, the first instance should lock the second. That should also happen if several people use the same user account.

        We already monitor when a post is being edited and show a warning. The purpose of the enhancements is to actually prevent saving a post from two different places simultaneously.

        • mindctrl 5:59 pm on January 23, 2013 Permalink | Log in to Reply

          Thanks for the clarification. Sounds great.

          Will this be implemented in the mobile apps? I’m wondering what would happen if someone tried editing a locked post from a smartphone or tablet, and would those devices be able to lock and/or take over a locked post?

      • Mike Schroder 6:22 pm on January 23, 2013 Permalink | Log in to Reply

        That’s the idea — you’d get the lock automatically if the post isn’t locked by anyone. Then, if it’s already locked, you have the option to request the lock from the author that holds it. The feature would still exist on single-author installs, but you wouldn’t notice it, because you’d be the only one able to hold locks.

        [edit] Previous comments weren’t showing when I typed this. @azaozz‘s comments above explain further πŸ™‚ [/edit]

    • Mark Jaquith 8:52 pm on January 23, 2013 Permalink | Log in to Reply

      Unless I’m misunderstanding, this approach seems like it could result in posts becoming permanently locked.

      1. Open post for editing
      2. Walk away
      3. ???
      4. Profit

      • Mike Schroder 9:18 pm on January 23, 2013 Permalink | Log in to Reply

        To resolve this issue, we’ve talked about including a concept of activity via keystrokes and maybe mouse movement to maintain the lock assignment (otherwise, a user would lose the lock after X amount of inactivity).

        • Andrew Ozz 7:49 pm on January 25, 2013 Permalink | Log in to Reply

          We can also monitor user activity comparing autosaves to the server. If there are no changes for x minutes, user is inactive. Maybe we can set another flag for “user-active” in the post lock and toggle it based on autosaves.

  • Andrew Ozz 12:58 am on January 19, 2013 Permalink
    Tags: , autosave and post locking   

    Autosave and Post Locking 

    Components and design

    As Mark pointed out earlier, this task includes several different components:

    “WP Heartbeat” API, #23216. This will do polling or long-polling so the server is able to send data and notifications to the browser. The primary use will be for setting, monitoring or taking over a post lock. Additionally it will be used to send autosave data to the server. It looks like we won’t need long-polling for now as post locks are not that time sensitive. A “standard” polling every 15 seconds would be sufficient.

    Post locking. How exactly to lock a post and how a user can take over the lock? Best would be to prevent user B from being able to edit the post while user A is still writing or editing. Some ideas discussed at the IRC meetup yesterday are to overlay a transparent div over the editor and/or set the form fields to read-only. There will be a button for user B to take over the lock, clicking it will prompt user A to save the post and close the browser tab. While user B is waiting to take over, we could show a non-editable “preview” of the content (even inside the editor) updated with every “heartbeat”.

    In addition we would show whether a post is being edited on the Posts screen (list table) , perhaps with the same type of button to request taking over. Other ideas welcome.

    Autosave to the browser’s local storage, #23220. Keep several revisions of the content on the user’s hard drive, saving every 10 seconds and “flushing” to the server every 2 minutes (same as currently). After saving to the server (including saving a draft or publishing), empty the local storage and start again. So at the end of creating or editing a post, the local storage will be empty.

    This will require “plugging into” the revisions API for restoring revisions from the local storage and some UI for letting the user recover the last revision from local storage when it exists.

    Log-in expiration warnings. Update the current functionality to use the new heartbeat API and improve the UX and UI. We can detect cookies expiration earlier and show a warning that would open an iframe so the user can log in again. After that interim log-in, we will need to update all nonces.

    Office hours

    The first feature team meeting in IRC will be next Tuesday,Β 22 January at 1pm PST / 21:00 UTC. Please join us if you’re interested in participating in the development of any of the above components.

  • Mark Jaquith 7:42 pm on January 7, 2013 Permalink
    Tags: , autosave and post locking   

    WordPress 3.6: Autosave and Post Locking 

    I want, as a major 3.6 bullet point, that we should never lose posts due to expired cookies, loss of connection, inadvertent navigation (even if AYS’d), plugin or core errors on save, browser crashes, OS crashes, cats walking on keyboards, children drooling in keyboards, etc. I want people to trust WordPress with their posts. They should never fear that something they’ve spent time creating or editing should go away due to their mistake or ours or that of a third party. Mistakes and errors should be recoverable. I can’t stress enough how important it is that people believe this and have good reason to believe it. If a post gets lost, there is a catastrophic loss of trust, that could take years to be regained (if indeed it ever is). This is people’s time and their creative output we’re talking about. If we’re not valuing those things above all else, then our priorities are seriously out of order. This is an all-hands-on-deck item for 3.6. Even if you’re not actively working on the code or the copy or the UI or the UX I want you to be thinking about ways in which WordPress could better treat your creative output as the valuable artifact it is.

    Things this will likely involve:

    • Local storage of post data while editing, in-between autosaves and manual saves.
    • More frequent “heartbeat” pings to the server (allowing data to hitch a ride at certain intervals, and also allowing us to quickly deliver messages back from the server about events).
    • Real and more granular post locking. Right now we just have a wimpy notice that isn’t a good deterrent against people simultaneously editing a post and overwriting each other’s changes.
    • Probably some interaction with the team working on improving Post Revisions.
    • UX work for making recovery from failure scenarios smooth, clear, and worry-free.

    @aaroncampbell and I have chosen @azaozz to lead this, as it will probably be very JavaScript-heavy. There are a lot of moving parts here, so please leave a comment if you’re interested in this important, heroic, virtuous endeavor. πŸ™‚

    • Mike Schinkel 7:43 pm on January 7, 2013 Permalink | Log in to Reply


    • Jon Brown 7:46 pm on January 7, 2013 Permalink | Log in to Reply

      +1 – May I suggest that versioning and autosaving of metadata be included in this push. I’ve seen several people become reliant on the revisions and auto-save of the content (yay, they trust it!) and then be disappointed to discover their excerpt or content in a metabox isn’t given the same treatment.

      • Mark Jaquith 7:55 pm on January 7, 2013 Permalink | Log in to Reply

        There’s at least one ticket that touches on that https://core.trac.wordpress.org/ticket/20299

        But yeah, we need to start thinking about the fact that as more people use WP as a CMS, a lot of their important data resides outside of post_content.

        • Travis Northcutt 8:01 pm on January 7, 2013 Permalink | Log in to Reply

          Absolutely this. We make heavy use of post meta in sites we build for people, and storing revisions would be a huge plus. Does anyone know of additional tickets that address this? (The one Mark linked to is specifically focused on the fact that previewing changes to a post updates meta (silently), which isn’t expected behavior).

    • Pippin (mordauk) 7:55 pm on January 7, 2013 Permalink | Log in to Reply

      Huge +1.

    • goldenapples 7:58 pm on January 7, 2013 Permalink | Log in to Reply

      +1, I’m very interested in helping work on these features. I’ve worked with the authors on the site I manage to find workarounds for a number of related problems and have several ideas I’d like to test out:

      • visualizing revision history as a tree rather than just a list (I look at vim’s :Gundo plugin as a rough UI example)
      • post meta as mentioned above, although that needs a LOT of thought (lots of postmeta is never shown in a meta box, or is not meant to be edited by authors…)
      • doing more to enable inter-user messaging along with the “heartbeat” autosave calls. Its possible to do something with websockets for the maybe 2% of sites that have that enabled, but for most people, the regular admin-ajax calls could be used to pass messages back and forth about what other users are viewing, if one user requests a release of the lock, etc.
    • adamsilverstein 9:07 pm on January 7, 2013 Permalink | Log in to Reply

      i’m interested in helping if i can

    • John Saddington 9:19 pm on January 7, 2013 Permalink | Log in to Reply

      omg. yes.

    • Arnan de Gans 9:22 pm on January 7, 2013 Permalink | Log in to Reply

      And on top of that… While you guys are at it, make the dashboard, the whole of it, faster. Better loading, faster rendering (?) Whatever. Often on sites that have a bunch of plugins active it get’s really sluggish.

      • Aaron D. Campbell 10:13 pm on January 7, 2013 Permalink | Log in to Reply

        This is largely dependent on what they plugins you’re talking about do on the dashboard. Sounds like they’re likely doing something wrong if they’re slowing down the dashboard that much.

      • Aaron Brazell 12:04 am on January 9, 2013 Permalink | Log in to Reply

        Or nuke it altogether. I don’t have numbers but I’m guessing the majority of people spend 1% of their time in the Dashboard. I find it altogether useless, although I’m sure some would disagree with me.

        When I login to WP to produce content, the first thing I do is click on Add New in the posts menu. That’s a hover and a click more than I need to get into content production.

    • John Kleinschmidt 9:46 pm on January 7, 2013 Permalink | Log in to Reply

      I have been doing a decent amount of work around offline storage recently and would love to help contribute on the JS side of things.

    • Md Mahmudur Rahman 10:10 pm on January 7, 2013 Permalink | Log in to Reply


    • Grant Norwood 11:59 pm on January 7, 2013 Permalink | Log in to Reply

      Thanks, Mark. This is a great goal, and worthy of the urgency you’ve expressed! Since you mentioned post revisions, I’d like to recommend that we think about how to better compare post/page/CPT revisions within the rich text editor. As it is currently implemented, non-technical users have difficulty comparing large amounts of plain-text and raw HTML, and often give up immediately when using the compare feature. Developers are accustomed to the unified diff format, but we’re the only ones.

      Could we take inspiration from the review/editing/comparison tools used in other popular copy-editing apps (i.e., MS Word) that would make a copywriter feel more at home when comparing content revisions?

    • Gabriel Koen 9:18 pm on January 9, 2013 Permalink | Log in to Reply

      I’d like to lend a hand with this, I can provide user insight (our dev team has been fielding issues regarding this topic for a few years from a large staff of writers) as well as do PHP and JS coding for it.

    • Mike Bijon 12:49 am on January 13, 2013 Permalink | Log in to Reply

      I’d like to help with this during this cycle too.

      Since I’m time-limited to being effective on only 1-2 tickets per cycle, I be happy to help with tests and testing if time there would be valuable.

compose new post
next post/next comment
previous post/previous comment
show/hide comments
go to top
go to login
show/hide help
shift + esc
Skip to toolbar