[ad_1] For more than a decade, WordPress developers have been discussing how core can support plugins that require one or more other plugins in order to work. Having a standardized way of managing plugin dependencies would be a useful and time-saving feature for developers, who currently have to roll their own solutions for this. “The situation there is a lot like the relationship between parent and child themes,” project lead Andy Fragen said in February when introducing the idea for the feature plugin. “Without their relationships to the bigger plugin, those dependent plugins can do very little. Every plugin developer is on their own to code a solution to resolve the issue. The single most common example is WooCommerce, which is a dependency for hundreds, if not thousands, of WooCommerce add-on plugins.” After nine months of discussion and development, the Plugin Dependencies feature plugin is now ready for testing. It allows plugin authors to specify any WordPress.org-hosted plugin(s) that are required for their plugins to function. A plugin that has dependencies can be identified by adding a “Requires Plugins” header to the docblock of the main plugin file. Plugin authors can specify as many dependencies as necessary in a comma-separated list of plugin slugs. How does it work? Site owners will get an admin notice if there are dependencies they need to install. The plugin card will be updated to display the Requires and Required by information on the Plugins screen. Fragen outlined how the community can test the new core support for handling plugin dependencies. You do not have to be a developer to participate in testing this new feature. It involves installing test plugin files and confirming admin notices appear and disappear at the right times. Testers who are comfortable editing plugin files can try adding dependencies, adding a dependency for non-WordPress.org plugins, and other more advanced tests. Version control is not part of this project, so developers will not be able to specify a minimum required version, for example. “Version control is out of scope for the feature as described in the original Make post referenced above,” Fragen said in response to a question on the feature plugin. “As the majority of the dependencies come from the dot org repository, the most current versions will be installed. “Specifically, WordPress should automatically prompt the user to update to the current version and may use auto-updates as well.” Testing will be open until December 1, 2022. Anyone who wants to be part of moving this long-awaited feature towards a possible inclusion in core can report issues to the WP Plugin Dependencies plugin’s repository. [ad_2] Source link
Continue readingTag Archives: Feature
Gutenberg 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 readingTheme Authors Should Be Able To Opt Out of Any Design Feature – WP Tavern
[ad_1] As I debugged issues with the new block gap feature added in Gutenberg 11.4 last week, I found the ticket introducing it. And, there was already a new ticket for one problem I had hit. However, there was some discussion over whether themes should be allowed to opt-out, rolling their own solution. There was no way to do it at the time. It felt like a no-brainer, something I would not think twice about. I quickly chimed in: Should theme authors be able to opt out? If this is ever a question that comes up, the answer is always: Absolutely, 100%, yes! The front end of a site is the theme author’s domain. Ultimately, they define how things work there. At least, this is how it has always been. Before the advent of the block system, there were cases where WordPress added its own spin to front-end features, such as styles for the gallery shortcode and emoji JavaScript-image replacement. Themes have always had methods for disabling those. With the introduction of the Gutenberg project and its evolving feature set, WordPress continues stepping into front-end design. This carries the benefit of standardizing the relationship between the platform, themes, and users. It makes things like block patterns universal, and it will continue doing so as we get into more advanced layout tools. This is a future that I am eager to witness because it will make theming much easier. However, within the in-ticket discussion, I came across one of the fundamental rifts between some people working on Gutenberg and third-party developers: I disagree with this take. This means that everything should be optional in WordPress and goes against the decisions not options. some things need to be options but not everything…I don’t think it should be a rule to have an opt-out for everything personally. For instance for structural styles, I’d rather have the themes rely on Core always instead of reinventing their own. Themes are here to bring personality and design but not to define what “horizontal alignment” means for instance. Riad Benguella If such a stance becomes one of the cornerstones of block theme development, it will turn many traditional themers away. I agree with the principle that this should be the foundation, the default way that theming works in WordPress going forward. The more pieces that we can standardize, the better. But, as a rule of thumb, theme authors should be able to opt out of any design-related feature. Then, we make rare exceptions to that rule when the need arises. Regardless of what Gutenberg and, ultimately, WordPress does, theme authors will find a way around it. Let us pretend that “horizontal alignment” is defined by CSS flexbox in core. I guarantee that someone will come along and use CSS grid. In the case of the “block gap” feature introduced in Gutenberg 11.4, it is essentially a fancy name for a global top margin that gets applied to blocks (not to be confused with the actual CSS gap property). In essence, it is a system for defining part of the default vertical rhythm. This feature has long been on my wish list, but the idea of mandating it never crossed my mind. If you want to see a heated discussion, throw a handful of web designers in a room and have them discuss the myriad ways of handling vertical spacing between elements. I am in the top margin camp. Fortunately, theme authors will be able to enable or disable the block gap feature. But, that is merely one battle. I had planned to reply in-ticket, but I did not want to get too far off-topic. I also wanted to give some consideration to the other side. However, I could think of few instances where WordPress should always be the deciding factor on front-end design. From that position, I envision little more than theme authors creating workarounds for what they will see as a broken system. There is nothing wrong with WordPress defining the defaults. However, it should always be from the mindset that developers will want to venture out. The best way to keep them happy is to not get in the way. Build a system that they want to use, not that they must use. And, for those who decide to go a different route, make it easy. Even if we think those rebel designers are creating a broken user experience, that is OK. It is their project to make or break. What makes WordPress so uniquely WordPress is that the platform has always catered to those who want to extend it in just about any imaginable way. If it starts creating stumbling blocks that need not be there, we have done a poor job as stewards of the software. Like this: Like Loading… [ad_2] Source link
Continue reading