-
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
Blockers for launching "Try Gutenberg" callout in core #7147
Comments
Is the Columns block planned for WordPress 5.0? I think the Columns block is currently too limited to be useful, and it should be either improved to have responsive functionality and non-equal-width columns, replaced with something better, or removed before the "Try Gutenberg" callout goes out. See also:
Additionally, the Text Columns block is also still a thing even though it is even more useless than the current Columns block and made obsolete by it. See #6506. For optimal content conversion from the Classic Editor, I think #6520 needs to be merged before the callout, so that blockquotes with more complicated content will be preserved better. #5941 and #5970 should also be resolved before the callout. There needs to be a decision made: is the Classic block supposed to exist purely as a legacy fallback? Or should its use be encouraged for those who want an editing experience with mixed content and various inline formatting options? I think the recommended way to have a lot of this stuff would be to use plugins that do things like add text color buttons to all the core blocks or add a "Freeform text" block that acts similar to the Classic block while being more adapted to Gutenberg design. Recommending use of the Classic block for anything other than legacy content seems like a bad idea to me. The callout will likely increase the amount of plugins developed for Gutenberg, so the Gutenberg API should be mostly stable by then. I think #2751 needs to be resolved before a callout, as that is the last big API change (that I am aware of) that has not happened yet. See also: #6733. |
Are we okay with the masses trying this out with all the accessibility issues remaining (ie. #179)? This affects a large number of users. |
Hi @SuperGeniusZeb / @brianhogg, Thanks for the feedback. There's certainly a ton of work to be done before WordPress 5.0 ships. I think the issues you've mentioned are good candidates for 5.0. For "Try Gutenberg", I'd like us to focus on blockers exclusively first, where "blocker" is defined as "causes some amount of data transformation that would be non-trivial to recover from at scale". Time-permitting, we can also work to address high priority issues that aren't necessarily blockers. |
I agree with @supergeniuszeb - the Columns are a necessary thing to get perfected. I don't think that can be overstated. The folks that get introduced to Gutenberg because of the callout are not the adventuresome folks like many who are following the beta project now. Hence, I suggest a fairly polished version prior to introducing it to novices. Of the 680 open issues in Git, over 200 are tagged as "[Type]Bug". Perhaps those should be focused on at some point prior to the callout. No one wants tons of duplicate issues being raised. Most importantly, first-impressions are critical, and a poor first-impression could deter 1000s of folks from upgrading when WP 5.0 is released. Gutenberg has a great start, but please wait long enough for the callout to give the new audience a stellar first-impression. |
Since my previous comment, several Gutenberg releases have happened and a bunch of stuff has been resolved. In addition to what is mentioned in the main post, here is what I think still needs to be resolved:
Elaborating on that last one, I think it would be a good idea to remove it before the callout for the following reasons:
|
On top of that, merging "Container" block idea into "Columns, where single-column === container" might be a good optimization, too. |
@lkraav Just to be clear, right now each column in a Columns block is actually a separate block: a Column block. Given that a Column is usually expected to have different settings from a Container (like its width compared to other Column blocks in the same Columns block), I am not sure that is a good idea. Column blocks do not have any settings right now, though, so this depends somewhat on how the Columns block develops. Some questions that should be answered first:
Maybe you are right. Having Container blocks nested directly in Columns blocks would certainly be a a good optimization in having fewer On a related note, I have been looking into Oxygen lately, and I am really impressed by its flexbox-based layout system. I think perhaps a flexbox-based layout block could be a good addition to Gutenberg in the future. It could act as a nice alternative to the Columns block, or maybe even a full replacement depending on how powerful it becomes. https://oxygenbuilder.com/documentation/visual-editing/layout-spacing/ |
I think #6102 is something that may be desirable to get fixed before the callout, simply because it may be a common source of frustration and duplicate issues. I know I certainly do not like my |
I'm pretty happy with where things are at now... 🚢 🚢 🚢 |
@danielbachhuber Are you sure about that? There are still some issues with conversions from the Classic block. See the latest comment in #6102. |
Yes.
I agree this is important to address in some way, but I don't think it needs to or can happen in the next few days. I'll comment on that issue directly. |
Following up on my original assessment eight weeks ago, I did another review of the entire issue and PR backlog yesterday. There are still some, but not too many, issues I think we need to resolve before launching the "Try Gutenberg" callout in core.
Notably, this list is subject to interpretation and open to debate. My qualifier for "Try Gutenberg blocker" is that the issue causes some amount of data transformation that would be non-trivial to recover from at scale (particularly if revisions are disabled). There's no sense in users experiencing this pain if we're already aware of it.
To recap the issues:
Opening Gutenberg post in Classic Visual editor adds unwanted.<p> </p>
contentGutenberg breaks "classic" posts w/ shortcodes by carelessly wrapping shortcodes into.<p>
tagsUnexpected content changes toggling Classic editor from Text to Visual to Text. Superseded by Create warning user experience around editing Gutenberg post in Classic Editor #8213Converting a table in a classic block to a table block removes all inline styles. Superseded by Table block: flesh out editor features #6923Modifying a block's HTML can cause an unexpected "This block appears to have been modified externally." errorAlso relatedCode Editor needs WARNING!. Superseded by Block Validation, Deprecation and Migration Experience #7604Converting To Blocks Loses Existing Anchor Tag Parameters.Converting blocks lose anchor tagsUse of loop and autostart in<audio>
causes unknown errorCSS classes are removed during conversion to blocks.Convert to blocks breaks images with CaptionsNew lines in shortcode content are ignoredDrag and drop uploading doesn't respect multisite max upload sizeTwo other sets of issues that seem like they could impact a large number of users, but aren't necessarily blockers, are:
<table>
support (e.g. Table block: flesh out editor features #6923 Add additional formatting options to the Table block inspector sidebar #7008 Add text alignment controls to Table block toolbar #6699 Table cells shouldn't use fixed pixel widths #4027 Table cell widths don't resize properly after inserting column #4026 Can't tab between cells in table block #4025 Table block markup in the front-end #2904 Tables: no method to define row or column header cells (th) #1470)The text was updated successfully, but these errors were encountered: