-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Comments
I agree. I'd love to be able to create text content without having the line breaks automatically converted to As a web developer I've always used the Classic Text Editor on my own projects. Having all those 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. |
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. |
@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. |
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
Provide a Text editor block that respects the content written by the user. Respecting content means.
<br />
tags or spaces.<p>
or<br />
tags.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.
<br />
's or paragraph tags<style>
or<script>
tagsWorked 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.
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.
br
tags or removal of them on save/preview.The most important requirement to satisfy is that line breaks in shortcode's content are left as is.
Possible Solution
I developed two prototype blocks: ASIS and freeform-text.
code
andpre
tags but failed.code
tag and removed thepre
tag.code
tag and retained thepre
tag.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 thecode
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...
code
( andpre
) tags are normally displayed as monospaced. I used the Additional CSS class to achieve this.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
The text was updated successfully, but these errors were encountered: