__group__,ticket,summary,owner,_component,_version,priority,severity,milestone,type,_status,workflow,_created,modified,_description,_reporter Slated for Next Release,41172,Allow autosaving to be disabled on a per post type basis,,Autosave,,normal,normal,6.6,enhancement,new,has-patch,2017-06-26T08:24:58Z,2024-02-27T22:31:57Z,"Autosaving should be a post type feature, so that individual post types can opt out. Disabling this feature should remove both the server-side and the client-side saving.",Frank Klein Unpatched Enhancements,24865,Allow plugins to hook into autosave and include field data from the autosave with the package.,,Autosave,,normal,normal,,enhancement,new,,2013-07-28T22:55:43Z,2019-06-04T19:24:10Z,"== Why? == Autosaves currently only save ""blessed"" data (post_title and post_description?). Plugin authors may want to add their own data in the autosave package so if they hook into `save_post` they can handle/save that data as needed. == How this works == Metaboxes are generated with an id already on the page. So what we do is add an extra parameter to the `add_meta_box()` function (`do_autosave` bool) so that when a plugin uses add_meta_box() they can set that flag. We set a javascript object that contains the ids of the metaboxes that have had that flag set and then `wp.autosave.getPostData` in `autosave.js` has been modified to loop through the metaboxes matching those ids and return the fields in those metaboxes as an object attached to the data param. Added a new jquery plugin (serializefullarray) as it will handle nested pseudo arrays set as the ""name"" values in inputs (i.e. somedata[one][two]) and create proper objects from them. ",nerrad Tickets Awaiting Review,47743,autosave locks db and is slow,,Autosave,,normal,normal,Awaiting Review,defect (bug),new,,2019-07-20T18:00:47Z,2019-07-20T18:32:35Z,"If I have 2 tabs open editing pages, they have apparently got synchronised autosaves. These seem to compete for the db connection resulting in delays and occasional failures to autosave. As a suggested way to fix this, you should consider only autosave queuing in the server side. Another annoyance in autosave is that it prevents a normal save. If autosave is in progress I should be able to queue up a proper save to happen immediately after the autosave. ",lamaan Tickets with Patches,29386,Autosave message should disappear when the next autosave happens,,Autosave,,normal,normal,,defect (bug),new,has-patch,2014-08-26T21:17:58Z,2019-06-04T19:26:37Z,"An autosave overwrites the previous autosave, so the message is no longer relevant. It will just display the same content as the current editor.",iseulde Candidates for Closure,42696,Autosave Notification not dismissible,,Autosave,4.2,normal,major,Awaiting Review,defect (bug),new,dev-feedback,2017-11-25T10:11:17Z,2023-05-15T10:09:44Z,"If I make changes to a Post/Page and then decide I don't want to keep those changes, I'll simpy click away from the edit page. The next time I decide to edit the page, I'm prompted with a notification advising ""There is an autosave of this post that is more recent than the version below. View the autosave"" https://cl.ly/082A3B0u3J1u The only option I'm given is to view the autosaved version. This notificaiton should be dismissible. I shouldn't have to view the autosaved version when I already know that I don't want it. I also shouldn't have to resave the page, just to get rid of the notification. I would like to see a Dismiss icon/link so that we can dismiss the notification for good. When developing a theme or plugin, we're required to make all notifications dismissible. There's no reason why core notifcations shouldn't follow the same rules and also be dismissible.",ahortin Unpatched Bugs,32912,Autosaves are generated every other preview if post is unchanged,,Autosave,4.3,normal,normal,,defect (bug),new,,2015-07-07T22:30:03Z,2019-06-04T19:30:34Z,"I'm trying to work with revisioned post meta and noticed an interesting quirk in core today that I'd categorize as ""unexpected behavior."" While this probably wouldn't come up very often, I think it can cause a bit of a headache when it does. To replicate: 1. Create a new post, give it a title, and publish it. 2. Once the screen reloads, click ""Preview Changes"". Don't make any changes to the post. * In loading the preview, WordPress created an autosave of this post 3. Return to the WordPress Admin and click ""Preview Changes"" again without making any changes. * In loading the preview, WordPress deleted the autosave it created in step 2 Every other preview will add an autosave and every other one will delete it. If at any point you do change the post, the autosave won't get deleted. In the code, what appears to be happening is, `wp_create_post_autosave()` checks to see if an autosave exists. If it does, the code checks to see if the autosave is different from the post, and if so, it deletes the autosave. If an autosave doesn't exist, the function then creates one (using `_wp_put_post_revision()`) -- *without checking to see if the post has changed*. It seems to me that there should be an intermediate function, e.g. `_wp_maybe_put_post_revision()`, which would check to see if the post has changed, and only then call `_wp_put_post_revision()`. This probably isn't a big deal, because it requires someone to attempt to preview (twice) without making changes. However, it's still a bug and it might come up in other ways. Verified in trunk and 4.2.2.",mboynes Tickets with Patches,43760,Create a revision when autosaving if the content has changed significantly,,Autosave,,normal,normal,Future Release,enhancement,new,dev-feedback,2018-04-13T13:08:12Z,2019-09-19T20:52:21Z,"Sometimes a user may edit a post for hours without saving it. We have autosaves to prevent any data loss. However in some cases there may be an user or a server error and the content may not be submitted or the post may be ""empty"". This doesn't happen often, but is usually devastating for the users. They just lost hours of work! To safeguard against these cases, we can create post revisions when the autosave data is significantly different than the existing post.",azaozz Tickets Awaiting Review,44910,function for discriminating during auto saving,,Autosave,,normal,trivial,Awaiting Review,feature request,new,has-patch,2018-09-07T05:33:12Z,2018-09-07T06:01:17Z,"I want a function to distinguish auto saving like **wp_doing_cron** or **wp_doing_ajax**. The following code can be simplified. before {{{ if ( defined( 'DOING_AUTOSAVE' ) && DOING_AUTOSAVE ) { //do something } }}} after {{{ if ( wp_doing_autosave() ) { //do something } }}} ",mt8.biz Unpatched Bugs,36479,Improve autosave in the browser,,Autosave,,normal,normal,,defect (bug),new,,2016-04-11T14:55:10Z,2019-06-04T19:36:24Z,"Several improvements that can make this quite better: - Try to better detect when a restore may be needed. - Make in-browser autosaves a ""higher priority"" than remote/server autosaves. The in-browser content is fresher. If both are available, prefer/emphasis the in-browser data. - Add some subtle, always present UI for restoring a post from in-browser autosave. This should (probably) be only available before the users start typing. - Consider adding the in-browser data to the revisions or display a preview/diff with the current data in some other way. ",azaozz Unpatched Enhancements,22601,Make post content autosave work more generically,,Autosave,,normal,normal,,enhancement,new,,2012-11-27T04:00:31Z,2019-06-04T19:23:41Z,"The JS for autosave/AYS looks for the contents of `#post #content`. While we should fix the other JS issue related to targeting `#content` in #22600, it seems that autosave/AYS should be looking for the textarea (or whatever type of input) with the name of content instead, since having that data in the form will save to the post content. That way, if somebody does choose to use a different ID but the right input name, the autosave benefits will kick in. Discovered while working on #22491.",helen Tickets Needing Feedback,11049,Page Preview does not autosave page template,nacin*,Autosave,2.8.4,normal,normal,,defect (bug),accepted,dev-feedback,2009-10-30T21:19:34Z,2019-06-04T19:21:39Z,"When editing a published page, if you change the page template and then click Preview, the preview does not show the new template choice. ",janeforshort Tickets Awaiting Review,40706,pasting text that has emojis into a new post breaks autosave and save draft,,Autosave,4.7.4,normal,normal,Awaiting Review,defect (bug),new,,2017-05-09T20:30:32Z,2017-05-09T20:35:10Z,"When copying text that includes emoji's into the editor, then clicking save draft, the page refreshes and doesn't save any of the text in the editor. Copying initially from Google Docs with and without emojis. I haven't specifically limited it down to only Google Docs copying; i'm not a writer and i hate emojis so. Good luck on the bug hunt, but it's definitely a thing. ",ryno267 Tickets Awaiting Review,49859,Post autosave called multiple times,,Autosave,5.4,normal,major,Awaiting Review,defect (bug),new,,2020-04-09T12:15:18Z,2020-04-09T12:15:18Z,"Hi everyone. I found an issue, which is mostly not related to wordpress core but the fix should be handled in wp core itself. autosave.js works just great except one point. If there is move than one wysiwyg editor in admin post edit screen (no matter how it is added, in my case it is created ACF plugin, but it can be just a custom meta box field implemented as wysiwyg editor field ), and there is and autosave for current post, then 'tinymce-editor-init.autosave' jquery event triggered on jQuery(document) will call checkPost() js method wysiwyg editors count times. As a result ""The backup of this post in your browser is different from the version below"" notice is rendered the same count times. If there are 6 wysiwyg editors including wp native one (I have 5 custom ones), 'tinymce-editor-init.autosave' is called 6 times, and as a result ""The backup of this post in your browser is different from the version below"" notice is rendered 6 times. This is very easy to reproduce. Please review. Thanks in advance. Rafik I.",Rufus87 Tickets Awaiting Review,59094,postChanged() is not working correctly in Text mode editor,,Autosave,6.3,normal,major,Awaiting Review,defect (bug),new,,2023-08-13T13:40:12Z,2023-08-13T13:40:12Z,"The javascript function `wp.autosave.server.postChanged()` from autosave.js always returns `true` if we change the post content in **Text** mode in the classic editor, even after autosave kicked-in as seen with ""Draft saved at ..."". It is supposed to return `false` after the post has been autosaved. If you switch to **Visual** mode editor, the function immediately returns `false` and after any content change, it switches from `true` to `false` in a few seconds. Easy steps 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 change anything more Tested on a brand new WP 6.3 default install with Twentytwentythree theme. It causes an issue when I try to schedule a new revision with the plugin PublishPress Revisions in Text mode after changing the post content. The button hangs and the revision never gets saved. The workaround is to click on the Visual tab to unstuck the button. The JS code of this plugin is checking postChanged(), if true it triggers an autosave with triggerSave(), waits 250ms and checks again if postChanged() is false. If not, it hangs. Also, this bug causes the editor to always warn you (with a javascript prompt) about unsaved content in Text mode if you try to close the tab or change the URL after having changed the post content, even after it has been autosaved.",skylex69 Tickets Awaiting Review,60314,Revisions: PHP Warning: Undefined array key 0 in .../wp-includes/meta.php on line 642,,Autosave,6.4.2,normal,normal,Awaiting Review,defect (bug),new,has-patch,2024-01-22T06:57:06Z,2024-02-15T07:34:17Z," - Call register_post_meta() with single = true, type = object and revisions_enabled = true. - Save your meta value as an associative array. - Next, call get_post_meta on a post that has a revision. - The following filter will fire: {{{#!php
""Contributing makes me feel like I'm being useful to the planet.""
— Anna Wong, Volunteer Content retrieved from post body:*** END MESSAGE *** As you can see from the error/message, there is reference to some placeholder version of the quote block. But when I look in the template and block libraries, I see no such placeholder text. Neither the core quote block nor the core pullquote block (as seen in the block library) contains a placeholder quote by Anna Wong. I searched the database. The main site (site #1) contains a couple of records in the _sitemeta table with this meta key: _site_transient_wp_remote_block_patterns_... Those records contain the placeholder quote that appears in the error message. The function generating the message gets printed to the file's output source: function() { window._wpLoadBlockEditor = new Promise( function( resolve ) { wp.domReady( function() { resolve( wp.editPost.initializeEditor(... That function seems to be generated by wp-admin/edit-form-blocks.php Since this error is only occurring on local and staging (which use v 5.8) and not on production (5.7.2) I'm reluctant to upgrade production right now. Sorry for the long read... Anyone else experiencing this or know what to do about it? Thanks!",tinamar""Contributing makes me feel like I'm being useful to the planet.""
— Anna Wong, Volunteer