Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Will it be possible to wrap Classic Block with <!-- wp:classic --> ? #6330

Closed
phpbits opened this issue Apr 21, 2018 · 9 comments

Comments

@phpbits
Copy link

@phpbits phpbits commented Apr 21, 2018

Hi,

I'm still testing my plugin integration for https://wordpress.org/plugins/block-options/ and found an issue with the Classic Block. It seems that this block wasn't wrapped with the required block tags. Will it be possible to wrap it with <!-- wp:classic -->? This will enable us devs to add more attributes to this block. Thanks!

Tagging @aduth and @gziolo since you both helped me a lot on my previous issues. Thanks!

@gziolo

This comment has been minimized.

Copy link
Member

@gziolo gziolo commented Apr 23, 2018

Not sure to be honest, but I guess it is designed this way to make it clear that Classic Block exists only for backward compatibility reasons. @mcsf or @mtias should be able to confirm.

@mcsf

This comment has been minimized.

Copy link
Contributor

@mcsf mcsf commented Apr 23, 2018

Hi, @phpbits. The Classic block, by definition, represents pre-Gutenberg content: it's the non-block block. :) As @gziolo points out, it's merely there for backwards compatibility. Thus, there are no plans to wrap it with block tags. I also struggle to see what an attribute for it would mean, so could you expand on:

This will enable us devs to add more attributes to this block.

Thanks!

@aduth

This comment has been minimized.

Copy link
Member

@aduth aduth commented Apr 24, 2018

Specifically, the freeform block is opted out of comment demarcations by design:

switch ( blockName ) {
case getUnknownTypeHandlerName():
return saveContent;
default:
return getCommentDelimitedContent( blockName, saveAttributes, saveContent );
}

@phpbits

This comment has been minimized.

Copy link
Author

@phpbits phpbits commented Apr 25, 2018

@mcsf @gziolo How about when the Classic Block was used as block and not the backward compatibility? Here's my plugin which adds additional attributes on each block : https://wordpress.org/plugins/block-options/ and would love to know the best solution to make it work with Classic Block. Thanks!

@mcsf

This comment has been minimized.

Copy link
Contributor

@mcsf mcsf commented Apr 25, 2018

How about when the Classic Block was used as block and not the backward compatibility?

I'm not sure I understand the question.

Here's my plugin which adds additional attributes on each block

That doesn't help us know what information would need to be encoded alongside a Classic block, or why. Without that information, I can't recommend anything else.

FWIW, at the parser level, Classic content is picked up as freeform, represented as a quasi-block with only inner HTML and no attributes. There are no plans to change this, since conceptually Classic "blocks" can be no more than this.

function freeform( s ) {
return s.length && {
attrs: {},
innerHTML: s
};
}

Block_List
= pre:$(!Block .)*
bs:(b:Block html:$((!Block .)*) { /** <?php return array( $b, $html ); ?> **/ return [ b, html ] })*
post:$(.*)
{ /** <?php return peg_join_blocks( $pre, $bs, $post ); ?> **/
return joinBlocks( pre, bs, post );
}

@phpbits

This comment has been minimized.

Copy link
Author

@phpbits phpbits commented Apr 25, 2018

@mcsf What I mean is what if I use the Classic Block when I've doing Gutenberg contents? It should work as regular block wrapped with since it's been used the same way as the other blocks. Thanks!

@mcsf

This comment has been minimized.

Copy link
Contributor

@mcsf mcsf commented Apr 25, 2018

Regardless of whether the block was spawned out of back-compat to handle older content, or whether the block was added explicitly to contain arbitrary TinyMCE content, it will be represented in post_content as non-demarcated content.

It should work as regular block wrapped with since it's been used the same way as the other blocks.

At the post_content-level, it will remain an exception, at least for now. However, during an editing session, it will exist in memory as a proper block.

It cannot, however, have attributes sourced from post_content. It is still not clear to me what kind of attributes could be created for Classic. By definition, it represents content unaware of the block abstraction, so it cannot have block attributes; it can only have its own HTML markup and perhaps post meta, if fitting.

@mcsf

This comment has been minimized.

Copy link
Contributor

@mcsf mcsf commented Apr 25, 2018

However, during an editing session, it will exist in memory as a proper block.

For the record, this means that it's possible to get creative with hooks and intercept Classic blocks in the editing context, if you need to.

@phpbits

This comment has been minimized.

Copy link
Author

@phpbits phpbits commented Apr 25, 2018

@mcsf I'll just disable the Block Options on Classic block since there's no way for now to save the attributes. If in any case users ask for it, I'll just send this thread. Thanks!

@mcsf mcsf closed this Apr 25, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.