With that said, we’re huge fans of Advanced Custom Fields (ACF). It provides a robust set of field types that enables us to create flexible and friendly content management solutions for our clients. The time we save from writing, testing, and maintaining code with ACF makes it worth paying for an ACF PRO license. Our wd_s  starter theme includes commonly-used content blocks built on ACF.

ACF 5.8 has added support for Gutenberg. You can add ACF fields to a Gutenberg block without any JavaScript code. In this article, you will learn how to build a custom Gutenberg block for hero area using ACF without writing a single line of JavaScript code.

Adventurous, right?

ACF and Gutenberg

To build custom blocks using Gutenberg, you must be familiar with writing Modern JavaScript using the latest syntax (ES6, ES7, ES8, JSX), as well as creating components using React. To see this in action, here are some code examples to demonstrate a classic “Hello World” example for Gutenberg.

Custom Gutenberg Block with Vanilla JavaScript:

View the code on Gist.

Custom Gutenberg block with Modern JavaScript:

View the code on Gist.

The second example is smaller and cleaner but requires a build tool setup to compile Modern JavaScript syntax and JSX into browser supported code. You can get a head start by using create-gutenberg-block created by Ahmad Awais to scaffold a Gutenberg block without learning how to set up build tools.

Side Note: Learn JavaScript Deeply

Matt Mullenweg recommended that the WordPress community “Learn JavaScript deeply“ in 2015. If you’re a frontend developer, this still applies—not only for Gutenberg but JavaScript frameworks like React, Angular, and Vue are now widely-adopted and in-demand. Here are some resources to level up your JavaScript skills:

• ES6, the right parts by Kyle Simpson
• React for Beginners by Wes Bos
• EggHead.io
• FrontendMasters.com
• Comprehensive List of Resources from Frontend Masters

Hero Block

You will be recreating a simpler version of the hero area that is included with wd_s. This is the end result of the custom Gutenberg block that you will create:

Requirements:

1. Gutenberg (WordPress 5.0)
2. Advanced Custom Fields PRO 5.8.0

Step 1: Register the Hero Block

ACF introduced acf_register_block function with 5.8, which you will be using to register a custom Gutenberg Hero Block.

The example below shows how to register the hero block. You can drop this function in the functions.php file of your theme.

View the code on Gist.

To learn more details about each parameter of the acf_register_block  function, visit the official documentation.

Step 2: ACF field group for Hero Block

A field group is a set of fields that can be assigned to a WordPress post, page, widget, etc., and now a custom Gutenberg blocks registered with acf_register_block.

Next, you’ll add a new field group for the Hero Block from the Custom Fields page.

The basic field requirements for this block are:

• Tab field: Block Content
• Title field
• Text field
• Button text field
• Button URL field
• Tab field: Background Options
• Background image field

Next, assign the field group to the Hero Gutenberg Block.

To reiterate, Block is a new rule type in ACF which refers to all Gutenberg blocks registered with acf_register_block.

Save your changes!

This is how these fields will display in Gutenberg:

Step 3: Set up the Hero Block template

Custom Gutenberg Block created with ACF will use a template file to display it within the Gutenberg editor and on the frontend.

Create a template file template-parts/gutenberg/hero.php within your theme’s folder to match with render_template parameter of acf_register_block defined in Step 1.

The template file will contain HTML markup to add layout and return data from the fields.

View the code on Gist.

The get_field function from ACF is used to get data from the ACF fields.

The rest of the markup is basic HTML for setting up the Hero block’s layout. Just to appreciate the power of this feature by ACF, I want to point out that you didn’t have to write a single line of JavaScript. That’s amazing!

This is how the block looks within the Gutenberg editor:

Step 4: Styling the Hero Block template.

The final step is to style your Gutenberg Block.

To do this, you will be using the enqueue_block_assets action. This hook is used to enqueue assets for Gutenberg’s editor and frontend. If you want to have a separation between frontend and backend styling, you can use enqueue_block_editor_assets to enqueue assets only within the Gutenberg editor.

Drop the following code in your functions.php file to enqueue the stylesheet for your custom Gutenberg Hero Block:

View the code on Gist.

Create gutenberg.css in the root of your theme’s folder and drop the following code for styling the block:

View the code on Gist.

CSS is compiled from Sass.

This finishes your block setup with zero JavaScript code. Congratulations! This is how your Hero Block will look in the Gutenberg editor:

And this is how it will look on the frontend:

In my opinion, ACF provides a solid platform that fills the gap between PHP and JavaScript developers. ACF makes the whole Gutenberg Block creation process easier, faster and reliable. Even though I can foresee the limitation of ACF when a complex Gutenberg Block will come in action, I still appreciate and applaud ACF’s approach on making the whole process super simple for all level of developers.

Technically, acf_register_block is extremely powerful considering that a filter can be added to settings array to be used by other themes and plugins to make it even better (or worse).

The post Advanced Custom Fields and Gutenberg appeared first on WebDevStudios.

At WebDevStudios, we decided to create a child theme for a recent client project. Customizing Storefront directly would make it impossible to upgrade for new features and bug fixes. Any changes would be overwritten during the upgrade process. By creating a child theme, we have the ability to upgrade the parent theme (Storefront) for access to new features and bug fixes.

Throughout the article, when I refer to parent theme, it’s Storefront.

Folder Structure

A child theme is basically a blank WordPress theme—it becomes a child theme when you define the parent theme in the “Template” param in the header block of a child theme’s style.css file.

For example:

View the code on Gist.

Notice how we have defined “storefront” in the template param of the style.css header block. The template param should equal the folder name of the parent theme. In this case, our parent theme’s folder name is storefront.

This flexibility of a blank WordPress theme allows us to set up this project similar to the starter theme that we use for all our internal projects.

The following folder structure is inspired by our starter theme wd_s. For this project, I have simplified the folder structure, especially the sass folder, since we will be mainly using Storefront’s styles and doing little customizations to it.

Folder Structure:

• assets
  • images
    • sprites
    • svg
    • svg-icons
  • sass
    • style.scss
  • scripts
    • concat (individual JavaScript files in this folder are compiled into project.js file).
• inc
• languages
• template-parts

Build Tools

We will be using Gulp setup from our starter theme wd_s. Gulp will will perform the following tasks:

• Compiles Sass files into CSS (from sass folder)
• Vendor prefixes CSS automatically
• Minifies JS files (from scripts folder)
• Compiles JS files from concat folder
• Minifies images inside images folder
• Generates sprite file & Sass mixins automatically from images dropped in sprites folder
• Compiles and minifies SVG icons dropped into svg and svg-icons folder
• Generates .pot file for il8n strings based on theme’s text-domain
• Automatically runs the build process on file changes
• Immediately preview changes in the browser using BrowserSync
• Runs Sass and JavaScript lint in a task to help identify coding errors

To get started, install Gulp globally:

npm install -g gulp

Create a package.json file in the root folder of your theme with the following contents: the package.json file is used to define npm packages that are used by Gulp to execute the build process.

View the code on Gist.

Run npm install to install all the packages defined in the package.json folder.

Make sure to add thenode_modules folder to the .gitignore file. We don’t want to version control node_modules.

Next, we need to define the Gulp tasks and how to run each of them. Create a gulpfile.js file in the root folder of the child theme:

View the code on Gist.

1. Edit _s on line 292, 293 and 295 with your theme’s text-domain. This will be used to generate the il8n pot file.
2. To setup BrowserSync, edit _s.test on line 361 with your local development URL. Access BrowserSync by adding port 3000 to the end of the development URL.

After the above setup is complete:

Running gulp in the terminal after the setup is complete will generate sprites and pot file. Compile and minify icons. Minify images. Compile and minify stylesheet and JavaScript.

Running gulp watch in the terminal will continuously look for changes in the PHP files and files in the assets directory. Any changes that you make to those files will not require a browser refresh on the development URL. Gulp will live stream the changes to the development URL with the help of BrowserSync.

During the development process, it is highly recommended to run gulp watch.

Running gulp lint will run JavaScript and Sass lint.

Coding Standards

PHP Coding Standards

For PHP code, we use our own set of coding standards extended from WordPress Coding Standards. PHPCS is the tool used to run against these rules. You can configure your editor to run through these rules.

WordPress Coding Standards

WDS Coding Standards

JavaScript Coding Standards

We use WordPress JavaScript coding standards and extend it to adapt to our way of writing code. These rules will be tested against whenever you run gulp lint. You can configure your editor to run ESLint tests, which is recommended and makes it easy to see errors and warnings as you write code.

WordPress ESLint Coding Standards

WebDevStudios ESLint Coding Standards

Sass Lint

We use Sass to write all CSS. Like ESLint, the rules are defined in a sass-lint file and will be tested against whenever you run gulp lint. Just like ESLint, you can configure your editor to run sass-lint which is recommended and makes it easy to see errors and warnings as you write code.

WebDevStudios Sass Lint Rules

This ends a quick rundown on how we set up Storefront for our client projects. Having build tools and coding standards added to our projects help us write clean and maintainable code. How do you setup your Storefront projects?

The post Modern Theme Development with Storefront appeared first on WebDevStudios.