Tag Archives: Speeds

Gutenberg 11.3 Introduces Dimensions Panel, Adds Button Padding Support, and Speeds Up the Inserter – WP Tavern

[ad_1] Earlier today, Gutenberg 11.3 landed in the WordPress plugin directory. The latest update introduces a new dimensions panel for toggling spacing-related block options. The Button block now supports the padding control, and the Post Featured Image block has new width and height settings. One of the release’s highlights was a speed improvement for both opening and searching within the inserter. The opening time dropped over 200 ms, from 370.35 ms to 137.28 ms. Search speed went from 190.37 ms to 67.24 ms. The latest release includes a simplified color picker library. Rich previews for links, a feature introduced in Gutenberg 10.9 for external URLs, now works with internal site links. Theme authors should enjoy the reduced specificity of the reset and classic editor stylesheets. Such changes always make it a little easier for theme authors to match editor and front-end styling. Dimension Panel for Spacing Controls Toggling the padding and margin controls for the Site Tagline block. Gutenberg 11.3 introduces a new Dimensions panel for blocks that support either margin or padding controls. The feature adds an ellipsis (…) button in place of the typical open/close tab arrow. Users can select which controls they want to use. The long-term goal is to clean up the interface, only exposing controls that a user actually needs. Because such needs are subjective, allowing users to toggle them on/off is an ideal route to take. The current downsides are twofold. Once choosing to display margin or padding controls, the panel itself cannot be collapsed. This exacerbates the very problem that the new feature attempts to solve — decluttering the sidebar interface. For me, at least, I always want quick access to spacing controls. However, I do not always need them shown. The second issue is that the user choice of what to display does not seem to be stored. Each time you work with a block, you must select which controls should appear. The new Dimensions panel is only one part of the process of wrangling sizing (width and height), spacing (padding and margin), and related controls for blocks. Work toward a more well-rounded solution is still underway. Presumably, the development team will address these issues and others in future releases. However, those who run the Gutenberg plugin in production should expect oddities with usage. The Block Visibility plugin has the most user-friendly version of such a toggle control right now. It is not yet a perfect solution, but it works a little better than what is currently in Gutenberg. Button Block Padding Testing the new Button block padding option with TT1 Blocks. It is no secret that I dislike the default padding of the Button block when using the TT1 Blocks theme (block-based version of Twenty Twenty-One). I have made it one of my missions to routinely point it out, even going so far as refusing to use the block in the last call for testing as part of the FSE Outreach Program. An oversized button is not always the wrong stylistic choice on a webpage. Context matters and I somehow continue to run into scenarios where I need something a bit more scaled back. Control over the Button block’s padding has been on my wish list for months, and the Gutenberg development team delivered. As of 11.3, users can control the padding of individual Button blocks. It will now appear as an option within the new Dimensions panel mentioned earlier. Prayer answered. Now, let us move toward adding padding controls to all the blocks. The one potential issue some users might run into is maintaining consistent spacing when using multiple Button blocks together. The easiest way to do this is to add and style the first, then duplicate it to create others with the same spacing. This is not a new issue; it applies to all Button options where users want consistency within a group. Featured Image Dimension Controls Adjusting a Post Featured Image block’s dimensions. The Post Featured Image block has finally received a small but handy upgrade. In the past, users and theme authors only had a single option of deciding whether to link it to the post. Now, they can control the width and height of the image. If a user sets a height for the image, the editor will reveal a separate “Scale” option with the following choices: Cover (default) Contain Stretch What do these options actually do? That would be a good question. Even as someone in the web design and development loop for close to two decades, I sometimes forget and must look them up. They are values for the object-fit CSS property and are likely to confuse users in many instances. Cover and contain allow the image to fit within the containing element’s box while maintaining its aspect ratio (no stretching the image). The difference is that the cover value will be clipped if it does not fit and the contain value may be letterboxed. A stretch value will fill its container regardless of the aspect ratio. Depending on the image’s aspect ratio on its container, each of the values could essentially display the same thing on the screen. Or, they could provide wildly different results. Coupling these dimensions controls with wide and full alignments (also width-related options) could make for some unpredictable experiments too. The theme designer in me wants to disable the UI for this altogether and present something slightly more controlled: an image size selector. Such a selector should not be confused with width and height controls. WordPress theme authors have been registering custom image sizes for years. The primary use case for this was featured images. Users can use these sizes with the current Image and Latest Posts blocks. However, they do not yet have this option with Post Featured Image. I am in the camp that believes image size controls should have been the first addition to the block. It is such an integral part of WordPress theme design that it cannot be left out, and I have

Continue reading

New Boilerplate Speeds Up Building “Nearly Headless” WordPress Themes – WP Tavern

[ad_1] Alex Standiford, a WordPress developer at AffiliateWP, has released a boilerplate for what he is calling a “nearly headless” WordPress theme. It uses Underpin ,Nicholas, and AlpineJS to provide an app-like experience for a website while providing the flexibility for rendering specific pages using PHP instead of Javascript. In a post titled “Headless WordPress is Overrated: A Case for The Nearly-Headless Web App,” Standiford describes a few of the drawbacks of going fully headless. One problem with fully-headless WordPress is routing. Behind the scenes, WordPress has a lot of logic built-in to handle routing, and with a headless approach you have to build something to handle that on the front end. Ultimately, you’re re-inventing the wheel, and it takes a lot of extra time to build. Another problem with headless WordPress quickly becomes apparent the moment you try to use most WordPress plugins. The ugly truth is that you usually have to re-invent a lot of things just to get the plugin working properly.  Standiford’s nearly headless system is a product of his rethinking headless WordPress. He wanted to preserve the app-like feel as well as all of WordPress’ built in capabilities and those available through the plugin system. The Nearly Headless WordPress theme uses AlpineJS for rendering, which Standiford says is light, easy-to-understand, and “plays exceptionally nice with PHP server-side rendering.” It is loaded around HTML template tags that source post content using WordPress’ REST API. The system uses session storage to keep things speedy and minimize the number of REST API calls. Standiford’s WP Dev Academy learning site and his agency, DesignFrame Solutions, are both using beta versions of the nearly headless system. Since the time those sites were developed, Standiford has completely rewritten the system and made significant improvements based on what from what he learned from earlier versions. He has a live demo of the current version available at nearly-headless.dev. .@DFS_Web’s website redesign will make it possible to visit any page without an internet connection shortly after the first page is loaded. This makes this site FAST even if your internet connection is slow. pic.twitter.com/keOxyMU8cq — Alex Standiford (@AlexStandiford) December 9, 2020 The nearly headless approach is comparable to a traditional headless approach in terms of performance, thanks to Standiford’s Nicholas library, which includes client-side caching and a routing layer as the application support for the theme. “Nicholas will load content via REST, much like how a headless site does,” Standiford said. “In these cases, the load times are very similar to what you’d see on a headless site. In fact, they behave, and fundamentally work in the same manner. The key is Nicholas also stores the data in session storage after the page is visited, and any time that page is loaded thereafter, it is loaded instantly.” How far can the boilerplate take you? Developers who use it should be ready to extend or replace the basic templates it includes to load WordPress. It doesn’t enqueue any CSS. Key functionality is broken into separate dependencies so users can stay up to date as the project evolves. “For all intents and purposes, the boilerplate is a blank slate,” Standiford said. “You can think of the boilerplate as _s for the nearly headless approach. All of the dependencies, scripts, and items needed to run the engine are included in the boilerplate. All of the dependencies are packaged up in Composer or Node, so your theme can be updated as the system improves without re-writing your entire theme.” Standiford has some major improvements planned for the future of the boilerplate. It is currently compatible with the block editor and many plugins but requires a compatibility mode. “The big up-front improvement is going to be removing the need for compatibility mode on as many pages as possible,” Standiford said. “Many block libraries, forms plugins, and other things have specific scripts that they expect are loaded on the page that the app has no way to know about, and because of this, some plugins won’t work without turning on compatibility mode. It is possible to make these work, but I would benefit from help from plugin developers to help me understand what styles/scripts need to be included when the app runs.” Standiford said he sees an opportunity to create npm packages that integrate other plugins, and ensure they work as expected. “Yoast and other SEO plugins for example set the SEO information in the head of each page, and right now that doesn’t happen without writing another piece of middleware,” he said. “It’s not too difficult to add it, but it’s one of those things that could be packaged up and included instead of manually being written for every theme that uses this approach.” Another item on the Nearly Headless WordPress theme boilerplate roadmap is improvements to how dependencies are compiled to better avoid plugin and theme conflicts. Standiford thinks this would make it easier to distribute themes built using this method on the WordPress.org directory, or even to sell them commercially. He has also been experimenting with automatically caching all the content on a page when it loads, without bogging down the browser or overloading the server with requests. The result would be instantaneous page loads with reduced server loads. The Boilerplate for Nearly Headless WordPress Themes is available on GitHub and Standiford is also creating a course that will help developers build sites using this nearly headless paradigm. He anticipates it will be released in November 2021. Like this: Like Loading… [ad_2] Source link

Continue reading