5

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

5
  • 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. Aug 17, 2018 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, 2018 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! :) Aug 20, 2018 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, 2018 at 6:02
  • For visitors in 2021+, it is becoming more and more feasible to modify core block functionality. I think the validation error here could be resolved with a 'editor.BlockEdit' filter. That said, modifying the core blocks is still generally an unstable and considerably work-intensive practice prone to falling apart as Gutenberg iterates, and subject to cause issues and conflicts with other plugins if not approached very very carefully.
    – bosco
    Jun 27, 2021 at 18:38

2 Answers 2

5

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)

3
  • Hi @MarkKaplun, you are so right! Created a new block for this, which works like a charm. But still the original problem puzzles me... Aug 20, 2018 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. Aug 20, 2018 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, 2018 at 15:24
1

Long time ago... :)

In the meantime I wrote a little tutorial for extending Gutenberg blocks:

Extending Gutenberg blocks

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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