[ad_1] WPZOOM is coming in strong with its first block theme approved for the WordPress Themes Directory. UniBlock is a beautifully designed theme that is well-suited for businesses and freelancers. The company plans to adopt the concept of full-site editing in other WPZOOM themes as well, following the release of UniBlock. UniBlock’s default look is sporting a darker color palette in the navigation and above the fold, with a lighter background for the rest of the website. The video on the sample homepage uses the free WPZOOM Video Popup Block plugin, which supports Vimeo and YouTube. It’s a simple, lightweight block that allows users to customize the play button and play icon. After activating the theme, clicking on ‘Customize’ will prompt the user to install the video plugin. It can also be converted to a Custom HTML block or removed entirely at the user’s discretion. UniBlock’s 19 custom block patterns include everything one might expect from a business theme but, most impressively, it ships with five full-page patterns: Front Page About Services Blog Contact Alternatively, users can assign the page template in the post settings to get the same effect. These full-page patterns are convenient for speedy page building. They make it possible to get a basic business website up in a matter of minutes. Here’s an example of the Services full-page pattern that will instantly embed when selected. Users can delete any sections they don’t need, add more blocks and patterns, and quickly fill in all their own information. Separately there are patterns for a footer with text, links, multiple arrangements of featured boxes with text and button, multiple designs for call-to-action sections, pricing tables, team members with social icons, testimonials, header cover, sidebar, 404 page, and more. Users can delve even further into customizing the templates with the site editor, as UniBlock is packaged with nearly two dozen templates and template parts. Here they can also edit the menu and adjust global styles. WPZOOM is developing a Pro version of the theme to release in a few weeks with support for importing the whole demo, multiple color schemes, multiple demos, premium block patterns, and additional header and footer layouts. Check out the demo on the WPZOOM website to see the theme in action. WPZOOM has also written documentation for UniBlock, which covers general topics like how to use block patterns, how to set up the front and blog pages, and how to create a menu in the site editor. Since the company’s most popular themes are what would be considered classic themes, UniBlock is new territory for most of their customers. It is so far the only block theme among WPZOOM’s collection of 31 themes. Block theme adoption is slowly making its way across WordPress’ major theme shops and the official directory is now hosting 160 themes tagged for full-site editing. As more longtime theme companies make their block theme debuts and develop a base for future themes, WordPress users may start to see a rapid acceleration of the number and variety of block themes available. UniBlock is so far one of the few block themes in the directory with a singular focus on business websites. It is available to download for free from WordPress.org or via the admin themes panel. [ad_2] Source link
Continue readingTag Archives: Block
Learning 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 readingShould Users Be Able To Select More Than One Block Style? – WP Tavern
[ad_1] When I first tried the block styles feature in WordPress, I was impressed. As a theme creator, it was a simple way of allowing users to select a design-related class without them actually needing to know what was happening under the hood. In that first week or so, I hit the problem that many others had. I wanted to combine two or more classes/styles to offer a wide range of user options. This was back in late 2018 or early 2019 — around the time of the WordPress 5.0 release. Others have requested the ability to combine styles since, and Keith Devon, the co-founder of Highrise Digital, brought the issue up again via Twitter last week. However, these multiple requests have never resulted in a change to the core code. This snail’s pace has been beneficial. Jumping too early on some features when others have yet to mature can create unnecessary legacy baggage. Over the past couple of years, I have reassessed my position on combining block styles. As the editor has evolved, there is a clearer vision emerging around what options users will have. While I initially wanted to combine block styles, I am not so sure anymore. The primary reason for this is that core has already made many obsolete through block options, and it will continue to do so with other controls in the future. When WordPress itself handles this, it creates a standard that all themes can rely on. With one of those passion projects I’m building in my free time, I currently have six styles for the Image block: Rounded Flip: Horizontal Flip: Vertical Polaroid Polaroid: Tilt Left Polaroid: Tilt Right Polaroid-style image tilted left. There are times when mixing and matching some of those might make sense. For example, the Flip: Horizontal style fits well with all the others and would not cause issues when combined. I could also go overboard by adding choices to meet every possible variation. Some combos would break down entirely or not be aesthetically pleasing. For example, the Rounded style does not work well with the Polaroid styles. However, these are simple styles that barely scratch the surface of what is possible. Most of these are not block styles that I would want to ship with a theme. For example, the Rounded style could easily be handled via the WordPress-supported border-radius option. The Polaroid style is just a fancy name for some padding and a box-shadow on the image. These are all standard design features that should eventually be a part of the base editor experience. Currently, themes that ship such styles are filling in the gaps where WordPress has yet to do so. In the short term, theme authors must cater to their user base. However, down the road, WordPress should offer a more robust set of tools that cover the basics. There really is no reason for every theme to have a different, non-standard slug (i.e., class name) for essentially the same block styles (e.g., Polaroid vs. Framed vs. Borders). It creates cross-theme compatibility issues that we should avoid when possible. Block styles are handy for introducing quick methods for achieving these fundamental design options, but I am looking at what they should be for the long term. If core WordPress evolves to the point where it makes most of these styles obsolete, what should theme authors do with the feature? That is where more specialized block styles make sense. The goal is the same: fill in the gaps that WordPress leaves open. One example that would be tough to replicate with simple design options would be a tag/label style for the Tag Cloud block, as shown in the following screenshot. Tag/Label style for tags. I also have a Pill Outline style for the same block: Pill Outline block style for tags. Obviously, those two styles would not work together. Creating a system where users could choose both would result in some problematic outcomes. The more complex any two block styles become, the more likely they will conflict with each other. Right now, it is too early to commit to a multi-select feature for block styles. We need to let this thing play out a bit and give the core design tools a chance to catch up. We can reevaluate when most of the blocks packaged with WordPress have a broader set of styling options. At that point, it may even make more sense to begin using block variations, an API that allows developers to preconfigure block attributes. If a solid set of design options exist, it would be simple to offer multiple combinations out of the box for users. In the meantime, I would like to see a reevaluation of the UI for block styles. Shaun Andrews has an in-depth piece, Thinking Through: Switching Block Styles, that explores various options on how we could iterate on it. Like this: Like Loading… [ad_2] Source link
Continue readingGutenberg 11.5 Adds Widget Grouping, Iterates on the Block Gap Feature, and Updates Nav Menus – WP Tavern
[ad_1] Gutenberg 11.5 landed earlier today. It is a hefty release that includes extensive changes to the Navigation block, a new way for grouping widgets, and more block gap feature integration. I have had mixed reactions to the features that made it into the latest release. At some points, I thought to myself, finally, this made it in. At other moments, I rendered my best version of Jean-Luc Picard’s famous facepalm. But, the wheel keeps turning, and the developers who put their time and effort into the project continue to improve it. One quick note is that everyone not running a theme that supports the block editor should check that their backend styles are not out of place. Gutenberg automatically outputs some default editor styles if the user’s active theme does not register its own or have a theme.json file present. This should be bundled in point release such as WordPress 5.8.2 so that users are not waiting for it until 5.9. Navigation Block Changes With nav menus still being a pain point in site editing, Gutenberg has added new levels of complexity. The Site Title and Site Logo blocks are allowed inside of the Navigation container. As Joen Asmussen shared in the original ticket, some complex layouts would benefit from allowing more inner elements within the Navigation block: Navigation block patterns. This could open a world of layout possibilities for theme authors through custom patterns. I have no issue with Gutenberg tackling the foundation for these more advanced layouts. However, we have yet to smooth out the basics of navigation. The experience of searching for and inserting in-site links is lackluster at best, requiring multiple mouse clicks. There is an open ticket for a lighter navigation experience, and that should be the focus. Theme authors should also note that the Navigation block now relies on the CSS gap property for spacing instead of margin. I almost missed this since I customized this for my own projects months ago — welcome to 2021, where we no longer need to rely on hacky margin solutions for simple spacing. This change could impact existing theme designs. FSE Admin Notice Limited to Themes Screen The lone FSE theme admin notice. There are plenty of gripes to be had with the Gutenberg plugin as its features are constantly in flux. However, the most annoying thing about running the plugin has been its persistent, non-dismissible admin notice when a user is running a block theme. In previous versions of the plugin, this notice has appeared on every screen in the backend. Now, it only appears on the Themes/Appearance page. Over the past few months, I have kept the Toolbelt plugin by Ben Gillbanks active for the sole purpose of hiding this notice. Good riddance. Farewell. Widget Group Block Editing a Widget Group block title. While I generally believe the Gutenberg plugin developers and core WordPress make good use of feedback, the block-based widgets system has been one area where the project has dropped the ball. As I have been repeating since September 2020, the feature was fundamentally broken. The goal was to allow end-users to add blocks in more places, but it was never compatible with classic theme markup and styles. I proposed using patterns, but the team went with a Widget Group block. The end result is similar but not exactly the same. The good news is that it fixes what should have been a blocker for the feature landing in core. The better news is that this is likely to land in WordPress 5.8.2 instead of the 5.9 release later this year. I would not go as far as calling it a perfect solution. The experience does not make it immediately clear how to add a widget title. Users must first add a block. Once a block is added, they can then click on the heading/title placeholder that appears. Then, the UI switches to a field for typing the title. The following video shows how the Widget Group block works: I would rather have a bit of a janky experience than no solution at all. At least users now do not have to manually create widget wrappers. Some could even deactivate the Classic Widgets plugin if this issue was a holdup. “Row” Group Variation and Flex Layouts Adding a post meta (byline) section with the Row block variation. To begin testing the new flex layout system introduced in Gutenberg 11.2, the development team has added a variation on the Group block named Row. This allows users to align inner blocks side by side instead of on top of each other in the default “flow” layout. There are tons of use cases for the feature. One of the primary scenarios for theme authors will be aligning post and comment metadata bocks next to each other. Previously, this required use of the Columns block or custom styles, neither of which are ideal. The experience is rough around the edges. I often found it hard to click in the right spot to edit a block, and the appender button did not always appear for adding new ones. The Social Icons block also uses the new flex layout. However, there is currently no way to switch it to flow mode for vertical social links. More Block Gap Integration Gap between each Column block. The Columns block now uses the gap feature introduced in Gutenberg 11.4 for handling the spacing between individual Column blocks. There is no UI for end-users to control this yet, but it is likely to land in a future release as the feature evolves. Gutenberg 11.5 has now added a bottom margin to the post title in the editor. For whatever reason, the development team has made a leap and assumed its current handling of the block gap feature needed this. It is a complex problem to solve. In the meantime, some users might see more whitespace than they are accustomed to between their title and content in the editor. Lots of extra
Continue readingInsights Into Switching Between Block Themes – WP Tavern
[ad_1] Unlike routine testing rounds for the FSE Outreach Program, Anne McCarthy threw a bit of a twist on the Make WordPress Test blog earlier today. The announcement asks users to think about what they would like to see when switching between block themes. The test is open to anyone who wants to participate through September 29. The steps are loose and not required. The goal is to get people thinking and discussing what the theme-switching flow will look like over time. McCarthy asked several questions, but they are merely a starting point for a more open-ended discussion. While I sometimes need structure, I tend to break the rules anyway. The format of this test suited me well today. I am not one for switching themes. Since I learned how to design for WordPress well over a decade ago, I have never moved from one theme to the next. At least not in the same way that the average user would. Instead, every time I have added a new coat of paint on my websites, I have simply switched over the foundation to whatever I had been working on at the given moment. WordPress themes, for me, were always just an iteration upon the last project. One of the cornerstones of programming is to reuse your code, and it is a principle that I have taken to heart. Even now, as I continue to explore block theme design, I am doing so from a gutted version of the last WordPress theme I built. When I think about switching themes, it is not an experience that I am accustomed to. Even when I started working for WP Tavern, the site already used one of my themes with some customizations. It feels like I have missed out. Throughout my entire journey with WordPress since version 1.5, in which the platform first introduced themes, I have never truly experienced the theme-switching process in the most fundamental way. I will soon, but we will talk about that on another day. When I have “switched” themes, I have done so in test environments for writing about them or running tech support for end-users. The call for exploration mainly focused on global design-related features. However, in my experience, these tend to matter far less than what a user’s content will look like. The first thing I do when testing any theme is to load a demo post. Lately, this has been the “Welcome to the Gutenberg Editor” test post. The primary question: Can I read the content comfortably? If I do not get past this stage, I simply deactivate the theme. For this experiment, I chose three themes: I started with that foundation of testing how easy it was to read a simple blog post. Overall, each theme performed admirably. However, Quadrat’s use of the featured image on a single post view felt out of place. One question that keeps me up at night is how cross-theme compatibility will work on the content level. Default block output should translate from one theme to the next with little or no issues. However, custom block styles, font sizes, colors, and the full range of presets are already a problem area. This is not a new conversation. There is an ongoing discussion on standardizing some features. But the cat is already out of the bag and running loose through the house. Global styles and templates are features that themers have been dealing with for years in some form or another. The new systems are just different ways of doing the same thing. However, when design elements merge with content, switching themes becomes more complex without an underlying, standardized system. To illustrate this point, I checked all three of my test themes against a post that used custom block styles, gradient colors, and font sizes. I wanted to push the boundaries beyond a simple blog post. The content was built with my custom theme and an “open canvas” template. Quadrat had a similar template for hiding the post title, but TT1 Blocks did not. The result was, ahem, rough: Of course, my custom theme looks as it should. This is not to say that TT1 Blocks and Quadrat are poorly designed. They are actually two of the best block themes available at the moment. The problem is that they do not share the same block styles and presets. WordPress and Gutenberg are also missing some fundamental layout tools that could make it easier to carry this design from one theme to the next. The most complex piece of the design is with the opening Cover block pattern: Technically, this is a Cover block within another. The bottom layer has a background image with a duotone filter and sets the inner content to 90% width of its parent. The second layer has a theme-defined gradient background and sets its inside container to the left at 50% width. Plus, it has a sprinkling of custom font sizes. These layout controls are only possible through custom block styles or some hacky uses of the Columns block. I chose the former because it was easier, but it also means they are broken when used with any other theme. While I called this the most complex piece of the design, it is actually a simple thing to do with most page builders or with a few lines of CSS. Until WordPress has some type of grid container block, theme authors will rely on custom techniques to make such layouts possible. It can and will get even uglier than this the longer we wait. The open discussions on standardizing presets like font sizes and color names may bear fruit that could help with the more trivial parts. However, I have not seen gradient names pop up in this discussion. I do have at least one ulterior motive for this test. I have long wanted to try more experimental post designs and layouts here at WP Tavern. However, I know that we will eventually switch themes.
Continue readingA World Where (Some) Block Development Is Merely a Templating System With No Build Process? – WP Tavern
[ad_1] What if WordPress developers lived in a world where we could create PHP-based templates that would output data on the front end and handle editable fields via the block editor? Or, we had a system where we could create blocks without a build step? While there are many reasons the modern WordPress editor is not the best fit for everyone just yet, one stumbling block has been building custom interface components. The ecosystem has a deep history of creating bespoke solutions for clients using PHP. These have been custom meta boxes and form fields in the classic editor screen for the most part. When WordPress 5.0 launched with its block editor, it turned the world upside down, often leaving agencies and freelancers with no way to move forward without dedicating massive resources to learning React to build blocks or interact with the new editing screen. The solution? Stick with what you know. It was cheaper and already seemed to do the job well. As we talk about the support window for the Classic Editor plugin, the WordPress project needs people to provide tools for this segment of the ecosystem if it ever plans on bringing them along for the ride. Solutions such as ACF Pro and Genesis Custom Blocks have bridged some of the technical gaps. However, the user experience can be sub-par when using server-side rendering in the block editor. That method works well for some types of blocks but not all. We need to take this one step more. Mark Jaquith, a lead WordPress developer, shared a few questions from Helen Hou-Sandí, another lead developer, around this idea and a basic concept about what this might look like: Weekend exploration, egged on and sparked by @helenhousandi: “What if building custom blocks for the Block Editor was as easy as supplying attributes and a block of HTML? What if this produced React editing code and PHP rendering code without a build step?” pic.twitter.com/r86Phu88SX — Mark Jaquith (@markjaquith) August 30, 2021 Hou-Sandí followed this with a detailed post on the concept, but she pointed out that this is merely an exploratory phase. “The React-based WordPress block editor (sometimes referred to as Gutenberg) is a powerful tool for WYSIWYG editing that continues to prove to be somewhere between a speed bump and a roadblock for long-time WordPress developers who historically have been more PHP-centric,” she wrote in the post. If you are a WordPress developer, there is a not-so-small chance that you are thinking, Yep, I have hit a few of those speed bumps and crashed into that roadblock a few times. This is unlikely news to you. What might start winning hearts and minds is acknowledging and understanding where much of the problem lies for custom development. “By leveraging the familiar parts of PHP-based templating and creating a bridge that demonstrates the power of React when combined with the markup and styling already being done for the front-end, we can de-duplicate code, help demystify the critical role of JavaScript in modernizing WordPress, and serve as an on-ramp for PHP-centric developers to create compelling and delightful 1:1 live preview editing experiences,” wrote Hou-Sandí. This all boils down to the process of, essentially, writing some template code that works on both the front-end and editor without all the complexities of currently setting up and building blocks. That is an exciting prospect, evidenced by the numerous likes, retweets, and replies to Jaquith’s tweet. Hou-Sandí pointed out that the current thought process is primarily about easing the transition for custom client block solutions and not necessarily for WordPress itself. However, that does not mean that this or a similar solution might not be a part of the core platform’s future. Gutenberg project lead Matías Ventura replied to Ben Gillbanks in the same Twitter thread that it was definitely something they were considering. “From a core perspective we had to ensure the primitives and interactivity is not compromised, but there’s no reason why that should imply a full JS toolchain for simpler blocks. Lowering barrier of entry is important.” Like several others, Gillbanks thought that such a system would have made an easier transition for PHP-centric developers from the start. However, the project was not ready for that at the time, according to Ventura. “It’s tricky to do something like this from the start until the compile target APIs are robust enough,” he tweeted. “We are getting to a point where many of the interactive properties are clustered into primitives and components, which makes a templating approach more appealing.” Automattic developer Riad Benguella shared a similar solution in the past week, launching the Blocky project on GitHub. With his approach, developers utilize the block.json file to create the template or view component and run it through a simple build step to generate the block’s code. While it is not too early to hope and dream, it may just be a bit premature to begin seriously considering whether such tools will land in core WordPress. However, seeing some of the lead WordPress and Gutenberg developers at least openly talking about solutions is something worth paying attention to. Like this: Like Loading… [ad_2] Source link
Continue readingACF 5.10 Introduces Block API v2 Support, Block Preloading, and Security Improvements – WP Tavern
[ad_1] Advanced Custom Fields (ACF) has released version 5.10, the first major release since the plugin was acquired by Delicious Brains. It introduces several new features that were previously experimental, closing out tickets that were started by previous owner Elliot Condon. The release enables HTML escaping by default, which helps prevent Cross-Site Scripting (XSS) attacks. It runs content rendered by ACF through the WordPress wp_kses() function. There was a little confusion about how this works and the release post has been updated to clarify: “It’s important to note that this only affects content rendered by ACF in your WordPress dashboard or any front-end forms rendered through acf_form(),” Iain Poulson said. “This will not affect field values loaded through API functions such as get_field() and the_field(). We don’t make any assumptions about where you are using your field values within your theme and do not escape to them as a result.” Version 5.10 also introduces support for the WordPress Blocks API v2 for ACF blocks. WordPress 5.6 came with a new Block API that makes it easier for theme and plugin developers to style the block content with more consistent results matching the front end. The ACF team has created a Block API v2 help doc with examples that help developers update their blocks and make use of the new block filters included in the update. Other features introduced in this release include block preloading turned on by default, a new full-height setting for blocks, opacity support for the color-picker, and many bug fixes. Next up on the roadmap for the plugin is adding WordPress REST API support to ACF field groups. “As API-powered JavaScript front-ends become more and more popular in the WordPress space, it’s clear that many of our customers want this functionality included in ACF core,” Poulson said. “We also plan to improve the performance of the plugin and work on other quality of life features. Now that our development team has a solid handle on the codebase and the release process, we can start working on these more complicated but long-requested features.” Shortly after the acquisition, Delicious Brains representatives published a pinned thread in the forum, clarifying expectations for free support and response times. The official support forum for both free and PRO users can be found at support.advancedcustomfields.com, which is more active than the WordPress.org forums. Since the plugin is more developer-focused, the team is taking a looser approach to support by giving the community a place to help each other: We rarely provide support in either forum. The exception is after a major release, when we keep an eye on both forums to spot any problems caused by the release. The primary purpose of both forums is for people in the WordPress community who are having trouble with Advanced Custom Fields to help each other. Response times can range from a few days to a few weeks and will likely be from a non-developer. We jump in now and then when the description sounds suspiciously like a bug. The release of version 5.10 is a good sign that ACF will continue to make progress under its new ownership and a reassuring milestone for the small minority of users who were unsure about the plugin’s future. Like this: Like Loading… [ad_2] Source link
Continue readingAdding Custom HTML Attributes With the Block Attributes Plugin – WP Tavern
[ad_1] Earlier this week, websevendev released its fourth WordPress plugin to the official directory named Block Attributes. The extension allows end-users to add any HTML attribute to nearly any block. One of the problems with the WordPress editor is that it can be a bit fussy about customizing HTML. Blocks are built on a set of standards, and the markup is supposed to meet those expectations. If something does not fit, users see an invalid markup warning. However, there are times when users need to drop in a custom HTML attribute for various reasons. For example, I sometimes need to add a custom data- attribute for working with a bit of JavaScript. Since I know my way around code well enough, I typically write out the HTML in those situations via the Custom HTML block. But, that does not make sense when minor attribute additions are called for. WordPress currently allows users to add classes and IDs (called an “HTML anchor” in the admin) to almost every block. It does not allow for direct input of the dozens of other possible attributes that HTML supports. The use cases for the average user are few and far between. For those scenarios where some users could use the extra feature, the Block Attributes plugin is handy. The plugin is straightforward to use. It adds a new field named “Additional attributes” under the Advanced tab of every block. Users can add the attribute name and click the “Add” button. From there, it creates a new field for adding the attribute value. Adding an onclick attribute to a Button block. The plugin also supports multiple attributes. Once you add one, you simply use the same input field to create more. For my first test drive, I added a simple onclick attribute with a value of myFunction(). Then, I hopped over to my theme and created that function via JavaScript to output a simple message in the console. Everything looked good under the hood, and it worked. HTML view and console with custom JS for a Button block. Most of the use cases I have in mind are for integrating with JavaScript, and this was a simple example of what is possible. There are far more complex things a developer could do with such a feature. That is reason enough to keep this plugin in the toolbox — sometimes you need a wrench instead of a hammer. I could also see Block Attributes being used for adding ARIA attributes in other situations where it might aid accessibility. Users could add custom styles to a specific block via a style attribute with the plugin. However, unless this is a simple one-off, I would recommend against it. For more advanced use cases, Blocks CSS is a far more suitable plugin. It has a built-in syntax highlighter. Plus, a textarea is friendlier than a one-line text input box. The only downside to Block Attributes I have seen is upon deactivation. You will see the dreaded “this block contains unexpected or invalid content” message in the editor if you have added any custom attributes. The editor has managed to resolve any issues I have run into with the core blocks. Resolving block warning after deactivating plugin. Deactivating the plugin should not affect the front-end output. Because the custom attributes are a part of the HTML markup, they will still be there. The error message should only show in the editor. Like this: Like Loading… [ad_2] Source link
Continue readingGallery Block Refactor Expected To Land in WordPress 5.9 – WP Tavern
[ad_1] Last week, a GitHub pull request I had been watching since October 2020 on the Gutenberg repository was finally merged into the codebase. It changes the structure of the WordPress Gallery block to be a container for nested Image blocks. The new format is expected to land in WordPress 5.9. For those who want to begin testing it early, it should ship with Gutenberg 11.4 next week. However, you can grab the nightly test version from Gutenberg Times to see it in action now. To use the new Gallery format, you must enable it from the Gutenberg > Experiments admin screen. “If you have ever added a custom link to an image block and then tried to do the same on a Gallery image, you will understand the frustration and confusion of not having consistency between different types of image blocks,” wrote Glenn Davies in the refactor announcement post. “This inconsistency is because the core Gallery block stores the details of the included images as nested <img> elements within the block content. Therefore, the images within a gallery look and behave different from images within an individual image block.” At the surface level, the Gallery block refactor does not change much for many users. They will still add images to galleries as they have for years. However, for more advanced usage, it opens a world of possibilities. One oft-requested feature is the ability to add links to individual images in galleries. In the past, users could only link to attachment pages or the media file itself. Both options applied to all images. With the most recent change, users can modify each Image block, including customizing its link. Adding a link to an Image block within a Gallery. While this allows for handling something as simple as links, there is so much more that users could do. In a theme that I have been building, I have a custom Gallery block style that allows users to create a group of images with a Polaroid-style frame around them. It is something fun for folks who do not want the all-business-all-the-time look. Sometimes, I like to throw in a bit of whimsy. Polaroid-style frame for galleries. The problem with that block style is that it does not go far enough. For example, I also have Tilted Right and Tilted Left styles for individual Image blocks. However, users are unable to apply those within a Gallery. It would be easy to make those available to the entire set or randomize different “tilt” styles. However, the ideal method would be to control the design at the Image level. The same is true for other options. Users could do something fun like add block styles and mix in custom colors, borders, and more. Colored Polaroid-style frames with different “tilts.” There are other fun things users might be able to do, such as alternating square and rounded styles: Alternating square and circle images. The new structure may not be without some issues early on. WordPress will likely continue supporting the old format for a while for backward compatibility. All new Gallery blocks will be in the new. However, core should eventually automatically transform the old markup over. Theme authors who have added custom CSS will be those with the most potential work ahead. Attempting to support both the new and old markup could be an exercise in frustration. The new Gallery block has broken output with my custom theme — margins and widths are off. All styles for the new format begin with, at least, .wp-block-gallery.blocks-gallery-grid.has-nested-images. This will likely overrule custom theme styles. I have yet to figure out the obsession with chaining selectors in the core code. It creates a ton of code bloat and forces theme authors into a specificity battle. I am hoping this gets dialed back a bit. Either way, theme authors have plenty of time to test and implement any fixes if needed. In the long term, I am excited about the potential of breaking away from the idea of just adding images to galleries. For example, I would love to see a grid option for something like the following: Gallery with quote. Nesting a quote in the middle of my image gallery could be a fun block pattern idea that does not rely on a mishmash of stacked Column blocks. We will see what the future holds. For now, turning Gallery blocks into containers is a welcome step. Like this: Like Loading… [ad_2] Source link
Continue readingA Second Look at ElmaStudio’s Aino Theme and Companion Block Plugin – WP Tavern
[ad_1] I am about a month away from my second anniversary writing for WP Tavern. There has been one project that I have followed since the beginning of this journey. In some ways, we are learning the ropes and growing in this block-based WordPress era together. In 2019, just before taking on this role, one of the first story notes I jotted down was some thoughts on ElmaStudio’s Aino Blocks plugin. However, it was not until nearly a year later when the team took the project out of beta testing, and I followed up with a review of the flagship Aino theme and plugin. Perhaps it is fortuitous that the team recently released version 2.0 of its theme at just about the same time I started taking stock of my time at the Tavern. Maybe this is fate’s way of telling me that we should always have a yearly update on Aino — sound like a good idea? It also did not hurt that Matías Ventura, the Gutenberg project lead, name-dropped their work in a conversation we had last week. “It fills me with joy when I see initiatives like [Aino] built by just a couple folks,” he said. “Apart from the user aspects of our work, it’s what makes it all worth it.” This was part of a more in-depth discussion related to the barriers to entry in the modern WordPress era. We agreed that one of the easier onramps was theme creation and site design, a focus area for Aino. It was time to dive back into the project. I had not looked into it deeply enough since my last review a year ago. Admittedly, at the time, I had mixed feelings about it. I initially thought the plugin launched too late. It seemed to be yet another block library after larger companies beat them to the punch. Ellen Bauer, who co-owns the company alongside Manuel Esposito, encouraged me to check back in as they continued building. They were merely setting the stage for their vision. “We wanted to release the Aino blocks and theme on WordPress.org since they are stable to use right now,” she wrote in the comments. “But the actual work is just starting for us, since we are now creating block patterns for our system, and I think it is only then that users will see why we built the theme and blocks in a certain way.” A Year Later One of multiple feature patterns from the Aino theme. The ElmaStudio team is taking that leap that most theme companies will inevitably need to take. They announced that Aino 2.0 ditched its classic garb and moved to 100% blocks earlier this month. For this particular theme, the move was not as monumental as it would be for others with more intricate layouts. Aino itself was always a minimal design, more of an open canvas for blocks than anything. It is the sort of theme meant to get out of the way and allow the user to create individual pages from the ground up. That may have been its downside a year ago. The team had built a plugin for easing users into the page-building process, but its single block pattern did not provide much of a starting point. Its Grid block is a powerful tool but also feels like it is catered more toward designers/developers. Its options may be too advanced to some end-users depending on their familiarity with CSS terminology. Today, this looks much different. The Aino theme comes with — count ’em — 42 block patterns. It is also where this project shines. I may have mentioned something about this being the route to go last year: The company’s best bet is to focus on building patterns. Its first pattern shows some promise. I am holding out hope for more interesting work to come. The team took that dev-friendly base of the Grid block and built a system of easy-to-use layouts on top of it. Users merely need to click to insert and customize. Aino’s Grid block used in a portfolio pattern. Because Aino’s patterns are built upon this grid foundation, the design studio’s layouts are fine-tuned for each screen size. Unless other theme authors build on top of the same plugin or a similar grid-based block, they are left with stock WordPress/Gutenberg. This provides limited options for responsively designing more complex layouts. This should be a focal point of the WordPress 5.9 release cycle, but it could be a while before we have something as powerful as the various grid blocks available via plugins. ElmaStudio’s groundwork in the previous two years is bearing fruit, at least in terms of what the team can create. With the foundational elements in place, nothing should stop them from building the next 42 patterns and more. A team pattern from the Aino theme (also built on the Grid block). I am still lukewarm about most of the blocks in the plugin, think the Hero and Testimonial blocks should just be patterns, and the [Aino] Buttons block should be an options extension for the one in core. The Grid layout is the feature that all the best things about the Aino project hinge on. The Aino theme itself seems unimpressive on its own, at least at first glance. However, the project is not whole until it is coupled with the Aino Blocks plugin. The theme needs some design work on its default spacing. For example, paragraphs that follow a wide or full-aligned block have no gap above them. Blockquote text butts against the side of the left border. Trivial bugs like these are easy fixes. Sometimes, it is not evident that there is an issue until a Gutenberg plugin update, which often leaves theme authors chasing changes. Such is the life of a designer living on the bleeding edge, supporting the latest features via a block theme. I am happy I once again had the opportunity to dive back into the Aino project. A year
Continue reading