Gutenberg: the_editor_content hook seems not to be there

Created on 20 Nov 2018  路  13Comments  路  Source: WordPress/gutenberg

Hi,
imagery gone in Gutenberg editor, still there in Classic. URLs are dynamic via "internal" (not for user) short-codes and it seems "the_editor_content" hook used for them isn't there for Gutenberg.
Something else should be used instead?
Thanks.

Backwards Compatibility REST API Interaction [Type] Documentation

Most helpful comment

@kivig2 I think option B is better, as it's a bit more precise. Option A will apply in many more areas, which could cause unexpected results.

All 13 comments

@kivig2 can you tell me a bit more about your setup? Are you using the Gutenberg plugin with WP 4.9.8 or WordPress 5.0 beta or WordPress.com?

imagery gone in Gutenberg editor, still there in Classic

Do you mean you cannot upload images?

URLs are dynamic via "internal" (not for user) short-codes

Are you talking about the permalink shown above the title or maybe the one in the post settings sidebar (or both)?

it seems "the_editor_content" hook used for them isn't there for Gutenberg

Can you help me with a good set of steps for testing this? (I can help test but am not a developer. I can follow instructions if you walk me through! If no, no worries and I can tag this issue for a technical review which we'll need to wait for.)

Thanks.
WP 4.9.8 with Gutenberg plugin.
For domain/directory independence all the local URLs in both existing and new content are replaced with short-codes upon save and restored into currently appropriate URLs on load/view/edit.

For editor this is done via "the_editor_content" hook (and "content_save_pre" hook accordingly), which was working fine.
In Gutenberg editor those URLs (looking at "view page source") still contain short-codes instead of domain/path, suggesting "the_editor_content" hook isn't there for Gutenberg editor.

Perhaps there are some new hooks for Gutenberg or other plans regarding pre/post filtering? Or it might be a bug?

As for replicating:
function content_load ($content) { $content = str_replace('[home]', 'not-home', $content); return $content; } add_filter('the_editor_content','content_load',2);
This, as a part of any plugin, for classical editor replaces all instances of "[home]" before the post is shown to a user. It doesn't for Gutenberg.

Tested with WP 5.0 - behaves exactly the same.
It seems there is no the_editor_content filter hook.

Hi all, here i've the same problem with a plugin that uses this hook.
the_editor_content hook runs with the classic editor in WP 5.0.1 but not with the block editor

the_editor_content hook runs with the classic editor in WP 5.0.1 but not with the block editor

Correct. You'll need to filter REST API requests and responses instead.

If you can provide an example of how you're using the_editor_content and content_save_pre, I'll put together an equivalent example using the REST API.

Hi Daniel, and thanks a lot

function entradas_predefinidas_insertar_contenido($content) {
    global $post;
    if ($post->post_type == 'post' && get_post_status ( $post ) == 'auto-draft') {
        $content = get_option('entradas_predefinidas_value').$content;}
    return $content;
}
add_filter( 'the_editor_content', 'entradas_predefinidas_insertar_contenido' );

Oh. If you're just adding the value when a new post is created, you can use default_content:

add_filter( 'default_content', function() {
    return 'My custom default content';
});

image

See https://github.com/danielbachhuber/gutenberg-migration-guide#actions--filters

We'll still need to document how to perform the equivalent of the_editor_content though.

Thank you very much @danielbachhuber

Hi, unfortunately default_content won't help in my case:

function guid_load ($content) {
$hmo = get_option('siteurl');
if(strrpos($content, $hmo)=== false) {$content = $hmo.$content;}
return $content;}

function content_save ($content) {
$hmo = get_option('siteurl');
$content = str_replace('href=\"'.$hmo, 'href=\"[home]', $content);
$content = str_replace('src=\"'.$hmo, 'src=\"[home]', $content);
return $content;}

function content_load ($content) {
$hmo = get_option('siteurl');
$content = str_replace('[home]', $hmo, $content);
return $content;}

function handle_upload_filter ($file) {
$hmo = get_option('siteurl');
$file['url'] = str_replace($hmo, '', $file['url']);
return $file;}

function load_guid_complete ($guid) {
$hmo = get_option('siteurl');
if(strrpos($guid, $hmo)=== false) {$guid = $hmo.$guid;}
return $guid;}

add_filter('content_save_pre','content_save',99);
add_filter('the_editor_content','content_load',1);
add_filter('the_content_rss','content_load',1);
add_filter('the_content_feed','content_load',1);
add_filter('gettext','content_load',1);
add_filter('wp_get_attachment_url','guid_load',1);

Ok, it seems I've found two solutions. The question is which one is more appropriate, if any:

A:

function act_the_post( $post_object ) {
$post_object->post_content = content_load($post_object->post_content);
}
add_action( 'the_post', 'act_the_post' );

B:

function rest_prepare_filter( $response, $post, $request )
{
    if( in_array( 'content', $response->data) )
        $response->data['content']['raw'] = content_load( $response->data['content']['raw'] );
    return $response;
}
add_filter( "rest_prepare_post", 'rest_prepare_filter' , 10, 3 );
add_filter( "rest_prepare_page", 'rest_prepare_filter' , 10, 3 );

@kivig2 I think option B is better, as it's a bit more precise. Option A will apply in many more areas, which could cause unexpected results.

I am removing the [Type] Help Request and Needs Technical Feedback labels since a few code examples have been noted and adding the [Type] Documentation label because there is a request in the discussion earlier asking for better documentation on how to move from using the_editor_content and content_save_pre to filtering REST API requests and responses instead.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

mhenrylucero picture mhenrylucero  路  3Comments

youknowriad picture youknowriad  路  3Comments

nylen picture nylen  路  3Comments

hedgefield picture hedgefield  路  3Comments

BE-Webdesign picture BE-Webdesign  路  3Comments