Support » Plugin: Gutenberg » Gutenberg and Autosave

  • Resolved christosharrison


    This is not a page related matter, although there are a few issues.

    The major one is Gutenberg’s autosave.

    We need to be able to shut this off. It gets seriously annoying trying to go from one “block” to another, with autosave causing a serious lag.

    Give us the option to shut this annoying feature off. We are fully capable of saving our work at our pace.

    It has taken me over an hour to do what i used to be able to do in a quarter of the time.

    The page I need help with: [log in to see the link]

Viewing 8 replies - 1 through 8 (of 8 total)
  • Moderator Samuel Wood (Otto)

    (@otto42) Admin

    It shouldn’t be causing a “lag” because it happens in the background, through the REST API.

    Do you see any error messages in the Javascript console?


    I’m facing this issue as well

    Console shows:

    [HTTP/1.0 403 Forbidden 480ms]

    – it is online server,
    – no other plugins activated
    – not possible to create/publish new post or edit old one
    – plugins version: 3.5.0


    Moderator Samuel Wood (Otto)

    (@otto42) Admin

    Okay, so, you need to figure out why your server is returning a 403 for the REST calls.

    Do you have a security plugin blocking the REST API?


    – it is online server from well-known hosting company . no special server setup.
    – no other plugins are used
    – it is fresh WordPress installation
    – default 2017 theme

    And it is issue with whole save/publish functionality (not just autosave).


    • This reply was modified 2 months, 4 weeks ago by  dannci.
    Moderator Samuel Wood (Otto)

    (@otto42) Admin

    Anything that blocks the REST API calls will cause various issues, because that’s how the editor talks to your site.

    The new editor interface is very Javascript oriented. Everything you edit happens in the browser, and then it talks back to the site using the REST API to save things, make changes, etc. It also uses that to get information from the site, like what categories are available and so forth.

    So, anything that blocks that wp-json call will essentially break the editor. You need to look at your server configuration and find out what is blocking that call. You may need to ask your host why it’s returning 403 Forbidden messages.

    I have a problem with autosave as well.
    It freezes and locks up, then I need to reload the entire editing window.
    I also get a failed save message on the autosave, even though there’s no problem saving when I manually press the “Save” button.
    This feature is really annoying and wastes a lot of time.

    Hello christosharrison,

    Autosave is a handy feature, but not just for saving, because it (hopefully) maintains contact with the server periodically, so will lower the chance of connection timeout – which if the contents are not saved locally, or you move away from the page before you’ve attempted to save to a text file (copy and paste), then you might not be so happy about having a timeout (which may be similar in effect as to what yourexpireddomains has described – but worse).
    Yes though, to the experience that you are having. Clearly the designers have not intended for you to be having this happen. And it may be a combination of a number of factors which are not isolated to Gutenberg, though Gutenberg would probably be involved.
    The suggestion you make of being able to turn off the autosave sounds interesting, and would be interesting to see how that progresses.

    Hello dannci,
    There are some other causes that could be worth checking.
    The ones commonly mentioned as standard checks on the net are ;
    a) the “.htaccess file”, and
    b) file and folder permissions
    Samuel Wood is correct when he says that “anything that blocks the REST API calls” will cause issues, and he asked if you have a security plugin.
    The problem may be due to security functions that are not just in a plugin.
    Less easy to find are other causes and respective solutions, include such things as ;
    c) having a CDN
    d) having a firewall (in WP, on server, in hosting service, Isp or networking service, in-house)
    e) small chance of settings in browser (but not likely)
    f) caching systems (within WP, within PHP, on server, on-route through the network & internet, and browser – these are not so much a cause of 403 errors, but having received a 403 error, if one tries to refresh the 403 error page, then in some cases, the browser will refresh the 403 page (which is not likely to change) rather than re-attempt to load the page that caused to 403 page.
    Also, having received a 403 message, it is handy to refresh your browser to flush the browser cache – not that that has a big chance of fixing it, but it is quite easy to do to at least eliminate that possibility.

    Help for all of those situations is available on the internet, so need not be described here.
    But the above should serve as a check list for searching for possible causes.

    Hello yourexpireddomains,
    Sorry to hear that you find this feature to be really annoying and that it wastes a lot of time. I am not a developer of this plugin, but it might be handy to run your browser in some sort of debug mode to pick up the scenario that the event happens in. The developers however may be able to see if there is a difference in the code for the auto-save save, and save when done manually.
    In the mean time, you may be able to find a ‘work around’ for this, to avoid it happening, perhaps by timing the auto-save interval, and then do a manual save before the auto-save gets to activate.
    I don’t know the code, but if it has been designed for future flexibility (which is very likely), then there may already be some setting that controls this, but has not been made available in the present user interface. If there is, then it would probably involve doing something like, use the server file manager (or ftp program), and find some php file, look for something like “autosave=true” and change it to “autosave=false”, or “autosave-interval=300″(secs) and change it to “autosave-interval=0” (never).
    It might be imagined that you too would like to have christosharrison’s option to disable auto-save. After all, this is a beta test, and until things are known to work with high reliability, then it is helpful to be able to turn-off any function which is not of critical need, in the event that it causes problems under any scenario for any user. That way they can continue testing, without risk of further adverse results – possibly finding more problems, all of which can be reported earlier, and so speed up the development cycle.

    And of course, many thanks to all the support crew who are handling these reports, and aiding the rapid development.

    I hope this is of some assistance to at least one of you.

    This thing is so annoying. It’s autosaving much too often, and I have to sit there and wait for it to complete before I do anything, because for some reason, the changes aren’t being kept.

    Tags especially are a problem. When I put in a tag and press the comma, it disappears, then after a few seconds, it reappears.

    With autosave now, sometimes it will save entering tags, and I have to keep putting the tags in over and over.

    Another example? When autosave happens as you’re publishing and you have to sit there and wait for both to complete? I’ll publish, and then have to sit through an autosave.

    And if I try to navigate away, I’ll get that prompt asking me if I’m sure. And so that I don’t fill up my database with auto draft entries, I have to update then navigate away.

    This is a problem.

    Please give us the option to either disable this, or at least decrease how often it autosaves. I understand what you’re saying about server connection, but there has got to be another way for that to happen in the background.

    As it is now, it adds much more time than is necessary to post a blog post.

    • This reply was modified 2 months, 2 weeks ago by  techdex.
Viewing 8 replies - 1 through 8 (of 8 total)
  • You must be logged in to reply to this topic.