Interactive WordPress blocks refer to blocks that enable user interaction or engagement directly within the content. These blocks can include elements like forms, buttons, polls, quizzes, and more, allowing visitors to interact with the content rather than just passively consuming it.

Let’s dive headfirst into a GitHub treasure trove of interactive WordPress blocks. Some may be old, some are new, but nevertheless, there are some interesting finds if you are willing to search.

Quick note, though: in general, it’s recommended to stick with plugins and blocks that can be found in the WordPress Plugin Repository. This plugin marketplace is more than convenient; it has proven to be essential to a great WordPress experience. The repo helps ensure a higher level of quality control.

Below are some fun, interesting, interactive WordPress blocks available on GitHub. These particular blocks exemplify the power of WordPress and where we can expect future WordPress blocks to take us.

Apple Maps Block

The past is the past, and you’re ready to give Apple Maps another chance. Good for you! Apple Maps has been quietly improving and offers a pleasant and modern design and experience. The Apple Maps Block plugin gives you the option to add an Apple Maps interactive WordPress block to your site. This plugin does require you to have or create Apple MapKit credentials. Find it on GitHub.

OpenStreetMap Block

The OpenStreet Map Block allows you to select different tile layer providers like OpenStreetMap, Mapbox, or Stamen, so it has a unique flexibility. You can also adjust map behavior through import/export location data. Unlike Apple Maps, there is no API key required at this moment. There is also a setting for watercolor maps. Now that’s creative! Get the OpenStreetMap Black on GitHub.

Charts Block

The Charts Block adds a selection of colorful chart blocks to your theme. The Data for your chart can be adjusted in a CSV file and then uploaded. I found that these blocks worked better when inserted into a column block to contain the size. Find it on GitHub.

Chart Block

This plugin offers a chart block that can switch between different chart types, such as lines, bar, horizontal bar, and pie. Unlike the previously mentioned block, the Chart Block requires that you paste or type in your CSV data in a field.

I’m not sure how this would act with a large data set, but it should be fine for a simple chart. Go to GitHub to access Chart Block.

360 Image Block

This plugin allows you to add images with a 360-degree camera to be viewed and panned on your site. 360 Image Block even makes non-360 images feel a little bit 360. There is also a sister plugin that handles 360 videos. Find both 360 Image Block and 360 Video Block at GitHub.

Honorable Mentions

These interactive WordPress blocks are also worth checking out.

• Chatterbox – Text Message Bubble Block
• Syntax Highlighting Code Block

The post Block Party: Exploring Interactive WordPress Blocks appeared first on WebDevStudios.

But the compatibility landscape of WordPress 5.0 and beyond is much different. The new WordPress block editor Gutenberg is built upon React, and the development pace of React, Gutenberg, and all things JavaScript, in general, is extremely fast. I’m hoping this can serve as a reference or forewarning to those trying to keep up.

Gutenberg Versions

When you’re trying to build a Gutenberg block that is compatible back to WordPress 5.0, navigating this landscape is tricky. Since the Gutenberg editor is developed as a separate project, they have their own versions that get bundled with the major WordPress releases. Trying to find this historical information can be difficult.

After some research and discussion, Senior Backend Engineer, Sal Ferrarello, and Frontend Engineer, Mike England, started a compatibility matrix, which can be found on GitHub. But that didn’t answer all of the questions and solve all of the issues. The official Gutenberg Handbook itself is based on the latest Gutenberg code, which is ahead of the current version of WordPress. Sal opened an issue highlighting that the blocks API documentation is based off of the master branch of Gutenberg.

Block API Reference

Sadly, Sal’s documentation version issue wound up being closed citing:

We’re fixing bugs more than we’re introducing new APIs at this point.

But shortly after the version matrix was created and the version issue filed, a new page showed up in the block editor handbook highlighting the version information:

Versions in WordPress

Still, this “official” table can be a bit confusing. When you look at it, there is a range of Gutenberg versions included in a particular WordPress release:

This is because bug fixes are back-ported into the WordPress release bundle. If you’re using it for an API reference standpoint, always go with the smaller release number.

React Versions

There are several things to think about if you want to provide backwards compatibility to WordPress 5.0. One consideration is the React version included in WordPress.

If you want to create Functional Components instead of Class Components in your Gutenberg block, that requires React version 16.8. WordPress 5.2 is when React 16.8 was included. The easiest way I found to determine which versions of WordPress include which versions of React is to go to the source.

You can find the package.json for WordPress 5.2 here. This includes React 16.8.4. You can replace “5.2” with the version you’d like to investigate.

If you’ve written functional components for distribution in the WordPress.org plugin repository, don’t forget to add the “Requires at least” field to your plugin header:

/**
 * Plugin Name:       My Plugin
 * Requires at least: 5.2
 */

That way, people will not be able to upgrade/install your plugin automatically, unless they’re on WordPress 5.2 or newer.

Block Compatibility

My best advice is to tread lightly and go slowly. React and Gutenberg aren’t great at reporting where your errors are through the browser console. To start, I install the WP-Downgrade plugin so I can easily go back and forth between past and present versions.

If you’ve got something working, test it out and commit your changes. Then, test it for backwards compatibility. When you’re dealing with more than one compatibility error at a time, it’s difficult to hone in on what is going wrong. WordPress might not even load your Guten-block code if there are errors; and it also may not print a message in the console.

The most common issue I’ve encountered is with importing WordPress components. Sometimes things work by importing from a package. Sometimes they’ll only work by destructuring from the global wp object.

WordPress Gutenberg import versus Destructuring Global wp

You may have to experiment with both to see what works for maximum version compatibility.

Example: ServerSideRender

@wordpress/server-side-render

The documentation says once you include it in your package.json you can either import it:

import ServerSideRender from '@wordpress/server-side-render';

Or destructure it from the wp global:

const { serverSideRender: ServerSideRender } = wp;

But neither of those work in WordPress 5.0 (Gutenberg 4.6.1) because @wordpress/server-side-render wasn’t a package yet. It also isn’t at wp.serverSideRender at that time, it’s at wp.components.ServerSideRender.

If you want it to work in WordPress 5.0, you’ll need to destructure it from the wp global like this:

const { ServerSideRender } = wp.components;

In new versions of WordPress, you’ll get this warning message in the console:

wp.components.ServerSideRender is deprecated. Please use wp.serverSideRender instead.

The user may never see that, and it sure beats them seeing this in the editor:

Deprecation Hunting

Other popular components that have moved since WordPress 5.0 are BlockControls and InspectorControls. I’ve got them working in 5.0 with the following browser warnings:

wp.editor.BlockControls is deprecated. Please use wp.blockEditor.BlockControls instead.

wp.editor.InspectorControls is deprecated. Please use wp.blockEditor.InspectorControls instead.

But how did I find them? Going to the source is always best. Clone the Gutenberg project and check out the tag for the most recent version of WordPress:

git clone git@github.com:WordPress/gutenberg.git
cd gutenberg
git checkout v8.6.0

You can browse the tags on GitHub or list them with git tag. After checking out the tagged version, start looking for the component that’s not working. For InspectorControls I used grep to find it:

$ grep -r InspectorControls .
...
packages/editor/src/components/deprecated.js: 'InspectorControls'
...

There’s a lot of output when searching, but the path of the deprecated.js file gave me a clue: packages/editor. It used to be in wp.editor and is now in wp.blockEditor (which has the path packages/block-editor). Again, the documentation isn’t great, so you have to do some sleuthing and gather context clues.

Good luck out there, and always keep compatibility in mind!

The post WordPress Blocks Backwards Compatibility appeared first on WebDevStudios.

Well, depending on your coding preferences, you could build a frontend form to update post meta, or implement some custom jQuery with AJAX, or use a page builder with frontend editing capabilities. If, on the other hand, you’ve been experimenting with your own blocks and are looking for a way to update block content and attributes from outside the confines of the post editor, then buckle up, and keep reading.

Note: The example snippets in this post are modified from @ravewebdev/initiative-tracker, my Initiative Tracker block plugin for table-top role-playing games, which was built with @WebDevStudios/create-block, the WDS block scaffolding CLI tool.

1. Block Setup

First off, we’re going to cover some necessary block configurations to consider when diving into frontend block editing:

1. Unique block identifiers
2. Frontend rendering

1.1. Unique Block Identifiers

When you work with blocks in the admin, WordPress handles differentiating blocks automatically. That means, when you add multiple instances of the same block, you don’t have to worry that editing one will somehow change anything about another. They’re unique and self-contained.

Unfortunately, when messing around with frontend editing, we don’t have access to the built-in block attributes for uniquely identifying and reliably targeting a block, so we’ll need to roll our own:

View the code on Gist.

First, we’ll add a new attribute called id with the type string to the block configuration. In our block’s edit function, we’ll set our new id attribute to some unique string.

You have several options here, but in this example, we’re using the built-in clientId property, an alphanumeric string such as 1bb09bce-77a1-46ee-bff5-ad6e41b13f3e that uniquely identifies a block.

The actual string itself is less important than ensuring it’s both unique and only set once, at the time the block is created. This ensures you can reliably and accurately target the correct block and prevents the value from being changed or overwritten later on.

Without the latter, the id attribute could change on every load of the edit screen and/or every render of the block, which makes WordPress think you’ve intentionally edited the post content. This triggers the dreaded “Are you sure you want to leave this page?” popup; and, the next time the post is edited, potentially displays the autosave warning, “The backup of this post in your browser is different from the version below.” Both of these instances, you are probably very familiar with and often find them annoying if you do a lot of development work in the block editor.

So, let’s try to avoid that, shall we? That’s where useEffect() comes in.

Our block’s edit property is a function component, so we’ll utilize the Effect Hook to perform a side effect, which will set our ID attribute. By passing an empty array, [], as the second argument, we specify that this effect should only occur once, on mount, i.e., immediately following the initial render. For more information, check out the note at the bottom of the Optimizing Performance section of the Effect Hook doc.

But, we’re not done, yet! While the Effect Hook helps us avoid extraneous attribute resetting on every render, it will still run every time the edit screen is loaded. To ensure we only run it once, right when the block is created, we’ll perform a quick check via if statement to see if the ID attribute has already been set.

1.2. Frontend Rendering

Now, we’re getting into the actual frontend display of our block, but before we get into the fun (tricky? mind-melting?) stuff, we need to ensure we’re building a dynamic block.

Luckily, that’s as simple as returning null in our block’s save function (as shown in the previous step), which instructs WordPress to save the block’s attributes without any markup. Without this step, frontend edits to our block could break it, causing a validation message like, “This block appears to have been modified externally,” the next time we try to edit our post in the admin.

Of course, returning null means our block no longer appears on the frontend at all. So, we need to handle its rendering another way… with PHP! To do this, we’ll provide a render_callback function when calling register_block_type() for our block, like below:

View the code on Gist.

This callback function receives an array of the block’s attributes and returns a string of HTML representing our block. For the most part, the HTML output here should mirror the JSX we’d use to display the block with React.

For the purposes of frontend editing, there are two important data attributes we need to output in our block wrapper:

• id – The block ID attribute we created above.
• post_id – The current post (or page or CPT) ID.

Note: It’s a good idea to pass any other block attributes you’ll need as additional data attributes to help with rendering your block in React later on.

2. Frontend React

At this point, our (currently static) block should be displaying on the frontend. Phew! Next, we’re going to tackle re-rendering our block with JavaScript and JSX by implementing the following steps:

• Frontend React component
• Static block replacement

2.1. Frontend React Component

For the most part, we’ll want to rely on any components already created for rendering our block in the admin to render it again on the frontend; however, creating a new frontend-only component is useful as an intermediary. So, that’s what we’ll be tackling now.

View the code on Gist.

Here we’re setting up the basic function component that we’ll use as a wrapper to render our block on the frontend. First, we destructure our props to get our dataAttributes, which will be an object created from the data attributes we defined in step 1.2. Given how we’ll be rendering our frontend component, the initial props we receive above won’t update when we change things in our block.

Therefore, if we want to track changes between renders, we’ll need to use the State Hook, useState(), within our new frontend component. In this instance, we’ll be keeping track of our block’s attributes with a single state variable, attributes, as an object; although you’re welcome to refactor your code to use multiple individual state variables instead.

Similar to earlier when we set the block ID in the admin in step 1.1., we’ll again take advantage of useEffect(), passing an empty array, [], as the second argument to apply this effect only once. Here, we’ll override our new state variable, attributes, with the values we were passed via dataAttributes.

This ensures the initial values of our data attributes are reflected in our block’s state. Later, when we actually get into the process of frontend editing, we’ll update this state variable to track any changes to our block attributes (e.g., with an input’s onChange event).

At the bottom of our new frontend component, we need to call our pre-existing components (the ones we used in the admin to display our block). Here, we’re wrapping everything in a React Fragment (<>)  in case we have multiple components to display, but if you only need to call one component, you can remove the wrapping fragment to simplify the return.

2.2. Static Block Replacement

Now that we’ve gotten the basics of our frontend component set up, we need to replace the static HTML block we created in PHP. The code in this section will need to be placed in a new JavaScript file enqueued on the frontend of the site. And, as a bit of foreshadowing, make sure to add wp-api-fetch as a dependency for this new file; this will allow us to use apiFetch() to make our frontend updates later on.

View the code on Gist.

We’ll define the target class for our block, use it to retrieve all instances of our target block with document.querySelectorAll(), then iterate over each instance. For each instance, we’ll extract the block attributes from the data attributes we defined in step 1.2. For some of these data attributes, we may want to parse the values to get the necessary data format. For example, we’ve used parseInt() to retrieve the integer value of the passed post ID.

Then we call wp.element.render(), an abstraction of ReactDOM.render(), which takes two parameters:

• element: The element to be rendered—our frontend component—to which we pass the variable we just created, attributes, as the dataAttributes property value.
• target: The DOM container node we want to update—the tracker element—which represents the current instance of our custom block. Note: the element passed will replace all contents of the target container but not the container node itself.

Hooray! Our block is now being displayed dynamically with React on the frontend.

Next Steps

We’ve laid the groundwork in preparation for frontend editing with our block. We covered properly identifying a block instance, dynamic block rendering with PHP, then replacing our plain HTML block with a frontend React component. Let’s take a breather before diving into the WordPress Rest API and request fetching in Part 2.

The post How to Enable Frontend Editing with Gutenberg Blocks (Part 1) appeared first on WebDevStudios.

The goal of this blog post is to dive into the existing Gutenberg content blocks and document some useful examples for all skill levels. Let’s see what’s possible by simply configuring existing blocks to make clean, quick, functional layouts and spicing up your WordPress site with Gutenberg content block recipes. No code required.

Who benefits from Gutenberg Content Block Recipes?

Chances are, if you’re a WordPress developer, you’ve experimented with Gutenberg content blocks to some degree. However, if you’re like me, you’ve spent a good amount of time rolling your own custom blocks via JavaScript or ACF’s Gutenberg block-building features.

Anyone with a basic understanding of WordPress can build the following examples now. I hope that everyone from non-coders to engineers will appreciate how easy it is to build clean, simple layouts with these exciting features. Seasoned developers may come to realize that they can save time by opting for a solution that’s already baked in, or at least glean some inspiration for making your own custom block that functions in a similar fashion.

The Details

I’m using the Twenty Twenty theme for the remainder of this article. If you’re using Gutenberg content blocks on a different theme, the functionality should be the same, but the appearance will probably change. At the time of writing this, I’m using WordPress 5.3.2.

How to Add Gutenberg Content Blocks to Your Page

Content blocks can be found under the plus symbol on your post or page. Blocks are organized by categories.

Currently, the default categories in this order are:

• Most Used
• Common Blocks
• Formatting
• Layout Elements
• Widgets
• Embeds.

There’s a large selection of useful blocks, but these recipes below should give you a good starting point for exploring the possibilities.

Here’s a list of the Gutenberg content blocks we’ll be using, and where to find them in the WordPress Editor:

Button: Layout Elements → Button

Cover: Common Blocks → Cover

Gallery: Common Blocks → Gallery

Group: Layout Elements → Group

Heading: Common Blocks → Heading

Media & Text: Layout Elements → Media & Text

Paragraph: Common Blocks → Paragraph

Pullquote: Formatting → Pullquote

Latest Posts: Widgets → Latest Posts

Separator: Layout Elements → Separator

Hero Block with Headline, Text, and Background Image

Description

Build a classic Hero Block. This technique can be used anywhere emphasis is needed on a page. The Heading Block can be changed to accommodate context H2, H3, etc. Or, just use a paragraph and add some text.

Ingredients (Blocks)

1. Cover
2. Heading
3. Paragraph

Recipe

Begin with a Cover Block. Set the background image to your liking. Insert a Heading Block and a Paragraph Block.

Details: Experiment with Background Opacity and Overlay Color Options in the sidebar. If you select the Fixed Background option, you can create an instant Parallax scrolling style for your block. The focal point picker option allows you to drag the image around, or you can manually set the image positioning with horizontal and vertical positioning fields.

Alternate Version 1 — Divider with Image

Description

Need something less indulgent? Refactor this block to be a narrow divider with image.

Ingredients (Blocks)

1. Cover
2. Heading

Recipe

Leave only the Heading Block and adjust overall height. In the sidebar under dimensions, set a minimum height in pixels.

Details: I’m using 175px as the minimum height in pixels, but you’re the chef!

Alternate Version 2 — Divider with Pullquote

Description

This is a great block for highlighting a quote from someone. Use sparingly.

Ingredients (Blocks)

1. Cover
2. Pullquote

Recipe

Add a Pullquote to the Cover Block.

Details: I find the author attribution color by default to be a bit faint. Be careful with legibility contrast here.

Gallery Block with Headline and Background Color

Description

This is a nice way to add some flavor and color with custom adjustments to your photo gallery.

Ingredients (Blocks)

1. Group
2. Spacer
3. Separator
4. Heading
5. Gallery

Recipe

Start with a Group Block. Add a Gallery Block. Add a Heading Block and a Three Dot Separator Block. Use Spacer Blocks at the top and bottom to create desired negative space.

Details: The number of columns can be set in the sidebar options. You can opt to crop images, which I’ve done here. Or, you can let them scale into the available space. Click on each image in your gallery to add a caption. You’ll see an option to add a link to the caption as well.

Media & Text Block

Description

Create a Multi-Column Block with the image on one side and the text on the other. This built-in block works great, and with a few tweaks, something very expressive can emerge.

Ingredients (Blocks)

1. Media & Text
2. Heading
3. Paragraph

Recipe

Add a Media & Text Block to your page. Adjust text content area to suit.

Details: Remember that you can nest blocks. Try adding a button or even a gallery, if it makes sense! Select the outer containing block and set the background color for more emphasis. You can drag the vertical bar left to right, in order to set the ratio between image and text. I would recommend using the “stack on mobile” setting to allow for a nice layout when the block is viewed on mobile devices.

Alternate Version — Full Width

Description

Utilize the full-width option to make a bolder impact.

Recipe

Click and select the outermost container. Select the Full Width setting from the toolbar for a more dramatic look.

Recent Posts Block

Description

This is great if you want to alert your readers to other recent posts on your site.

Ingredients (Blocks)

1. Recent Posts Block

Recipe

This one requires only the Recent Posts Block, which looks great right out of the box. There’s a lot of customization possible here; so, read the details below.

Details: The settings for this allow the user to limit the amount of content, show only the excerpt (we’re doing that in this example), or show the full post. You can toggle the date, set filtering order, category, number of items, and columns. In our example, we’ve chosen two columns.

Call-to-Action Block

Description

Create a call-to-action using the Cover and Button Blocks.

Ingredients (Blocks)

1. Cover
2. Button

Recipe

It’s super-simple to create a nice call-to-action using existing content blocks. Embed a button in the Cover Block.

Details: Experiment with the button settings. Click directly on your button, then adjust settings in the sidebar. Border Settings will allow you to set the Border Radius for a more rounded appearance. You’ll also find the option to open the linked page in a new tab.

Now It’s Your Turn

I hope these have been inspirational for you, or at least have whet your appetite for what can be done with this useful tool. I encourage you to go see what you can make with what’s already available in WordPress.

The post Spice Up Your WordPress Site with These Built-In Gutenberg Content Block Recipes appeared first on WebDevStudios.