The team is now working on the WordPress Interactivity API. This unblocks the same UX Frontity framework enabled but directly in WordPress Core, fully compatible with the new Site Editor.
Regarding the questions, I’m going to answer them myself but feel free to add your opinion:
Should this work by default or should it require a processor?
I think it’s safer to add it by default. After all, we are “fixing something we broke”. Without this processor the content <scripts> won’t work and in WordPress they work fine.
Should this work with code scripts, or only external scripts? Using something like eval() ?
Following the same principle, we should also execute the code inside the <scripts> because that’s the way it works in WordPress.
We can add a setting to html2react to turn this behavior off:
@luisherranz I really don’t see a use-case for setting allowScripts. I don’t think there is anyone that would want their embedded blocks to come in another form/shape/structure. I mean, I want to see twitter embeds come out as designed.
Just wanted to say I saw the newsletter and this seems super dope! This should make it easier to implement things like my planned lightbox gallery component. I can do it easily in PHP but it’s a little hard to figure out how to do it in a React centric way (I’ll still try to do it in a react way if I can but it’s nice to have this option)