for a project I have to extend the core block core/cover-image. For the first basic try I came up with the following code:

PHP:

add_action('enqueue_block_editor_assets', function() {
   wp_enqueue_script('hephaestus-admin-script', 
   get_template_directory_uri() . '/dist/js/admin.js', ['wp-blocks', 'wp-element', 'wp-edit-post'], THEME_VERSION);
});

admin.js:

function transformElement(element, blockType, attributes) {
  if (blockType.name != 'core/cover-image') {
    return element;
  }

  var newElement = wp.element.createElement(
    'div',
    {
      className: 'wp-block-cover-image',
      style: 'background-image: url(\'' + attributes.url + '\');',
    },
    [
      wp.element.createElement(
        'p',
        {
          className: 'wp-block-cover-image-text',
        },
        [
          wp.element.createElement(
            'span',
            {
              className: 'wp-block-cover-image-text-stage',
            },
            attributes.title
          )
        ]
      ),
    ]
  );

  return newElement;
}

wp.hooks.addFilter(
  'blocks.getSaveElement',
  'hephaestus/modify-get-save-element',
  transformElement
);

Basically this works. I can add the cover image block in the editor and the frontend output is as desired too.

But when reaccessing the site in backend, Gutenberg gives me the following error:

Block validation: Block validation failed for core/cover-image

Expected:

<div class="wp-block-cover-image" style="background-image: url('https://xxxxxxxx/wp-content/uploads/2018/08/xxxxxxxx.jpg');"><p class="wp-block-cover-image-text"><span class="wp-block-cover-image-text-stage"></span></p></div>

Actual:

<div class="wp-block-cover-image" style="background-image: url('https://xxxxxxxx/wp-content/uploads/2018/08/xxxxxxxx.jpg');"><p class="wp-block-cover-image-text"><span class="wp-block-cover-image-text-stage">This is a test</span></p></div>

Note: image url is intentionally crossed out

Why do I get this block validation error here? I think it has something to do with the title attribute. But I can't figure out what causes this...

Help, anyone?

Regards, Marcus

  • Hi @sally-cj! Replacing the attributes.title in the code above with a simple string (e.g. "test") works fine and without any validation error. So I doubt that the block is expecting an empty span. It seems that in the validation process the attribute title is missing or something. – Marcus Kober Aug 17 at 10:19
  • Hey @MarcusKober, please just ignore whatever I've said before! Lol really sorry. I think it's actually a simple fix - use attributes.title.toString() instead of attributes.title because from my tests just now, that is an array. So you got that error most likely because the React engine is expecting a string and not an array. Sorry again and hopefully that works for you. =) – Sally CJ Aug 18 at 4:39
  • 1
    Hey Sally, sorry - but no. Sadly attributes.title.toString() doesn't help here either. It comes to exact the same error manage. Should've mentioned it that I tried that before... :( But thanks for your help! :) – Marcus Kober Aug 20 at 5:23
  • 1
    Well then, a custom block is probably much preferred since it's not hard to make one. 😉 Cheers! – Sally CJ Aug 20 at 6:02
up vote 4 down vote accepted

Not a real answer alert

This sounds like a long term bad idea. You are modifying a core functionality with something which do not inherit any of the generated markup of the original block. Any later processing of the block might make assumption about the markup based on the block name, but the assumptions might be wrong and it will be hard to pinpoint why as the block has the expected name.

Just like with widgets and shortcodes, if you are going to basically fork the block you should just create a new one. Modifying a block should be done only when all you do is modifying some small aspect of it, and maybe not even then.

(I do realize that you might be just playing around, but still a new block is much more KISS compatible considering the code you show here)

  • Hi @MarkKaplun, you are so right! Created a new block for this, which works like a charm. But still the original problem puzzles me... – Marcus Kober Aug 20 at 5:26
  • 1
    IMHO gutenberg is not stable enough yet to trust whatever answer you might get at this stage. Until it is merged in core I am not sure that as a plugin developer you will be able to trust that such details as you basically ask about will not change. But if this still bothers you, maybe opening an issue on the GB github is the right thing to do, you might get an explanation or this might turn out to be a bug. – Mark Kaplun Aug 20 at 6:18
  • So, at the time of writing, I generate a custom block for every output I like to change. Not ideal. – uruk Nov 13 at 15:24

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.