[wp-trac] [WordPress Trac] #45250: Backward compatibility: Impossible to prefill a new post in WP 5.0

[WordPress Trac]

#45250: Backward compatibility: Impossible to prefill a new post in WP 5.0
-------------------------------+---------------------
 Reporter:  Chouby             |       Owner:  (none)
     Type:  defect (bug)       |      Status:  new
 Priority:  normal             |   Milestone:  5.0
Component:  Editor             |     Version:  5.0
 Severity:  normal             |  Resolution:
 Keywords:  reporter-feedback  |     Focuses:
-------------------------------+---------------------

Comment (by Chouby):

 @danielbachhuber Thank you for looking in to this. I also made some
 progress in my investigations. The difference of behavior betweeen
 Gutenberg and WP 5.0 is due to the order in which things are done:

 * In Gutenberg, the action `add_meta_boxes` is fired before the editor
 scripts are added because the function
 `gutenberg_editor_scripts_and_styles()` which adds scripts is correctly
 hooked to `admin_enqueue_scripts` and
 https://github.com/WordPress/gutenberg/pull/10660 restored the order
 between the 2 actions. This is, I believe, the behavior that we should
 expect.

 * In WP 5.0, the action `add_meta_boxes` is fired after the editor scripts
 are added because the scripts are added directly in the file `edit-form-
 blocks.php` without enqueuing them in a function hooked to
 `admin_enqueue_scripts`. This is, I believe, not the correct way to add
 scripts.

 Regarding fields not working, even in Gutenberg, such as `menu_order`, I
 had envisaged to use the `rest_prepare_{$post_type}` filter when I tried
 to solve the issue with Gutenberg
 https://github.com/WordPress/gutenberg/pull/7421#issuecomment-399432232
 but at that time, there was a blocking issue with the post title.

 Now, filtering the REST response would work for the fields such as
 `menu_order` as you tested it, but it would not work for the title,
 content and excerpt. That means that Gutenberg/WP 5.0 introduces some
 inconsistent behavior. Some fields need to be filtered in the REST
 response and some other using the global `$post` variable (or the filters
 `default_content`, `default_excerpt` and `default_title` which in fact
 have always and are still just an indirect way to modify only 3 properties
 of the global variable).

 Is there a way to know if the REST request is coming from the blocks
 editor and from anywhere outside?

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