Deprecated extended blocks

  • Hi,

    I extended a core block using the blocks.registerBlockType, editor.BlockEdit & blocks.getSaveElement filter hooks.

    I’m trying to add deprecation to the custom core block by using lodash ‘assign’ 

    settings.deprecated = assign(settings.deprecated, {
        save: (props) => {
            return (
                <div className="cover-link-container">
                    <a className="wp-block-cover__link" href={href.url} rel={rel}>
                        {element}
                    </a>
                </div>
            )
        },
    })

    When I test changing the classname in the blocks.getSaveElement from cover-link-container to cover-a-container it’s still having validation issues in the editor as it doesn’t seem to be picking up my deprecation, as far as I’m aware the way I’ve done it is correct.

    Any advice?

    Thanks,

    Craig

Viewing 5 replies - 1 through 5 (of 5 total)

  • Hi there!

    I think the issue you’re running into is that the deprecated property is actually an array of objects ( each representing a deprecation ) and assign is used to modify an object.

    Can you try this instead?

    settings.deprecated = [
	...settings.deprecated,
	{
		save: ( props ) => {
			return (
				<div className="cover-link-container">
					<a
						className="wp-block-cover__link"
						href={ href.url }
						rel={ rel }
					>
						{ element }
					</a>
				</div>
			);
		},
	},
];
    • This reply was modified 2 years, 1 month ago by Ryan Welcher.
    Thread Starter craig030

    (@craig030)

    Hi Ryan,

    Thank you for getting back to me, I tried this but sadly it still gives me a validation error as it is not picking up the change in the editor.

    I’ve also slightly changed the code 

    <a style="padding: 0;" className={element.props.className} href={href.url} rel={rel}>
                {element}
            </a>

    It didn’t like the variables either, element comes from the blocks.getSaveElement hook and in the deprecation, we are writing code for the save() function as you would in a custom block rather than extending. Does this mean setting up deprecation won’t be possible when extending blocks?

    I did strip out all the dynamic data and tested with my original class names and that’s when I was still getting validation errors. Any ideas?

    Many thanks,

    Craig

    Hi Craig,

    Sorry for the late response here. I think I’d need to see the full code to get a better sense of how it’s all working together. Are you able to share it as a gist perhaps?

    Thanks,

    Ryan

    Thread Starter craig030

    (@craig030)

    Hi Ryan,

    Thanks for getting back to me, no problem here is a gist of the code. It’s to extend the cover block to wrap it with an <a> element so I can add links to the block.

    https://gist.github.com/craig030/80d6f817ac416a9691392c144eb2eb11

    I don’t have the deprecation part added to this gist but maybe you can make a suggestion with my comments before?

    Appreciate your help thank you!

    Many thanks,

    Craig

    • This reply was modified 2 years, 1 month ago by craig030.
    • This reply was modified 2 years, 1 month ago by craig030.
    • This reply was modified 2 years, 1 month ago by craig030.
    • This reply was modified 2 years, 1 month ago by craig030.

    Craig,

    I was only able to replicate the error when assigning a rel so this may not be the fix for what you’re running into. Part of the validation error I saw seeing was to due to missing attributes.

    I found that if I defined the rel attribute ( and didn’t defined any deprecations) , it worked:

    settings.attributes = assign(settings.attributes, {
    href: {
	 url: {
		 type: 'string',
		 default: '',
		 },
	 },
	 rel: {
		 type: 'string',
		 default: '',
	 },
 });

    Could you give that a try and let me know if that works?

    Thanks!

    Ryan

Viewing 5 replies - 1 through 5 (of 5 total)
  • The topic ‘Deprecated extended blocks’ is closed to new replies.