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

Requirement: Classic Text block #5123

Closed
2 tasks
bobbingwide opened this issue Feb 18, 2018 · 3 comments
Closed
2 tasks

Requirement: Classic Text block #5123

bobbingwide opened this issue Feb 18, 2018 · 3 comments
Labels
Backwards Compatibility Issues or PRs that impact backwards compatability New Block Suggestion for a new block [Type] Enhancement A suggestion for improvement.

Comments

@bobbingwide
Copy link
Contributor

Requirements for a Classic Text editor block. Aka freeform, ASIS, verbatim, hand crafted, stet.

Issue Overview - background

WordPress has been around for many years. In that time users have created content in a number of ways, often using poorly structured HTML. To help reduce their problems developers have provided shortcodes and server side functionality that enable users to write their content in a simplified form and have it displayed nicely on the front end. Shortcodes are often used to encapsulate content that can be seen and edited in both the Visual and Text editor. The user may not know how the shortcodes work; they just follow the rules. The system works.

When the new editor is delivered in WordPress 5.0, users will expect to be able to edit their existing content. They may also want to try using the new editor. But there will be times when the only way they know how to do anything is the old way. This impedes progress.

This requirement is to provide a new Classic Text editor block that will enable users to achieve the transition to the new editor for most of their content. The user will continue to use this block type until support is provided by the plugins or theme upon which they were dependent, or some other migration path is found.

Requirements

asis-block
Provide a Text editor block that respects the content written by the user. Respecting content means.

  • New lines remain as new lines, they do not get converted into <br /> tags or spaces.
  • No automatic creation of <p> or <br /> tags.
  • No encapsulation in other tags.
  • Server side filters should not modify the user content.

When content is first loaded into the editor and it determines that it need to support it as legacy content, then the system should determine which Classic block type is most suitable. The following are indicators that the Classic text block should be used in preference to the Classic block.

  • New lines without <br />'s or paragraph tags
  • <style> or <script> tags
  • Enclosed content shortcodes
  • Non standard HTML structure
  • No HTML in content
  • wpautop disabled or filtering applied at non-default priority
  • User has disabled the rich editing option

Worked example

So that you can get a better understanding of the requirement, here is a more complicated scenario for #4456.

This image shows the post's source in the Blocks widget in the sidebar.
The content area shows the result of shortcode expansion.
issue-4456-part-two

Current Support

Can I achieve what I need with the existing blocks?
Short answer: Nearly.
I tried to develop my own blocks ( ASIS and freeform-text ) but failed to get them to work exactly as required. I noted that some of the problems I encountered have already been reported as issues and labelled as Bugs. Here's a summary of the results.

The row entry for each of the following columns will be Y when the block satisfies the requirements
for the round trip - from editor to editor, from editor to browser.

  • New lines - Line breaks are left as is. No conversion to br tags or removal of them on save/preview.
  • No auto p - No automatic wrapping of content in paragraphs
  • No texturize - Content should not be texturized
  • Unwrapped - Content should not be enclosed in other tags. e.g. No code, pre or other tags added.

The most important requirement to satisfy is that line breaks in shortcode's content are left as is.

Block type New lines No auto p No texturize Unwrapped Comment
Code Y Y N N Adds code and pre tags.
Classic N N Y N
Custom HTML N N Y N
Shortcode N Y ? Y Converts new lines to blanks
Preformatted N N N N Adds pre tag. Seems to only work for copy/paste

Possible Solution

I developed two prototype blocks: ASIS and freeform-text.

  • I was trying to remove the need for the code and pre tags but failed.
  • So, in the ASIS block I retained the code tag and removed the pre tag.
  • And in the freeform-text block I removed the code tag and retained the pre tag.
Block type New lines No auto p No texturize Unwrapped Comment
ASIS See below Y N N Uses code tag. Quotes and single quotes altered etc
freeform-text Y Y N N Uses pre tag. HTML tags are escaped

The ASIS block was OK for enclosed content shortcodes.
Outside of shortcodes, the results varied depending how the wpautop filter function was applied.

  • If not run at all then the line breaks were lost.

  • If run after shortcode expansion then unexpected p tags were wrapped around the code tags that I didn't want in the first place.

  • I didn't test running before shortcode expansion... That's always been an issue.

  • There are also problems with shortcode parameters enclosed in quotes.

The freeform-text block was also OK for enclosed content shortcodes... new lines were respected
but you couldn't use HTML. So that makes it a non-starter.

ASIS block as potential replacement for the Shortcode block

In its current form, the prototype ASIS block is, in some respects, superior to the existing Shortcode block. The caveats being...

  • In order to style the blocks I needed to override the de facto standard that code ( and pre ) tags are normally displayed as monospaced. I used the Additional CSS class to achieve this.
  • Shortcode parameters passed with quotes are not handled correctly.

Additional requirements

I've not yet considered transforms between block types. It may be that the final solution will entail use of the Convert to blocks function to create the most appropriate blocks. And that will mean improving the existing blocks ( such as Custom HTML) to be more lenient with regards to the user's content.

This Classic text block may however been needed to satisfy the implicit requirements of #4634.

I've also not considered any toolbar icons or advanced settings. If the approved solution is to extend the existing Classic block to support Visual and Text - just like the Classic Editor - then I would expect to be able to use the original set of Quick tags and any extensions delivered by plugins.

Related Issues and/or PRs

#4456
#4672
#4992
#4981

Todos

  • Tests
  • Documentation
@cr101
Copy link

cr101 commented Feb 19, 2018

I agree. I'd love to be able to create text content without having the line breaks automatically converted to <br> tags and the content automatically wrapped in <p> tags.

As a web developer I've always used the Classic Text Editor on my own projects. Having all those <br/> and <p> tags in the content is distracting and annoying and also as I've mentioned in #4446 I don't want to save HTML tags in the database.
I can convert the new lines myself on the front-end as I have been doing for a number of years and it's been working well.

Having the option to use a Classic Text editor block and also set as the default when creating a new post is a great a idea.
Not everyone needs or wants to use <p> and <br> tags in their content.

@jeffpaul jeffpaul added [Type] Enhancement A suggestion for improvement. New Block Suggestion for a new block labels Mar 8, 2018
@danielbachhuber danielbachhuber added the Backwards Compatibility Issues or PRs that impact backwards compatability label Apr 10, 2018
@danielbachhuber danielbachhuber added this to the Merge Proposal milestone Apr 10, 2018
@karmatosed karmatosed modified the milestones: Merge Proposal, Merge Proposal: Back Compat Apr 12, 2018
@mtias mtias removed this from the Merge Proposal: Back Compat milestone Jul 17, 2018
@danielbachhuber
Copy link
Member

Thanks again for all of your detail on this, @bobbingwide.

I think much of this has been addressed since you originally opened the issue. If there are further, more specific changes you'd like to suggest, feel free to create new issues for each.

@bobbingwide
Copy link
Contributor Author

@danielbachhuber I'm back to working with Gutenberg after a 5 month gap. There have been a lot of changes. The Classic block is much better and now appears to satisfy my requirements except when viewed using Edit as HTML... which is not quite the same as Classic Text. Hence the new issue.

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 New Block Suggestion for a new block [Type] Enhancement A suggestion for improvement.
Projects
None yet
Development

No branches or pull requests

6 participants