Tag Archives: Block

The Block Editor’s Main Competitor Turns Up the Heat

[ad_1] Now that WordPress is a full-featured Content Management System (CMS), it needs more tools to help create stellar websites. The native Block Editor is a step in the right direction, but in this Elementor review, we’ll showcase the clear leading competitor to the platform’s creative vision. On the surface, Elementor is another in a long line of page builder plugins with increased scope over what WordPress offers out of the box. On close inspection, it’s almost a framework in itself. You could conceive a website and content using the functionality available, without breaking into WordPress’ toolset. For this Elementor review, we’ll look at how to use the page builder to develop layouts. What’s more, we’ll try and compare it to the Block Editor, and judge its future within the WordPress ecosystem. Elementor Review: Introducing the Page Builder Unless you’re super-new to WordPress, you’ll have heard of Elementor. After all, we’ve featured it on the blog many times over the years. It’s a page builder plugin at heart that has rocketed to become the most successful WordPress plugin of all time. It provides you with a strong and robust set of customization options to help take a literal blank page and turn it into a site matching your exact requirements. Digging deeper into what’s on offer, there are many strings to Elementor’s bow: Editing. You have a full suite of tools to help construct layouts, starting with the drag-and-drop live editor. There are a few cool User Interface (UI) and User Experience (UX) inclusions too, such as the Navigator and Finder. Design. Apart from the extensive layout options, you can also work with typography and colors as you would with a high-powered graphic design tool. Along with basic customization, you have almost limitless scope for adding interactive, dynamic animations, micro-elements, and much more. Marketing. Elementor includes a few different aspects to market your site. For instance, there’s a built-in form builder; a bunch of widgets to help you add a Call To Action (CTA), pricing tables, social media icons, testimonials, and more; counters; and much more besides. Element Builders. We’ve mentioned the form builder, but there’s also a comprehensive pop-up builder, WooCommerce builder, and theme builder too. The general goal of Elementor is to give you almost zero reason to go searching for another creative plugin on your site. The development team look to add all the practical features you need to build and launch your website. We’ll have more to say on each of these aspects later. For now, let’s discuss Elementor’s place within WordPress. How Elementor Fits Into the Rest of the WordPress Ecosystem Before Elementor was released, page builder plugins were functional and solid. The likes of Beaver Builder (see our review) ruled the roost, and the flexibility of that plugin is still evident today. Though, once Elementor arrived, it changed the game. There were more options to change every aspect of your site, and also so-called ‘front-end editing’ that showed how your site would look. The big talking point at the time centered around how adaptable the editor is when building layouts. You can be almost pinpoint accurate when it comes to implementing the ‘box model’ on your site. It’s a graphic designer’s (and front end developer’s) dream: Though, as Elementor has evolved, it’s gained more ground in areas outside of editing. For example, form plugins can’t rest easy – Elementor’s built-in form builder does away with the need for a third-party plugin. Other WooCommerce themes will sweat too, as Elementor lets you create a fully-functional store with its toolkit. In fact, almost no niche is safe when it comes to Elementor’s offerings. Because of this, the user base has shot up. It helps that there’s a huge community initiative too – almost as vibrant as WordPress itself. It’s understandable that WordPress’ top brass are hot under the collar. The Elementor team has come under fire due to misleading ads that undermine the WordPress project. Given that the Block Editor is front and center when it comes to WordPress’ key selling points, a solution such as Elementor bundled with its own blank starter theme is trouble. On the whole, the next phase of WordPress will be a fight between Elementor and the Block Editor. This is good for competition, although it could mean huge fallout in the near future. Elementor’s Competitors (And How It Stacks Up) As we’ve touched on, there are a few competitors chasing Elementor right now. The Block Editor is (of course) the primary target because it’s a native way of building a layout within WordPress. Right now, the Block Editor can’t touch the breadth and depth of Elementor’s functionality. Though, the core development team are all hand on deck to try and bring Full-Site Editing (FSE) to the masses sooner rather than later. When this happens, expect fireworks between leading WordPress figures and Elementor. There are also other page builders vying for attention – the most notable being Beaver Builder: This is another solution we’ve talked about before on the blog, and it has a different aesthetic and goals to Elementor. You could argue that Beaver Builder is more focused on building layouts, rather than becoming a framework within WordPress. Though, it’s fair to say there are hardcore fans of Beaver Builder as much as there are Elementor. The previous ThemeForest darling in the WPBakery Page Builder is falling behind as a go-to solution as well. Even a cursory glance at ThemeForest’s marketplace will show you that Elementor is mentioned just as much as the previous Visual Composer. There are a bunch of other page builders on the market, such as the Divi Builder, and even full themes such as Avada. Though, it appears as though there are two camps – plugins that lock you in using shortcodes and custom infrastructures, and those such as Elementor that don’t. The public is voting for no lock in, and it will be interesting to see what the likes of Divi, Avada, and even

Continue reading

The Road Toward Deeper Responsive Block Design – WP Tavern

[ad_1] Gutenberg project lead Matías Ventura announced the Preliminary Road to 5.9 on the Make Core blog earlier today. He covered several big picture items, including several sub-points for each. He also linked to a GitHub issue with specific tasks and tickets that need work. The post covers notes on block patterns, navigation menus, the theme.json interface (global styles), design tools, and editing flows for block themes. There is a lot of information to take in and enough areas to cover various interests. The most exciting focus of 5.9 might just be going deeper into responsive design at the block level, whether this is under-the-hood code or block options available via the UI. “One of the biggest points of friction for pattern and theme builders are the lack of responsive tools available at a block level,” wrote Ventura. “This needs to be solved in a way that doesn’t disproportionally increase interface complexity.” Intrinsic Web Design With Blocks Mobile design patterns shared by Ventura. It is easy to become disgruntled at the slow progress toward responsive block options over the last few years. I am not entirely unhappy with it because I want the team to be methodical and approach this in a future-proof way, at least to the extent that it can. Far too often, what we have seen with requests and even third-party plugins is the use of viewport-based media queries for controlling how blocks respond to different devices (e.g., desktop, tablet, and mobile). While such controls can sometimes be the right tool for the job, they are not always the correct path for component-based design. Media queries tend to favor holistic design methodologies. However, component-based design is the modern face of the web. Blocks are just another component, and because developers or even users can place them anywhere in the overall design, we must approach how they respond to their surroundings more so than the browser viewport. “The block model is a good case to apply some intrinsic design principles, since a block can occupy a place in many different layouts and containers, for which prescriptive media queries that don’t take context into account are inflexible,” wrote Ventura. A simple example to look at is the core WordPress Columns block. We could easily add media query options for when each inner Column block breaks. However, how should the typography respond for three columns vs. four and at different widths? That is a function of the container’s size rather than the viewport. And, how do such media queries work when Columns are nested within another Column? This becomes a more complex problem to solve if you are putting layout controls into the hands of users. Pushing the fast-forward button on responsive block options might feel good at the moment, but it could also create legacy baggage that will be hard to drop when a better solution rolls around. Even something as seemingly simple as a basic website header can become complex when designing for user input. For theme designers, there is no way to know how many characters are in the site title, for example, or how many items are in the nav menu. The block system can complicate that further by allowing end-users to drop in other unknowns. “Each block area should be intrinsically responsive allowing blocks to compose together, wrap, stack, and organize themselves to fit the different spaces and screens,” wrote Ventura. “For this to work well, container blocks need to absorb more layout controls.” He also mentioned container queries as a possible expansion point when they are fully supported by browsers in the future. Chrome Canary currently has a support flag to enable the feature. Container queries are a bit of a Holy Grail for designers. As web designer Ethan Marcotte wrote four years ago: Maybe I’ll start here: in the last few years, my design work has focused much more on patterns, and less on “pages.” Instead of treating a responsive design as a holistic, unified thing, where every part of the layout changes and adapts at the same rate, it’s more helpful to break a responsive layout down into smaller, reusable bits of design, including things like “masthead,” “footer,” “image caption,” and so on. In other words, my design process involves looking at a responsive design as a network of small layout systems. Each of those components are basically little responsive designs themselves, with their own sets of breakpoints. Sound familiar? Yes, the WordPress block system is built on that same foundation of small layout components. Anything that WordPress does today at the UI level needs to account for the container queries of the future. Or, at least make use of existing tools that could replicate the feature in some ways, such as the min(), max(), and clamp() CSS functions. The trouble is figuring out which features should be exposed as block options vs. being handled under the hood. The development team must strike a balance between the user experience and flexibility for designers. Some things should “just work” out of the box, and others should be configurable on a case-by-case basis. This should be one of the more interesting, complex, frustrating, and rewarding problems to solve in the WordPress 5.9 cycle. For those looking for a challenge, it might be the perfect entry point. Like this: Like Loading… [ad_2] Source link

Continue reading

Gutenberg 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 reading

From eCommerce Integration to Location-Based Controls, Block Visibility Pro Expands Upon Its Free Version – WP Tavern

[ad_1] It has been several months since I last dived into Nick Diego’s Block Visibility plugin, and it is now one year since the initial release. Recently moved on from his past job into the WordPress product space, he has been building one of the best context-based plugins for showing or hiding content. In January, Diego touted some of the ideas he had for a yet-to-be-released Block Visibility Pro. He was already fulfilling user needs, but there was so much left to be explored. “As Block Visibility grows, there will be advanced and/or niche functionality that will be useful for certain users,” he said at the time. “Think integrations with other third-party plugins. There will always be a free version of the plugin but some of these additional features will ultimately be provided by a premium (paid) add-on called Block Visibility Pro.” Diego quietly released the pro add-on in June, which does not take away from the free version. Everything in it is a pure value-add and helps specific sets of users. Last week, he released Block Visibility Pro 1.1.0, and I managed to get a test copy to play around with. In short, I am more impressed than I was when I first covered the free version in January. Pro Additions Early versions of the free plugin had visibility controls for all visitors, user roles, and start-and-stop dates. Since then, Diego has beefed up the options to include screen size, logged-in status, and user accounts. It also integrates with Advanced Custom Fields and WP Fusion. That is more than many other content-visibility solutions will offer before needing to upgrade to a commercial or pro version. The current pro version includes conditional controls for the following: Location (Query and Post) Time-based and day of week WooCommerce Easy Digital Downloads Browser and Device URL Path Referral Source The Location controls are what I have found myself tinkering with the most. They are handy at the moment but will offer more power when used in conjunction with WordPress’s upcoming site editor. Location, query-based visibility controls. The Location controls are essentially query-based visibility options. Users can choose to show or hide blocks based on post type, taxonomy, and more. Everything from individual post attributes to the archive type is available. Users can also create multiple rule sets, combining various location-based options. For shop owners, the WooCommerce and Easy Digital Downloads integrations are extensive. Users can display blocks based on shopping cart content, customer metrics, and product metrics. This could come in handy for promotions, coupons, and similar features. One of my favorite features, which is also included in the free version, is a popup option for selecting which visibility settings should appear in the sidebar. Toggling visibility controls in the Visibility tab. This feature reduces the footprint of the plugin’s Visibility tab in the block sidebar panel while giving users control over which options they would like to use. It looks similar to a current proposal for the Gutenberg plugin that would allow users to toggle specific controls: Proposal for toggling block typography controls. The differences between the two are in the location of the “ellipsis” button to open the popup. The Gutenberg proposal has it at the top of the tab. Block Visibility adds it as a control within its Visibility tab. However, the concept is the same, and the plugin provides a real-world test of how the feature could work. Thus far, I am happy with the result. It allows me to hide options that I would rarely use. I am eager for something similar to eventually work its way into core WordPress. From Developer to Developer If I am being honest, I am a bit envious of the work Diego has done. Many do not know this, but I also built a similar solution to Block Visibility in 2019. It was before I joined the staff here at WP Tavern. Before seeing that project mature, I handed it over as part of a larger IP sale. I point this out because I understand the complexities of building a solution that works from a technical standpoint while also being user-friendly. It is not easy, but Block Visibility seems to hit the right balance. And I do not say this often, but Diego’s work far exceeds anything I had built or even had in the pipeline. It is on another level, so a part of me is glad that he and I are not competing in this space. At the same time, I wish I could go back and implement some of these ideas on my former project. Like this: Like Loading… [ad_2] Source link

Continue reading

Full Page Patterns Are Still the Missing Piece of Block WordPress Theme Development – WP Tavern

[ad_1] It was the early days of the Gutenberg project. Many on the Theme Review Team and those in design circles were trying to wrap their heads around this new concept called blocks. In particular, we wanted to know how it could be applied to theme development. There were many discussions on the pros and cons of the early editor. Overall, there was a bit of cautious excitement in the air, our optimism tempered by a buggy version of alpha-level software. The block system could potentially solve one of the biggest hurdles of theme development: inserting default/demo content for a full page into the editor. I cannot remember who initially explained the idea, but it was a lightbulb moment for many at the time. The general concept was pre-building a custom homepage or any page design that users could choose visually. It would all be done through a standardized block system, and we would no longer need to rely on piecemeal theme options, third-party plugins, or attempt to work around the review team’s “do not create content” guideline. No one really knew how this would work in practice, but we understood the theory of how it would make the life of a theme developer much simpler. In October 2019, Automattic developer Jorge Bernal opened a ticket titled Starter Page Templates. His team was working on a template selector for mobile apps, and the WordPress.com Editing Toolkit already had the feature. The goal was to bring it to the core platform, allowing third-party theme designs to build on top of it. Starter page templates idea initially shared in the ticket. Because the term “template” is overused in the WordPress space, I will refer to these as “page patterns.” This naming convention was coined by Noah Allen, a software engineer for Automattic, in the ticket. It makes sense because we are actually talking about a page’s content rather than the wrapping template. The Genesis Blocks plugin is one of the best ways to understand the page pattern concept. It has a Layouts button at the top of the editor that, when clicked, creates an overlay of designs to choose from. Selecting a full-page layout from Genesis Blocks. These designs are split between sections and layouts. Sections are the same thing as patterns in core WordPress: small, reusable pieces of starter content. Layouts are full-page starting points for users to create various types of pages. The StudioPress/Genesis team was not the first to market this concept. However, they have created a well-rounded user experience on top of the WordPress editor. You will find similar experiences via GoDaddy’s onboarding process for its managed hosting service. The Redux Framework allows much the same, and Editor Plus offers templates and patterns from the Extendify library. That initial excitement has waned a bit. It felt like that early promise was a dream that would never be a reality. Theme authors, especially in the commercial space, have long offered home-brewed solutions for the one-click insertion of full-page content. Whether via a ThemeForest project or a popular theme on WordPress.org, there are endless examples of everyone solving the same problem. One might even argue that these custom inserters are so ingrained into theme agency systems that anything WordPress offers at this point will not appeal to those who have already brought their solutions to market. Where the core platform has failed to meet user demands, our development community has stepped up. Some of you may be thinking that the current block patterns system works for this. Yes, and no. Theme authors could shoehorn full-page designs into it, but the user experience is lacking compared to third-party solutions. Patterns today are one of the best theming tools available, but they fall short of what is needed to see this thing through. The foundation of this feature exists via the Patterns API. From the theme author’s perspective, they merely need a method for flagging a pattern as a full-page layout, separate from the others. However, the UI and UX flow need an overhaul. The flyout panel for the current inserter does not cut it, especially on large screens. A fullscreen overlay has become the de facto standard among other systems. Users should also have another option between selecting from an existing page pattern or starting empty upon creation. “I think this would be so useful to have in the core,” wrote Ana Segota of Anariel Design in a recent comment on the ticket. “I created 2 FSE themes so far and also our latest premium theme is made with block patterns and this is exactly what I thought and talked with few people about. It would be great when a user opens a new page, to chose design/page patterns however we called it and it starts editing it right away. Most of the users just want to add a page, choose a layout and start adding their content.” Of course, this is not a revelation to the average theme author who works with end-users daily. Inserting or importing entire page designs into WordPress is one of the most common requests. WordPress is almost there with its current patterns system. We just need to take it to the next level. Like this: Like Loading… [ad_2] Source link

Continue reading

Open Survey for WordPress Theme Authors on JSON Files and Block Themes – WP Tavern

[ad_1] WordPress 5.8 introduced an opt-in system for themes to configure block settings, styles, templates, and more. It is done through a new theme.json file that authors can put at the root of their theme folders. Anne McCarthy, the lead of the FSE Outreach Program, announced a survey earlier today to get feedback from developers on this feature. “Since this new mechanism is an early step towards a comprehensive style system for the future of WordPress, it’s important to hear from everyone who is currently using theme.json to learn more about how folks are using this tool and what might make sense to include in Core going forward,” she wrote in the announcement. The survey is open to all theme authors who have used theme.json, giving them a chance to put in some early feedback and help steer the ship going forward. Because I have worked extensively with this system over the past few months, I had a few things to say. Plus, I just like participating in WordPress-related surveys. I also decided it would be an opportunity to share some of my unfiltered thoughts from a development perspective on the current state of theme.json. What follows are my responses to the survey’s questions — well, the tidied-up version. Note: This is a developer-centric post that might not universally appeal to all of our readers. I have attempted to explain some things in user-friendly terminology, but some prerequisite knowledge of theme development may be necessary. Experience The first question of the survey is pretty cut-and-dry. It asks what your experience is with building block themes or using theme.json. It provides four choices (and an “other” option): I have built and launched block themes. I have experimented with building block themes. I have explored using theme.json with a classic theme. I have used a block theme, but I have not built one yet. I chose the first option because I have already built two block themes for family and friends. These were simple personal sites that I already maintain for free — honestly, I need to start charging. I am also working on a theme that I hope to release publicly. How It Started and How It’s Going The second question asks how one got started with block themes and theme.json. The choices are between forking an existing theme, using the Empty Theme, or starting from scratch. Again, this is one of those things where I have experimented with each direction, but I cannot remember the exact starting point. The bulk of my work has come from forking a theme that I last worked on in 2019. I plan to release this as a new theme for free at some point. I am mostly waiting on the following: Navigation block development to settle down The Post Author block to be split into smaller blocks A robust set of comment-related blocks Post Featured Image block to have a size option I think I could realistically release a use-at-your-own-risk beta version of my theme today if those items were addressed. Templates and Template Parts The survey asked which templates and template parts themers always include in their block-based themes. There was a freeform comment field — steps upon soapbox… I have a love/hate relationship with block templates at the moment. The static nature of HTML templates reminds me of simpler times when theme development was less complicated. However, this also presents a problem in a dynamic system. I cannot remember the last time I have built a traditional, PHP-based theme with more than one top-level template: index.php. The dynamic pieces have always been the guts of the thing, which are template parts. With PHP, it is easy to set some variable or use a function call to contextually load the templates parts necessary for whichever page a visitor is currently viewing on a site. The block template system does not work like that. It essentially forces developers into breaking the Don’t Repeat Yourself (DRY) principle. For example, if a designer wanted to display a different header template part for pages and posts, they would only need to create a header-page.php or header-post.php template in traditional themes. However, because the block template system is different, they must now create two top-level templates, single.html (post) and page.html, to accomplish the same thing. This is a “bad thing” because theme authors must duplicate all the other code in each of the top-level templates. There is no way to contextually load different template parts. To answer the question: I am using almost all of the possible top-level templates out of necessity. I also answered the second part of the question and listed my most commonly used template parts (broken down by hierarchy): Header Content– Loop– Sidebar Footer The content-*.html and loop-*.html template parts are those with the most variations. Defining Colors The next section of the survey asks how theme authors define their color palette slugs in theme.json. Believe it or not, naming colors may be the most controversial topic in the theming world in years. The only two things generally agreed upon are “background” and “foreground” colors. Morten Rand-Hendriksen opened a ticket in 2018 for standardizing a theme color naming scheme. It was not the first discussion and has not been the last. The problem it was meant to address was the slugs for colors in the system, which is how themes define their palettes. Once a user makes use of a preset color, the slug is hardcoded into their content. Switch to another theme with different slugs, and the old colors disappear and do not automatically change to the new theme’s colors. I use semantic names that follow something that closely resembles the Tailwind CSS framework’s shading system. Instead of red-medium (descriptive), I would use primary-500 (semantic), for example. A semantic approach would allow theme authors to define a set of colors that are updated each time a user switches themes. Of course, there are other schools of thought, and even everyone who prefers

Continue reading

Create a Publishing Task List With the Todo List Block – WP Tavern

[ad_1] Rich Tabor, the Senior Product Manager of WordPress Experience at GoDaddy, has been on a bit of a publishing productivity and workflow kick as of late. The co-creator of the Iceberg Editor plugin released a Markdown Comments block last month, allowing users to write editor-only notes. Last week, he launched the Todo List Block plugin. The latest plugin is yet another simple, editor-only tool. The goal is to allow publishers to create and keep track of tasks on a per-post basis. It is essentially a way to create a publishing checklist directly in the editor’s content canvas. Adding a Todo List to a post. For solo writers, it should work well as a standalone plugin. Larger teams might consider coupling it with a plugin like Post Descriptions for a more robust solution. One annoyance when using the block is that clicking the Enter button twice on the keyboard does not break you out of the Todo List. This is how lists work in core WordPress, allowing users to create a new paragraph or add a different block. I am not sure how to move out of the Todo List via the keyboard. The issue could be related to how the plugin builds the list. Technically, it creates two separate blocks. The Todo List block is a wrapper for individual Todo Items. However, I am generally a fan of this approach because it allows developers to create block options for each item (e.g., different colors for each), a feature I have needed on occasion with the core List block. Plugin + Theme Integration Theme JSON integration. One of the hardest things about developing plugins in past years was having no standardized method for themes to style plugin output. Every plugin author had their own system, which would often change from version to version, and theme authors had to keep up. Tabor may have just struck the perfect balance with the Todo List block. It defines its own styles but leans on the new theme.json standard available since WordPress 5.8. Almost anything a theme designer might want to style is easily configurable via JSON, and the plugin has an example bundled within it. Theme authors can simply copy the code wholesale, paste it, and modify it to suit their design. Or, they can just use the bits they want. I only wanted to change the text color, so it was as simple as plugging in a single custom value. This is the sort of forward-thinking that we need in this new era of blocks. And, this solution might just be the standard that other plugin authors should follow. It provides themers with an uncomplicated method for customizing plugin output and does not require nested styles to overwrite rules with high specificity. A Checklist Block Type in WordPress My initial interest in the Todo List Block plugin was its similarity to checklists (also called task lists). Essentially, these are unordered lists with a checkbox input for each item. For transparency, I mostly just want to build a recipe block pattern with a checklist. This would let readers check each step in the instructions as complete. Creating a task list of recipe instructions. It is a relatively standard feature in Markdown editors to be able to create checklists by typing something like the following: – [ ] Incomplete task. – [x] Completed task There is a ticket to bring a similar feature to the Gutenberg plugin. It was opened in 2019. However, other than a few people chiming in, it has not seen much traction in the two years since. Gutenberg project lead Matías Ventura shared a concept he had tried out early in the ticket: Given the similarity with the Todo List block, maybe we can give Tabor a little nudge and have him bring a checklist solution to the masses. Like this: Like Loading… [ad_2] Source link

Continue reading

Guide to the new Query Loop Block • WPShout

[ad_1] I was talking with the current students in the Up and Running Bootcamp last week about the new Query Block in WordPress 5.8. I had to admit I’d not really played with it much myself. For that reason, I was quite excited that when I sat down to look for posts to share this morning with you all, I found this great little guide to it that Justin Tadlock put together over on the WP Tavern a few weeks ago. For those who aren’t yet comfortable with the name of this block, here’s Justin’s great summary: 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. Visit wptavern.com → [ad_2] Source link

Continue reading

Understanding Block Plugins • WPShout

[ad_1] I loved reading this write-up from Rich Tabor about the what and why of Block Plugins. For those new to this whole thing, I’ll pull his opening summary: What are Block Plugins?  If you’ve built blocks before, you may be asking what’s the big deal about block plugins. For the most part, you can think of block plugins as one block, registered and compiled completely in JavaScript, that serves a singular function. These plugins exist solely to distribute a block — and nothing more… and these plugins are meant to be included within the Block Directory. He goes in to way more besides that—how to make them, what they look like, and how make sure yours works—so be sure to give the whole thing a look. Visit richtabor.com → [ad_2] Source link

Continue reading

Gutenberg 11.1 Adds Drag-and-Drop Support for List View and Upgrades Block Borders – WP Tavern

[ad_1] The Gutenberg plugin continues to march forward. Yesterday’s release, coming merely a day after the launch of WordPress 5.8, brings several new features and nearly three dozen bug fixes. The big-ticket items are drag-and-drop blocks in the list view and a much-needed upgrade for border support. Theme authors should enjoy the ability to control the Columns block’s stacking on mobile and some updated design controls for nav menus. While labeled an “enhancement,” themers should also check their designs against a breaking change to the RSS block’s updated styles. Drag and Drop Blocks in List View Dragging a block around in list view. Drumroll, please. The moment we — or at least many of us — have been waiting for has finally arrived. The editor’s list view has become a powerhouse for managing long documents with many blocks. Over the past dozen or so releases, the development team has continued to tack on necessary feature after necessary feature. In version 11.1, users can drag and drop blocks from within the list view to order and organize content. However, users are not merely limited to moving things around within the list view itself. They can drag blocks from the list over into the content canvas and vice versa. I do not often use emoji, but sometimes I like to dole out a slow clap for a job well done. 👏 👏 Border Support Adding a dashed border to a Group block. I have already been having a bit of fun with the new border options. Lately, I have been in the holiday spirit because I was getting ahead and buying my Christmas tree in July (when you find the good deals). This inspired me to create a coupon code block pattern, and the Group block’s border support was perfect for this. Gutenberg 11.1 refines the user experience for border options. The development team tightened the UI and placed the settings into logical groupings. Only the following core blocks have partial or complete border support: Button Group Image Search Table Users can also define individual corners with the border-radius option in this update. I would love to see the same treatment for the top, right, bottom, and left borders in the future. I also would not mind seeing a double-border style. Columns Block: Stack on Mobile Adding post metadata to an unstacked set of columns. By default, individual Column blocks will stack on top of each other in mobile views. However, users can now disable this via the parent Columns block on a case-by-case basis. This has also been one of the missing pieces for more layout control in block themes. One of the primary use cases for a Columns block that does not break on mobile devices is post metadata sections that should be inline. For example, theme authors often want to align the post author, date, and comments link in a single row below the post title. This toggle switch sort of moves us in that direction. However, it is a stopgap solution that does not afford theme designers the flexibility they are accustomed to with CSS (this is not generally a complicated affair). Before block themes and the site editor are rolled into core WordPress, theme developers will need fine-tuned responsive control over the Columns block and, perhaps, some type of row/inline/flex block to go along with it. Theme authors who need to target the Columns block based on whether mobile stacking is disabled can use the .is-not-stacked-on-mobile class. Post Terms and Tag Clouds Controlling the number of tags output. The development team has crossed one of my months-long pet peeves off the list. In past releases of the plugin, the Post Terms block (variations of Post Tags and Post Categories) has displayed a pipe (|) separator between individual items by default. It now shows a comma, followed by a space. Theme authors can change this in their block templates, and users can customize it from the editor. The setting is located under the “Advanced” tab in the block options sidebar. The Tag Cloud block got a small but much-needed upgrade. Users can now set a limit on the number of tags to display. By default, it is set to show 45 tags. Navigation Submenu Colors The Gutenberg development team added two new color options for the Navigation block. Aside from its existing text and background colors, users can now change the text and background colors for submenu items. The Navigation block, while improved, still seems to be one of the trickiest pieces of the site-editing puzzle. It is trying to be the Jack of all trades, mastering few — if any — solutions. And, there is already a ticket gaining traction that would allow users to stuff a wider range of inner blocks into it. But, we have submenu text and background colors, which is a win. Only, they are named “Overlay Text” and “Overlay Background.” I am unsure whether it works as part of the mobile responsive menu. Gutenberg seems to have once again failed to bundle its front-end navigation JavaScript. Like this: Like Loading… [ad_2] Source link

Continue reading
1 2 3 4