As of May 2018, WordPress runs ~30.7% of the internet. For better or worse, it’s going to be hard to ignore the impact Gutenberg will have on the web when it officially launches. The new feature is being teased to the public now, and though it’s nowhere near a stable final release, its adoption rate is growing exponentially and WDS needed a game plan to ensure we’re not behind the curve.

Pre-Planning

In August 2017, during one of our weekly leadership calls, the topic of Gutenberg was brought up. Everyone thought the project was a bit premature to start building on top of. We discussed the possible future implications but weren’t ready to give the idea of building our own custom Gutenberg blocks any serious attention. Gutenberg had just barely been announced, and like many suggested features, its future was uncertain. So it was tabled for several months.

Four months later, WDS named Greg Rickaby to the position of Director of Engineering, and by this time, Gutenberg had become the biggest topic in the WordPress space—there was no ignoring it.

Greg spoke with Cristina Holt, our Director of Project Management, and the initial thoughts were to approach Gutenberg just like a client project and pitch it to our CEO, Brad Williams, and put the full weight of our talented developers behind the project.

“First we needed to train our engineers and project managers,” explains Greg. “Second, we had to come up with a development plan and schedule, then finally put together a project team. It took a few conversations with leadership, but Brad and Lisa eventually agreed to let us move forward with the ‘WDS Gutenberg Project.’”

Once the project was approved, Cristina and Greg assembled a team which would be led by Lead Frontend Engineer, Corey Collins, and Lead Backend Engineer, Kellen Mace. The engineering team was rounded out by Jo Murgel, Eric Fuller, and Will Schmierer.

Our first release was to replicate or replace components such as Heroes, Cards, and Calls-To-Action. These are components that are commonly used by our clients on typical website projects and are already included in our starter theme, wd_s. We call these “Global Content Blocks” and they’re powered by Advanced Custom Fields’ “Flexible Content” feature.

The Training Plan

Zac Gordon has been leading the charge on educating WordPress developers since Matt Mullenweg so famously said, “Learn JavaScript, deeply.” We purchased Zac’s Gutenberg course (now called WordPress Block Editor) over at https://javascriptforwp.com/. After all, the best way to learn anything is to immerse yourself.

Each of our engineers was scheduled some time to take the course. Once they completed their training, they could get spun up on WDS Blocks.

The Development Plan

While training, Kellen Mace had read about Ahmad Awais’s Create Guten Block on Github, which bills itself as a zero-configuration toolkit for spinning up Gutenberg blocks. He proposed using it to provide the foundation for our WDS Blocks project. Finding this toolkit was honestly a relief, as the thought of scaffolding the project and configuring Webpack from scratch wasn’t something any of us really wanted to do.

We also needed to provide greater advanced settings for each block including the ability to change the background decoration (image, color, video), add some visual flair (animate.css classNames), and a few other options to provide greater control to users beyond what is inherently available from WordPress out of the box.

Our blocks needed to provide a simple and clean backend experience with a fairly generic theme-friendly frontend render. For release 1.0 we ended up working toward a hero, call to action area, recent posts grid, manual-select related posts grid, a dual-column layout, and a gist embed. Since then we’d added several updates to these blocks and a users grid block with room to grow going forward.

The Result

Like most stories, the journey is far more interesting than the end result. We learned a lot about what Gutenberg can and can’t do, why they chose React.js, and why they added an abstraction layer.

Utilizing Gutenberg’s Inspector Control tools, we were able to create a set of Background, Text, and Other Options that we could easily replicate across all of our blocks. We even wrote about it so we could share what we learned and how we were able to keep our code DRY in order for our options to be as easy as possible to implement in new blocks.

Despite the insistence from WordPress themselves that aMultiSelect component wasn’t necessary, Issue #1044, we found the use case for such a component important. So we built one as a part of our recent posts and users grid blocks.

During the rest of our development, we found ourselves needing to reuse bits and pieces throughout our blocks. In addition to creating seven new blocks (plus a default block to copy from), we also created 10 new reusable components! These cover Options noted above, post search, and MultiSelect amongst others. Being able to create standalone components, and control their output at the component level, helps us keep a clean and consistent codebase across all of our blocks.

Based on the way Gutenberg is built and how it renders markup to post_content there was a problem with creating dynamic or non-static blocks that needed to be worked out. More on that at the WDS Blog: WordPress Gutenberg — Arrays, Attributes, and the Fundamental Flaw – WebDevStudios.

Initially, our plan was to render all of our blocks via PHP because we ran into issues when updating the markup for blocks. For instance, when rendering in JSX, if you were to add a className to your block container, you would receive a popup in the post editor informing you that your block was no longer valid, and the new className would not be present on the front-end. After some digging, we were able to realize that Gutenberg’s deprecated function was exactly what we needed. This allows for you to make changes to your block, to have those updates visible on both the backend and frontend of your site and to avoid the “invalid markup” popup after changing your block’s markup. You can read more about Deprecated Blocks in the Gutenberg Handbook.

Finally, WordPress provides a feature for styling both the front and backend render. Before Gutenberg existed, you’d have a simple text-based WYSIWYG editor with no real indication of how the content might look on the front end. Appending theme styles to a WordPress Gutenberg Block has never been easier, with its shared styles allowing for a user experience which more closely resembles that of the frontend.

The Future

This is just the beginning. Every release of Gutenberg unveils changes in functionality, bug fixes and deprecated features forcing us to keep up with testing and look for additional functionality that can improve the user experience.

We plan to use WDS Blocks as a starting point for new website projects, providing many of the common blocks that our clients will likely need, then add to those any project-specific blocks.

We’ve opened the repo to the public and encourage everyone to get involved with the project. We welcome your help as we work to build out a library of powerful and useful blocks that take full advantage of WordPress’ new editing experience.

The post The Journey to 1.0 — WDS Blocks and WordPress Gutenberg appeared first on WebDevStudios.

Now, before I go down this road, the flaw of which I speak isn’t broken code or something that was just missed during the initial scaffolding. It’s a result of the way that Gutenberg, React.js, and its extraction layer work together to get the job done. Specifically, it’s how Gutenberg sets attributes and renders content to the page and updates post_content.

The Standard Block

Let’s walk it through the way that a standard field works. In this example, we’re looking at the default Cover Image block. The field itself allows you to upload a background image and add some text. This block has several attributes to handle alignment, some special features, brightness, etc, but the elements we’ll look at here more closely are the attributes that handle the title, URL, and ID.

When we save our post, the block renders the field HTML to post_content. The strings (URL and ID) are saved into the block comments as an object accessible after the fact using a library called GitHub – aduth/hpq: Utility to parse and query HTML into an object shape.

So we can see above that the URL and image ID is added to the comment and therefore we can access those again later using JavaScript of the PHP render_callback function.

But what about our title, which is an array? What happened to that?

The title array was rendered as HTML, formed by the block’s save function, before it was saved to post_content. Awesome. It does all the dirty work for us, so there’s no need to manually parse array objects or duplicate additional markup later on. So where’s the downside?

This might be a matter of semantics, but I find it problematic that we’re unable to access the title attribute after the block is rendered and saved to post_content. This is especially important when using the render_callback function which has a save function return a value of null or save: () => null in order to access the attribute outside of the block in our plugin or theme’s PHP.

In this example, without a save function rendering HTML that would then be saved to post_content there ends up being no saved title attribute or HTML markup in our post_content—no empty array, no value whatsoever.

When we set our save function to null as above, we run with the assumption that we are going to take advantage of the function render_block( $attributes ) which gives us access to our attributes via the $attributes variable. The value of which would be equal to ONLY our url string and our id integer. We cannot access our title attribute since Gutenberg renders all arrays into HTML (assuming a valid save function) or disregards it entirely upon save, as in our case.

At this point, there are probably two questions. First, what if I don’t want to utilize PHP with my block? Second, why does it matter if our jsx is handling the render for us, everything it just handled?

These are both valid questions. You certainly don’t need to use PHP to render your block. There are pros and cons for this method which I won’t get into, but it’s not required. And you’re right, if we are just supplying data that needs to be rendered to HTML, there’s no reason we even have to worry about our title attribute array being lost during render.

Enter a practical use case: any dynamic block that utilizes state. A block that simply requires an input of some text or a string or some content doesn’t require any state. You can rely on the block, rendered content, and updates without any fuss. But if you’re perhaps querying posts, for example, selecting posts to display in a drop-down or multi-select block, once you save that output might get rendered to HTML and therefore render to the page. But if you were to refresh or open the post once again, you might find the block to be empty or broken. This is because the expectation of the block is that of the rendered HTML, but the actual output is more likely a drop-down, some HTML or js that doesn’t render the page. And because our array attribute is empty because the value was rendered to post_content we can just access the array attribute to repopulate our dropdown and selections.

So, to back up a bit…

Let’s run through the process here.

Our title attribute is an array using the <RichText /> component here. It generates an array of values, tags, potentially multiline elements, and some other various values, a simple example would just be an array of strings:

When we save that value gets removed and converted into our HTML based on other options supplied to the <RichText /> component:

Which ends up returning our title attribute to its default state or:

So if we were to try and re-access this.props.attributes.title the value would be our string until save at which point it would be an empty array. If you rely on this content to render a field that differs from the rendered output, you will find you’re not going to be able to do anything.

Enter a fix

While working on the WDS-Blocks Related Posts block I needed to solve this same problem. The content rendered on the front end by the save function would only match one part of the admin functionality, the display of posts. The multi-select block and specifically selectedPosts would not have any attributes to reference. This is a dynamic block with multiple working parts. By default, it would seem that Gutenberg intends the rendered content and the admin content to be identical. It does not anticipate more robust functionality.

On refresh, the block would be reset because our selectedPosts array attribute was emptied to render our HTML. I needed a way to access this data after the fact.

This may be a little convoluted, but the solution works. What I did was add a second attribute string.

That string would be identical to our selectedPosts array prior to save that had been run through the JSON.stringify( props.attributes.selectedPosts ) function to render it to string. We can then re-access our array of selectedPosts by parsing that with JSON.stringify( props.attributes.selectedPostsJSON )

On page refresh, or revising the post/page, our selectedPosts attribute may be an empty array, but we still have a set of saved data in our attributes we can utilize to repopulate the state of the block. The post_content ends up looking like this, in the case of the Cover Image block:

We can see our title array now accessible within the JSON string appended to the block comment object.

If using the PHP render_callback function, the JSON would be available as an option in the $attributes variable.

It would be better to just save attributes to post_content or post_meta out of the box, but this at least gives us a new way to use our information that Gutenberg hasn’t provided us with. It might not be the most efficient, especially if you’re dealing with full post objects, but a string, in general, is far more efficient than an array or object and there are ways to make our JSON data more efficient before it makes its way to post_content.

So what do you think?

Can you see this being useful? Are you aware of a better way to save and utilize arrays within Gutenberg? I’d love to hear about it.

The post WordPress Gutenberg — Arrays, Attributes, and the Fundamental Flaw appeared first on WebDevStudios.

What Is Gutenberg?

Named after a revolutionary publishing invention that changed the printing industry, Gutenberg is a big upgrade that will be a part of the WordPress 5.0 release this spring. It is a significant enhancement to the editor; and in the context of WordPress, the software that currently powers 30% of all the websites you view on the internet today, Gutenberg is a brand new editor that allows you to create and publish blocks of content. Users will now have more control over the layout of their content, rather than just writing and a publishing a single article.

An update like this is huge. The WebDevStudios team has been in the preparation and planning stages for Gutenberg and the effects it will have on our clients’ websites and our own sites for several months now since it was announced in early 2017.

Working with Blocks of Content

WDS has been building client sites like this for several years, utilizing blocks of content that can be used and reused in various areas of a website in order to simplify a client editorial workflow and provide them with finite control over what content is displayed on their website and where. This has always been accomplished with plugins like ACF, CMB2 and customized development around the meta fields core feature of WordPress. With this previous experience and real-world knowledge and application, our team already feels prepared to work with Gutenberg and familiarize our clients with it.

Gutenberg Preparation and Internal Training

During the State of the Word in 2015, Matt Mullenweg announced that we should all “Learn JavaScript, deeply.” because it “is the future of the web.” We took that to heart and have been putting a larger focus on JavaScript training internally. In preparation for the release of Gutenberg, our team of Engineers has been taking various online Gutenberg and React training courses. We have plans for continuing education and training leading up to the first official release of Gutenberg in WordPress.

To get an idea of what Gutenberg looks like and how it affects the way users will interact with it, we recommend watching this demonstration of the tool from December’s WordCamp US.

Meet WDS Blocks

We have assigned Corey Collins and Kellen Mace as our internal Gutenberg Leads. Corey and Kellen have been creating the groundwork for our internal WDS Blocks framework.

In preparation for Gutenberg, our Engineering Team has been hard at work on creating a framework that we are, internally, calling the WDS Blocks project.

We have already done this with other plugins, like ACF and CMB2, by wireframing out a default frontend experience, coupled with the required engineering to make it all work together to standardize content blocks that are utilized on many websites, such as:

• Hero / Header modules
• Content Grids
• Carousels
• Sliders
• Photo Galleries
• Embeds
• Pull Quotes
• Call To Action blocks

Our Stance on Gutenberg

One of the reasons we love WordPress is the solid foundation that it creates for all web development projects. The WordPress Core software allows us the ability to extend and customize as necessary for every website project we support. Gutenberg is an exciting new way to create and manage content in WordPress. This new feature ships with some great core blocks and, of course, we can easily extend Gutenberg to give our clients a truly customized experience that fits their needs exactly. We are very excited about the future of WordPress including the new content experience provided by Gutenberg.

How Will Gutenberg Affect Existing Sites?

One question that comes up frequently is how will Gutenberg affect existing WordPress websites? The idea of any WordPress core feature affecting your existing and future content is a scary one. At WDS, we are taking a proactive approach to the Gutenberg release. We are currently creating integration plans to review with all of our current clients. These plans are very specific to each client’s current website setup and content editorial flow. Some of our clients will be able to use Gutenberg on day one, while others will need a lengthier integration and rollout plan.

Is Gutenberg right for everyone? Not every feature of WordPress is right for everyone. Most content creators will be able to leverage the power of Gutenberg and content blocks on their website. While this powerful new content experience is an amazing enhancement to WordPress, it’s important to use the right tools for the job. At WDS, we work closely with all of our clients to architect the best WordPress experience to hit their project goals.

The Future of WordPress and Gutenberg

Gutenberg is a sign of the growth and potential of WordPress. More than a blogging engine, WordPress is quickly becoming the website platform of choice for eCommerce, mass media conglomerates, enterprise-level corporations, and small businesses alike. We believe Gutenberg will continue to develop and empower website owners and companies to have more control over the look, feel, and experience of their website. As WordPress begins to take over more of the market share of the web, we see Gutenberg as a vehicle to drive this expansion, and our team at WebDevStudios is ecstatic to be a part of the ride. We invite you all to join us on this journey.

The post WebDevStudios, Gutenberg, and Planning for WordPress 5.0 appeared first on WebDevStudios.