Let’s take a closer look at how patterns have developed since their introduction in WordPress 5.5, and explore the latest features enabled by the newest APIs.

WordPress Block Patterns

In August 2020, WordPress 5.5 introduced something new called block patterns. These are ready-made pieces that help you design your website pages more easily.

With block patterns, you can choose from many designs to put into your pages. You can make a big headline, a picture gallery, or a testimonial section without doing much work. Block patterns first showed up in the Gutenberg plugin Version 7.7. They were pretty simple at first, but they quickly got better and became useful for building websites.

What’s great about block patterns is that you find them right where you work in WordPress. You don’t need to go anywhere else to use them. It’s like adding a new feature to your website that’s already part of WordPress.

Also, in WordPress 5.5, block patterns worked with reusable blocks. If you had something you used a lot, like your business hours or a contact form, you could still use them with block patterns. But as WordPress improved, block patterns became more powerful, offering more design choices. Using reusable blocks became less important, and block patterns became the main tool for making cool layouts.

Utilizing Block Patterns

Here’s how you can use block patterns:

1. Making a Pattern: First, design a layout using blocks in the block editor. Then, save it as a pattern and use it in different parts of your website.
2. Patterns API: WordPress gives developers a way to add and manage patterns to create custom designs.

Block patterns make it easier for everyone to design their website pages. They’re like shortcuts that help you make your website look great without spending much time on it.

Improvements to Block Patterns

One common struggle developers faced was maintaining the structure of patterns while allowing content editing. This meant that users could unintentionally disrupt the layout of patterns when making changes.

Introducing Block Level Locking

WordPress 5.9 introduced a new block level locking mechanism aimed at simplifying block editing within patterns. With this enhancement, users now can selectively apply locks to individual blocks, controlling their movement or removal. This means that developers like myself can now ensure that the structure of patterns remains intact while still allowing users the freedom to edit content within those patterns. It’s a small but significant improvement streamlining the pattern editing process and enhancing the overall user experience.

WordPress 6.0 Enhancements

Version 6.0 introduced significant enhancements for working with patterns and themes, offering developers more flexibility and site owners a smoother experience. Three notable features stand out:

Pattern Registration from Pattern Directory for Themes

In WordPress 6.0, themes can register patterns from the Pattern Directory using the theme.json file. By specifying the desired patterns within the “patterns” field, themes can integrate selected patterns into their design. This simplifies the process of accessing and utilizing patterns directly within themes.

Placement of Patterns in the /patterns Subfolder

Themes now have the capability to define block patterns as files within the /patterns directory. Each pattern file contains metadata headers followed by the pattern’s source code. This organizational structure streamlines the management of patterns within themes, particularly benefiting block themes by reducing reliance on functions.php for control.

Block patterns have progressed significantly since their introduction in WordPress 5.5, with each update to make website design easier. WordPress 5.9 brought enhancements that improved control over block editing within patterns. By WordPress 6.0, patterns were further refined, allowing themes to easily incorporate patterns from the Pattern Directory and define patterns in a separate /patterns subfolder.

These improvements made it simpler for developers to integrate patterns into themes, providing them with more options and solidifying patterns as a key tool for modern website design.

Starter Patterns for Any Post Type

In WordPress 6.1, developers have introduced an enhancement for site builders: the ability to add starter patterns to any post type. Now, you can opt-in to utilize starter patterns when creating content on your WordPress site, whether it’s a blog post, a portfolio item, or any other custom post type.

Reusable Blocks Renamed to Patterns

WordPress 6.3 introduces a terminology change: Reusable Blocks are now called Patterns. This update reflects the broader scope of patterns within the WordPress ecosystem and brings Synced Patterns, a new type of block pattern that behaves similarly to reusable blocks. Synced Patterns enable you to make edits in one place, with changes reflected everywhere the pattern is used. You can also customize individual instances without affecting the original pattern.

For more details, visit Synced Pattern Documentation.

Improved Pattern Management

WordPress 6.4 brings significant improvements to pattern management. Now, you can categorize and filter patterns, making the site-building process simpler. Custom categories help organize patterns effectively, while advanced filtering in the Patterns section of the inserter makes it easier to find and use patterns.

Additionally, introduces the ability to share patterns across sites. You can easily import and export patterns as JSON files directly from the Site Editor’s patterns view, making collaboration easier and workflow smoother. These updates allow users to make better use of blocks and make site building in WordPress even more straightforward. For access to a wide range of patterns, visit WordPress Patterns.

Conclusion

While no specific enhancements were introduced in version 6.5, we entered this stage with a robust set of patterns. With synced controls, locking options, starter patterns, and a wide range of options and controls, patterns have evolved into one of the most powerful tools for site builders. It’s been a long road from the first pattern iteration to what we have now.

Check out the patterns documentation to explore further and unlock the full potential of WordPress Patterns.

The post Block Patterns Redux: Progression and Application in Modern WordPress appeared first on WebDevStudios.

If you’re contemplating the transition from classic to block-based themes, it’s essential to understand the key differences that distinguish these two approaches.

Classic Themes

• Classic themes rely on PHP files to manage content display and page structure.
• The template hierarchy governs the organization of template files.
• PHP functions, such as template tags, are employed to render content.

Block-Themes

• Block-based themes employ HTML files to create adaptable and flexible blocks for different parts of a website.
• While adhering to the template hierarchy, blocks form the fundamental building blocks for all content, with the post-content block taking the place of the_content().
• While text in HTML files is not natively translatable, block patterns can utilize PHP functions to address translation needs.

It’s essential to acknowledge that classic themes retain their significance within the WordPress ecosystem. However, adopting block-themes offers advantages in terms of scalability, performance, and streamlined customization without undermining the strengths of PHP.

Illustrating the Difference Between Classic and Block-Based Themes

To provide a visual representation of the distinction between classic and block-based themes, let’s take a look at two WordPress themes: TwentyTwentyOne (classic) and TwentyTwentyThree (block-based).

As you can see, there is a significant difference in the language used between a classic theme and a block-based theme. In a classic theme, all template files are in PHP, whereas in a block theme, they are not. If we take a closer look, we may wonder: where is the functions.php file? And where do all my functions go?

In block themes, the necessity for a functions.php file is no longer mandatory. However, you have the flexibility to include functions.php in your block theme if you require actions such as enqueuing stylesheets or JavaScript, adding custom block styles and image sizes, or utilizing hooks.

Now, let’s examine the updated hierarchy and template files in block themes. We’ve reorganized the index, page, single, and other templates into a tidy ‘templates’ folder. The former ‘template-parts’ directory is now ‘parts’ in the block theme.

Comparing index.php and index.html

Our focus now shifts to a side-by-side comparison of index.php and index.html files, where we encounter the most noticeable divergences.

Let’s break down these differences as highlighted in the image above:

1. The function get_header() has transformed into a template part, which serves as a block type for organizing your website. As a container block, it displays other blocks within specific sections like the site header or footer. In the header, you’ll find a template part where the Site Logo Block and Navigation Block are grouped and wrapped together. Begin with a blank header.html and place it in the ‘parts’ folder. WordPress programmatically generates a template part block from this file, allowing seamless utilization of your website’s design.
2. The traditional concept of the loop has evolved into a collection of blocks, granting enhanced flexibility and content control. In this code, a wp-block-query block performs a query to display specific posts based on defined parameters. Within it, a wp-block-post-template block handles the layout and structure of individual posts, comprising child blocks for featured images, titles, excerpts, and dates. For easy navigation through posts, a wp-block-query-pagination block handles pagination with navigation arrows. This new approach empowers developers to create custom layouts and designs using blocks, replacing the traditional loop and offering more granular content presentation control.
3. The get_footer(); function, which outputs the footer section of a website, can be replaced with a template part. With FSE, the footer is defined as a reusable template part that can be easily included in your block-based theme.

All About the Blocks

This is a remarkable transformation where familiar templating functions are now seamlessly replaced by blocks. The shift is evident not only in common functions but also throughout various template files, where everything now revolves around blocks. It’s clear that memorizing individual block markups can be challenging; WordPress offers some options for building block-based themes—some as easy as copy and paste!

Comparing Classic Customizer and FSE Editor

Previously, most editing tasks were concentrated within the Customizer, but with FSE and block-based themes, we now have access to the Site Editor. Let’s examine the significant differences between these two approaches and understand how styling works in the new editor.

At the core of the FSE editor lies the theme.json file, which plays a central role in styling each block. Rather than focusing on template-wide styling, FSE adopts a modular approach, enabling individual block styling. Blocks now manage every aspect, from margins and paddings to fonts and colors.

Classic themes allowed changes only in the Customizer’s global settings, affecting the entire template. However, with block-based themes, everything revolves around blocks. Each block can have its unique and personalized styles, making theme.json knowledge crucial. Luckily, there are abundant resources available to understand theme.json and master block-based theming effectively.

Hybrid Themes: Bridging the Gap

As we wrap up our discussion on switching from classic to block-based themes, it’s worth exploring hybrid themes—a middle-ground solution that combines elements of both worlds. In fact, WebDevStudios’ own wd_s Version 4.0 is a hybrid theme.

A hybrid WordPress theme adopts features of block-based themes like theme.json for defining styles and customizing the block editor, while still utilizing traditional PHP template files. It harnesses the block editor for content but not for building the theme itself. A hybrid theme presents a classic theme enriched with additional Site Editing features.

Since WordPress 6.1, classic themes can add block-based template parts. This feature enables customization of output via the Appearance > Template Parts option in the WordPress admin, offering theme authors increased control and customization capabilities. However, it’s important to note that theme authors must register support to enable this feature.

Here are some of the key advantages of hybrid themes:

• Combined Editing Experience: Hybrid themes offer the familiarity of the classic editing experience while introducing the new features of block-based themes.
• Easier Transition: For users apprehensive about fully committing to the block-based editor, hybrid themes provide a smoother transition.
• Enhanced Customization: With more options for page designs and greater control over the design and layout of posts and archives, hybrid themes offer a superior customization experience.
• Block Templates and Template Parts: Hybrid themes can enable block templates and block template parts, adding another layer of flexibility.
• theme.json Features: By adopting theme.json, hybrid themes can leverage features that were previously only available in block-based themes.

The Evolution Is Here

In conclusion, whether you choose to transition directly to block-based themes or take a more balanced approach with hybrid themes, the evolution of WordPress theming opens up new opportunities for creativity and flexibility. Hybrid themes, in particular, offer a compelling blend of traditional and new features that make them worth considering in your WordPress theme transition. As always, the key is to choose the path that best aligns with your needs and comfort level.

Thank you for taking the time to read this article. I look forward to sharing more insights and tips on WordPress development in future posts. If you have any questions or topics you’d like me to cover, please feel free to leave a comment.

The post Switching from Classic to Block-Based Themes in WordPress appeared first on WebDevStudios.

To get started, we will create a plugin to store our code. The quickest way to create a plugin scaffold is by using the WP-CLI command npx @wordpress/create-block loop-patterns, which will generate the necessary files for us.

If you want more information on the create-block script, you can check out the WordPress documentation.

Query Loop Variations

WordPress provides block variations as a way for developers to create custom versions of core blocks. To get started, we will need to create some directories to store our code. We can do this by running a few commands in the terminal.

We begin by creating a simple block variation called simple-query, and adding a CSS folder to store minimal styles. We don’t want to change the theme styles already declared in the theme.json file. To add our code, we will edit the simple-query/index.js file.

We will use the registerBlockVariation() function to register our block variation. If you are unfamiliar with block variations, you can learn more about them here.

This code defines a constant called SIMPLE_QUERY, which is set to the string 'loop-patterns/simple-query'. This constant represents the name of a block variation that is being registered.

The wp.domReady() function is a WordPress function that is called when the DOM (Document Object Model) is fully loaded and ready for manipulation. Inside the wp.domReady() function, the wp.blocks.registerBlockVariation() function is called with two arguments: 'core/query' and an empty object {}.

The wp.blocks.registerBlockVariation() function is used to register a block variation. The first argument is the name of the parent block (in this case, 'core/query'), and the second argument is an object that specifies the properties of the block variation being registered. In this case, the object is empty, so no additional properties are being set for the block variation.

As previously mentioned, the registerBlockVariation() function takes two arguments: the first argument is the name of the parent block, and the second argument is an object that specifies the properties of the block variation being registered. Let’s review the properties of the object.

1. name: This property specifies the name of the block variation being registered. In this case, the value of the name property is the constant SIMPLE_QUERY, which represents the string 'loop-patterns/simple-query'.
2. title: This property specifies the title of the block variation. This title will be displayed to the user in the block editor. In this case, the value of the title property is 'Simple Query'.
3. description: This property specifies a description of the block variation. This description will be displayed to the user in the block editor. In this case, the value of the description property is 'Displays a Simple Query'.
4. return: This property is a function that specifies the conditions under which the block variation should be displayed to the user. In this case, the function returns true if the namespace variable is equal to SIMPLE_QUERY and the query.postType variable is equal to 'post'. Otherwise, the function returns false.
5. icon: This property specifies the icon that should be displayed for the block variation in the block editor. In this case, the value of the icon property is 'edit-large', which represents a pencil icon.
6. attributes: This property is an object that specifies the attributes (i.e., data values) that the block variation should have. In this case, the object is empty, so no attributes are being set for the block variation.

Block Attributes

The next step will be adding our block attributes. Let’s take a look at the Query Loop block attributes.

Based on the screenshots, we can add the following to the attributes object in our script:

The attributes object in this code defines the query parameters that will be used to retrieve posts from the WordPress database.

Here is what each attribute does:

• perPage: The number of posts to be displayed on each page.
• pages: The number of pages to be displayed.
• offset: The number of posts to skip before starting to display posts.
• postType: The type of post to be displayed (e.g., post, page, etc.).
• order: The order in which the posts will be displayed (either asc for ascending or desc for descending).
• orderBy: The criteria used to order the posts (e.g., date, title, etc.).
• author: The ID of the author whose posts will be displayed.
• search: A search term used to filter the posts that are displayed.
• exclude: An array of post IDs to exclude from the query.
• sticky: A value used to include or exclude sticky posts from the query.
• inherit: A boolean value indicating whether the query should inherit the context of the current page.

These attributes can be used to customize the behavior of the query and fine-tune which posts are displayed.

Finally, we will build our template. We can use the innerBlocks property to build our template by creating nested blocks within the parent block.

In this case, the innerBlocks array has three nested blocks:

1. The first nested block is an instance of the core/post-template block, which is a template block that can be used to display a single post. The second element of the array is an empty object {}, which represents the attributes of the block. The third element of the array is another array, which represents the content of the block. In this case, the content of the core/post-template block consists of two blocks: the core/post-title block and the core/post-excerpt block.
2. The second nested block is an instance of the core/query-pagination block, which is used to display pagination links for a list of posts.
3. The third nested block is an instance of the core/query-no-results block, which is displayed when a query returns no results.

This is what our final code will look like::

Register Our Scripts

Now let’s test our simple query to make sure it is reading our code correctly. To do this, we need to change how we register our scripts in the **loop-patterns.php**file. Replace the existing content with the following:

To make sure you are calling the script correctly, add the following to the src/index.js file:

And make sure that you’re calling the script correctly on src/index.js. Add this:

Let’s visit the block editor and check out our new block variation. See how it appears in the block editor and on the frontend of the site.

While our custom variation is simple, it’s a good starting point. Now that we have a better understanding of how to register a query loop variation let’s create a flip cards variation for the Query Loop block. To create a new flip-cards variation, we can follow the same steps we used to create the previous variation.

This code registers a new block variation for the core/query block calledflip-cards. The variation has a name, title, and description and is only active if the namespace is FLIP_CARDS and the postType attribute of the query object is 'post'. The variation also has a set of attributes, including a className, tagName, and queryobject.

The variation is scoped to the block inserter and does not contain any inner blocks.

Inner Blocks

For our inner blocks, let’s do the following:

This code defines an array of inner blocks for the flip-cards variation of the core/query block. The inner blocks include a core/post-template block, which is locked and has a specific className. The core/post-template block also contains a core/group block, which in turn contains a core/columns block. The core/columns block contains two core/column blocks, which each contain various blocks such as core/post-title, core/post-date, core/post-author, and core/post-excerpt.

The structure of the inner blocks creates a layout with flip cards, where each card has a front and backside. The front side of the card contains a featured image, and the back side contains the post title, date, author, and excerpt. The blocks are nested inside each other to create the desired layout and functionality.

If you’re having trouble understanding how to access the block’s attributes, a helpful resource is the block library on GitHub. Alternatively, you can view the block’s attributes by clicking the Code editor option under the Editor toolbar, or by referring to the attributes we registered earlier.

The same applies to all blocks, I found it very helpful when looking for the attributes.

Adding Styles

The finishing touch will be adding our styles, which are the following:

With all the pieces in place, we can now see the results of our custom query loop variation. In the block editor and on the frontend of the site, we should see:

I hope you’ve enjoyed this tutorial and have learned how to create custom query loop variations in the block editor. With these skills, you can give your content a unique look and feel and customize the Query Loop block to meet your needs. Thanks for following along, and I look forward to seeing what you create!

The post Having Fun with Query Loop Block appeared first on WebDevStudios.

The minimum requirements to create a custom theme and how some of the new blocks work for the page creation have also been tweaked. Before 6.0, we needed to have the Gutenberg plugin installed and a block-based theme. Now, we only need a block-based theme.

You can start downloading an empty starter. Begin with this GitHub repo. This starter theme was made by Carolina Nymark. She has really great material on FSE. Check out her other work.

Open your favorite IDE and open your theme files. If you use localWP, you can spin up a local WordPress install. Now, add your theme and activate it.

We are going to build a simple home page for our theme, with a minimum amount of code. Thanks to theme.json and the Full Site Editor, let’s look at what we are going to build. This is a basic mockup I made with Figma:

We have a Header, a Footer, and some common sections that we will turn into Template Parts and  Block Patterns, as well as our colors, font sizes, and font family—all of which we are going to add to our theme.json.

theme.json

The first step, once we got our blank theme up and running, is to set our global styles. Let’s add some colors and font styles.

If it’s your first time working with theme.json, I encourage you, before you continue, to check the official documentation and get a grasp of what you can do.

Our color palette will look like this:

So on our theme.json, we do the following: on the settings object, we have our colors object. Let’s add our primary color:

This results in the generation of the CSS variable in the body of the website: --wp--preset--color--black: #D63E4B;.  Follow the same pattern and add the rest of the colors ( Secondary: #48655E, Tertiary: #59BDB4, Black: #333333, and White: #FFFFFF ).

This will generate our color palette. Go to your dashboard and open your Full Site Editor. Open the styles toolbar and click on the colors tab. There is our theme color palette:

We can also disable the default and custom colors by adding this  "defaultPalette": false,"custom":false, to the colors object.  Setting up our font sizes and styles is similar to how we add our colors. We will update the typography object on our theme file.

As with the colors, WordPress programmatically will create --wp--preset--font-family--helvetica-arial: Helvetica Neue, Helvetica, Arial, sans-serif; will generate the CSS Variable on the body of our website, and on the Full Site Editor, our typography is registered.

Follow the same pattern and add these sizes: 14, 18, 20, 24, 28, and 40px. When ready, save your theme.json file and open your Full Site Editor. Open the styles bar, and you will get your font family and font sizes.

Let’s take a look what theme.json has created for us. On your website, open the inspector tool. On the Styles Panel, take a look on your body element properties.

Excellent! We now have CSS variables with our values, globally available,  fonts and colors, and there are more settings for gradients, duotones, line-heights, borders, etc.

For the sake of this article, we are going to keep it simple. Lets’s take a look at how we can apply these styles to our elements and blocks.

First, we go back to our theme.json file on our IDE. We will add some properties to the styles, some spacing to our blocks, our typography, and default font sizes.

If we go back to our inspector tools, we can see the body has now our properties. You can use theme.json to adjust the styles to elements and blocks. Don’t forget to check the documentation to better understand what you can do with it.

Styling Blocks

Applying these styles to our blocks can also be done using the FSE editor. Open the styles tab, and let’s add some global styles to our buttons.

Here, we can set the typography, colors, and layout that the buttons will use. Follow the example below. Once you’re ready, hit save. It will let you know you’re adding a custom style. Save again.

So now, our default button is styled and looking like this on the backend/frontend. Using the inspector tool on our website, we can check the generated styles and our CSS Variables:

You can apply these styles to your blocks also on your theme.json. Following the same pattern, open your IDE,  and on the styles object:

Now that we get to know better theme.json ,  we can now focus on our Block Patterns.

Block Patterns

Our Hero, the Latest Post section, and our Call To Action section can be patterns. So, first of all, what are patterns?

Block Patterns are predefined block layouts available from the patterns tab of the block inserter. Once inserted into content, the blocks are ready for additional or modified content and configuration.

This feature in WordPress is super handy and it also has its own library. So, you can grab and use it, similar to how you add a theme or a plugin.

To build the Hero, we are going to use the cover block. With an inner group block, add a Heading (H1) a Paragraph, and a Button. Remember, we already set up all our styles via theme.json. All the settings can be added using the Full Site Editor. It should look similar to this:

Our pattern looks like the one on our mockup. There is no way we can add the patterns via the editor, similar to how we add template parts or reusable blocks.

You can use a plugin There are a few on the plugin repo  or you can create your own programmatically.

Once your block is ready, select the block. Open the sidebar options on the block options and select copy. This will copy the block markup. Go back to your IDE and open your  theme. Create a directory, name it patterns, add a new file hero.php and paste the markup.

Notice that we not only need to add the markup, but we also need to declare our pattern to let WordPress know what to do with this file. Similar to how we declare our templates, we declare the title, the slug, and categories. You can get more details on the official documentation. Click the Block Inserter, and there is our Hero Pattern:

Awesome! There is also one other pretty neat feature on theme.json. You can also declare patterns from the block pattern library. The patterns field is an array of pattern slugs and you can get the pattern slug from the URL in a single pattern view at the Pattern Directory. For example:

Sweet. Now, that we know how to create patterns, it is time to create the Latest Posts pattern. We are going to use the query loop block to show our three latest posts, with post image, post title, and the excerpt.

To get more on this super handy block, what do we do? Head to the official documentation.

Go ahead and do it yourself with what you learn in our previous example, but here is the gist in case you need it. I’m pretty sure you won’t. Our Latest Posts pattern looks like this:

Go ahead and create the final pattern. Again, you can build it yourself with what you learn so far. In case you need it, here is the gist for our final pattern.

Creating a Template

Now that we have our patterns, the next step will be to glue them to our templates. Open your Full Site Editor. Under templates, we have the index from our theme files.

We are going to create a new template by clicking on the Add New button. It will display a list of options that follows the WordPress Template Hierarchy. Select Front Page.

The first thing we are going to do is add our Template Parts, our Heading, and Footer. We have these parts already on our theme files, and most importantly, the Post Content Block.

Following our mockup design, click on the Block Inserter. On Patterns, add our own. It will look like this:

Now, we need to add some content to our homepage for the Subject of the page. Open a page and add your content. Copy what we have on the mockup.

Once that is ready, save it. Go to the dashboard, click on Settings >  Reading > then select your new page as Homepage. Save it and open your website.

We are getting closer… really close. I will say, we need to add a few styles here and there, but we manage to get really close to the mockup without a single line of CSS.

With the help of theme.json we add global styles, colors, fonts. And with the help of the Full Site Editor and the Block Patterns, we create our template and some patterns that we can use across our site—not only when templating, but also when creating posts and pages.

So far, we have just created the Front Page template, but is up to you to create the rest of the templates needed for your theme.

Exporting My Theme

Yes, you can build themes locally with the help of the Full Site Editor and also export it and ship it. Since we are creating a theme, before exporting, we still need to enqueue some custom styles that we need for our theme.

From here, there are many options. You can add wp-scripts or any task runner to your theme. For now, I will only enqueue a basic stylesheet.

Back to your IDE. Create a new directory for our styles. Name it css. Create a CSS file (named as you like) and paste these styles. To enqueue styles on a block-based theme, use the traditional way and add it to your theme’s functions.php file.

Now, here is our theme with the styles. Pretty good.

Great! We just completed our task, created our landing page, and it is also responsive by default. Now, let’s export our theme.

On the Full Site Editor, click on the three dots on the top bar to open the settings bar. Click on the option to export your site:

This will generate a .zip file ready to ship. Go ahead and add your theme and try it out. Here is the repo of the generated theme.

This is just a basic example of what you can do with the new Full Site Editor. I’m really excited about this new way of building themes. There are a lot of documentation, tutorials, and humans that are doing really great things with WordPress.

Thank you for taking the time to read this article. See you next time!

The post Let’s Create an FSE Theme appeared first on WebDevStudios.

One of the most interesting aspects of WordPress FSE are the block-based themes. All of the previously dynamically created parts of a theme (i.e., site title, site tagline, navigation, widgets) have become blocks. You can use Gutenberg blocks to create your entire website and not just a page or post.

For Five for the Future, I gave myself the task of creating a theme with the minimum requirements and used the Gutenberg Editor to create a block-based theme. Here’s how that went.

Full Site Editing Minimum Requirements

WordPress FSE has three simple elements. All you need is WordPress 5.8, Gutenberg, and a block-based theme.

Before you can use the site editor to create new block templates, a block theme needs to be installed and activated. Let’s create one.

Initialize a Block-Based Theme

Before taking the following steps, the Gutenberg plugin must be enabled.

• Create a new theme folder inside wp-content/themes.
• Create a style.css file for your new theme.
• Create a blank functions.php file.
• Create a blank index.php file.
• Create two new folders inside the theme folder: block-templates and block-template-parts.
• Inside the block-template-parts folder, create an empty HTML file called header.html.
• Inside the block-templates folder, create an empty HTML file called index.html.

WordPress FSE themes use a standard style.css file header.

Themes do not require functions.php to work. If you need to enqueue styles, JavaScript, fonts, create block patterns, or use hooks that are not available for blocks,  you can use it to cover things that full site editing can not do yet.

Without a blank index.php file inside the theme folder, WordPress will consider the theme broken. In order for Gutenberg and WordPress to recognize that the active theme has Full Site Editing support, the theme must include an index.html file and it must be placed inside the block-templates folder.

Although not required, block-template-parts help structure the theme with reusable smaller parts. For example, for block-based themes, /block-template-parts/header.html is the equivalent of header.php seen in classic themes.

Activate the Theme

Once we have this set up, let’s get into the editor and activate our theme. Navigate to Appearance > Themes and there you will see your new block-based theme. Now, click the activate button.

Creating a Header

After activating my theme, the first thing I noticed was a change in the Appearance menus. Now, I have the new Site Editor tab:

Using the Site Editor, I will create my header. From the editor menu, go to Site Editor. I will go ahead and select the header by clicking on Template Parts => Header.

What’s really neat is that you have the option to isolate the template parts you want to edit.

Although we previously created the header.html file, it does not mean we cannot create it also from the editor. Do this by clicking the + symbol.

The theme editor is no different from the Gutenberg editor; and thanks to the Gutenberg plugin, I have a set of blocks to edit my header.

I will set the basics to my header: a Logo, and a Navigation. In the screenshot below, you can see the structure of the blocks used to create the header template part.

The Site Logo block displays an image to represent your website. Once a site logo is set, it can be reused in different places and templates. The Navigation block allows you to place a menu of links onto any page so that your visitors can easily navigate to other parts of your site.

The Page List block displays a list of your site’s pages. You can use the Page List block to automatically compile and display a hierarchical list of all your site’s published pages.

Within the block library, under the “theme” category, we have several blocks to build our templates using the Site Editor. I will not refer to all but to the ones that I am going to use for this first look. Always check the official documentation for the latest on these blocks.

Adding the Header to the Index Template

With my header finished, I am going to add it to my Index template. Still on the site editor, under Templates, you will see your index template. Click on it to open the editor. So far, we have not left the editor to start building our theme based on blocks.

From within the editor, from the block library, Template Part => Header, the Template Part Block allows me to add a template already created and even create one from the block. So, I select my header previously created.

Creating a Static Page Template

Now, it is time for my static page template. I chose something something minimal—a template with a hero section. Back on the Site Editor, notice that under the Templates Tab there is + sign. That sign will show some WP templates. Let’s choose Front Page.

The front-page template file is used to render your site’s front page, whether the front page displays the blog posts index or a static page.

Once my template is created on the editor, I add the header part. For the hero, I add a cover block,t hat will print the Post Title. With the Post Title Block, you can both display and edit the title text. You can make the title a link, add a rel attribute, and choose whether or not to open the link in a new window.

The result is okay. I mean, it was really easy adding blocks. I have a home page created with some content, selected as a static page, without having written a single line of code and no styles; and it has the desired structure.

So far we achieved several things. We created our header, a template, and we added the loop to it without writing a single line of code, using only blocks.

Now, what if we add it to our FrontPage, our latest posts? We return to the editor. This time, we are going to use the Query Loop block. (You can check the official documentation.)

I want to show my latest post in my template, but only on the page I select as a Static Page. Adding the Query Loop Block and following the documentation, I ended up with my latest post in two columns with my featured image on the left and my post title and post excerpt on the right.

I wanted this between my content. The List View option in the toolbar is super useful to control my blocks.

I really recommend you check the official documentation. The query block is really a powerful block.

Creating a Single Template

Let me add some more content by creating a single template. For this, I can do it two ways. First, on my Code Editor (IDE), on the theme files, inside the block-templates folder, I can create an empty HTML file and name it single.html.

Back to the editor, always in Site Editor mode, I can see my single template. If I don’t have a code editor on hand, I can also create the single template by going back to the Dashboard on the editor, under Appearance => Templates. There, I can also create any template I need.

This is how I set my single template:

The editor gives us the option to create more templates, such as the one for the pages, archive, and the 404 with only blocks on the editor. Well, as we can see, if it is possible to edit and even create different templates from the editor.

Exporting Your Theme

If you wonder how to export your new theme, Gutenberg has a tool for that. From the sidebar menu, click the three dots on the top right. This will open the menu bar. Select Export, and it will compress your site on a zip file so you can easily add to other WordPress installs.

The result of this first try will not win an award for the best design of the year, but here is the final result. Using just blocks, I have my header, a hero section, and I have also created my single post page.

Adding Theme Styles

What about adding styles to my theme? Can I create themes templates without using the editor?

In the next part of this series on WordPress FSE, I’m going to pimp my theme. I will cover how to add Page, Archive, and 404 templates differently. Using HTML tags to add blocks to our templates on the code editor, add styles, and modified some blocks with theme.json.

With block themes, you use blocks to create entire pages or websites. Everything you see on a page is a block.

The post WordPress FSE and Block-Based Themes appeared first on WebDevStudios.

If you are working with React and webpack, you probably or mostly never have to create your own local server. If you ever wonder how it works under the hood, here is a simple way to get a local server up and running in no time.

Install Node

First we need Node. You probably have node installed. If not, and you’re on a Mac use Homebrew:

View the code on Gist.

Your First Server

Create a index.js file:

View the code on Gist.

Then on our index.js :

View the code on Gist.

To learn more about the Node http package, use the following link to learn all about http.

Finally, run index.js with:

View the code on Gist.

Go to your browser and enter http://localhost:3000/ in your browser. You should see the text, ‘Hello Node.js.’

Request and Response

To have different responses based on different URLs, we now change our respond:

View the code on Gist.

Let’s restart Node: CTRL + C. Run  node index.js. Go to localhost:3000 and navigate the routes:

To see your request information, open developer tools/network/status. It will show the status code from the request.

What about adding HTML Files to our routes? In the same directory of index.js, create:

View the code on Gist.

With Emmet, it is as easy as typing ! or doc and hit the ENTER KEY. Your file will have the HTML code necessary to run. If you use Visual Code like me, support for Emmet snippets and expansion is built right into Visual Studio Code; no extension required.

Emmet takes the snippets idea to a whole new level. You can type CSS-like expressions that can be dynamically parsed, and produce output depending on what you type in the abbreviation. Emmet is developed and optimized for web developers whose workflow depends on HTML/XML and CSS but can be used with programming languages too. Bookmark this: Emmet Cheat Sheet.

Now, add a navigation. Let’s use Emmet one more time.

Between the body tags, go ahead and type ul>li*3>a and hit enter. This will create an unordered list with three items and a tags. Add your links, as seen in this screenshot, and then add a h1 tag on each of the pages named Homepage, About, Contact, and Page Not Found. Your files should look like this:

Let’s update index.js.

View the code on Gist.

Restart the server with CTRL + C and run  node index.js . Go to: http://localhost:3000; you’re now navigating your HTML files.

Express

Express is a minimal and flexible NodeJS web application framework that provides a robust set of features for web and mobile applications. Express provides a layer of abstraction to make handling web traffic and APIs easier. In short, Express did for NodeJS what Bootstrap did for HTML/CSS and responsive web design.

Some of the advantages of using Express are:

• Almost the standard for Node.js web middleware
• Simple, minimalistic, flexible, and scalable
• Fast app development
• Fully customizable
• Low learning curve
• Majorly focused on browsers, making templating and rendering an almost out-of-the-box feature

Before we install Express, we need to create a package.json file. On your root directory, run:

View the code on Gist.

If you’re not familiar with npm init and its flags, I recommend running npm help init for definitive documentation on these fields and exactly what they do.

Now that we have our package.json in our project. Let’s go ahead and install Express:

View the code on Gist.

Let’s refactor our index.js to work with Express:

View the code on Gist.

Previously we create a server and started with:

View the code on Gist.

We have to take care of importing http, fs , other packages, and also the request and response object; but with Express, we achieve the same thing.

Run CTRL + C and  node index.js . Check your terminal. It should now log from Express, your routes are probably broken.  We’ll take care of that next.

View the code on Gist.

Routing with Express

You define routing using methods of the Express app object that correspond to HTTP methods—for example, app.get() to handle GET requests and app.post() to handle POST requests.

The following code is an example of a very basic route.

View the code on Gist.

To learn more about Express routing click here. For now, let’s add routing to our app go to index.js.

View the code on Gist.

Express adds things like the sendFile method which makes it easier to write request handler functions.

That’s it! Run CTRL + C and node index.js and navigate within your app.

Serving Static Files

Express has this special function, app.use(), which mounts the specified middleware function or functions at the specified path. The middleware function is executed when the base of the requested path matches path. This special function, express.static(), is a built-in middleware function in Express. It serves static files and is based on serve-static.

What is middleware? Middleware is a software that bridges gaps between other applications, tools, and databases in order to provide unified services to users. It is commonly characterized as the glue that connects different software platforms and devices together.

View the code on Gist.

Create a directory:

View the code on Gist.

Add this code on your index.js file in the root of your app:

View the code on Gist.

To reference styles.css in index.html, add in index.html and on all your HTML files between the <head> in the following lines:

View the code on Gist.

Let’s make sure we are reading the styles and script; on your style.css add:

View the code on Gist.

In your index.js, be sure that this is the new index.js the one on our public folder on the js directory, and is not our root index.js.

View the code on Gist.

That’s it! You have an app running locally with Node and Express.

We learned how to install and run a Node application locally and leverage it with Express. We also learned how to serve static files with express.static().

Automatic Server Restart with Nodemon

Nodemon is a utility that will monitor for any changes in your source and automatically restart your server, making it perfect for development. We have been starting and stopping our server each time we make a change on index.js, but with Nodemon, we don’t have to that anymore.

Let’s install Nodemon: npm i nodemon --save-dev. Now update your package.json.

View the code on Gist.

So instead of node index.js, we now run our app with npm start.

I hope this article helps you understand what happens under the hood on some of the most popular JavaScript bundlers.

The post Local Development with Node and Express appeared first on WebDevStudios.

But first, what is the JAMStack?

In the JAMStack, JavaScript (JS) is responsible for giving the necessary dynamism to the web page. Of course, the JS runs 100% on the client. There is no restriction on the style of the code or the JS library/framework that can be used. All the data and business logic that the web requires must be accessed via APIs. A set of markdown templates define how this data will be displayed.

As you can see, the JAM architecture is very different from what we are used to seeing if we use a pure WordPress or Drupal type CMS, where each individual client request involves a query to the CMS database to retrieve the data to display and render them with the corresponding template. At JAM, the website is pre-generated.

What does this mean?

It has many advantages, such as greater speed, security, price, and user experience. The million-dollar question is, then, what do I do when the data that my website has to show changes?

No problem. At JAM, the web is not static but is pre-generated. You can regenerate the web as many times as you want so that the data is always updated.

Once regenerated, it behaves like a static web. Simplifying, the web follows a continuous deployment process just like you already do (or should do) with the code. Services like Netlify help you automate this process. Note that you can even continue using WordPress as a backend if you want, but seen as a headless CMS, which we will access during the rendering process of the web prior to its deployment

The Jamstack Conf

That said, the Jamstack Conf is the must-attend event for anyone building the next generation of web applications. The event was hosted by Netlify, and the Keynote was by Matt Biilman, who gave us a brief tour about the state of the JAMStack and why it is so important, especially in these times, because web access to information is a really big thing in this global pandemic and situation. The web has always been central to the idea of ​​sharing and accessing information from all over the world, from all kinds of devices and places.

For example, Matt mentioned that for the outbreak of 2003,  23 articles and studies were published. For the emergence of the COVID-19, there are currently more than 10,000 articles on the virus and even more to come. This is a huge volume of information. It’s a truly global phenomenon with researchers all over the world talking to each other, communicating online, and sharing information with the public and researchers.

Matt talked to us about how the JAMStack has helped researchers and gave the example of a website that took advantage of this technology. The COVID Tracking Project was created to share data from all over the US, making it available to anyone with an interest. It’s based on a modern workflow around Github and Git, with people from all over the web industry contributing. It’s a project that reaches places like the White House or the New York Times, to public institutions. The COVID Tracking Project has been widely circulated and has had more than 35 million unique visitors. That blows my mind how much a server or servers could cost to handle 35 million unique visitors or days with more than a hundred million requests.

Matt also highlighted the great difference in internet speeds, citing as an example that the speed of bandwidth increased by 20.65% but also increased the speed difference of users by up to 125 times more, between places with the slowest speed and the fastest. Matt closed his presentation by mentioning that if you were a web developer back in the 90s, you actually had to think about physical servers. You had to think about power cords and stuff.

On the other hand, you would never have to deal with client-side optimizations, client-side builds, or responsive design. So, as the web has progressed and the demands of the experiences and the devices accessing sites have gone up, the idea behind JAMStack had to sort of build layers of abstraction that take some of this complexity away, making it possible for a developer to work without considering those lower layers of the stack. I’m thankful for it!

Then it was time for the State of the JAMStack. This year, they surveyed over 3,000 web developers, both Netlify users and not, both JAMStack fans and not, about how they are building sites in 2020. To see the results, visit State of the Jamstack.

Q&A, Expo & Networking

At Jamstack Conf, there was also time to meet attendees and sponsors. There were video rooms; I loved it! Thanks to that, I was able to see first-hand several interesting new products, such as imgIX. This image processing and optimization API transforms, optimizes, and caches your entire image library using simple URL parameters, various headless CMS, such as Strapi, Prismic, or those already known, such as Sanity and the Algolia search engine.

Fireside Chat

After the break, it was time for one of my favorite talks: Harper Reed, former Head of Commerce at Braintree, and Frances Berriman. In 2011, Harper served as Chief Technology Officer for Barack Obama’s 2012 re-election campaign. Together, he and Frances talked about various topics, such as the beginning of JavaScript, libraries, and the future of JAMStack.

Lightning Launch

Netlify’s David Calavera CTO introduced the new Netlify Edge Handlers. Then it was Renaud Bressand’s turn to show us how to use Prismic with Nuxt.js.

Tom Preston-Werner presented a demo of RedwoodJS. RedwoodJS is bringing full-stack to the JAMStack! Built on React, GraphQL, and Prisma, Redwood is an opinionated, full-stack, serverless web application framework that will allow you to build and deploy JAMStack applications with ease. Imagine a React frontend, statically delivered by CDN, that talks via GraphQL to your backend running on AWS Lambdas around the world, all deployable with just a Git push. After that interesting talk, Erin Kissane told us more about The COVID Tracking Project.

Internet consumers in the emerging market are accessing your web products differently. Yes, there is fast growth, but the bar is still low. Christian Nwamba in his session walked us through the path of internet users in Sub-Saharan Africa and how JAMStack can help by providing a better experience.

Celebrating JAMStack

Overall, the conference had many helpful topics and showed the strength of the stack. For lovers of JAMStack, like me, it was a conference that fulfilled all my expectations. I wanted more, and I hope to be able to be present at the next Jamstack Conf, which will be October 6-7 in San Francisco.

If you want to relive the first Jamstack Conf Virtual, videos of talks are available on the official JAMStack channel.

The post Post Event Report: Jamstack Conf Virtual 2020 appeared first on WebDevStudios.

Storybook is a user interface (UI) development environment and playground for UI components. The tool enables developers to create components independently and showcase components interactively in an isolated development environment.

Storybook supports many different frontend view layers. React, Vue, Angular, Mithril, Marko, HTML, Svelte, Meteor, Ember, Riot and Preact are currently supported.

Why Is It Useful?

As developers, our goal is usually to build software incrementally, with the goal of new features being written in a modular manner. To ensure that our code operates correctly, we usually capture its behavior in a set of unit tests. These tests exercise our code in an isolated way. However, when we later go to manually test our components, it’s typically done within the context of the full website.

Storybook allows you to see and interact with your components in an isolated way, similar to how unit tests scope the testing of your component code.

The most important aspect of it is that Storybook gives us a great way to visually test our application during construction. The ‘stories’ will help ensure we don’t break our task visually, as we continue to develop the app.

Key Benefits

• Isolation
• Props mocking
• Action logger
• Hot reloading
• Runs anywhere
• Showcase your components

Who Uses Storybook

Over 30,000 projects use Storybook. It powers frontend development for teams at Airbnb, Lyft, Slack, Twitter, and thousands of more companies. It’s used to build top design systems like Shopify Polaris, IBM Carbon, Salesforce Lightning, and the WordPress Gutenberg project.

Quick Guide to Get Up and Running

The easiest way to get started with Storybook is to use the automated command-line tool, a CLI that scans your app and will make the changes required to get storybook working. The tool inspects your package.json to determine which view layer you’re using.

If the CLI doesn’t detect your project type, it will prompt you to choose manually your project type.

Start Storybook with:

Visit http://localhost:6006/ and check your newly created Storybook.

That’s all you need to set up and run your storybook dashboard. A folder called storybook/ was created in your root project. That folder contains all the setup generated by the Storybook CLI.

What’s Next?

Now that we have our Storybook ready, it’s time to add stories.  We have to remember that a Storybook is a collection of stories; one story for each of our components. The official docs refer to each story as a function that returns something that can be rendered to screen.

You will find on your local installation that you also have a new directory named stories/ . There are many ways to name and place the scheme. Storybook recommends placing it alongside the component.

I like to keep it outside src/ directory, keeping main project files separated (and by default, when running the CLI, you will get a stories directory).

The most convenient way to load stories is by filename. Your stories files are located in the stories/ directory. You can use the following snippet in the storybook/main.js:

So for example, if you have a Buttonnamed Button.js, you would  name your story Button.stories.js.

This is the basic example of stories for a Button component:

Now that you have set up your Storybook, it is time to create your own.

Why Should You Be Using It?

Alright, let’s say you are starting your project. You enter in your src folder and create a new file called Modal.js. After that, you call this component inside your index.js file and open your browser to check the component. You’ll repeat it every time you create a new one!

Okay, maybe that process isn’t an issue, if you are working on a small project. But what if it is a big project, or you are working with a remote team? If one of your team members needs to use your component, this person will need to open your Modal.js file, check the properties, styles, actions, etc. Eventually, you’ll learn that it’s a long process that takes time. However, Storybook helps you and your team to easily manage components with a single source of truth.

Now, you’ll be able to use Storybook to quickly prototype, more easily communicate with your team, and envision how Storybook can be extended to fill other gaps in your process. The official docs and LearnStorybook.com are great resources.

Use this living design system that updates with production to optimize your development process.

The post StorybookJS and Why You Should Use It appeared first on WebDevStudios.