Gutenberg 14.6 was released last week with a long list of small but impactful refinements to core blocks and the full-site editing experience. One of the most practical enhancements included in this update is the new list view for editing the Navigation block.
The list view makes it easy for users to reorder navigation items using a drag-and-drop UI. The Navigation block in the content area instantly previews items that are moved in the block inspector.
As part of a larger effort to make it easier to edit Navigation Links off the canvas, this release also adds a new URL field to the Navigation Link inspector controls. Now user can edit the URL from the inspector controls as well as from the main link control.
Version 14.6 also adds a variation picker to the Group block placeholder. When users insert a new Group block, it will now allow them to select from among different variations to set the layout for the block. This makes it significantly easier for users to get started when using a Group block, instead of having to fiddle around to manually assign the desired layout.
One of the most creative features introduced in this release is the new “Randomize colors” feature that will automatically generate color palettes on the fly. It utilizes hue rotations based on the Cubehelix color scheme.
“Hue rotation consists in rotating the hue wheel — such as the one you might see in a color picker — by a determined amount of degrees, each turn generating a new color,” Gutenberg contributor Vicente Canales said in the PR for the feature. He also noted that this new feature surfaces “the need for themes to explicitly support style randomization, as well as the need to incorporate a way to define a color’s role within a palette as a way of avoiding getting, for example, palettes where background and foreground don’t contrast, rendering text illegible.”
While randomizing color palettes is a fun feature for users, some theme and plugin developers do not see the need for it to land in core Gutenberg and eventually WordPress.
“Yes, it’s fun, but from a theme designer’s perspective I don’t see an urgent use since the theme designer can provide numerous style variations,” block and theme developer Ellen Bauer commented on the PR. “For the user this provides the same kind of ‘fun feel’, but theme designers would provide an experience that actually works.
“There is so much potential in styles, but not much is published yet. So as a theme builder I feel style export/imports, the option to separate font styles from color styles are much more basic features I would love to have first.”
Newsletter Glue co-founder Lesley Sim agreed that it’s a fun idea but that anyone using a theme will probably rely on the theme’s style variations.
“And that will probably feel like a randomizer to them already,” Sim said. “At least, that’s how I personally view style variations.
“I’d much rather focus on basic features first too, rather than fun ones. Let plugin and theme developers build the fun.”
Other notable features in Gutenberg 14.6 include the following:
Block Toolbar is now hidden when Spacing Visualizer is displayed New keyboard shortcut for transforming Paragraph block into Heading block Focal Point handle updated to be more representative of the broader selection area New “Minimum Height” dimension control is now available for the Group and Post Content block This update’s performance benchmarks for the site editor and post editor are significantly improved for three out of four metrics over the last release. Check out the release post for a more detailed look at every PR included 14.6.
If you are interested in original article by Sarah Gooding you can find if here
The U.S government National Vulnerability Database (NVD) published warnings of vulnerabilities in five WooCommerce WordPress plugins affecting over 135,000 installations.
Many of the vulnerabilities range in severity to as high as Critical and rated 9.8 on a scale of 1-10.
Every vulnerability was assigned a CVE identity number (Common Vulnerabilities and Exposures) given to discovered vulnerabilities.
1. Advanced Order Export For WooCommerce
The Advanced Order Export for WooCommerce plugin, installed in over 100,000 websites, is vulnerable to a Cross-Site Request Forgery (CSRF) attack.
A Cross-Site Request Forgery (CSRF) vulnerability arises from a flaw in a website plugin that allows an attacker to trick a website user into performing an unintended action.
Website browsers typically contain cookies that tell a website that a user is registered and logged in. An attacker can assume the privilege levels of an admin. This gives the attacker full access to a website, exposes sensitive customer information, and so on.
This specific vulnerability can lead to an export file download. The vulnerability description doesn’t describe what file can be downloaded by an attacker.
Given that the plugin’s purpose is to export WooCommerce order data, it may be reasonable to assume that order data is the kind of file an attacker can access.
The official vulnerability description:
“Cross-Site Request Forgery (CSRF) vulnerability in Advanced Order Export For WooCommerce plugin <= 3.3.2 on WordPress leading to export file download.”
The vulnerability affects all versions of the Advanced Order Export for WooCommerce plugin that are less than or equal to version 3.3.2.
The official changelog for the plugin notes that the vulnerability was patched in version 3.3.3.
Read more at the National Vulnerability Database (NVD): CVE-2022-40128
2. Advanced Dynamic Pricing for WooCommerce
The second affected plugin is the Advanced Dynamic Pricing plugin for WooCommerce which is installed in over 20,000 websites.
This plugin was discovered to have two Cross-Site Request Forgery (CSRF) vulnerabilities that affect all plugin versions less than 4.1.6.
The purpose of the plugin is to make it easy for merchants to create discount and pricing rules.
The first vulnerability (CVE-2022-43488) can lead to a “rule type migration.”
That’s somewhat vague. Perhaps an assumption can be made that the vulnerability may have something to do with the ability to change the pricing rules.
The official description provided at the NVD:
“Cross-Site Request Forgery (CSRF) vulnerability in Advanced Dynamic Pricing for WooCommerce plugin <= 4.1.5 on WordPress leading to rule type migration.”
Read more at the NVD: CVE-2022-43488
The NVD assigned the second CSRF vulnerability in the Advanced Dynamic Pricing for WooCommerce plugin a CVE number, CVE-2022-43491.
The official NVD description of the vulnerability is:
“Cross-Site Request Forgery (CSRF) vulnerability in Advanced Dynamic Pricing for WooCommerce plugin <= 4.1.5 on WordPress leading to plugin settings import.”
Fixed some CSRF and broken access control vulnerabilities”
Read the official NVD announcement: CVE-2022-43491
3. Advanced Coupons for WooCommerce Coupons plugin
The third affected plugin, Advanced Coupons for WooCommerce Coupons, has over 10,000 installs.
The problem discovered in this plugin is also a CSRF vulnerability and affects all versions less than 4.5.01.
The plugin changelog calls the patch a bug fix?
“4.5.0.1
Bug Fix: The getting started notice dismiss AJAX request has no nonce value.”
The official NVD description is:
“Cross-Site Request Forgery (CSRF) vulnerability in Advanced Coupons for WooCommerce Coupons plugin <= 4.5 on WordPress leading to notice dismissal.”
Read more at the NVD: CVE-2022-43481
4. WooCommerce Dropshipping by OPMC – Critical
The fourth affected software is the WooCommerce Dropshipping by OPMC plugin which has over 3,000 installations.
Versions of this plugin less than version 4.4 contain an Unauthenticated SQL injection vulnerability rated 9.8 (on a scale of 1-10) and labeled as Critical.
In general, a SQL injection vulnerability allows an attacker to manipulate the WordPress database and assume admin-level permissions, make changes to the database, erase the database, or even download sensitive data.
The NVD describes this specific plugin vulnerability:
“The WooCommerce Dropshipping WordPress plugin before 4.4 does not properly sanitise and escape a parameter before using it in a SQL statement via a REST endpoint available to unauthenticated users, leading to a SQL injection.”
Read more at the NVD: CVE-2022-3481
Read the official plugin changelog.
5. Role Based Pricing for WooCommerce
The Role Based Pricing for WooCommerce plugin has two Cross-Site Request Forgery (CSRF) vulnerabilities. There are 2,000 installations of this plugin.
As mentioned about another plugin, a CSRF vulnerability generally involves an attacker tricking an admin or other user to click a link or perform some other action. That can result in the attacker gaining the user’s website permission levels.
This vulnerability is rated 8.8 High.
The NVD description of the first vulnerability warns:
“The Role Based Pricing for WooCommerce WordPress plugin before 1.6.2 does not have authorisation and proper CSRF checks, and does not validate files to be uploaded, allowing any authenticated users like subscriber to upload arbitrary files, such as PHP”
The following is the official NVD description of the second vulnerability:
“The Role Based Pricing for WooCommerce WordPress plugin before 1.6.3 does not have authorisation and proper CSRF checks, as well as does not validate path given via user input, allowing any authenticated users like subscriber to perform PHAR deserialization attacks when they can upload a file, and a suitable gadget chain is present on the blog”
The official Role Based Pricing for WooCommerce WordPress plugin changelog advises that the plugin is fully patched in version 1.6.2:
“Changelog 2022-10-01 – version 1.6.2
* Fixed the Arbitrary File Upload Vulnerability.
* Fixed the issue of ajax nonce check.”
Read the official NVD documentation:
CVE-2022-3537
CVE-2022-3536
Course of Action
It is considered a good practice to update all vulnerable plugins. It’s also a best practice to back up the site before making any plugin updates and (if possible) to stage the site and test the plugin before updating.
If you are interested in original article by Roger Montti you can find it here
WebP, an image format developed by Google, which is intended to replace JPEG, PNG, and GIF file formats, will soon be generated by default for new JPEG image uploads in WordPress and used for website content. The main work for this feature was committed to core for inclusion in the upcoming WordPress 6.1 release.
The initial proposal was revised after significant critical feedback. The most notable changes include automatically generating WebP versions of only core image sizes, keeping secondary (WebP) sub-sizes only if they are smaller than the primary MIME type, and only generating WebP images for image sizes that are intended for use in user-facing front-end content.
Despite a raft of revisions, and filters to control or disable WebP uploads, the proposal remained controversial. Contributors continue to report issues after testing. Many still have reservations about whether this should be opt-in or on by default.
“When converting medium-resolution photographs (approx 1600px – 2500px on the long edge), WebP files are often larger than the JPEG equivalent,” WordPress developer Mark Howells-Mead commented on the main ticket for WebP work. “(In my tests using my own photography, in around 60% of cases.) This change might make the ‘modern image format’ test of Page Speed Insights happy, but enforcing WebP by default on sites which use a lot of photography will often cause longer image loading times.”
Some developers are supportive of the change but prefer for it to be off by default when it is first rolled out, to allow the ecosystem to prepare for the change.
“I definitely see it as a big advantage to add Core support for additional MIME types for sub-sized image files,” Matthias Reinholz said. “But I can’t see adding conversion to a specific other file format as preferred behavior. This may help to optimize the market position of WebP but it will also be a serious threat to plugin authors and existing larger websites that do not pay attention to this change.
“Therefore, I’m questioning why this functionality should be activated by default at this stage. IMHO, it should be opt-in only. Plus ideally, we would already start to think about adding further image formats to be supported by this feature.”
NerdPress founder Andrew Wilder created a separate ticket urging contributors to consider making the feature opt-in, but the ticket was closed and conversation directed back to the main ticket so as not to splinter the discussion.
“Making these new features opt-in instead of opt-out would be the best way to be cautious about potential impacts,” Wilder said.
“There have been many requests for this to be opt-in (as well as some asking for a setting on the Media page, rather than only a filter for developers). So far there hasn’t been any open conversation about why that’s not being taken into consideration.”
The notion that WebP by default should be opt-in was summarily dismissed and the conversation was not revisited before the changes were committed.
“The feature will have widespread benefits for users by opting in core sizes (to start) – if it were entirely opt-in it would have little impact – or benefit,” Google-sponsored Core Committer Adam Silverstein said in response to opponents.
In response to suggestions that this feature ship with a UI for enabling it on the media page, Silverstein said, “We have discussed both suggestions in chats and issues with mixed responses. Project philosophy is regularly mentioned as aligning with the current approach.”
The ticket remains open awaiting patches for a few loose threads on the technical implementation. Contributors have continued to chime in with additional concerns.
The Performance team has a new blog where people can follow updates on their current projects and proposals. Now that the main WebP work has been committed, the next steps will discussed in future meetings with notes posted to the new Core Performance blog.
If you are interested in original article by Sarah Gooding you can find it here
Full-Site Editing is one of the main improvements added to the WordPress platform with version 5.9. It allows users to make sweeping changes to their website design and layout via a graphic interface, thus moving WordPress closer to the experience of a page builder. In addition, it offers new ways to create and customize themes.
These drastic changes have great consequences not only for the WordPress user experience but also for large parts of the platform’s ecosphere. For that reason, in this post, I am planning to take a deep dive into WordPress Full-Site Editing (or FSE for short, there are also discussions about changing the name because it’s a bit of a mouthful).
In the following, I will first talk about what Full-Site Editing is and provide a tutorial on how to use it to make changes to your site. I will also examine the tools it provides for theme development and close with a discussion of how the arrival of this feature will impact developers, theme authors, and existing page-builder plugins.
In a nutshell, Full-Site Editing means that WordPress now offers the ability to create and edit page templates and elements like headers and footers in a block-based graphic user interface.
This is part of phase two of the Gutenberg project and the preliminary culmination of a development that saw its beginning with the introduction of the WordPress block editor in WordPress 5.0. Since its initial release, the block workflow has branched out to other parts of the WordPress user interface. For example, you can now also use it for widget management.
One of the main goals of Full-Site Editing is to provide users with a singular workflow for making changes to their WordPress sites. In the past, you often needed to know several different systems to create a new menu, compose a page or post content, populate the sidebar, or adjust the color scheme. Even more complex changes required you to know how to edit page template files or write CSS. With Full-Site Editing, you can now make changes to everything in pretty much the same way (even if much of it still happens in different menus).
For everyday users, the benefit is reduced dependence on front-end developers. Site owners can now do a lot by themselves that, in the past, would require technical chops or professional help, such as making changes to page templates. Plus, those changes are now visible in the editor right away instead of having to go back and forth between the front end and back end of your site or even a code file.
At the same time, Full-Site Editing makes it easier for theme developers and designers to create markup and allows for quicker templating.
Here are the main building blocks that Full-Site Editing consists of:
Page templates and template parts The central attractions are two new editor interfaces that allow you to customize page layouts similar to the normal content editor. You can move page elements around, change their design (colors, fonts, alignment, and so on), and add or remove them at will. The same is also possible for single template parts such as headers and footers. It’s even possible to edit them separately. Plus, you can export your templates to use and distribute them as themes.
Global styles and theme.json A common feature in WordPress page builder plugins, Full-Site Editing allows you to define global styling for your entire site, such as colors and typography, in a central place. In the past, you would have to change the styling in different locations (e.g., the Customizer and block editor). FSE also introduces the theme.json file, which acts as a nexus for different APIs and contains the majority of styling information in block-based themes.
Template blocks and block patterns Full-Site Editing adds new block types to WordPress and the WordPress editor. These include static blocks like the site logo but also dynamic elements such as blocks for navigation, post titles, and featured images. These change according to settings in other places. There is even a full-fledged query block that’s basically the WordPress PHP loop. It lets you display a list of posts anywhere on the page. Each block also comes with its own design and configuration options.
Sounds exciting? Then let’s dive into how to use this new WordPress feature practically.
How To Use Full-Site Editing To Customize WordPress #
In the following, I will first go over how to take advantage of Full-Site Editing as a user. Later, we will also examine what makes this a useful feature for developers and theme designers.
In order to take advantage of Full-Site Editing, the most important thing is that you have a WordPress site running at least version 5.9. You can also use a lower version, but then you need to have the Gutenberg plugin installed and up to date.
The second thing you require is a block theme. That’s a theme that can take advantage of the new feature. We will go over how these are different from classic themes later. For now, a good option is Twenty Twenty-Two, which also came out with WordPress 5.9. I will be using it for this Full-Site Editing tutorial. Refer to the resources section at the end for other options.
Finally, if you are giving WordPress Full-Site Editing a spin for the first time, I recommend using a staging site or local development environment for it. That way, you can make all the mistakes you want without anyone knowing.
When you are logged into your test site, you can access Full-Site Editing via Appearance > Editor (also notice that the widget and Customizer options are missing).
An alternative way to get there is via the Edit Site link in the WordPress admin taskbar on the front end. Either will land you on the main editor interface.
Let’s walk through all the options available here:
Top left corner: Let’s start here because it’s easy to overlook. A click on the WordPress logo opens up a menu to edit templates and template parts. It also has a link to return to the WordPress dashboard.
Top bar: This should look familiar to anyone who has used the Gutenberg editor before. It contains the option to add blocks and block patterns, toggle between editing and selecting blocks, and undo/redo buttons. You can also open a list view of the current page, select different template parts, and jump directly to them.
Top right corner: Contains the buttons to save changes and preview the design on different screen sizes. The gear icon opens up settings for templates as a whole and individual blocks. Besides, that is the option to customize Global Styles. The three-dot icon contains display options for the editor, the ability to export templates and template parts, and access to the welcome guide.
Center: In the middle is the main editing screen. Here is where you will make changes to page templates and work with blocks. It is also an accurate representation of what your design will look like and contains some controls to add blocks and other elements to the page.
Most of these are togglable, so you can only have those options open that you really need and want.
As mentioned above, you can access this menu by clicking the half-black, half-white circle in the top right corner. It offers two types of styling options: for the entire website and for individual blocks. What exactly is available here depends on your theme.
For Twenty Twenty-Two, you have options for typography, colors, and layout. We will get to those below. For now, let’s turn to the most exciting part of the Global Styles menu — the preset color themes. You can find them when you click on Browse styles.
In this menu, developers have the possibility to offer styling presets for the entire theme. Hover over one of the options to see a preview of its color and font scheme, and then adopt the look for your entire theme with a single click.
I really like this feature as it offers users different versions of the same theme that they can easily use as jump-off points for their own creations. It’s a bit like themes shipping together with a number of their own child themes. You can also go back to the previous state by clicking the three dots at the top and choosing Reset to defaults.
As you can see, it’s possible to customize the font family, size, line height, and appearance, meaning font-weight and slant. Options here depend on the theme as well. For example, under Font family, you can only choose System Font and Source Serif Pro as these are the only options Twenty Twenty-Two ships with.
However, this is also due to the fact that full support for (local) web fonts only became available in WordPress 6.0, and this theme came out before that.
Likewise, the numbers under Size represent defaults set by the theme authors. You also have the option to click on the little icon in the upper right corner to set a custom value.
What’s interesting here is the Palette option, where the theme can provide its own color palette, including gradients. This is besides the default options Gutenberg offers and custom colors that users can create.
Besides that, just like for typography, the theme provides different options for elements for which you can change colors. In Twenty Twenty-Two, that’s Background, Text, and Links.
After choosing any of these, you get to a screen where you can easily pick a color or gradient from available options or create your own. When you do, your pick automatically translates to what you see on the editing screen.
Styling defaults are not only available for the website as a whole, but you can also set them for individual blocks. For that, you find an option in Global Styles at the bottom where it says Blocks.
Click those in turn to find similar options to customize their design on a per-block basis. For example, below, I have set the link color globally to blue but set the color for the Post Title block (which is also a link) to orange. As a consequence, orange overwrites the initial value, and the title comes out in that color.
If you have ever worked with CSS, this principle should be very familiar. Set some site-wide standards at the top of the style sheet and then overwrite them with customizations further down in the cascade. It’s the same thing here.
Making layout changes works the same way as in the main WordPress block editor. Everything you see on the screen is made up of blocks. Some may be combined as groups or block patterns, but they are blocks nevertheless.
As such, you can move and customize them however you want. For example, the main part of the homepage is the Query Loop block, whose function is to serve up the latest blog posts. However, it, too, is made up of different blocks, namely Post Title, Post Featured Image, Post Excerpt, Post Date, Spacer, and Pagination.
If you want to change something about the way it looks, you can very easily do so. For example, you may click on the Post Featured Image block and then use the arrows in the toolbar to move it below or above the post title.
Alternatively, hover over the block and then use the Drag button (which looks like six dots) to move it to another position. If you hit Save after this, it will translate to the design on your site.
In addition to the ability to move them around, every block also comes with its own settings. Like in the Gutenberg content editor, you can access those via the gear icon in the upper right corner. When a block is selected, you will see its customization options there.
What’s available in this place depends on the block you are working with. For example:
Post Featured Image: Has options to add the margin, padding, and configure image dimensions.
Pagination: Control the justification and orientation of its elements, wrapping, colors, and whether to show arrows, chevrons, or nothing as indicators.
Post Title: Besides setting colors, you can decide if the title should be a link, open in a new tab, or have a rel= attribute. You can also control colors and typography (including the ability to use Title Case) and add a margin.
You get the gist. Be aware that there are often more settings hidden that you can access via a plus or three-dot icon within the sections.
In addition, there are settings in the toolbar atop blocks when they are selected. You should not forget those as they can be decisive. For example, in the case of the Post Title block, it’s where you determine what order of heading (h1-h6) it takes, an important factor for SEO.
Of course, you can not just customize the available blocks, but you are also able to add your own. This works the same way as in the content editor and comes with different options:
Hover over an empty space in the template until a plus button appears, and click it. Then search or choose what you want from a list of blocks.
Click existing blocks and use the options button in the top bar to pick Insert before and Insert after.
Use the plus button in the upper left corner to see and search the full list of available blocks, then drag and drop them where you want.
In some places and existing blocks, you will also find icons to add more blocks. Plus, you have the ability to add block patterns, but we will talk about this further below.
Leaves the question, how is any of this helpful?
Well, it means you can easily add both static and dynamic content to the homepage. An example would be a heading and paragraph above the Query Loop block as an introduction to your blog.
Naturally, you can also remove blocks you don’t want just as easily. Simply select one and hit the Del or backspace button on your keyboard, or remove it via the block options.
You also have the ability to open a list view at the top (the icon with three staggered lines) and navigate to blocks from there or choose to delete them right away.
Template parts are entire sections inside templates that you can exchange as a whole and modify separately. In the case of Twenty Twenty-Two, that is the header and footer. You can see this in the template options on the right or when you click the arrow in the top bar.
Template parts are just groups of blocks on the page, so you can edit them as described above. However, what’s special about them is that themes can offer variations that allow you to change the entire part with one click.
For example, when you select the header in the example, it will show a Replace option in the settings bar at the bottom.
Twenty Twenty-Two has several default options to choose from. Click any of them, and Full-Site Editing will automatically replace the entire header with the new option.
In the Template Parts menu, click Add New in the upper right corner to create additional ones. This is useful if you want to make another version of the footer, for example. The cool thing is when you click it, besides asking for a name, WordPress automatically gives you templates for both header and footer, so you don’t have to start from scratch (unless you want to).
Besides that, you may also just click on existing parts in the list to edit them. This works the same way as in the main editor. The only thing that is different for template parts is that you have handles on the left and right that you can use to shrink and expand the size in order to check its behavior on smaller screens, i.e., mobile devices.
Just like a template file, anything you change and save here will translate to all pages and templates that use this part.
Finally, if you have set up a group of blocks on the main screen, you can turn them into a template part as well. Click the options in the main screen or in the list view and pick Make template part.
In the WordPress logo menu, there is also an item called Templates. Unsurprisingly, it contains a list of all page templates available on your site, from the 404-page over archives and single pages to single posts.
Page templates are usually files that control the basic layout of different types of content. If you change the template, all content of that type changes, too. With Full-Site Editing, you can edit existing templates and create your own in the user interface instead of a code editor.
Note, however, that FSE only lets you create standard page templates via Add New. More on that soon.
Something that comes especially handy here (and also for template parts) is block patterns. These are predesigned layouts consisting of several blocks you can add to website pages to instantly create entire sections. Examples include newsletter sign-up forms, pricing tables, and event lists, but also simple things like a styled divider or an image with a quote or caption.
Patterns allow you to put together entire designs quickly. They are easy to use, too! When editing a template, simply click the plus symbol in the upper left and go to the Patterns tab.
Filter the patterns via the drop-down menu at the top, e.g., by featured patterns, footers, pages, or buttons. If you find something you like, simply drag and drop it on the page. You can also search for something specific, like a “header” at the top, which will even show blocks from the WordPress block directory.
For a better overview, it helps to click on Explore to access the block pattern explorer.
This shows the block patterns in a larger window with the ability to search and filter them on the left. A click on a pattern you like automatically adds it to the template editor, where you can position and customize it as usual.
By the way, you can clear all customizations you have made for individual templates by clicking the three-dot icon in the Template menu and choosing so.
There is a second way to edit and create page templates, which happens in the normal Gutenberg content editor. It offers less complexity than the site editor interface (e.g., no access to other templates) but works similarly.
Simply create a new post or page, then, in the document settings sidebar, locate the Template panel below Status & visibility.
Here, it lists your current template and makes other options available in the drop-down menu. You can edit what’s already there via the Edit button or create a new template by selecting New. Each opens the more limited template editing experience.
Edit and save the template in the same way as in the site editor. Anything you create this way will also show up in the list of templates in the Full-Site Editing editor.
To make templating in FSE possible, the developers have added a number of dynamic blocks that can pull content from the database depending on the following:
Site title, tagline, and logo;
Post title, featured image, content, excerpt, author, avatar, author biography, date, tags, categories, next and previous post, read more;
Post comments, single comment, comments query loop, author, date, content, count, comment form, and link;
Archive title and term description;
Query loop, post list, post template, pagination;
Template part.
These are also available in the normal WordPress editor. There are more to come in future versions, and you can get early access to them via the Gutenberg plugin.
When you have made all the changes you want, you have the option to preview them in different screen sizes by clicking Preview in the upper right corner.
If you are satisfied, a click on Save will make the modifications permanent. WordPress will also list which templates and template parts your changes will affect.
That way, if you want to discard them in one place but keep them elsewhere, you can do so. Simply uncheck those components where you don’t want to save your changes. Click Save again, and your choices will translate to the front end of your site.
Full-Site Editing is also a useful tool for developers. You can use the interface to create templates and then export them as files to add to and publish as themes.
To take advantage of this, you need to be aware that FSE-ready block themes have a different architecture than classic WordPress themes. For one, the template and template-part files for Full-Site Editing no longer contain PHP but are HTML files with block markup.
Instead of style.css, styling is mostly taken over by theme.json. Here is where you set up styles for the block editor and individual blocks, styling presets, as well as CSS defaults (both for the front-end and backend editor). In fact, theme.json is so powerful that, by modifying it, you can change the style of an entire website.
This also allows you to switch between different sets of global styles (i.e., theme.json files) in the same theme. It’s a feature that only arrived in WordPress 6.0.
Relying mostly on theme.json greatly reduces CSS in other places. For example, Twenty Twenty-Two’s style.css is only 148 lines long. For comparison, its predecessor Twenty Twenty-One has almost 6,000 lines in its style sheet.
In addition, theme.json uses a whole different kind of markup. Yet, you could write an entire article just on this one file, so you are better served to start with the documentation for details.
The minimum requirements for a block theme are to have an index.php, style.css, and an index.html file in a templates folder. The latter is what marks the theme as a block theme to WordPress.
If you want to add template parts, you will place those in a parts folder. Having a functions.php and theme.json files is optional. Finally, you can also include a styles folder for global style presets. For example, this can include different color schemes for the theme.
Besides the changed structure, you also have different ways of creating template files when using a block theme. While you can still do it manually, using the new WordPress interface is also possible.
USING FSE OR THE TEMPLATE EDITOR TO CREATE THEME FILES #
If you want to use the page editors to create templates, the first step is to simply set up your templates as described in the first part of this article. One important option here is to know that you can use the Advanced settings for template-part blocks to change their type of HTML element.
When satisfied, you can download all your theme files at once. The option for that is available in the More tools & options menu, which you access by clicking the three dots in the upper right corner of the Full-Site Editing screen.
Here, locate the Export option. It will automatically download all template and template part files as a zip. Simply unpack them, and you can use them for your theme.
Consequences Of Full-Site Editing For The WordPress Ecosphere #
Besides providing a tutorial on how to use Full-Site Editing, I also want to talk about what its arrival means for the WordPress environment and those working there.
As is to be expected, an important question is whether this kind of feature will eliminate the need for professional developers and designers. Are they still needed when users can seemingly do everything themselves?
The short answer is “yes.”
Neither the emergence of WordPress itself nor page builders or page builder plugins, or any other technology that makes it easier for laypeople to build their own websites have eradicated the need for professional help. And it won’t happen this time, either.
While these days, users don’t need help for every little thing (like changing colors or fonts), there are still lots of tasks that non-technical site owners simply can not do with the available tools and where they need someone to do it for them. Plus, if you want a unique design and not rely on a template that hundreds or thousands of other people might also be using, you still need a designer and/or developer.
Plus, with great power also comes a great opportunity to screw things up (to loosely quote Spiderman). Just because everyone has the tools at their disposal to make a well-designed website, that doesn’t mean everyone can. Design is more than mere technical ability.
What’s more, not everyone actually wants to do the work. They’d rather hire someone with the skills than acquire them from scratch. Finally, there is so much more to a successful website than “just” design, such as SEO, performance, security, and maintenance.
So, even if there are fewer obstacles to building websites, there is no need to think that designers and developers are a dying breed. In contrast, the switch to new tools offers plenty of opportunities to build services and products around them.
WHAT DOES FSE MEAN FOR THE THEME MARKET AND THEME DESIGNERS? #
So what about theme creators? Does everyone have to switch to block themes now?
Here, it’s first important to keep in mind that many themes have not yet switched to the Gutenberg block editor and that there are still many users on the Classic Editor. The latter will also continue to work for a while as the plugin will still be supported until at least the end of 2022.
Also, all of the features described above are optional, not mandatory. Therefore, the switch does not have to be immediate. You can even build hybrid themes that are not complete block themes but are able to use block templates. This option exists by default unless you specifically switch it off.
Nevertheless, in the long run, it’s probably a good idea to move your existing themes over to FSE capabilities. It’s something that WordPress users will likely grow to expect as it gives them more flexibility and power to customize themes on their own.
At the same time, as described above, you can also use Full-Site Editing to create themes with less coding, which can speed up development time. Plus, it offers new economic opportunities. Besides themes, theme authors can now offer extensions like blocks and block patterns, opening up whole new business models and opportunities.
The existing page builder plugins are probably one of the biggest question marks. Will the likes of Divi, Elementor, and Co survive when WordPress can do a lot of what they were created to provide?
First of all, it’s unlikely that everyone will immediately switch away from the tools they are used to working with, so page builder plugins will likely stay around for a while. Also, many of them are currently more powerful than what Full-Site Editing is capable of in its present form. Another reason to stay with what you have.
Overall, these types of plugins have become very established over the last years, to the point that they sometimes ship packaged with themes. For that reason, it’s improbable that they will suddenly lose all their market share. Despite that, Full-Site Editing will likely eat into it over time, especially with new users who get to know it as a normal part of WordPress.
Just like everyone else, page builder plugins will have to evolve so that they offer things that FSE doesn’t to stay competitive. One way would be to offer kind of hybrid plugins that extend WordPress’ native page editor. Similar things already exist for Gutenberg and for the Classic Editor.
If you are interested in original article by Nick Schäferhoff you can find it here
We are less than three weeks out from WordPress 6.1’s official release on November 1, 2022. RC 1 was released this week, marking the hard string freeze, which means 6.1 is ready to be translated.
The features landing in this release are heavy on block and site editor improvements that will bring users a greater level of design control. Many of these features have been tested in the Gutenberg plugin but will need further testing now that they are in core, including the expanded template experience, better placeholders for blocks, new modal interfaces and preferences improvements, and updated menu management. WordPress 6.1 includes 11 releases of the Gutenberg plugin (13.1 – 14.1).
If you are monitoring WordPress’ core development blog, you may have seen the deluge of dev notes coming in ahead of 6.1. A few of the highlights include the following:
Block API changes in WordPress 6.1
Block styles generation (Style Engine)
Editor Components updates in WordPress 6.1
Simplified data access with new React hooks in WordPress 6.1
Fluid font sizes in WordPress 6.1
Create-block scaffolding tool updates
The WordPress 6.1 Field Guide has also been published. This guide includes all the technical details of the changes coming in the release, as well as the full collection of dev notes. There are a good number of updates that fall outside of the editor with ticket references in the Field Guide, including error logging and hooks added to wp-cron.php, database updates, addition of required attribute for required inputs on multisite site registration, updates to external libraries, REST API improvements, and many more miscellaneous core updates.
Plugin and theme developers are encouraged to test their extensions against RC1 and update the “Tested up to” version in the readme file. WordPress testers who are not comfortable filing a Trac ticket for bugs should report them to the Alpha/Beta area in the support forums.
If you are interested in original article by Sarah Gooding you can find it here
Yoast WordPress SEO Plugin update fixes a fatal error issue… Should you update?
The free version of Yoast SEO updated to version 19.10 and the premium version to 19.5, introducing numerous important changes.
This is what you should know about these releases if you’re considering whether or not to update.
WooCommerce 7.1 Compatibility Both the free and premium version releases benefit users who run the recently released WooCommerce version 7.1.
WooCommerce 7.1 is a huge release and among the enhancements is a change to the database called, High Performance Order Storage (HPOS).
High Performance Order Storage makes changes to the database so the activation of this new feature is an optional for the time being to allow time for plugin developers to catch up with the new feature.
“After the first production release, the HPOS feature will continue to be opt-in and we will assist developers in making their plugins compatible with HPOS, closely monitor how many extensions are compatible and how many stores are actively testing the feature.”
Yoast 19.10/19.5 Premium both feature compatibility with the new WooCommerce HPOS feature. That means if activation of HPOS results in a website crash it’s safe to rule out Yoast SEO as a culprit.
Users of the WooCommerce SEO add-on for Yoast will also benefit from an update to structured data that makes it eligible for new enhancements in search in Google.
Yoast 19.10 Fixes a Fatal Error Bug
The updated Yoast SEO plugin offers a patch for a bug that can result in website crashes.
The Yoast SEO changelog blames the problem on other (unnamed) plugins:
“Fixes a bug where a fatal error would be thrown in the classic editor in combination with certain plugins that misuse metabox hooks.”
An example of a metabox is a custom field that allows users to add additional content that isn’t in the main content.
Fixes Two Elementor-related Bugs
The first Elementor-related bugfix repairs an issue that affected the ability to save Yoast SEO meta data (under certain circumstances), which is a big deal.
The changelog states:
“Fixes a bug where Yoast SEO-related post meta data would not be saved if a user without the manage_options capability would save a post in Elementor.”
Yoast’s second bugfix is related to the previous one in that it arises from the same “manage_options capability” problem.
The changelog explains:
“Fixes a bug where users with site-wide basic access authentication would be prompted to insert their credentials when saving a post in Elementor if they didn’t have the manage_options capability.”
WordPress 6.1 Compatibility and Miscellaneous
Version 19.10 deprecated over a dozen hooks that are used for adding custom content to Yoast SEO settings pages.
Lastly, Yoast SEO offers full compatibility with the just released WordPress 6.1 code-named Misha.
Should You Update to the Latest Version of Yoast SEO?
Some people understandably prefer to wait before updating a plugin in case there’s a major error and that’s not a bad strategy.
Yoast SEO is used by over five million website publishers. The updated plugin was released yesterday and there are no reports in the Yoast SEO support forum that indicates that there are any widespread problems with this update.
In fact, there are currently only random issues that sometimes have more to do with other plugins and themes.
There are no problems that indicate a pattern of issues related to this update.
Considering updating to the latest version of Yoast SEO is a good idea, particularly to those who use WooCommerce or Elementor but not limited to those users.
Yoast SEO 19.10/19.5 Premium are both compatible with the latest version of WordPress so that in itself makes updating a desirable option as well as being a good practice to using the latest version of all plugins and themes since this helps prevent incompatibility issues.
If you are interested in original article by Roger Montti you can find it here
This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish.AcceptRead More
Privacy & Cookies Policy
Privacy Overview
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.