WordImpress: Impressive WordPress Plugins and Support
WordPress experts providing top-notch plugins for your website. WordImpress means Impressive WordPress plugins backed by rock-solid support.Besides that, they are documenting their experience on the blog by giving you tutorials, tips and interviews with WordPress developers.
Gutenberg is the future of WordPress, but you don’t need to be a developer to help shape it. So how do you contribute without code?
As a WordPress Engineer and part of the team behind GiveWP, I’ve been closely following the development of the new Gutenberg editor. While I write code in the WordPress ecosystem every day, my contributions to Gutenberg thus far have been decidedly code-free, as I’ve instead focused on testing and leaving feedback in the project’s GitHub repository.
In open-source software, providing feedback without execution is often interpreted as laziness or entitlement, but when done with respect and the right intentions, feedback can be just as valuable as the code that results.
Contribution vs. Execution
In sports and in many other aspects of life, the concept of affecting change without executing change is accepted without question. Whenever we credit coaches, teachers, or family members for our success, we are acknowledging that their intangible contributions played a vital role in our outcome.
For example, nobody doubts the contributions of Pittsburgh Steelers coach Chuck Noll even though he never played a snap of football during his four Super Bowl-winning seasons. Of course the coach’s strategy, foresight, experience, and motivational ability had a clear impact on the team’s success. He contributed without executing.
Sadly, when it comes to software development, we often limit our definition of contribution strictly to code-related activity. Too often the amount of code committed to large projects like Gutenberg is used to evaluate the worth of an individual. While code contributions are obviously essential to the success of a project, so too are the conceptual contributions that shape how and why the code is written in the first place.
(Not) Representing the Opposition
In a recent conversation about Gutenberg with my friends Matt Cromwell and Josh Pollock, I took on the role of “The Opposition.” I suppose I earned this title when my opposing views on Gutenberg’s meta box support found their way onto WP Tavern. While it’s true that I have strong opinions on the subject, I care much more about the wellbeing of the community — the Humanity of WordPress — that I remember Rich Robinkoff describing at my first-ever WordCamp.
Opposing views provide a necessary system of checks and balances in open-source projects, but the success of this system relies on a spirit of collaboration, not merely criticism. If my feedback has had any impact on the project, then I credit it to a conscious effort to respond passionately while never losing sight of the humanity behind the screen.
The Right to React
While I can’t always commit code, I can still influence the decision-making process of those executing change. I can lend my experience, my foresight, and my advice to those more capable than I am.
In other words, while I may struggle to write “hello world” in React, I still have the right and responsibility to actually react.
Stirring the Pot with Respect
When contributing to a project without code, it’s important to carefully consider one’s first impression. Be direct, objective, and provide actionable feedback. While you may not be the one to implement the solution, you can still set the wheels in motion.
From the team’s perspective, you may appear as a stranger barging into a project in the middle of development. Remember they’ve put in their time; you haven’t. Keep the following in mind and slowly but surely you’ll begin to settle in with your fellow contributors.
Be respectful, always.
Assume the best in people. Someone contributing hundreds of hours to WordPress is probably in it for the right reasons.
Lead with the good, or at least the acknowledgement of good intentions.
Criticize ideas, code, and pixels, not the humans behind them.
Provide rationale. Don’t like something? Explain why and be specific.
Imagine speaking to your subject in person. If you wouldn’t say it to their face, don’t press Comment. Breathe. Try again.
We’re in this together. Use “we” and “us” instead of “you” and “they.”
Be conscious of your feedback velocity (the number of replies over time). Give others a chance to chime in.
Make it worth their time, every time. The emails, notifications, and alerts that your feedback triggers all have a cost. Is it worth it? Does it bring value?
You’re only as good as your last response.
To the Gutenberg Team:
I’ll be the first to admit I haven’t always followed these rules verbatim, but I will—and we as a community should—do better. We should not only contribute, but also defend your contributions when outside criticism crosses the line into vitriol. Again, we’re in this together.
To the WordPress Community:
You have opinions—smart, valid opinions worthy of contribution whether they are accompanied by code or not. I encourage you to speak out when you disagree, endorse ideas when you do agree, and don’t be afraid to be the opposition every once in awhile.
After all, even the most talented chefs need someone to stir the pot.
I chatted with some prominent plugin authors, page builder authors, and Gutenberg contributors to understand how Gutenberg could impact the broader WordPress ecosystem. This article discusses how it can impact content authors, plugin authors, and page builder plugins in the near future.
Gutenberg is the proposed new content editor for WordPress Core. It is currently in beta development. It is a radical departure from the simple WYSIWYG (what you see is what you get) approach WordPress has traditionally had for content creation. As with any major change in WordPress, this will inevitably have ripple effects throughout the WordPress marketplace. With that in mind, here’s my take on how Gutenberg will affect the broader WordPress ecosystem.
The Awesome for WordPress Content Creators
From everything I’ve seen, the main motivation — primarily from WordPress co-creator Matt Mullenweg — is to dramatically improve end users’ experience with content creation in WordPress. With the advent of website builders like Squarespace and Wix, a cleaner WYSIWYG in Medium, and the plethora of full-featured page building WordPress plugins, the simple post editor has started to feel downright antiquated.
From all looks and appearances, Gutenberg is aiming to be the content creator of the future for WordPress. It’s not an interim improvement to the post editor — it’s a full-screen replacement for the entire post edit screen — en masse.
But will such a dramatic change actually help users or simply overwhelm them? Ideally, the Gutenberg editing experience should help users write better content with better search engine results. With that in mind, I asked a few folks who know what it takes to write great content in WordPress what they thought of Gutenberg and its potential.
Joost de Valk is the founder and creator of Yoast SEO — a plugin used by tens of millions of WordPress sites. I asked Joost if he thought this puts a giant wrench into his plugin or whether it opens new opportunities for the plugin and its users. In a word, Joost is excited.
Joost de Valk
Founder/Creator of Yoast SEO
“We love what Gutenberg means for the future of WordPress. The new editor experience comes with some new concepts around the publishing experience.
An example of one of the new concepts discussed for Gutenberg is a pre-publishing workflow, that allows for an intermediate step between being done with writing your post and actually having your post published. We’re actively thinking about integrating our snippet preview there.
The concept of “little blocks” also allows for a deep optimization of how we analyze post content, as instead of analyzing the whole thing, we can do it block by block. This also means giving feedback at a block level.
In all, we’re excited about the opportunity to reimagine one of the most important aspects of our plugin.”
This is good news for content writers, marketers, and advertisers. When each “little block” of your content can be customized you have more control and that ideally means better results as well.
Our own Marketing Manager, Bridget Willard concurs that if Gutenberg encourages better semantic writing, then it’s a win for content authors:
Marketing Manager at WordImpress/GiveWP
“Gutenberg changes how a user interacts with the CMS, not how the content is read by Google.
When a user is less intimidated by adding content (writing and publishing) there is potential for better and more frequently-published content. If the heading structure is more intuitive with Gutenberg, that would definitely be a plus for SEO — which is basically findability.”
But as they say, “with great power comes great responsibility.” Just because Gutenberg enables you to write all kinds of awesome things doesn’t mean you should either. SEO and Marketing pro Pam Ann Aungst warns that having more power over your content doesn’t replace the need for professionals like herself.
Pam Ann Aungst
President at Pam Ann Marketing
“I haven’t used it yet myself, but any kind of DIY functionality scares me from an SEO perspective. This could make it just too easy for clients to bloat their posts full of slow-loading ‘rich content’ and do things that go against SEO best practices like adding in multiple H1 tags.
I also am always weary of pagebuilder-type things like this because they tend to bloat the code, which also brings down page speed. And I can imagine that compatibility with AMP is either too far out in the future, or not even on the development radar — which is also concerning since most of what Google pontificates about lately is fast load times on mobile.
Overall, I’m a bit of a purist when it comes to technical SEO, so unfortunately, I’m more concerned about this than I am excited.”
Pam’s concerns are valid for sure. It wouldn’t be wise for WordPress to put a bloated page builder into core, or make AMP integration more difficult. Based on what I’ve seen from the code so far, Gutenberg doesn’t add anything additional to the front-end (except a tiny stylesheet as a basis for its layouts). Further, Gutenberg doesn’t make additional h1’s easier than currently with TinyMCE, so generally I think this will evolve to be something SEO Pro’s like Pam can eventually embrace. I think Pam and other SEO auditors and Pros are safe even if they might perhaps have more nuanced work to do; which also could be a win for them.
Generally speaking, it’s fairly clear that there is a lot of opportunity here for content writers and marketers. Gutenberg generally seems to be on track to meet these needs.
Reactions from Plugin Authors
While content authors might be already rejoicing, a lot of plugin authors are feeling hesitant and are experiencing trepidation. This comes primarily from the fact that they’ve been arm-wrestling TinyMCE into submission for years and they’ll have to reimagine how they can integrate their plugin into this new interface while supporting customers who might be totally lost. This doesn’t even factor the customers who are not on the current version of WordPress who also need support.
There is interesting insight on the Github repo for Gutenberg in this regard. The discussions around how it will support Custom Post Types and Custom Meta Boxes are complex and thoughtful.
Meta Boxes In Gutenberg
This ticket is advocating for an “Extended Settings” section that will render all the PHP-based meta boxes in a static area at the bottom of the content screen. Personally, that would be a horrible user experience — but like I said, it’s the conversations around that question that are fascinating.
Gutenberg and Widgets & Shortcodes
Another big question is how will Gutenberg deal with widgets and shortcodes? This ticket focuses primarily on the WordPress Core widgets but the implications for plugin widgets are pretty extreme. This quote from Joen Asmussen is particularly revealing.
Code Wrangler at Automattic
“The block, combined with the inserter, are both intended to be evolutions of the shortcode interface.That is, the block can offer the same as and more than the shortcode can, and the inserter is a unified level playing field for inserting them in the content.”
So we might be looking at the end of hard bracket shortcodes as we know it. Personally, I say “Hallelujah!” Shortcodes are a terrible user experience particularly when a minor misspelling or missing character results in ruining the output completely. Generally speaking, plugin authors might question how much work it will be to re-code their shortcodes. I expect the Gutenberg contributors will ensure that registering new blocks would be as relatively straight-forward as registering new shortcodes. Meaning, it wouldn’t be all that much work in the end, only a matter of implementing your new block settings for the user to interact with in Gutenberg instead of memorizing shortcode attributes.
One criticism I’ve heard (and shared) from several developers is how Gutenberg identifies its blocks from a markup perspective. John James Jacoby first brought this to my attention. I expected well-defined markup; but instead, Gutenberg is using inline HTML comments to wrap block elements. What!? Here’s his summary of the problem:
John James Jacoby
Core Contributor & Lead Developer for bbPress and BuddyPress
“I feel very strongly that inserting HTML comments into post_content is a decision that would be deeply regrettable later. It’s extremely clever, and neat, but I am afraid of what problems plugins, themes, and core formatting functions will uncover… We’d be deciding that the very-best we can do is invest heavily in a bespoke data format with a loose set of conventions chock-full of compromises due to legacy schema restrictions, and we know how that song goes – it’s not good for anyone, and we’d have a hard time being convinced that it is a good idea if it weren’t our idea.”
He said it so well. But John’s solution is that each block would be saved like a child_post relationship and would have its own individual post_meta as well. Personally, I think that’s overkill, but I am concerned about the level of HTML markup not being consistent with either Best Practices or the WordPress Way. After all, Open Source is not just about democratizing publishing, it’s about educating future developers. This markup would be leading them astray, and that’s putting it mildly.
To get more insight, I contacted Weston Ruter. We both joined the WPwatercooler for a discussion on Gutenberg. I asked him afterward about the decision to go with HTML comments.
This is what he said:
Gutenberg Contributor & CTO at XWP
HTML comments are used for encoding blocks for the following reasons, that come to my mind:
(1) Shortcodes were extensively used in unanticipated places, including HTML attributes, because the bracket notation didn’t enforce any limitations. By using HTML comments, however, there is a guarantee that the tags will only ever appear outside of HTML elements and thus can be reliably parsed.
(2) There are existing HTML comments that are already used in post content in WordPress, including < !--more-- > and < !--noteaser-- >. So blocks are following that pattern.
(3) Plugins can introduce their own blocks. When these plugins are disabled, any of the plugin’s blocks will then just be hidden or rather the underlying fallback content contained inside the block will then be displayed. This is in stark contrast to shortcodes which then show up everywhere when the shortcode is no longer recognized.
(4) HTML comments are resilient when post content is manipulated by other editors, including the classic WP editor or editors in other apps. They won’t get stripped out, though they also will be invisible.
Overall, those are all fair and reasonable points that I wouldn’t have considered at all. Further, a big part of John’s goal with child_posts is portability of blocks. The discussion is already happening about how that might be accomplished as well.
Gutenberg and Plugin Authors
Generally speaking, the plugin authors I’ve spoken with dare optimistic about and eager to see how they can make the most out of what it has to offer. For example, Adam Warner of FooPlugins likes that Gutenberg will allow plugin authors to make their features more apparent via the Insert feature, saying that
Co-Founder at FooPlugins
“Making sure we have our plugins tightly integrated will be key for our continued growth, but more importantly, it gives us the chance to offer our features front and center within a more cohesive content creation experience.”
Josh Pollock said he agrees with everything Gregory says and added to the discussion in his own article at Torque. Josh’s overarching concern is that Gutenberg can’t promise the highest level of backward compatibility that has made WordPress as successful as it has become. If backward compatibility really is ruined with Gutenberg, then it would be detrimental to WordPress as a whole. At this point though, I have faith that the Gutenberg contributors still ascribe wholeheartedly to the WordPress Philosophy of backward compatibility 100%.
Page Builders and Gutenberg
The challenge Gutenberg presents to page builders is the elephant in the room. Will Gutenberg gut and destroy all these major page builder companies that have banked on being the end-all-be-all of content and layout customization in WordPress? My short answer is — it depends.
It depends largely on the page builder in question and how they pivot. When chatting with Weston Ruter he mentioned that the Gutenberg team has been intentional about reaching out to page builder authors, like Beaver Builder, in order to learn from their insight and experience, as well as to prepare them for what’s coming.
In terms of the conversation around Gutenberg and page builders, this Github issue is really instructive. You can see the questions generally revolve around either toggling between editors (meaning they would not be integrated with each other in any reasonable fashion) or that whenever a “text editor” block is used in the page builder that it would be a Gutenberg instance. As of today though, the mock-ups being produced are primarily about having an either/or experience with page builders.
I reached out to Robby McCullough from Beaver Builder and he had this to say:
Co-Founder at Beaver Builder
I like the idea of standardizing and modernizing shortcodes and widgets. I’m excited about it. I think adapting to change is always tough, but there’s lots of potential for us to leverage Gutenberg and vice versa. Shared blocks and such.
That part about “adapting to change is always tough” is the thing that will set folks like Beaver Builder apart from other page builders that will just die away.
Another factor is the nature of the builder itself. For example, Divi Builder has a huge user-base, but it’s also very tightly integrated with the Divi theme itself. With that amount of coupled control (functions inside a theme), they can do what they want with Gutenberg. But seeing it as a challenge and opportunity would be the smart move. The only problem with that is that I have no idea what coupling Divi with Gutenberg would even look like. Also,who in their right mind would want to work with that?
Tailor is a relatively new page builder that was developed intentionally simple. In many ways, it does what Gutenberg is now doing. I have a hard time imagining Tailor surviving Gutenberg — but I could be wrong.
Elementor is another one that has come to prominence recently. They have a relatively smart way of interacting with existing widgets and shortcodes. They could also easily pivot with Gutenberg, but it all depends on how they manage that pivot and that user experience.
Overall, Gutenberg could very well be a radically new content writing experience for many WordPress users. But that doesn’t mean everyone wants to use it or that everyone should be forced to use it. Allowing a natural and programmatic way for users to choose to edit their content with page builders instead of Gutenberg is a good idea. I hope that happens with finesse.
How to Stay Informed with Gutenberg Progress
If you’ve read this far, you must be really invested in Gutenberg — bravo! One thing you should have picked up through it all is that there still is a lot to be determined. It’s still very early in development of Gutenberg at this time.
Quite honestly, I think it would have been more helpful to call this release an Alpha rather than a Beta simply because many very significant and important features and code architectural questions have zero consensus still. That’s a really important aspect of this whole discussion. We are having this discussion now simply because of how much impact this new feature could potentially have on WordPress as a whole and that it might even make it into Core by the end of this calendar year.
With that in mind, if you are interested in keeping up on Gutenberg progress, here are the best places to do that:
Download and test it here but not on a live or production site. Updates are pushed there so you’ll get them as soon as they are stable and available.
Gutenberg Github repo is where actual code is happening and all issues are being publicly discussed there as well.