Remove all references to WP in markup (more CMS-agnostic)?

[perandre]

Currently, HTML classes and comments use the term "WP" a lot. No problems with that – if you are using WordPress.

As some might know, we are in the process of porting Gutenberg to Drupal. While this is perhaps not a huge concern for Gutenberg devs, but I think it is worth exploring to not have WP in class names at least. If developers start relying on those classes now, things will break later.

Background: front/drupal-gutenberg#6

[maximebj]

Yes but in my opinion we should keep something in front of the classname in order to avoid having generic classnames.

.gut-* ?

[perandre]

Yep, agree. This discussion also plays into this: #4681

[gziolo]

Can you provide some more details with examples of those classes and comments? As far as I remember the only place where we use wp-block-* prefix for HTML class names is inside block-library module where all the blocks are defined. In addition, it is possible to override this class auto-generated for almost all blocks (some of them can opt-out) with the following hook:
https://wordpress.org/gutenberg/handbook/extensibility/extending-blocks/#blocks-getblockdefaultclassname

[perandre]

Thanks for your reply! Can you provide a more complete list here, @SofiaSousa?

[SofiaSousa]

Didn't know about getBlockDefaultClassName filter, thanks @gziolo.

After a quick search for wp in the repo, there are 3 different areas where wp uses to be used:

1. Blocks classes and comments (ex: <!-- wp:button --><div class="wp-block-button">...). getBlockDefaultClassName;
2. Paths for api requests (ex: hardcoded '/wp/v2/types');
3. And Gutenberg's packages which are available through the global wp.

[perandre]

Did a presentation on Gutenberg on Drupal Europe yesterday (https://www.drupaleurope.org/session/introducing-gutenberg-content-editor-drupal-8). A few people asked if it was possible to remove references to WP in code. Purists :) A lot of interest, however.

[perandre]

For true block re-use between Drupal and WordPress (what we try to accomplish with https://gutenbergcloud.org), it would be greatly helpful if the wp-* class prefix was not there at all. And I can imagine removing it after 5.0 is out would be very painful. So: Are there any reasons not to replace it with something more CMS agnostic?

[tomjn]

I'm not sure I fully understand the technical problem that removing references to wp solves, perhaps some clarification?

After all it'll be pretty obvious where the interface came from once WP 5.0 is released regardless of what the HTML classes are, and it's not common practice to take JS and PHP libraries and maintain forks that only change the prefixes

[mcsf]

And I can imagine removing it after 5.0 is out would be very painful.

This is true, though it is currently already hard to change, as third-party developers have been trusting Gutenberg based on interface stability in this stage leading up to 5.0.

Are there any reasons not to replace it with something more CMS agnostic?

The answer is a mixture of the difficulty described above — which is enough on its own — and the fact that it is hard to prioritize this sort of change against all the remaining work needed for WordPress core's tight schedule for 5.0.

I'd like to label this issue Future and close it, since a solution in Gutenberg core should have to wait.

• However, w.r.t. class prefixes, third-party extensions should be able to extend blocks' class lists, possibly via duplication (e.g. class="wp-block-separator gut-block-separator"), thus helping meet requirements of non-WP-core uses and maintaining compatibility with core styles, themes, etc. This is possible using the blocks.getBlockDefaultClassName filter — see docs.
• W.r.t. the block-grammar spec, i.e. HTML comments, I think a path forward will become much clearer once the 5.0 dust settles, and we could then perhaps expand the grammar to treat wp: and gut: as aliases.

[perandre]

I'm not sure I fully understand the technical problem that removing references to wp solves

To reuse the same block in different CMSs, we want the markup to reflect just that. Frontend devs care about semantics! We could implement a fix for this in Drupal and Magento plugin for the editor – but that means the block would break in WP.

We are really cheering for Gutenberg to become the editor for the open web. If the markup incorrectly indicates it's for WP only, I believe wider adoption will be much harder. This assumption was confirmed when talking to frontend developers on Drupal Europe recently: They find it very hackish to have wp-*in their markup.

I respect the tight deadline. However, the alias fix seems to solve all this neatly: If we could use gut-* from the start, it would be a huge step forward. Waiting until Nov/Dec is too late IMO.

[mtias]

@perandre first, thanks for all the work and interest in using the editor for Drupal. I think it's amazing we are having these kind of conversations and opening up ways to collaborate. If we can increase this collaboration the web as a whole will benefit.

To make this more productive in the midst of the push for WP 5.0 release, I suggest you to start looking at places where prefixes might be hardcoded and figure out ways to make it optional through editor configuration without necessarily having to opt-out of wp on our side. Would that work for you as an initial path forward?

Eventually we may end up with <!-- web:block --> (I prefer it to gut as an alias), which would be exciting. But I think we should be pragmatic about seeing where this leads all of us, what layers of commonality we uncover, where Drupal can help push things, where we can align back, and be open to the fact this will be a novel process of alignment across the web and its major CMSs.

[perandre]

Thanks for cheering us on, @mtias!

Would that work for you as an initial path forward?

For most references to WP (as listed by @SofiaSousa) above: Yes. The only truly urgent part, is HTML classes. Forcing other classes inside Drupal would make it impossible to drop in WP blocks.