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

Convert to Blocks: HTML Attributes are not copied to the DOM Node within callbacks of custom transforms #8648

Closed
AndiDittrich opened this issue Aug 7, 2018 · 2 comments
Labels
Needs Technical Feedback Needs testing from a developer perspective. [Type] Bug An existing feature does not function as intended

Comments

@AndiDittrich
Copy link

Dear Gutenberg Team,

the "Convert to Blocks" feature (content parser) seems to ignore element attributes on raw DOM Nodes.
By converting "RAW" blocks by custom transform rules, no attributes are available within the isMatch(node) callback even if they are defined in the legacy html sources.


Example Code to reproduce the issue

Plugin

wp.blocks.registerBlockType('test/myblock', {

    // block element transformation/converting
    transforms: {
        from: [
        {
            type: 'raw',
            priority: 4,
            isMatch: function isMatch(node) {
                // ALL kind of attributes/classes are MISSING
                console.log("classes: ", node.classList.length);
                console.log("attributes: ", node.attributes.length);
                return false;
            },
            transform: function transform(node) {
                // some custom transform rule
                return wp.blocks.createBlock('core/codeblock', { content: node.textContent });
            }
        }
        ]
    }
})

Editor Content

<pre class="EnlighterJSRAW" data-enlighter-language="php">
define('ENLIGHTER_GUTENBERG_PLUGIN_PATH', dirname(__FILE__));
define('ENLIGHTER_GUTENBERG_PLUGIN_URL', plugins_url('/enlighter-gutenberg/'));
</pre>

<div class="echo">lalala</div>

Current Behaviour

Attributes are ignored by the parser and not copied to the node passed to the transform callbacks isMatch(node) / transform(node`)

Console Output
gutenberg_transform_attribute_bug


Expected Behaviour

ALL attributes should be copied to the node (and become available in isMatch(node) + transform(node) to apply custom transform rules.

This is absolutely required to convert legacy addons to blocks (lot of them are based on custom classes)

best regards, Andi

@designsimply designsimply added [Type] Bug An existing feature does not function as intended [Feature] Parsing Related to efforts to improving the parsing of a string of data and converting it into a different f Needs Testing Needs further testing to be confirmed. labels Aug 7, 2018
@designsimply designsimply added Needs Technical Feedback Needs testing from a developer perspective. and removed Needs Testing Needs further testing to be confirmed. labels Aug 15, 2018
@mcsf
Copy link
Contributor

mcsf commented Oct 31, 2018

Hi, @AndiDittrich. You most likely need to define a schema to go along with your transformation. See the case of the More block, in which we look for a node like:

<wp-block data-block="core/more" data-custom-text="Optional"></wp-block>

More's transformation:

type: 'raw',
schema: {
'wp-block': { attributes: [ 'data-block' ] },
},
isMatch: ( node ) => node.dataset && node.dataset.block === 'core/more',
transform( node ) {
const { customText, noTeaser } = node.dataset;
const attrs = {};
// Don't copy unless defined and not an empty string
if ( customText ) {
attrs.customText = customText;
}
// Special handling for boolean
if ( noTeaser === '' ) {
attrs.noTeaser = true;
}
return createBlock( 'core/more', attrs );
},

@mcsf mcsf closed this as completed Oct 31, 2018
@mcsf mcsf removed the [Feature] Parsing Related to efforts to improving the parsing of a string of data and converting it into a different f label Oct 31, 2018
@AndiDittrich
Copy link
Author

Hi @mcsf

thanks for your feedback and the node.dataset hint!

after some testing, i've noticed that node.dataset always contains a StringMap with all data-xxx attributes defined on the particular element - but independently of the schema

is assume that the schema is not used in raw transform definitions (i didn't found any hints within the docs..) ?

best regards,
Andi

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Needs Technical Feedback Needs testing from a developer perspective. [Type] Bug An existing feature does not function as intended
Projects
None yet
Development

No branches or pull requests

3 participants