[wp-trac] [WordPress Trac] #62057: Addressing Autosave Memory Issues

[WordPress Trac]

#62057: Addressing Autosave Memory Issues
--------------------------+-----------------------------
 Reporter:  whyisjake     |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Future Release
Component:  Editor        |     Version:
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:
--------------------------+-----------------------------

Comment (by tallulahhh):

 In tests, the editor behaves just the same when not loading the autosaves
 route, it just uses less memory doing so. The "there is a new autosave"
 warning the editor pops when applicable still does so as expected. When
 the autosaves route isn't preloaded, the "newer autosave" message pops up
 when Gutenberg does its equivalent rest_request for it.

 I tinkered with this, and found that limiting the fields output by the
 /autosaves/ routelet seems to have no adverse affect on the "there is a
 newer autosave", so there's definitely no need to load the large fields
 like excerpt and content just to check for presence of newer autosaves.

 Here's the field-limiting filter I was using for testing:
 {{{
 function filter_autosaves_response( $response, $post, $request ) {
     // Check if the request is for the autosaves endpoint
     if ( strpos( $request->get_route(), '/wp/v2/posts/' ) !== false &&
 strpos( $request->get_route(), '/autosaves' ) !== false ) {
         // Limit the fields to id, dates, and parent
         $limited_data = array(
             'id' => $response->data['id'],
             'date' => $response->data['date'],
             'date_gmt' => $response->data['date_gmt'],
             'parent' => $response->data['parent'],
         );
         $response->set_data( $limited_data );
     }
     return $response;
 }
 add_filter( 'rest_prepare_revision', 'filter_autosaves_response', 10, 3 );
 }}}

 Also useful for this, since the /autosaves/ route is private: here's a
 handy "force all rest route to public" filter that I was using to make it
 easier to directly examine the posts/123/autosaves route's response on my
 test rig:

 {{{
 function make_all_routes_public( $endpoints ) {
     foreach ( $endpoints as $route => $handlers ) {
         foreach ( $handlers as $key => $handler ) {
             if ( isset( $endpoints[$route][$key]['permission_callback'] )
 ) {
                 $endpoints[$route][$key]['permission_callback'] =
 '__return_true';
             }
         }
     }
     return $endpoints;
 }
 add_filter( 'rest_endpoints', 'make_all_routes_public' );
 }}}

 Additionally, the revision diff tool used to compare autosaves does its
 work with direct SQL queries, and doesn't touch the /autosaves/ route, so
 none of this affects that.

 The conclusion I get from all this is that the autosaves route (and
 preloading it) is largely used for making POST requests to it (performing
 autosaves during editor use), and the editor's GET requests for it without
 a field specification arg is a waste of resources, loading fields that
 aren't used in a regular editor session.

 So this could maybe be addressed by doing a fields arg on all GET requests
 for the route, something like this for the preload:
 {{{
 sprintf( '%s/autosaves?_fields=id,date,date_gmt,parent&context=edit',
 $rest_path ),
 }}}
 In Gutenberg, I think this would be a case of adjusting what fields are
 requested by `getAutosaves` and `getAutosave` (plural and singular) in
 `packages/core-data/src/resolvers.js`.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/62057#comment:9>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform