__group__ ticket summary owner _component _version priority severity milestone type _status workflow _created modified _description _reporter Tickets Awaiting Review 27244 'Restore This Autosave' immediately updates a published post Revisions normal normal Awaiting Review defect (bug) new 2014-02-28T23:43:29Z 2024-02-25T19:29:55Z "The ""Restore This Autosave"" button on the revisions screen immediately replaces the post with the autosave without making it clear that that is the case. Steps to reproduce: 1. Publish a post. 2. Edit the content of the post and trigger an autosave (either by waiting two minutes or by clicking the 'Preview Changes' button). 3. Navigate away from the post editing screen. 4. Return to the post editing screen and note the message stating ""There is an autosave of this post that is more recent than the version below"". Click ""View the autosave"". 5. On the revisions screen, click ""Restore This Autosave"". 6. Note that the autosave has been published rather than simply being restored to the editing screen." johnbillion Tickets Awaiting Review 29920 Autosave breaks if post revision fields contains a value that isn't a string Revisions normal normal Awaiting Review defect (bug) new has-patch 2014-10-10T14:11:32Z 2019-06-04T18:12:47Z "This isn't exactly a bug... Its possible to filter '_wp_post_revision_fields' to add more fields. I am using this to track revisions for some meta fields. However the value of this must be an string otherwise you get notices when trying to create an autosave - as this calls `normalize_whitespace` on an array. It would be nice if this didn't completely break things. I've added a patch that only calls normalize whitespace if both values are strings - otherwise just do a simple comparison. If you think i'm doing_it_wrong - feel free to tell me so! I guess this is related to #20564 and any other meta revision fields." mattheu Tickets Awaiting Review 49291 Code issues with set_time_limit Revisions 5.3.2 normal normal Awaiting Review defect (bug) new 2020-01-25T23:24:12Z 2020-01-27T12:43:01Z "file: wp-admin\includes\ajax-actions.php function: `wp_ajax_get_revision_diffs` line: 3425 Issue: no time limit set Suggestion: set value to 120 file: wp-includes\class-pop3.php function: `__construct` line: 63 Issue: timeout value is not tested and can be set to 9999999 or a negitive value that acts the same as 0 Suggestion: Force a range for the value (1 to 120) " madpeter Tickets Awaiting Review 53607 Loading or saving a post with enough (large) revisions exhausts available memory Revisions 5.7.2 normal normal Awaiting Review defect (bug) new 2021-07-06T14:22:21Z 2021-07-06T14:22:21Z "This is a follow-up to #34560. **What steps should be taken to consistently reproduce the problem?** - create a post with enough (large) revisions (see ""Steps to reproduce"" from #34560). - Reduce `WP_MAX_MEMORY_LIMIT` so that it is enough to load one revision but not enough to load tens / hundreds of revisions (e.g. 128M) - save post -> `Updating failed. The response is not a valid JSON response.` - edit post -> `**Fatal error**: Allowed memory size of 134217728 bytes exhausted` **Does the problem occur even when you deactivate all plugins and use the default theme?** - yes **Likely cause** It seems full post revisions (including post content) are still being loaded when editing a post. This is likely the cause of high memory consumption. To look into this: - on a standard WordPress installation, activate [https://wordpress.org/plugins/debug-bar/] with {{{#!php }}} - edit a post with revisions enabled - check the ""Queries"" tab of the debug bar (might need to turn off Gutenberg full screen mode to see it) and look for the query that loads the exhaustive list of full revisions (`wp_posts.*`): {{{ SELECT wp_posts.* FROM wp_posts WHERE 1=1 AND wp_posts.post_parent = [[THE CURRENT POST ID]] AND wp_posts.post_type = 'revision' AND ((wp_posts.post_status = 'inherit')) ORDER BY wp_posts.post_date DESC, wp_posts.ID DESC }}} " mlbrgl Tickets Awaiting Review 45366 Optimize wp_get_post_revisions() call in wp_list_post_revisions() Revisions 4.9.8 normal normal Awaiting Review defect (bug) new has-patch 2018-11-16T18:40:35Z 2018-11-17T20:15:51Z Currently, `wp_list_post_revisions()` calls `wp_get_post_revisions()` with the current post's ID as the only argument. This fetches full post objects for each revision. When the current post is very large and has an extensive revision history, this can cause out-of-memory issues (this has been observed when loading a post with ~43,000 words and 158 revisions). While limiting the number of revisions can address this issue, as far as I can tell there is no reason to load full post objects for all revisions, as all of the subsequently called functions in `wp_list_post_revisions()` only require a revision ID. Calling `wp_get_post_revisions( $post->ID, array( 'fields' => 'ids' ) )` significantly improves the performance of this function under such circumstances. greatislander Tickets Awaiting Review 44684 Page/Post revisions don't seem to load into preview Revisions 4.9.7 normal normal Awaiting Review defect (bug) new has-patch 2018-07-31T14:27:24Z 2018-08-01T19:24:56Z "Two different websites had this problem, but it now seems only the one I look after has it. Video attached. It seems that whenever you use the slider on the revisions page of a page/post, it fails to load. Instead it spits out an error in relation to ""admin-ajax.php"" file. This is with initial install, default theme, no plugins. Chrome / Firefox / Safari." ckhatton Tickets Awaiting Review 43189 Restoring page revision doesn't restore page template previously used Revisions 4.9.2 normal normal Awaiting Review defect (bug) new 2018-01-31T13:23:15Z 2018-01-31T15:09:27Z "I noticed this when one of the editors made a change in a page and also changed page template. We reverted the change by restoring a previous revision, but this didn't restore the previous page template. " bugnumber9 Tickets Awaiting Review 44540 Revision restoring redirect issue when using custom wp_query inside shortcodes Revisions 4.9.7 normal normal Awaiting Review defect (bug) assigned 2018-07-07T10:43:11Z 2019-03-11T20:44:02Z "Using a custom WP_Query inside page content shortcodes leads to weird ""revisions restoring"" behavior which is redirecting to improper page id. However the page content is restored correctly. Have found this lines 55, 56 in revision.php {{{ wp_restore_post_revision( $revision->ID ); $redirect = add_query_arg( array( 'message' => 5, 'revision' => $revision->ID ), get_edit_post_link( $post->ID, 'url' ) ) }}} While wp_restore_post_revision( $revision->ID ) returns a correct post_id, the redirect is made to get_edit_post_link( $post->ID, 'url' ) and $post->ID may be broken by custom wp_query loop. Why not using wp_restore_post_revision( $revision->ID ) returned result to perform a correct redirect? " vendetta90 Tickets Awaiting Review 44929 Revisions: wp_get_revision_ui_diff only displays existing meta fields of the current post Revisions normal normal Awaiting Review defect (bug) new 2018-09-11T08:38:42Z 2019-01-16T23:01:18Z "For reproducing the issue: 1. Turn on revisions 2. Create a post 3. Save 4. Create a custom field with some value 5. Save 6. Delete the custom field 7. Save 8. Go to the revision comparison 9. The field added and deleted won't display in the comparision After doing some debug I found out that the the foreach loop in the function wp_get_revision_ui_diff in wp-admin\includes\revision.php uses _wp_post_revision_fields( $post ) which only takes into consideration of the custom fields of the actual post. Solution: Change: {{{ foreach ( _wp_post_revision_fields( $post ) as $field => $name ) { }}} To: {{{ $fields_from = array(); $fields_to = array(); if ( $compare_from != null ) $fields_from = _wp_post_revision_fields( $compare_from ); if ( $compare_to != null ) $fields_to = _wp_post_revision_fields( $compare_to ); $fields = array_merge( $fields_from, $fields_to, _wp_post_revision_fields( $post ) ); foreach ( $fields as $field => $name ) { }}} " luisarn Tickets Awaiting Review 53417 The revisions endpoints provide an incorrect JSON schema Revisions 4.7 normal normal Awaiting Review defect (bug) new 2021-06-15T23:20:51Z 2021-06-15T23:29:55Z "The schema provided by the REST API endpoints for revisions at `wp/v2/posts/{id}/revisions` and `wp/v2/pages/{id}/revisions` is incorrect. The schema states that `content.protected` and `excerpt.protected` properties exist for each revision, but these properties do not exist. * [https://github.com/WordPress/wordpress-develop/blob/afee26086fea307c2a5c31c0e2018cb6acd598f7/src/wp-includes/rest-api/endpoints/class-wp-rest-revisions-controller.php#L736 The schema is constructed here] from the parent controller for posts, which does include this property * [https://github.com/WordPress/wordpress-develop/blob/afee26086fea307c2a5c31c0e2018cb6acd598f7/src/wp-includes/rest-api/endpoints/class-wp-rest-revisions-controller.php#L600-L604 When the content data is prepared here] the `protected` property is not included * [https://github.com/WordPress/wordpress-develop/blob/afee26086fea307c2a5c31c0e2018cb6acd598f7/src/wp-includes/rest-api/endpoints/class-wp-rest-revisions-controller.php#L608-L611 When the excerpt data is prepared here] the `protected` property is not included Two options: 1. Remove the `content.protected` and `excerpt.protected` properties from the schema 2. Add the `content.protected` and `excerpt.protected` properties to the response Here is the `content` property from the schema. Note the `protected.context` property states that the property exists for all three contexts. {{{ ""content"": { ""description"": ""The content for the post."", ""type"": ""object"", ""context"": [ ""view"", ""edit"" ], ""properties"": { ""raw"": { ""description"": ""Content for the post, as it exists in the database."", ""type"": ""string"", ""context"": [ ""edit"" ] }, ""rendered"": { ""description"": ""HTML content for the post, transformed for display."", ""type"": ""string"", ""context"": [ ""view"", ""edit"" ], ""readonly"": true }, ""block_version"": { ""description"": ""Version of the content block format used by the post."", ""type"": ""integer"", ""context"": [ ""edit"" ], ""readonly"": true }, ""protected"": { ""description"": ""Whether the content is protected with a password."", ""type"": ""boolean"", ""context"": [ ""view"", ""edit"", ""embed"" ], ""readonly"": true } } }, }}}" johnbillion Tickets Awaiting Review 48973 wp_text_diff() out of memory with 10GB memory limit on certain revisions Revisions 5.3.1 normal normal Awaiting Review defect (bug) new 2019-12-14T16:33:35Z 2019-12-16T20:59:38Z "Hi, I have identified a bug with wp_text_diff on a blank WP install on PHP 7.2.8 and 7.3.12 The bug causes the system to run out of memory no matter how much is available. I found it while trying to edit some revisions. The texts are large (50KB), maybe it has something to do with it. To replicate the bug you need to use this code. I will provide the files. {{{#!php ID); }}} I would like to propose that that line be changed into: {{{ $preview = !empty($_GET['preview_id'])?get_post($_GET['preview_id']):wp_get_post_autosave($post->ID); }}} The nonce has already been verified in `_show_post_preview()`, so there should be no security implications of this change. With this change, the Revisions meta box (Edit Post screen) could display a ""preview"" icon/link that includes the appropriate nonce and does the same thing as the main ""Preview"" button." coolmann Tickets Awaiting Review 38368 Add front-end revision browsing Revisions normal normal Awaiting Review enhancement new 2016-10-19T16:17:04Z 2018-03-08T20:14:27Z "This patch will add a live-updating revision browser to single post view when the current user can edit posts. This feature requires the post and post revision routes of the WordPress REST API, as well as the JavaScript client for the REST API. Here is demo of this patch: [[Image(https://github.com/Shelob9/revisions-browser/blob/master/CvIKaDdWcAAtRSa.gif?raw=true)]] Currently this is a functional prototype, as a plugin -- https://github.com/Shelob9/revisions-browser -- prepared by myself with guidance from @adamsilverstein and contributions from @mrahmadawais + @websupporter + @kadamwhite + @circlecube " Shelob9 Tickets Awaiting Review 47831 Compare any two revisions: Improve the distinction of From/To columns Revisions normal normal Awaiting Review enhancement new 2019-08-04T12:35:04Z 2019-11-12T23:55:04Z "This is a continuation from ticket #43532. We have a {{{From/To}}} when the ""Compare any two revisions"" is checked, but it might not be obvious what column is {{{From}}} and what column is {{{To}}}. Here are relevant comments from the #43532 ticket: @adamsilverstein suggests using e.g. ""added"" and ""removed"" (see here https://core.trac.wordpress.org/ticket/43532#comment:5 ) @kjellr mentioned that this was discussed in design chat https://core.trac.wordpress.org/ticket/43532#comment:19 >The Design team discussed this briefly in our triage today: >https://wordpress.slack.com/archives/C02S78ZAL/p1564417984166900 >(A WordPress.org slack account is required to view that link) >Both of these updates seem like solid improvements, and the screenshots look good. We're >going to remove ux-feedback for now. >Thanks, all! I'm adding the screenshots here below:" birgire Tickets Awaiting Review 48574 Create better post diff screens Revisions 5.3 normal normal Awaiting Review enhancement new 2019-11-12T19:45:19Z 2019-11-12T23:54:46Z "Post diffs showing the difference between post revisions have always been in raw form, showing differences in post HTML and not ''visual'' differences. With the addition of the Gutenberg editor to WordPress, there is now even more HTML shown due to the inclusion of block settings as comments. Additionally, Gutenberg blocks such as figures or lists create one-line HTML strings so small changes to list items result in one huge line change on the diff screen. It seems like now is the time to consider improving the post diff screen, and changing the way Gutenberg blocks generate their HTML to allow for cleaner diffs. See the attached image for an example of a block that could have been generated across multiple lines such that the addition of a link didn't generate 12 lines of diff. I suppose this feature request is twofold: - Improve the diff page UI to show visual diffs (but keep the current ""raw"" mode as an option). - Make sure Gutenberg block HTML is cleanly formatted across multiple lines to improve line-based diffs used on the post diff screen." seanleavey Tickets Awaiting Review 57395 Improve wp_die message when previewing post revision with expired nonce and unauthenticated requests Revisions 6.1.1 normal normal Awaiting Review enhancement new has-patch 2022-12-29T11:53:51Z 2022-12-29T11:53:51Z "For example, when viewing a revision with an expired nonce, http://localhost/sample-page/?preview_id=2&preview_nonce=07cb875d46&preview=true, a message ""Sorry, you are not allowed to preview drafts"". This works okay. However, the same message with the same status code (403) is being sent when viewing as an unauthenticated user (logged out). Would it be a good enhancement if we revised the status code and message a bit for a logged-out user? Thanks" dunhakdis Tickets Awaiting Review 48953 Improved revision control related to posts and the numerous auxiliary benefits Revisions 5.4 normal major Awaiting Review enhancement new 2019-12-12T19:27:54Z 2019-12-18T15:30:24Z "Imagine for a moment, the Gutenberg full-site editing capability is in full swing: - How does a user restore defaults? - How does a user easily undo actions? - How does a user easily go back to a previous theme? - If the user deletes a theme, how can all the associated custom post versions for that theme be deleted as well? That (and more) could be easily achieved if posts revisions worked in a different way. In the Gutenberg full-site editor example above, each theme could create a ""branch"" of revisions. There would then be major and minor versions. I propose that the default should be to keep all major versions (unless the user manually deletes them of course), as well as all minor versions since the last major version up to the current version. This would allow for the user to ""back space"" in the full site editor, but in a way that is actually meaningful. It has been suggested that a user could simply set the revisions constant. However, particularly in an environment that encourages ""tinkering"" like the Gutenberg full site editor would be, it is entirely possible that a user could create a thousand revisions in a very short period of time. Since there is no way to know which revision is which / search revisions, allowing users to ""backspace"" isn't meaningful. Having ""branches"" would also allow plugin authors to create simple mechanisms to do A/B split testing on appearance (not content, that should still be possible). Moreover, this has a huge implication on the size of the mySQL database, particularly in shared hosting environments and particularly when site content is exported and imported using the core Tools. While it is not feasible to keep 35 trivial changes to the background colour, every semi-colon change to a Terms of Service may very well be crucial. The core infrastructure should allow (whether inside core or via plugin) for different treatment of different post types in regards to revisions. This ticket is related to https://core.trac.wordpress.org/ticket/21666, but is not a duplicate." carike Tickets Awaiting Review 48315 Scheduling already published posts or pages causes 404 error on page Revisions normal normal Awaiting Review enhancement new 2019-10-15T20:44:41Z 2023-10-12T14:21:33Z "Scenario: If you have a live published page and need to make some changes to it but those changes shouldn't be visible until a certain time. **Steps** 1. Edit a published post 2. Change the publish date to future date and click update Result: The post is now unpublished! (404 error) Expected: New changes I made to update/appear on the scheduled date without taking down the page with a 404 error in the meantime. Solution: Draft a revision of a published post without un-publishing it? There is discussion about it here from a while ago, but none of the solutions or plugins are good: https://wordpress.stackexchange.com/questions/3986/is-there-any-way-to-draft-a-revision-of-a-published-page-or-post-what-workaroun https://redearthdesign.com/help-center/update-live-wordpress-page-post/ This seems like a common workflow?" wpfed Tickets Awaiting Review 42712 Enhance wp revisions to keep with expiration date for the revisions Revisions normal normal Awaiting Review feature request new 2017-11-27T13:16:26Z 2017-11-28T00:39:31Z "https://codex.wordpress.org/Revisions Now, the options of the revisions are: true (default), -1: store every revision false, 0: do not store any revisions (except the one autosave per post) (int) > 0: store that many revisions (+1 autosave) per post. Old revisions are automatically deleted. What about to have expiration by time also, not just with number. In that way, in big multisite installations, old revisions could desappear after X months. Decreasing the size of the database. Normally, if a post have not modifications after 1 year, is because not longer are necesary. Anyway, it would be a choice of the superadministrator of the installation. thanks" colomet Tickets Awaiting Review 57641 Need functionality to preview revisions for the post such as preview Revisions normal normal Awaiting Review feature request new 2023-02-06T10:19:46Z 2023-11-20T18:01:09Z "Can we add some feature requests to WordPress core that is to preview the different revisions for the posts exactly as the preview while creating the new post? This would help editors to review the revision full of content instead just checking normally content in revisions tab. With new Gutenberg editor, revisions are hard to check because blocks are not parsed while checking the revisions. We can have a preview button over the revisions page for which we are checking the revisions and can be previewed as whole content with all parsed blocks. This can help editor to review perfectly and restore the revision if needed. Current Revisions page have this kind of markup, [[Image(https://user-images.githubusercontent.com/58802366/216945642-5b5324f7-07cb-47a5-811c-ff53808de3d0.png)]] Need this type of markup with a preview button, so on click of that button, user can view the revision with that content. [[Image(https://user-images.githubusercontent.com/58802366/216946179-cb9c2a12-e4b5-4cbc-90f1-b8d244ac230c.png)]] " hbhalodia Tickets Awaiting Review 42086 Option to view condensed diffs for post revisions Revisions normal normal Awaiting Review feature request new 2017-10-04T16:08:37Z 2020-09-01T16:16:59Z "Viewing a revision of a post which has a lot of content in it can result in a very long screen. It would be great if there was a toggle somewhere on the revisions browser so a condensed diff view was shown. The condensed view would more closely resemble a traditional VCS diff view, which highlights only the changed lines and a handful of lines above and below each change. I haven't checked to see if the `Text_Diff` library that core uses supports such diff generation, I doubt it does but I'd like to be wrong." johnbillion Tickets Awaiting Review 59419 "Revisions page: how to support varying ""Go to editor"" link templates" Revisions normal normal Awaiting Review feature request new 2023-09-21T03:26:10Z 2023-11-21T01:46:00Z "For various post types, the Block Editor redirects to admin/revision.php. The page admin/revision.php has a couple of ""Go to editor"" links, which open the the current post in the editor. admin/revision.php builds the link by calling `get_edit_post_link()`, which uses the link template from `post_object->_edit_link`. For most post types, including pages and posts, the `_edit_link` template looks something like this: post.php?post=%d. get_edit_post_link() replaces the placeholder %d with the correct post id to build the edit post link. Each page under Site Editor sidebar contains a link to admin/revision.php for page revisions. However since the ""Go to editor"" links are constructed using `page_object->_edit_link`, they will always link to post editor. I would expect the links to return me to the editor from which I last came. The upshot is that we want the `_edit_link` template to vary depending on the origin of the referring URL. For pages, that means if we're coming from the Site Editor, the return template should be something similar to what the wp_template post object uses, which is site-editor.php?postType=%s&postId=%d&canvas=edit. The question is ""what would be the best way to do this?"" Challenges: 1. admin/revision.php does not know where the revision is coming from, that is Post Editor vs Site Editor, but we could use some sort of `$_GET` query param on `revisions.php` to solve that. E.g., let's call it editor: `revision.php?revision=150&editor=site`. That is very specific and might be too narrow. 2. If 1, what then? Whether we grab the query param on the revision page and pass it to `get_edit_post_link` (thereby changing the function signature), or modify `get_edit_post_link` to do the lot internally, we'd still have to build the link accordingly to some pattern. 3. If 2, where would we store that pattern? `_edit_link` is taken. Maybe a new property on the post object? `_edit_site_link` or something. It can be done I think without great fuss using the `get_edit_post_link` filter. With it we can return whatever we want. We would just have to come up with migration approach for Core and I'm not sure what the best option would be. Thank you for considering this issue! For discussion and context see: https://github.com/WordPress/gutenberg/issues/51343#issuecomment-1724580879" ramonopoly Candidates for Closure 47899 Drafts not saving revisions Revisions normal normal Awaiting Review defect (bug) new reporter-feedback 2019-08-19T07:49:54Z 2019-08-21T08:33:18Z "Revisions are supposed to work on drafts but is not working. Just lost an original post this morning because of this and no way to get it back. Working on posts but not drafts. " mitchellk Candidates for Closure 60099 Fix revisions system Revisions 6.4.2 normal minor Awaiting Review defect (bug) new reporter-feedback 2023-12-18T20:22:50Z 2024-03-11T12:49:30Z "After upgrading to 6.4, the added section of the last revision of every post is empty, instead of showing the latest changes. [[Image(revisions-issue.jpg)]]" aulivur Candidates for Closure 44786 Autosave: Conditionally allow revisions to be saved Revisions normal normal Awaiting Review enhancement new reporter-feedback 2018-08-13T22:45:46Z 2019-01-16T06:50:09Z "As is, when the `DOING_AUTOSAVE` constant is truthy, calling `wp_save_post_revision` immediately exits. One of the first things that endpoints responsible for `autosave`s are doing is set this constant -- making it impossible to save a revision using the Revisions API during the same request context. See: - [https://github.com/WordPress/gutenberg/blob/751a2fcdd7952fd4359984af292cc669cee065c8/lib/class-wp-rest-autosaves-controller.php#L169 Gutenberg] - [https://github.com/Automattic/jetpack/blob/585238715b2d3ff0a10615562001a729f12ed477/json-endpoints/class.wpcom-json-api-update-post-v1-2-endpoint.php#L165 Jetpack] Endpoints (& other plugins) would benefit from a filter allowing revisions to be saved. A particular use case is to occasionally save revisions for drafts during an `autosave` call (so there is less chance of irrecoverable data loss when the autosave is overwritten)." jblz Tickets with Patches 58844 Revisions: Compare Revisions layout issues on mobile Revisions 3.6 normal normal Future Release defect (bug) new has-patch 2023-07-18T20:45:48Z 2023-11-30T22:50:02Z "This is a follow-up to #33830. ""Restore This Revision"" button in wp-admin revision page can become hidden behind the diff panel in mobile view, particularly if the post author has a longer name. The problem occurs when the author info (Name & Timestamp) stacks below the Avatar. " plari Unpatched Bugs 30679 "Clicking ""Restore this Revision"" publishes immediately" Revisions normal normal defect (bug) new 2014-12-11T20:58:35Z 2019-06-04T21:13:03Z "This is the same as #27244, but for non-autosaved posts. The ""Restore This Revision"" button on the revisions screen immediately replaces the post with the autosave without making it clear that that is the case. Desired behaviour: Clicking Restore This Revision puts this revision into the editor, saving it as draft. Example: 1. Create a post with three revisions, and publish it Revision A Revision B Revision C <-- live and published 2. On the post edit screen, click on revision B. 3. On the revisions screen, click Restore This Revision. Revision A Revision B Revision C <-- live and published Revision B' <-- in the editor, saved as a draft " paulschreiber Tickets with Patches 23314 Allow published posts to be revised without being updated immediately Revisions normal normal Future Release enhancement new has-patch 2013-01-29T19:39:01Z 2020-01-10T21:02:19Z Two things. Let's allow contributors to submit changes for review to their published posts. Let's also allow users to make changes to their posts and pages and save those changes, without updating the published post or page. kovshenin Tickets Awaiting Review 41029 The changed author is not making the coming revisons adamsilverstein Revisions 4.8 normal normal Awaiting Review defect (bug) assigned 2017-06-13T14:02:03Z 2021-04-30T18:28:07Z "Hi In WordPress 4.8 the changed author won't be changed in the new revisions (and autosave)." elisa-demonki Tickets Awaiting Review 47518 Add an explanatory message to the Revisions screen for locked posts adamsilverstein Revisions normal normal Awaiting Review enhancement assigned 2019-06-10T15:30:43Z 2021-04-30T17:44:27Z "It's possible for a user to navigate to the revisions screen for a post that's locked due to another user editing it, and not be able to restore any revisions due to the fact that the post is locked. In this situation no message is shown on the Revisions screen that explains why the `Restore This Revision` button is disabled. Under normal operating procedure it's not easy to get to the Revisions screen for a locked post, but it is possible. A workflow related plugin, audit trail, or revisions list can make it possible to navigate directly to a revision without going via the otherwise locked editing screen. 1. User A navigates to the revisions screen for a non-locked post. 2. User B visits the editing screen for the post. 3. User A clicks `Return to editor` on the revisions screen. 4. User A chooses not to take over, and clicks `Go back`. User A is now shown the revisions screen for a locked post and the `Restore This Revision` button is disabled for all revisions but with no explanatory information." johnbillion Candidates for Closure 59827 wp_save_post_revision() assumes ALL post meta is text! Fatal error in PHP 8.2. adamsilverstein Revisions 6.3.2 normal normal Awaiting Review defect (bug) assigned reporter-feedback 2023-11-07T17:31:11Z 2024-02-05T19:14:55Z "The wp_save_post_revision() function assumes that ALL post meta is text: https://github.com/WordPress/wordpress-develop/blob/6.3/src/wp-includes/revision.php#L164 When using register_meta() with 'revisions_enabled' => true to register post meta that is an array, it causes a fatal error in PHP 8.2: {{{ PHP Fatal error: Uncaught TypeError: trim(): Argument #1 ($string) must be of type string, array given in /.../wp-includes/formatting.php:5486 }}} Since registering post meta is announced for WP 6.4 (see https://make.wordpress.org/core/2023/10/24/framework-for-storing-revisions-of-post-meta-in-6-4/), it's a pretty serious problem. I've tested the issue on WP 6.3.2 and WP 6.4 (although the footer says 6.5-alpha-57075). js." jsmoriss Tickets Needing Feedback 24958 Large number of revisions cause memory exhaustion adamsilverstein Revisions 3.6 low normal Future Release defect (bug) assigned dev-feedback 2013-08-05T17:17:59Z 2021-05-06T11:20:18Z "This may be a edge case, but if you have a a large number of revisions, a number of things can break. Right now the post in question has about 1,055 revisions. Noticeably, two things are happening: Calling wp_update_post from a plugin fails with the following error: {{{PHP Fatal error: Allowed memory size of 41943040 bytes exhausted (tried to allocate 16384 bytes) in /path/wp-includes/wp-db.php on line 1228}}} Using the new revisions API to view earlier revisions returns ""Sorry, something went wrong. The requested comparison could not be loaded."" and the error log contains the same memory exhaustion error. I can seem to update from the post edit screen. This is happening with the latest stable of 3.6 and only began happening after an update, so I suspect it's something in the new revision core/api. I haven't had a huge amount of time to investigate but my guess is it's trying to load too much revision data at one time? Maybe it should only try to load X amount of revisions at once?" jshreve Unpatched Bugs 30854 `wp_insert_post` doesn't save revision for new published post adamsilverstein Revisions normal normal Future Release defect (bug) assigned 2014-12-28T16:41:25Z 2022-04-19T05:55:17Z "Calling `wp_insert_post` with `post_status` of `publish` or any other status on a new post doesn't save a new revision. The reason for this is the `$update` check at the beginning: https://core.trac.wordpress.org/browser/tags/4.1/src/wp-includes/post.php#L3085 checks whether or not the args include an ID, indicating that we're updating a post. Further down, that update check is what calls `post_updated` https://core.trac.wordpress.org/browser/tags/4.1/src/wp-includes/post.php#L3473 which `wp_save_post_revision` is hooked to. Therefore, if we call `wp_insert_post` in a plugin to insert a post with a`post_status` of `publish`, WordPress doesn't save a post revision. Post revisions are supposed to be up-to-date with the latest post data, but we don't get a revision if we insert a post in this manner. I think the reason we ended up with this is to avoid saving a revision of the auto-draft that is created when opening up post-new.php, but that isn't necessary now, as `wp_save_post_revision` checks whether the `post_status` is an auto-draft. I think the easiest solution is to move the `wp_save_post_revision` to the `save_post` hook, but I'm not sure if there are other places in the codebase this would cause issues." JamesDiGioia Unpatched Enhancements 40577 Introduce a capability for viewing the revisions of a post adamsilverstein Revisions 2.6 normal normal Future Release enhancement assigned needs-unit-tests 2017-04-26T11:36:57Z 2023-03-02T06:35:53Z "In order to view the revisions of a post, a user needs the ability to edit the post. This makes sense because it may be undesirable for users to be able to view older revisions of a post which they cannot edit. However it may be desirable to allow certain users to view the revisions of a post which they cannot edit, for example for auditing purposes, or to allow contributors to browse the revisions of their own published post." johnbillion Tickets with Patches 27938 Restore This Autosave does not work for custom post types that don't support 'revisions' chriscct7 Revisions 3.8 normal normal Future Release defect (bug) reviewing has-patch 2014-04-20T13:42:49Z 2019-06-04T18:13:25Z "If you have a custom post type that doesn't support revisions but you manage to create an autosave which is more recent than the current version then you get offered the opportunity to restore it, but the restore action doesn't complete. You end up in an annoying(*) loop. Expected result: CPT restored to the autosave. Actual result: Redirected to edit.php for the CPT Steps to create the problem. 1. Ensure your CPT doesn't support 'revisions' 2. Create a new post and publish it 3. Create an update but don't publish it... just let it autosave 4. When you see the ""Draft saved"" message just quit 5. Edit the post again. 6. You will be shown the message: There is an autosave of this post that is more recent than the version below. 7. Click on the View the autosave link 8. Click on Restore This Autosave button 9. End up at the list of posts for this CPT. 10. go to step 5. Introduced by: #23497, change [23769] Note: Fixing this bug by simply reinstating the test on !wp_is_post_autosave( $revision ) leads to #27244 being applicable. In my opinion, this follow on problem is preferable to the current behaviour. Workaround for developers: Define 'revisions' support for your CPTs... especially those which support 'editor'. (*) What's annoying is that you get to see the autosaved version but it's not just a simple case of copying and pasting the text since the two versions get merged. " bobbingwide Unpatched Bugs 52303 Accessibility issues in revisions screen joedolson Revisions 3.6.1 normal normal Future Release defect (bug) assigned 2021-01-15T00:04:34Z 2021-01-27T21:59:41Z "In the course of assessing a functional problem with `wp_text_diff`, a number of accessibility concerns were unearthed regarding the revisions screen. Once the output of `wp_text_diff` is settled, the other concerns noted in #25473 should be addressed here. " joedolson