Add a filter to modify the default content of a new post

[Chouby]

Description

I propose to add a new filter to allow 3rd party plugins to modify the content of a new post before it is sent to javascript (as already done by Gutenberg only for the title). For the context, see #7000. This filter is needed to help the plugin Polylang supporting Gutenberg.

Types of changes

New feature (non-breaking change which adds functionality)

[youknowriad]

Hey thanks for the suggestion.

There are already two ways of doing this without introducing a new API.

• wp.data.dispatch( 'core/editor' ).resetBlocks( [ wp.blocks.createBlock( 'core/paragraph', { content: [ 'my content' ] } ) ] )

or attach a template to the CPT https://wordpress.org/gutenberg/handbook/templates/

I'd personally avoid adding new filters/hooks and consolidate on existing possibilities.

If the only known value is an html string. We could something like:

• wp.data.dispatch( 'core/editor' ).resetBlocks( wp.blocks.parse( myHtmlVariable ) )

[danielbachhuber]

I'd personally avoid adding new filters/hooks and consolidate on existing possibilities.

I agree with this. I think we need to figure out how to address #5958 on a whole, not in a one-off manner.

[Chouby]

@youknowriad Thanks for the tip. The last function with the html string seems to do what I need for the post content.

However (I admit that my title and description are not clear enough), we need to do that for almost all the post data (title, excerpt, menu order, comment status, ping status, post date, taxonomies, custom fields). As I understand it, I would need a different function call for each of them. Where can I find a documention to know the functions allowing to manipulate these data?

Allow let me advocate the solution with the php filter and compare the 2 solutions:

1. With the filter: I prepare all the post data in php and pass them to 'window._wpGutenbergDefaultPost' via the proposed filter and let Gutenberg do everything else.
2. Without the filter: I prepare all the post data in php (exactly as above) and pass them to a custom js variable and then write specific js code to overwrite what's has been done by Gutenberg just before.

The second looks more efficient to me, both in term of performance (the data is populated only once) and in term of code written. Please pardon me if I am wrong, I am a total beginner with Gutenberg.

@danielbachhuber I am not sure to understand the relationship with #5958. Maybe I did not fully understood it, but it seems to be a different issue, specific to WPML.

[youknowriad]

you can find the list of all actions and selectors to get/update editor's data here https://github.com/WordPress/gutenberg/tree/master/docs/data

I know we've been used to php for a long time and it seems like a straightforward option but it doesn't seem scalable to me. As we move to JavaScript and SPA like applications, I think we should try to avoid these php filters as much as possible because they force us to tweak or add new endpoints just to get values from filters. At the moment we do "localize" the post using this variable but that's just incidental of how WP Admin works at the moment, we should try to think of the backend and the frontend as separate application and see what's best in that case because that's the most future-proof.

[danielbachhuber]

@danielbachhuber I am not sure to understand the relationship with #5958. Maybe I did not fully understood it, but it seems to be a different issue, specific to WPML.

I see both issues fitting into a broad class of "how should multilingual plugins work with Gutenberg?" Both Polylang and WPML are modifying the Classic Editor experience in a way that we'll need to accommodate for in Gutenberg. However, it's unclear at this point how multilingual plugins should be accommodated for.

[danielbachhuber]

My point being: I'd like to first see the research done and a proposal for how we can address multilingual plugins on a whole. Adding filters in a seemingly hodge-podge manner doesn't seem like a great idea.

[Chouby]

we should try to think of the backend and the frontend as separate application

This is exactly my point. That's why I am trying to solve backend issues on backend, not on frontend as you propose.

I will come back on the context. #7000 has been opened because Gutenberg doesn't read the post data the same way it is done in WordPress. That is what I analyzed in #7000 (comment) against the version 3.0.1. The version 3.1 changed the code but the problem is still the same. We have (non backward compatible) workarounds for everything except for the title. Here are the problematic lines https://github.com/WordPress/gutenberg/blob/v3.1.0/lib/client-assets.php#L1035-L1043.

For some reason, you decided to modify the rest response outside the WordPress API. So even if I filled the rest response with the correct title, it is overwritten with an empty title by Gutenberg. And then the only possibility to fix that is to modify the title on frontend. I can modify everything on backend as I should, except the title, because it is modified by Gutenberg in a non-extensible way.

The goal of my PR was to propose a unified way to modify the post data of a new post (not only the title), using the way you already implemented in Gutenberg for the title. As you already wrote everything, that was the easiest. And I also believe that using this filter would be easier (and more obvious) than using rest_prepare_{$post_type}.

At worst, if you don't want to add this new filter, then I propose that you don't modify the title outside the REST response, but direcly modify the REST response using the filters already available in WordPress. That way I could still modify the title after Gutenberg using the same filters. It won't be as easy but will be feasible.

[Chouby]

Fixed with #10362