[ad_1] WordPress 5.8 is on deck for July 20, just a mere 10 days from now. The release is geared up to be the most feature-packed update the community has seen in a while. Block-based widgets, the pattern directory, WebP image support, template-editing mode, and many more tools are nearly ready to ship to the masses. However, one of the most powerful features is the Query Loop block. If you are unfamiliar with the terms “Query” and “Loop,” they are vital concepts within WordPress. Traditionally, they were only necessary for theme and plugin development. However, through the Query Loop block, users will gain exposure to what is, for all intents and purposes, the backbone of how WordPress displays posts on a site’s front end. Queries? Loops? Not everyone will be immediately familiar with these developer terms that WordPress is plopping down in the user interface. For theme and plugin authors, these are everyday concepts. However, even some users who have been using the platform for a decade have never been exposed to them. So, we should get some basic definitions in place. The term “Query” is simpler than you might think. It merely means to “query” or “ask” for posts from the database according to a defined set of options. For example, one might attempt to get the last 10 blog posts. “Loop” is an even easier concept to grasp. It means to “loop” or “cycle” through each queried post and output it. Technically, a developer could do things other than displaying the posts during this process, but we are only concerned with what gets printed on the screen. The two things combined become the Query Loop block. It allows users to ask for a set of posts and display each one. There is also a Post Template block, which throws a wrinkle in all of this. Aside from the word “template” being overused in WordPress for various features, this is a new method for an old concept. Traditionally, WordPress theme authors would write out all the HTML and call specific template tags within the queried posts loop to show things like the post title, author, content, and more. This is easy to do within a PHP file. However, in the block editor, there needed to be a new way to group these things together. The Post Template block acts as this group, housing the things users want to display in the Query Loop. WordPress also has a variation on the Query Loop block called Posts List. They do the same thing, but the latter has a more user-friendly title than the former. The only problem with this variation is that, when it is inserted, the user still sees the same “Query Loop” block title. There is a ticket to fix this, but it is unlikely to make it into WordPress 5.8. Query Loop Pattern Inserter When first inserting a Query Loop into the editor, WordPress will introduce users to another version 5.8 feature: the pattern inserter. Instead of having immediate access to interact with the block, users can select from a list of predefined patterns. By default, the inserter is a carousel that lets users can scroll through patterns individually: Query Loop pattern inserter: carousel view. However, they can switch to a grid-based layout and view all of the patterns at once: Query Loop pattern inserter: grid view. WordPress 5.8 is set to ship with six Query Loop patterns by default, unless more are added in the coming days: Standard Image at left Small image and title Grid Large title Offset I am not particularly fond of any of the default patterns other than the “Large title” one (shown in the screenshots above with the black background and white text). For this block to shine, users will need to build out their own designs or wait for theme authors to begin bundling custom Query Loop patterns. And, that is how it should be. Core WordPress should ship some basics while letting our community of theme designers showcase their craft. A custom simple blog posts listing. This is also an opportunity for theme authors to offer alternatives to their custom page template designs. It is not time to throw them out entirely. However, it is a way to begin recreating old ideas in the block era, such as building out eCommerce plugin integrations, portfolio grids, and much more. Some of the tools are still limited (we are getting to those next), but there is enough initial groundwork for exploration, helping users experience WordPress in new ways. Block Options The Query Loop block has several options for users to customize which posts to query the database for: Query Loop block and its options. In the block toolbar, there is a “Display settings” button. When clicked, it creates a popover with options for how many posts to show: Items per Page: Number of posts to display per page Offset: Number of posts to skip over Max page to show: Limit pages (this requires using one of the Query Pagination blocks) The “Settings” panel in the Query Loop’s block sidebar has several secondary options. Users can enable “Inherit query from template” to use WordPress’s global query, but this is mostly useless for WordPress 5.8 users without the Gutenberg plugin enabled and a block-based theme. For now, you will almost always want to disable this option. This will grant access to a slew of new choices, such as: Post type Ordering Filters panel for categories, tags, author, and keyword The Settings and Filters panels are the most fine-tuned pieces of the Query Loop block. The development team struck a sensible balance between ease-of-use and the dozens of query-related parameters available through code. It provides users with a ton of power right of the gate but should be flexible enough in the future for plugin authors to extend. The Post Template When inserting a Query Loop, the editor automatically adds its inner Post Template block. This is where most of the magic happens. Users
Continue readingTag Archives: 58s
Diving Into WordPress 5.8’s New Widgets Screen – WP Tavern
[ad_1] It has been a while since I have touched widgets. Once the site editor landed in the Gutenberg plugin, I almost exclusively dropped the old sidebar paradigm and moved to block templates. Reactivating old themes and jumping into the widgets screen felt like time-traveling into a bygone era. After months of being deeply embedded within block themes, it is hard to imagine moving back to the sidebar widgets system that most WordPress users are still using today. WordPress 5.8 is slated to ship with a small taste of bringing blocks outside of the content editor. However, it can feel like a surface-level refresh of a dying system, one that does not always work. Block-based widgets are part of the transitional phase between classic WordPress and the future, which centers on a complete site editor. Once the bulk of themes are built atop blocks, the need for widgets will wane. The site editor and block themes do not support the old sidebar system. Instead, users will be able to place blocks anywhere. Last October, I asked the question: Are Block-Based Widgets Ready To Land in WordPress 5.6? At the time, the widgets screen was expected to launch with the final release of 2020. However, the development team pulled back on the feature’s inclusion, primarily because the customizer implementation was sub-par. Asking the same question of WordPress 5.8, my answer is mostly the same. It is time to ship the current feature and prepare for a future without widgets. There are so many components that are far more exciting around the corner. The primary user-experience issues will linger around until users have moved on to block themes. I have long been in the camp of starting from a clean slate for block themes, letting widgets die out. However, the path WordPress has chosen is to create this stepping stone for users who may be on traditional themes for a while. It provides an opportunity to use blocks outside of the editor, which may be a leap forward for many. With the vast number of libraries, one-off blocks, and support from plugin authors, users have a wealth of block choices at their fingertips. Right now, if there is no equivalent widget, those users can only ever use those blocks in their content. Within a block-widget system, that limitation does not exist. It also lifts some burdens from developers. Those who want to shed some of their old code and go all-in on blocks can begin considering deprecating or retiring widgets. Transitioning to the new Widgets screen should feel simple to users familiar with the WordPress content editor. Inserting blocks is the same. The difference is that each sidebar has its own container. Widgets screen with a Gallery block in the Footer sidebar. The range of blocks within core WordPress could also let users drop some of their widgets-based plugins. One of the most popular types of widgets over the years has been for handling post lists. There are dozens of such plugins and an untold number of themes that include one. Coupled with WordPress 5.8’s Query Loop block, users can now recreate many of those widgets themselves. Custom post list using the Query Loop block. Much of this depends on the theme’s design support of blocks and whether it will accommodate anything other than traditional widgets. Customizer support for block widgets is lightyears ahead of where it was just a few short months ago. However, it feels awkward at best. There is a deep feeling of not belonging. While it was a remarkable programming feat to make the two features work together, the user experiences are nearly a decade apart. Editing a Heading block in the customizer. Despite the customizer providing a live preview, the Widgets screen in the WordPress admin gives the necessary workspace. Trying to squeeze the block editor into the tiny customize controls panel was never going to be an ideal experience, and it still is not. It gets the job done, but I recommend the traditional widgets screen for fewer headaches. Problems Remain In the eight months since I first dived into the block-based widgets, the system has been overhauled. However, the potential issues I brought up remain. Just dropping blocks into a sidebar can have mixed results. For example, compare a Legacy Widget to Heading and Latest Comments blocks in the footer sidebar of the popular OceanWP theme: Mismatched headings and colors. The issue is that WordPress treats every block as a widget. Traditionally, widgets have had both a title and content. Blocks have no such concept. A Heading followed by something like a Paragraph, Latest Comments, or another block has no special meaning in the block system. They are all treated separately. This issue is in full view when adding blocks to the default Twenty Twenty-One WordPress theme: Block treated as widget in Twenty Twenty-One footer sidebar. Notice the Heading and Latest Comments blocks are columnized because they are seen as separate widgets. To address this, users must add multiple blocks into a Group block if they want them treated as a single “widget.” It is a simple matter, but it could still be a usability hurdle for some. Even with a fix in place, there is no guarantee that blocks will appear as the widgets the theme author intended. I long ago gave up on the hope that there would be better handling for block widgets. The Classic Widgets plugin is available for those who need it, and theme authors can opt-out. These are necessary tools for an experience that can range from downright awesome to utterly broken. Bringing blocks outside of the content editor for traditional theme users is probably necessary for the transition, but the current site editor experience already feels much smoother than block widgets. The long-term focus should be on moving away from the dated concept of widgets and into a WordPress front-end 100% built on blocks. Like this: Like Loading… [ad_2] Source link
Continue reading