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

Persist custom CSS classes during block conversion when block supports additional classes #5028

Closed
benoitchantre opened this issue Feb 13, 2018 · 10 comments · Fixed by #7538
Closed
Assignees
Labels
Backwards Compatibility Issues or PRs that impact backwards compatability Needs Decision Needs a decision to be actionable or relevant [Type] Enhancement A suggestion for improvement.

Comments

@benoitchantre
Copy link
Contributor

Issue Overview

When converting a Classic block to blocks, existing classes are removed. CSS classes can have been added manually (edit as HTML or TinyMCE text mode) and should be kept to preserve the appearance of the content.

Steps to Reproduce (for bugs)

  1. Add a Classic bloc and copy the code below when editing as HTML
  2. Convert to blocks
<h2>Paragraph with CSS classes</h2>
<p class="custom-class-1 custom-class-2">Sed quae tandem ista ratio est? Ipse Epicurus fortasse redderet, ut Sextus Peducaeus, Sex. Aberat omnis dolor, qui si adesset, nec molliter ferret et tamen medicis plus quam philosophis uteretur. Ne amores quidem sanctos a sapiente alienos esse arbitrantur. Hoc non est positum in nostra actione. Quacumque enim ingredimur, in aliqua historia vestigium ponimus. <i>Non quam nostram quidem, inquit Pomponius iocans;</i></p>
<h2>List with CSS class</h2>
<ul class="custom-class">
<li>Utrum igitur tibi litteram</li>
<li>Videor an totas paginas commovere</li>
<li>Videamus animi partes, quarum est conspectus</li>
</ul>

Expected Behavior

Each block should keep its classes.

Current Behavior

Block classes are removed

Tested with Gutenberg 2.1

@youknowriad youknowriad added the [Type] Enhancement A suggestion for improvement. label Feb 14, 2018
@youknowriad
Copy link
Contributor

Converting to blocks can be a bit destructive because it's very hard to ensure all kind of markup is transformed properly, that's one of the reasons it's an explicit action instead of an automatic migration. so I'm considering this as an enhancement.

That said, it would be nice if we could add these extra classNames as custom classNames (Inspector control) when the block supports it.

@karmatosed karmatosed added this to the Future milestone Apr 27, 2018
@danielbachhuber danielbachhuber removed this from the Future milestone Jun 4, 2018
@danielbachhuber danielbachhuber added the Backwards Compatibility Issues or PRs that impact backwards compatability label Jun 4, 2018
@danielbachhuber danielbachhuber self-assigned this Jun 4, 2018
@danielbachhuber danielbachhuber changed the title CSS classes are removed during conversion to blocks Persist custom CSS classes during block conversion when block supports additional classes Jun 6, 2018
@danielbachhuber
Copy link
Member

@WordPress/gutenberg-core Can you provide technical direction on how I should implement this?

@youknowriad
Copy link
Contributor

The idea would be to be to create a custom matcher for the className, it would be used only internally to parse the custom className attribute (removing the generated className and assigning the remaining classes to the className attirbute)

This all would happen in editor/hooks/custom-classname.js. We'd have to change the definition of the className attribute and use the new "source" (something like "source: customClassname", it would be awesome to have a mechanism to define custom sources, but until we have it it's fine to hardcode this custom source in the parser blocks/api/parser.js) instead of persisting the custom className into the comments attributes.

@designsimply
Copy link
Member

Re-opening because I tested with 3.4 and found that #7538 fixes the case where adding classes in html mode resulted in an invalid block but did not address the case where the class attribute is removed when using "Convert to Blocks." Since it has come up a number of times in feedback, this issue should remain open for debate.

Also closed #8275 as a duplicate.

@designsimply designsimply reopened this Jul 31, 2018
@designsimply designsimply added the Needs Decision Needs a decision to be actionable or relevant label Jul 31, 2018
@danielbachhuber
Copy link
Member

did not address the case where the class attribute is removed when using "Convert to Blocks." Since it has come up a number of times in feedback, this issue should remain open for debate.

Interesting. My understanding was that both scenarios had been addressed..

@aduth
Copy link
Member

aduth commented Jul 31, 2018

Discussing this with @designsimply , the main issue preventing the classes from being preserved is that they are removed during the Raw Handling processing. The behavior implemented in #7538 would be capable of preserving the class if the 'raw' transform was to receive the node with classes intact.

@gziolo gziolo modified the milestones: 3.5, 3.6 Aug 8, 2018
@youknowriad youknowriad modified the milestones: 3.6, 3.7 Aug 15, 2018
@youknowriad youknowriad removed this from the 3.7 milestone Aug 30, 2018
@maddisondesigns
Copy link

Is this going to be fixed? #7538 says it's been merged but as of Gutenberg 4.0 Convert to Blocks is still stripping classes.

@samhermes
Copy link

Seeing the same as @maddisondesigns. This would be super helpful to have.

@youknowriad
Copy link
Contributor

Tried again and it seems like this is fixed

@changochivo
Copy link

It seems this problem has come back!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Backwards Compatibility Issues or PRs that impact backwards compatability Needs Decision Needs a decision to be actionable or relevant [Type] Enhancement A suggestion for improvement.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

10 participants