Support » Plugin: Gutenberg » Good start, still a long way to go

  • First, let me say that I’m glad a team is exploring new options. We’ve relied on ACF for over a year, so that we could create more complex layouts, and this feels like a step in the right direction. Allowing everyone to have blocks (funny, we call ours blocks too, but they’re ACF blocks) makes things somewhat easier. But, it really seems like there’s no way to make it as backward-compatible as WP has historically been. It almost seems as though in WP options, the admin role should be able to determine whether Gutenberg or the Legacy Editor will be the one in use. And I would go so far as to say we need a way to specify an editor type, per post type. When you register a CPT, having another argument for editor would be very helpful – we only use these fancy block layouts on a couple of post types, most others just use a basic theme template and no ACF.

    First question, how will things like columns work? Will Bootstrap or Foundation or something similar be baked into WP Core? If so, how will that interact with themes? Coupled with ACF, we use Foundation to make rows and columns easier, and use shortcodes for them when they’re not fully templated. I have a hard time envisioning where WP Core CSS (and even JS) would need to end, and a theme’s specific CSS and JS would begin. It’s just a paradigm shift that’s not necessarily bad, just hard to grasp at this point.

    Like many others we also rely on a lot of postmeta. Yoast SEO is a big one for sure – I was excited to see Yoast dedicated an accessibility-minded dev to the Gutenberg project and hope that things will be completely and utterly WCAG 2.0 AA accessible. I manage higher education websites and it’s already been an uphill struggle making sure every little thing is perfectly accessible. If Gutenberg is baked into Core, it needs to set a very high bar for everything being completely accessible out of the box.

    First observations:
    – I already miss the screen options view. On most of our sites we don’t allow comments or trackbacks anywhere. If that’s turned off sitewide, can the “Discussion” panel just not exist? We also don’t allow Tags on Posts and I was pleased to see that the “Categories & Tags” panel only listed our Categories, not any way to create Tags.

    – The “Settings” toggle button wasn’t intuitive to me. I expected it to be the “screen options” checkboxes but instead found it toggles the sidebar. I would brainstorm a different label and icon.

    – I would love to see a way for theme developers to turn off certain features. For example, changing an author is something we never need to do, and “stick to the front page” is also something we don’t ever use. If a theme dev had filters, per post type (we might change an author on a CPT but not a Post), that allowed them to hide all the clutter that their particular install didn’t need, that would be a big step toward decluttering and simplifying the UX.

    – How does one save a draft? Creating a new Post, I only see a Publish button – not a way to save a draft if I’m not ready to publish yet.

    – Along the same lines… how the heck do you set a permalink? We are notorious for having super-long Post titles, then manually shortening the permalink and the Yoast SEO title tag as well. I don’t see anyplace to adjust here.

    – A “paragraph block” is odd to me. When I add a paragraph there’s a 90% chance there will be multiple paragraphs. Maybe it’s more psychological than a real thing, but adding a separate block feels like there will be extra divs added for no reason. I would just call it a text block which naturally in my mind could contain multiple paragraphs, as well as headings and lists.

    – I’m confused about the gear icon that has the “Show inspector” tooltip. It doesn’t seem to do anything, and it seems like a magnifying glass might be a more fitting icon for inspection.

    – Instead of adding more Dashicons, has anyone considered embedding Font Awesome or something similar? That would enable plugin and theme developers to extend the blocks with fitting icons and just require 1 CSS embed, rather than plugin and theme authors adding their own icons into the mix. Again maybe more a psychological cleanliness than actual worry, but I like my code lean both on the front end and on the back end. The less there is, the less there is that can break, and the faster things load on days when I don’t have a fast, reliable internet connection. 🙂

    – Need better handling of empty blocks. I added a Vimeo block without actually inputting an URL, and once published, the front-end view shows simply “undefined.” Better to have a conditional check – if there’s valid content there, display it; else just skip that block.

    – Will it eventually be possible to add a Menu block?

    – How does one create a widget that will work in Gutenberg? Right now I have custom widgets from various plugins, and they do not appear in the available blocks, even though I can add them from Appearance > Widgets. Is there some form of sidebar I have to add to the Gutenberg layout before I can access non-Core widgets?

    All in all a solid start, and I appreciate that the team is doing small iterations and soliciting feedback throughout the process – this will give Gutenberg the best chance of success, versus developing everything without outsiders, then having to scrap the whole thing.

Viewing 3 replies - 1 through 3 (of 3 total)
  • One other oddity – I noticed the Featured Image gets added to the bottom of the_content() inside an HTML comment. Hopefully that’s just temporary, while this is in early development. I would still expect the theme to determine if, and where, to display a Featured Image per post type.

    Plugin Author Tammie Lister

    (@karmatosed)

    There are a lot of things to be worked out. Columns for example aren’t decided fully yet. For now, we have text columns and the layout side of those would come when the Customisation focus kicks in. Gutenberg is about the editor flow, not about the page layout and building. This is where things like menu blocks will likely fall.

    You mention about theme developers, the plan is to begin with having some ‘add_theme_supports’ but yes having themes decide what is on/off could be an option. This could become confusing for users so it’s ‘how’ and what can be a balance there.

    Drafts will save automatically, but you can also in the top left click to save them.

    Dashicons is a community supported project, so I’m kind of keen to see where that goes. There is a great team involved in that.

    Your Vimeo issue, could I ask a bit more about the browser you are using? This sounds like a bug to me and I’d love to dig deeper. If you could report it here: https://github.com/WordPress/gutenberg/issues that would be great. Alternatively, please give some more details and I’ll make a report.

    With regards to widgets, I would suggest you look at creating a block as these will likely become more expected than widgets (and potentially more range). There are some good documents to start looking at for creating blocks: http://gutenberg-devdoc.surge.sh/

    Thanks, Tammie. I’ve submitted an issue thru GitHub for Vimeo.

    I know it’s still early in the process. Is there a website or other location where I should check to find updated information on how metaboxes will be handled? In addition to Yoast, we’ve got some ACF relationships that we use for Related Posts. The relationship shows up above the editor, lists specified post types, and allows us to choose a set of related posts/pages/CPTs. When the post is saved, all of the posts that were chosen as related are also updated and get postmeta that shows them as related to all of the others. In this way, whenever a user edits any of the related posts in a group, the whole group is also updated, so site visitors who go to one page will see a Related Posts section with links to all the others – on all of the posts – so they can easily navigate among them.

    This doesn’t feel like something that would work well as a Block, because Blocks seem to be saved in the post content rather than postmeta. I would hate to try to code something that edits all of the related posts and auto-guesses where to insert the relationship – let alone, when we change existing related groups, trying to figure out which part of post content to remove when a post is no longer marked related. It feels like postmeta is still where this information would need to live. But, how to surface a UI to add and edit this postmeta is the question. 🙂

Viewing 3 replies - 1 through 3 (of 3 total)
  • The topic ‘Good start, still a long way to go’ is closed to new replies.