[ad_1] Easy Digital Downloads (EDD) put out a big release today, following several maintenance releases and the last major release in July. Version 3.1 introduces 10 new core blocks available to users who are running WordPress 5.8 or newer: Buy Button Order History Products Registration Form Login Form Download Terms Receipt Confirmation Cart Checkout (Beta) These blocks enable store owners to do more than their shortcode predecessors. Although the shortcodes still work, the block versions allow for much easier customization with a better UI. One example in the announcement is the Order History block. The previous Purchase History shortcode output a simple table of orders, but the new Order History block has a card style view and allows users to easily modify the number of columns and how many orders are displayed per page. Purchase History shortcode output New Order History block The other blocks have been updated in a similar fashion, with extended functionality and greatly expanded customization options. It’s important to note that the new Checkout block was released in beta. It is not turned on by default for new stores yet. Users who want to test the block will notice that EDD has reordered some of the fields to improve conversions, improved the user context detection (only showing necessary fields to users), and redesigned the payment method picker. Email Summaries is a new feature for store owners in 3.1. It sends a weekly or monthly email to the admin or other custom recipients with a store update that includes metrics like gross and net revenue, new customers, and average order amount. It can also be disabled in the admin. A few other notable changes in version 3.1 include the following: New setting to require users to login to download files Success Page has been renamed to Confirmation Page to differentiate it from the receipt More detailed views and filtering options for Reports reCAPTCHA keys added to Downloads » Settings » Misc so users can automatically enable reCAPTCHA for the lost password and the registration forms New color options for purchase buttons New “View Receipt” link in the orders table Easy Digital Downloads is installed on more than 50,000 WordPress sites. The ten-year-old plugin is continuing to evolve and become a more block-friendly tool for selling digital products. Check out the announcement post for a full tour of all the new blocks and their capabilities. Category: News, Plugins Tags: easy digital downloads Share this: Click to email a link to a friend (Opens in new window) Click to share on Facebook (Opens in new window) Click to share on Twitter (Opens in new window) Click to share on Telegram (Opens in new window) Click to share on WhatsApp (Opens in new window) Click to share on Pocket (Opens in new window) Click to share on Reddit (Opens in new window) Like this Like Loading… [ad_2] Source link
Continue readingTag Archives: Blocks
#46 – Nick Diego on Why You Should Be Excited About the Possibilities of WordPress Blocks – WP Tavern
[ad_1] [00:00:00] Nathan Wrigley: Welcome to the Jukebox podcast from WP Tavern. My name is Nathan Wrigley. Jukebox is a podcast which is dedicated to all things WordPress. The people, the events, the plugins, the themes, and in this case, why you should be excited about WordPress blocks. If you’d like to subscribe to the podcast, you can do that by searching for WP Tavern in your podcast player of choice, or go to WPTavern.com forward slash feed forward slash podcast. And you can copy that URL into most podcast players. If you have a topic that you’d like us to feature on the podcast, I’m keen to hear from you and hopefully get you, or your idea featured on the show. You can do that by heading over to WPTavern.com forward slash contact forward slash jukebox, and use the contact form there. So on the podcast today, we have Nick Diego. Nick is a Developer Advocate at WP Engine. He can be found, creating educational content, building plugins and themes, and contributing to WordPress core. He’s on the podcast today to talk about his passion and optimism for the future of WordPress using blocks. At the recent WordCamp US, Nick gave a presentation entitled, ‘Let’s build a custom block in 15 minutes’. It was his attempt at showing a group of WordPress enthusiasts that the barrier to creating blocks is slowly being eroded, due to the creation of new tools. These tools are creating opportunities for people who might otherwise have stayed away from block development. It’s becoming easier to create the blocks as the tools take away much of the technical burden of getting you up and running without advanced knowledge of JavaScript and React. Coupled with core components, native blocks supports, and a bit of guidance, Nick thinks that every WordPress developer can add custom blocks to their repertoire. It’s clear that Nick is all in on blocks. And during the podcast, he makes the case for why you should be too. They offer so many opportunities for what can be displayed on a page, and their capabilities are only getting better. We talk about how WordPress core blocks are trying to support developers by adding components and blocks supports so you don’t have to repeat the development work already done by others. You can build on top of previous work and thereby save yourself valuable time. It’s a fascinating chat, especially for those who are, as yet, undecided about whether they want to embrace WordPress blocks. Typically when we record the podcast, there’s not a lot of background noise, but that’s not always the case. Over the coming weeks, I’ll be bringing you recordings from a recent trip to WordCamp US 2022, and you might notice that the recordings have a little echo or other strange audio artifacts. Whilst the podcasts are more than listenable, I hope that you understand that the vagaries of the real world were at play. If you’re interested in finding out more, you can find all the links in the show notes by heading over to WPTavern.com forward slash podcast. Where you’ll find all of the other episodes as well. And so without further delay, I bring you Nick Diego. I am joined on the podcast by Nick Diego. How you doing, Nick? [00:04:03] Nick Deigo: I’m doing great. [00:04:03] Nathan Wrigley: Would you just introduce yourself? Give us a little bit of your background, who you work for. How come you’re at WordCamp US. [00:04:08] Nick Deigo: I’m a developer advocate at WP Engine. I also do a lot of contributing both on the WordPress core team and also on the training team for WordPress. [00:04:16] Nathan Wrigley: He’s doing a talk, presentation. What’s it all about Nick? [00:04:19] Nick Deigo: It’s all about trying to get people excited about building their own custom blocks, and I attempted to build a custom block completely in fifteen minutes. [00:04:27] Nathan Wrigley: Did you achieve it? [00:04:29] Nick Deigo: Just barely. I got the zero minute sign as I was just finishing the presentation, so I just got under the wire. [00:04:35] Nathan Wrigley: I guess the principle therefore, is that if you can do something in 15 minutes, I mean, let’s be honest, you’re pretty well versed, probably had a few runs through of that. But the bit that you are trying to educate people in, is that it’s easier now than it ever has been. So there’s no excuse to not explore. Is that basically it? [00:04:50] Nick Deigo: Yeah, and I think building blocks has been a bit scary. I know it was scary for myself. I didn’t come from a JavaScript background, mainly PHP. And so I wanted to show people that there’s so many more tools nowadays that it’s not as scary to get started, and if I can do it in 15 minutes, and I came from a non-technical background. You can do it too. [00:05:09] Nathan Wrigley: When blocks came around, Gutenberg was launched the first time, how did we build blocks and how has that changed? What things have come over the horizon since then to make it easier? [00:05:19] Nick Deigo: You wandered in the wilderness and looked for some documentation that maybe didn’t exist, and maybe looked at some core blocks and you kind of tried to figure it out. But today you can scaffold an entire block with one line of code in your terminal and voila, you have a block. [00:05:34] Nathan Wrigley: Is that because it’s become easier to do, or is that just that there’s more documentation? Are there actual tools? Are there pieces of software that you can download and use and things to make it more straightforward? [00:05:46] Nick Deigo: I find building with JavaScript is just inherently more challenging than PHP, but we have tools today written by contributors to WordPress that allow you to take all the hard bits and it takes care
Continue readingLearning to Build Block Editor Blocks, Part 2
[ad_1] I ended the last article with a functioning block that shows one thing in the editor and another thing on the frontend. The reason for doing so was so we could see how to put together the basic foundation of a plugin for the Block Editor. Now that we’re at this point, it’s much easier to start talking about things related to the Editor, things related to the frontend, how to start serializing data, how to start reading data, and so on. But because I’m trying to do this entire series as a backend engineer creating blocks – which is generally delegated to frontend development – I want to take it step by step. In the last article, I wrote: [T]he thing we’re going to look at doing next is adding styles for both the frontend and the editor and some basic functionality to the block. As I continue to write about learning to build block editor blocks, we’ll continue with looking at adding styles to both the backend and the frontend. In this article, we’re going to cover: adding controls to the block in the editor so we can control its placement within WordPress itself (or even remove it from the editor), ensuring what we see in the editor is what we see on the frontend Like last time, there are going to be things we have to dive into that will require reference material and links to external resources. But consider that part of the journey of learning to build blocks. Block Editor Blocks: Editing and Saving (Or Viewing) The first thing I want to mention is, as I wrote about in the first article, the two functions with which we’ll be working are edit and save. Personally, I think the functions are unfortunately named. It’s not that they don’t represent what they do, but they don’t represent just what they do. In other words, they do more than just allow us to edit and save content. 💭 A Digression on Function Names edit actually isn’t all of that bad since that’s the function responsible for allowing us to actually edit content. But save is overloaded. Not only does it read saved content, it renders it, too. And, as we’ll see in future posts, other functionality. So if you’re used to thinking in terms of how backend functionality works then you wouldn’t be far off in thinking something like: edit is for editing the content that’s saved in some type of data store, save is where the data is sanitized and written into said data store, read is where the data is retrieved and validated before displaying it, and render or display is a function for finally displaying it to the user. But that’s now how blocks work. At least, not at the time of this writing. Instead, we just work with edit and save. So that’s what I’m going to use in the rest of the article. You can read more about this in the Reference material at the end of the article. 🗺 Where We’re Going For starters, we’re going to do the following: add functionality to allow the block to be manipulated within WordPress, write styles to style our block, introduce them to the editor, introduce them to the frontend The reason for doing this is to give a concrete example as to how various files and functions play a role in block development. Granted, there may be a time in which you want something in the editor to appear one way and not on the frontend but the goal I’m working towards with this series of articles getting functionality added to the editor and presentation the same across what the author sees and what the user sees. Functionality Recall that in the last article, the edit function looked like this: edit: () => { return ( “This is content from the editor.” ); }, And this was sufficient for the demo but it only renders a string. Let’s make it a little more advanced such that it renders an HTML element. To that though, we’re going to have to get more into WordPress-specific block development. As usual, I’ll link to all of this in the reference material at the end of the article but I’ll explain each step as I work through it. First, I’m going to add some functionality to my block. Specifically, I’m going to the block the ability to be removed, to be moved, or to more generally be modified the in the context of the editor. To this, I need to add a few things. At the top of index.js, I need: import { useBlockProps } from ‘@wordpress/block-editor’; Then, in the edit function, update it to look like this: edit: () => { const blockProps = useBlockProps({ className: ‘tm-block-demo-container’ }); return ( <div {…blockProps}> This is content from the editor. </div> ); } Obviously, there are a few things in the code above that aren’t yet explained (such as blockProps and className) but I’ll get the explanation momentarily. Styles Let’s introduce some basic styles to the Editor. For example, let’s have the block include the following: a background color, a border and border color, a specific font color, a specific width, some padding First, let’s create an index.scss file in the src directory. This file will belong with other files like block.json, block.php, and index.php. Before adding any styles, though, we need to make sure we have the proper selector. So at this point, go ahead and write the following code in index.scss: .tm-block-demo-container { color: #fff; background: #0d63fd; border: 1px solid #0a58ca; font-weight: bold; padding: 0.5em; width: 100%; } Then in the same file, include the following (I like to place it above the registerBlockType function call): import ‘./index.scss’; The Code Thus Far Note at this point, the following is happening in the code: We’re now using @wordpress/block-editor which is a package that allows us to work with blocks within the context of the block editor (it
Continue readingAdding Blocks With Animated Backgrounds Using WebArea’s Latest Plugin – WP Tavern
[ad_1] As always, I like to highlight some things on the lighter side of the WordPress world. We have had enough business acquisitions in the past week — the whole year, really — that we need to take a break and enjoy the more experimental developments that the community has to offer. Such as the case with WebArea’s latest plugin, Background Animation Blocks. It is a collection of six blocks with different animated effects. I am obsessed with all things space and night-sky related, so I was immediately drawn to the Stars block. It has an animated background of simple dots floating in the background. It is also the most advanced animation, following the mouse cursor of the end-user. Stars animated block. The Stars block has a size, scale, and color setting for the background effect. Each of the other blocks has unique options, depending on what it does. Some, such as Bubbles and Gradient, allow the end-user to control the animation speed. Others have multiple color inputs. In total, the plugin provides six individual blocks with unique animation effects for the background. Effectively, they behave like the Group block, serving as a simple container. Each of the blocks supports both wide and full alignment. They allow users to control the text and background colors. And, any other block can be placed inside of them, just like you would expect from the core Group or Container blocks. They do not support some of the newer layout features from the Gutenberg plugin that other container-type blocks have. There is no need yet because those features have not landed in WordPress, but it is something to watch out for in the future. It is easy enough to wrap these animated blocks inside of another Group block for those features, though. However, I prefer not to put the burden of nesting on the end-user if possible. There are some downsides to the approach the plugin developer took. The animated backgrounds could have been tacked onto the existing Group or Cover blocks for WordPress, essentially behaving as a settings extension. An alternative route would have also been to create a single “Animated Container” block and allow the user to choose the specific background effect. With this method, the plugin author could have used the variations API to make each of the animations searchable and appear via the block inserter. However, the individual block route has been done before. Automattic took the same approach via its Starscape and Waves blocks. They are simply shipped as separate plugins instead of bundled as a collection. I prefer this solution because it allows users to pick and choose only the blocks they want. Assuming the library of animated blocks grows in future versions of the plugin, it could become overkill. The second issue is the plugin does not make use of the theme color palette in some instances. It uses the standard text and background color options for its blocks, but any custom setting only displays a color picker. For those who want to use a theme-defined color in those cases, they must know the hex code. Or, simply eyeball it to get it close enough. Despite what are, at best, trivial issues, the plugin was fun to tinker with. The blocks do not have to be relegated to the zanier side of WordPress. It is easy enough to adjust their settings for more subtle effects that could work for business-related or other types of sites. Like this: Like Loading… [ad_2] Source link
Continue readingGutenberg 11.2 Expands Color Support for Search and Pullquote Blocks, Introduces Experimental Flex Layout for Group Block – WP Tavern
[ad_1] Gutenberg 11.2.0 was released today with expanded color support for the Search and Pullquote blocks. Historically, customizing these elements has been out of reach for most users if their themes didn’t include them as options. This release introduces color support and border color support for the search button. Pullquotes are getting a similar treatment with border and color support, enabling some creative design options for those who enjoy taking the reins on customization. It’s these kinds of minute style changes that web developers would have been paid to perform back in the earlier days of theme customization gigs. Now the block editor enables anyone to jump in and do it themselves. These color support additions are part of a larger effort to improve the editor’s design tools to provide consistent application across blocks. “Another important goal of design tools is ensuring a wide range of exquisitely crafted patterns are possible; that best practices are not only possible but encouraged; and that customizing blocks is a consistent and natural experience,” Gutenberg Lead Architect Matias Ventura said in the ticket tracking design tool tasks. Gutenberg 11.2 also introduces support for a new experimental flex layout. The need for additional layouts was described by Rick Banister in a ticket submitted a year ago, requesting a “display horizontal” option for the Group block: When building patterns or trying to achieve a layout with multiple elements arranged horizontally it would help to have a parent block that would automatically arrange its children on a single line. Columns can be used to arrange things side-by-side, but they add quite a lot of extra nesting if you only need to arrange one set of blocks. We could leverage the Group block and add a ‘display horizontally’ or ‘act as a row’ option to it. It would wrap its children and act as a ‘flex container’ (display:flex; flex-direction:row;). Further flex parameters could be optional to align and distribute objects. A flex layout option has the potential to remove some of the complexity in nesting blocks. This early prototype shows a rough, unfinished UI for a layout switcher. It shows the difference between a flex layout and the default “flow” layout, which displays children one after the other vertically without any specific styles. The PR included in Gutenberg 11.2 makes it possible for blocks to support multiple layouts. Gutenberg engineer Riad Benguella said the plan is to introduce more layouts, such as “grid” and “absolute positioning container.” Adding “flex” layout support for the group block is the first step towards proving how multi-layout options can work in the block editor. “In the previous WordPress release, we introduced the layout config and the __experimentalLayout prop for inner blocks,” Benguella said. “The initial reason for these was to make alignments and content widths more declarative for themes. While this was an ambitious goal on its own and a hard one to achieve for the default layout, the goal has always been to absorb and support more kinds of layouts in the editor than the regular vertical list of blocks.” This experimental flex layout support can be useful for theme developers and makes sense in certain use cases with the Cover block, headers, social icons, columns, and other applications. The layout switcher UI is hidden in this release while the Gutenberg team works on a better design and wording for the feature. Like this: Like Loading… [ad_2] Source link
Continue readingBuddyPress 9.0.0 Transforms Legacy Widgets Into Blocks – WP Tavern
[ad_1] BuddyPress 9.0 was released one day before WordPress 5.8. As all major BuddyPress releases are named for pizza joints, this one has been dubbed “Mico” in honor of Pizzéria Chez Mico, a small restaurant on the French riviera, where you just may find capers and anchovies on your pie. This short release cycle was laser focused on getting all of the BP component widgets ready to be used as blocks to ensure that they work with WordPress 5.8’s new block widgets experience. BuddyPress 9.0 introduces 10 new BuddyPress blocks to be used in place of the legacy widgets. New BuddyPress Blocks in 9.0.0 This release also enables users to transform legacy widgets into a block with two clicks, while preserving all of their settings and automatically importing them. The availability of these new blocks is an important milestone that BP contributing developer David Cavins said is “the first step toward the progressive retirement” of BuddyPress widgets. All this functionality that used to only be available in widgetized areas can now easily be used as blocks inside content areas. The blocks vastly expand BuddyPress’ flexibility, enabling site owners to do many things that used to require custom development. Designing unique landing pages for communities is now easier than it has ever been. “My coworkers are pretty excited to have these new BP blocks,” Cavins said during a chat in the BuddyPress development channel on Slack. “For instance, with the login form block, you can pretty well replace login form customization plugins and put the form in your landing page with ease.” The release also includes a new Sitewide Notices endpoint for the BP REST API that will enable site admins to create, edit, or delete notices and let users fetch the active notice. For a full list of the improvements and bug fixes included in 9.0.0, check out the release notes in the codex. Like this: Like Loading… [ad_2] Source link
Continue readingIdentify and Select Blocks via the Wayfinder WordPress Plugin – WP Tavern
[ad_1] Christopher John, a Seattle-based designer and UX engineer, released his first project to the plugin directory yesterday. Announced via Twitter to high praise, Wayfinder is a block outline solution for the WordPress editor. Like similar plugins, the goal is to make it easier for end-users to select nested blocks, which can sometimes be tough to pin down. Wayfinder outlines each block in the editor on hover. It then displays the block name at the upper left of the box. My favorite feature that you will not find elsewhere is the addition of each block’s classes at the bottom right of the box. This makes it easy for designers or users who want to quickly find a class for styling. Outline of a Heading block. Users can also enable or disable the pieces of the UI they want to appear via the plugin’s setting screen. However, any changes affect all of the site’s user experiences. Currently, there are no per-user settings. At first glance, the plugin seemed to work great. The hover outline experience felt smooth, and I did not need to change the default options. Wayfinder almost seemed to be everything one might look for in a block-outline solution. It was besting existing plugins in nearly every way. However, things soon began rolling downhill when writing a typical blog post with nothing other than Heading, Paragraph, and Image blocks. I first noticed that I could not type the same number of words as usual on one line. My perfectly-tuned typography was breaking sooner than it should have. Spacing between paragraphs seemed a bit too large. My wide-aligned images were just a little smaller than usual. The user experience still felt good until this point, but the little oddities were stacking up. Something was not right. The plugin had been showered with praise on Twitter and already received three five-star reviews in its first 24 hours. Maybe my custom theme was the issue. However, similar problems arose when testing several others, such as Twenty Twenty-One, Nutmeg, and Eksell — each a well-rounded theme catered to the block editor. As clean as the plugin’s UI is, it more often than not wrecks the theme’s default block spacing. This becomes more noticeable as users begin adding nested layers of blocks. The problem is the plugin adds 18 pixels of padding around every block via its stylesheet. .wp-block:not(.block-list-appender) { position: relative; outline: 1px dashed transparent; padding: 18px; overflow: visible !important; } To the untrained eye, this may not be a visible issue in many cases. It will affect each site differently, but 18 pixels of extra padding on every block will undoubtedly mess things up to some degree unless the theme itself uses that exact same spacing in its design. The more noticeable issues are seen with blocks like Social Icons: Holy moly! Those are some gigantic social icons! But, even something as basic as a List block can be misaligned: List block shifted out of alignment. Theme authors can write custom CSS to overrule the plugin’s padding. However, the last thing the WordPress community needs is a specificity war between themes and plugins. Themers already have to do this enough to wrangle blocks now. Removing that one padding rule from the plugin’s editor-style.css killed 99% of its issues. Afterward, things were running like a well-oiled machine. As a developer, I would explore outline-offset for spacing between the block and its outline, maybe cutting that 18px down a bit. Because outlines are not a part of the CSS box model, it would not affect spacing. Adjustments may be necessary on a per-block basis, especially when those blocks are nested or small (e.g., Social Icons, Navigation). It would carry its own challenges but should be a less destructive course. To a lesser extent, the plugin’s overflow rule breaks the theme design from time to time. Its position and outline rules could overrule some edge-case block styles too, but they are necessary for the plugin to actually do its job. In particular, I could see positioning being problematic with sticky headers as we get into site editing. The only other issue might be themes that use ::before and ::after pseudo-elements on blocks, but the plugin also needs to overwrite those to display the block name and classes list. This is likely another edge case. Despite the issues, the plugin is ahead of the pack at this point. Gutenberg Editor Full Width Blocks Border (a bit of a mouthful), another recent plugin to offer similar functionality, breaks custom theme design across the board. It does accomplish the job of making blocks easier to select, but the sacrifice of a WYSIWYG is not worth it. The Editor Block Outline plugin has been my go-to recommendation for a while. It has a few design issues of its own, but some of those are adjustable on a per-user basis. However, as of late, it has made the editor feel sluggish. Plus, its misuse of the WordPress admin notice system for Twitter followers makes it something I’d prefer to steer clear of. EditorsKit has a similar “block guidelines” feature that uses a box-shadow instead of padding and an outline. It does not muck up most theme layouts with that technique. However, I have hit other style conflicts with the plugin. Plus, EditorsKit is overkill for users who simply want just one feature. That leaves us with Wayfinder. Warts and all, it is the best standalone option right now. Maybe that’s not saying much, but it is saying something. This is a feature that is hard to nail down. I do not envy the developers who are trying to make miracles happen. It is sure to please many who have been on the lookout for a block outline solution. It is in a position to pull farther ahead of the competition with its relatively solid first outing. With more thorough theme testing and a bit of adjustment to its approach, it could be even better. I am eager to test
Continue readingAutomattic Launches Mayland Blocks, Its Second FSE Theme on WordPress.org – WordPress Tavern
[ad_1] Automattic released its second block theme to the WordPress theme directory last week. Mayland Blocks is geared toward photographers and other users who want to showcase their projects. It is the child of Blockbase, a sort of starter/parent hybrid the company’s Theme Team recently announced. I had high hopes for Mayland Blocks going in. I have kept a loose eye on its GitHub repository in the last couple of months. It was one of the first 100% block-built themes the team seemed to be working on. While block themes are still experimental at this stage, I was admittedly disappointed. Maybe my expectations were too high. I was eager to be wowed when I should have gone into this review more level-headed. However, I am who I am, and that is someone who is genuinely excited each and every time a new block theme comes along. I am ready for the next big thing, but Mayland Blocks did not fit the bill. As I began the process of testing the theme, the first order of business was to recreate the Masonry gallery as shown in the theme’s screenshot: Expected gallery layout from Mayland Blocks My first thought was that the default gallery output would automagically work. It did not. Then, I looked for a Gallery block style. Nothing there. I searched for a custom pattern. Nothing there either. In short, it was impossible to recreate the gallery shown in the theme’s screenshot — one of the primary features that drew me to it. Bummer. I was looking forward to seeing a Masonry-style gallery of images built on top of the block system. Standard gallery output with Mayland Blocks. With a tiny bit of sleuthing and peeking under the hood of the theme’s demo on WordPress.com, I saw that it was using the CoBlocks plugin by GoDaddy. The thing that made the theme special had nothing to do with the theme. After a quick install, I converted my existing gallery to the CoBlocks Masonry block. Success! Masonry gallery output via CoBlocks. At that point, I began to wonder why I was even testing Mayland Blocks at all. Its claim to fame hinged on showcasing photography. The core Gallery block works well enough, and I can use CoBlocks with any theme. Most decent ones provide the sort of open-canvas template that is no different than Mayland’s front page. What would have made it a great theme would have been living up to its screenshot’s promise. This was also a missed opportunity to showcase some alternate Gallery block styles and patterns. If we want more users to buy into this system, some of our best design and development teams need to take that one extra step. For such a simple theme, one well-suited as a one-page design, this was the moment to lean into the photography angle. Provide users a Polaroid picture frame option: Add a “no gutter” block style: Bundle a few patterns that combine the Gallery block with others. Give us a little flavor. Mayland Blocks works well as a WordPress.com child theme because its suite of plugins is available to all users out of the box. For a publicly-released project on WordPress.org, it is a little disappointing that it was a straight port. The child theme is essentially its parent with an open-canvas front page template and some trivial font and color changes. Surprisingly, it made it into the theme directory with so few alterations. Two days later, another child theme was outright rejected for just adding “some minor changes which can be made directly from the parent theme.” The inconsistent application of the guidelines by different reviewers has long been a thorny issue, especially when more subjective rules come into play. However, block themes have more wiggle room at the moment. There are so few for users to test that it makes sense to let things slide. One of the Themes Team’s previous hard lines has been that bundled front page templates must respect the user’s reading settings. This meant that if a user explicitly chose to show blog posts on their front page, the theme must display those posts. Mayland Blocks is the first that I have seen get a pass on this, a hopeful sign of more leeway for directory-submitted themes in the future. Block themes are a different beast. HTML files are not dynamic, and there is no way to put a PHP conditional check in a front-page.html file in the same way as themers once did in a front-page.php template. There is a technical workaround for this, but I do not think it is necessary. Block themes are changing the game, and the guidelines will need to follow. I love seeing the contribution — any contribution, really — of another block theme to WordPress.org. However, I want to see more artistry on top of the Blockbase parent theme. Like this: Like Loading… [ad_2] Source link
Continue readingNew Blocks, New Widgets Screen, and Pattern Directory on Deck – WordPress Tavern
[ad_1] WordPress 5.8 beta 1 is ready for testing. This upcoming release makes major strides towards solidifying WordPress’ site building capabilities, along with improvements to features users have enjoyed since the launch of the block editor. It is one of the most feature-packed releases in recent history and as such requires all hands on deck for testing. New blocks in 5.8 include Page List, Site Title, Logo, Tagline, Query Loop, and Duotone. I decided to take each one for a spin this weekend on a test site, putting myself in the shoes of someone trying these blocks for the first time. I was surprised to learn that the template editor will be available to sites using any WordPress theme, since all the previous FSE testing rounds have called on testers to use the latest version of the TT1 Blocks Theme. It will be interesting to see how users respond to this and if it works well with older themes. Users can now create and edit custom templates for pages and posts using blocks. The template editor includes the new List View panel that gives an overview of all the sections and blocks in the template. Most of the new blocks in 5.8 are intended to work within the context of the template editor, but they also work in the post editor. The Page List block magically populates a list of all the pages on a site as soon as it is inserted. Unfortunately, there isn’t a way to delete a single page from the list. If you try to delete a page the entire block disappears. This seems like a bug and is a frustrating experience in the context of the post editor. It may be more useful in terms of building navigation but this seems like a rough first pass. The Query Loop block comes with some different designs for how the loop could be displayed. Once a basic layout is chosen for a starting point, users can further customize the blocks within the loop, including typography, color, length of excerpt, and more. The Site Title, Tagline, and Logo blocks all seem to work as expected but I found previews to be unreliable for things like alignment and spacing. At this point in time, it seems like template editing will be better suited to users who are more adventurous and experimental when it comes to new features. Duotone is a fun new core block that you can see in action below, demonstrated by WordPress documentation contributor Milana Cap. The block adds images effects that can be used in media blocks. Theme and plugin developers can also employ and customize the effects for their own particular use cases. Oh. My. Gutenberg. Imagine images in duotone on your website 🤯 And now that you imagined it, you want it, right? Right? It’s coming up in #WordPress 5.8 😍 stay tuned 😊 pic.twitter.com/t5JHBcTEOV — Milana Cap (@DjevaLoperka) June 9, 2021 Hello New Widgets Screen! WordPress users will be greeted with a new block-based widgets screen in 5.8. It allows you to use blocks in any widgetized area. It wasn’t until I saw how this works that I realized how rigid our old widgets system was. Whatever functionality you were trying to insert had to be readily available as a widget or shortcode. Now any block from the vast world of blocks can be added to widgetized areas. Justin Tadlock wrote a post about how users can disable it with the Classic Widgets plugin. Should you disable it? Not unless you are forced to because of using a theme that doesn’t support it very well. Using blocks in widget areas is going to give you much more flexibility for what you can insert. You can even continue to use the old style widgets via the Legacy Widget block. Users may need a little time to adapt to the new interface but it’s worth it to have access to the growing world of innovative blocks. Pattern Directory Will Be Integrated with WordPress 5.8 The new Pattern Directory will launch on WordPress.org along with the 5.8 release. Justin Tadlock recently amplified the Design Team’s call for pattern contributions that would be available to users right away. Several have already been submitted via GitHub issues for the directory and the creativity here is energizing. In addition to introducing an exciting new avenue for designers to put their work out into the ecosystem, the Pattern Directory stands to become a valuable resource and inspiration to users who are designing their own websites. A “How It Works” pattern submitted by Lax Mariappan At launch the directory will only contain patterns that use core blocks but using blocks from WordPress.org may also be a possibility in the future. “There have definitely been some discussion of allowing any blocks from the Block Directory to be used and that they would be auto-installed if someone inserted the pattern,” Shaun Andrews commented in response to a theme studio inquiring about submitting their own patterns that use free blocks. “I believe this is possible, and something we should do, but there simply hasn’t been any work done to enable it yet. “We’re focused on getting the first iteration of the Pattern Directory launched, and then we plan to continue improving things.” Pattern transformation is a new feature launching with the new directory, which allows users to convert a block or collection of blocks into different patterns. Patterns can also be recommended and selected during block setup, which should make product onboarding easier. These are just a few features coming in WordPress 5.8 that need testing. Check out the 5.8 beta 1 release post for a more comprehensive list of all the improvements that are on deck. The official release is scheduled for July 20, 2021. Like this: Like Loading… [ad_2] Source link
Continue reading