Advanced Sidebar Menu – Version 9.9

Version 9.9 of the Advanced Sidebar Menu plugin is now available and ready for general use.

Version 9.9 brings new ordering options for Category widgets, performance improvements and architectural changes as building blocks for future versions.

This version includes 87 commits with over 170 files being changed. This article could easily be 10 pages long and still not cover all the little improvements made in this version. Instead of covering everything, I’ll highlight the most interesting changes.

Block Registration Size Reduction: Phase 1

The Gutenberg block system required you to register information for blocks on both the PHP and JavaScript side for attributes and other items to work correctly. The common way to solve this requirement is to use a block.json file to hold all registration information then parse this block.json file in both PHP and JS when the editor loads.

Despite the obvious performance issues with parsing JSON on every request, we fundamentally avoid this approach for the following reasons:

1. It is impossible to use static analysis to compare and validate a .json file.
2. You can not use a single PHP filter to expand the block registration. You must maintain 2 separate filters, one for JavaScript and one for PHP, and hope they stay aligned.

We use a PHP first approach for registering blocks then pass the finished result to JavaScript using a standard wp_localize_script approach. This guarantees consistency across PHP and JavaScript, not to mention allows for verbose unit tests and static analysis.

There is a downside to the PHP first approach. Blocks with a lot of attributes, supports and other configurations can add a bit of size to the HTML content of the Gutenberg pages. Imperceptible to probably all users, we don’t take any performance areas for granted.

To reduce the impact on the HTML content size we’ve begun a 2 phase approach to make the information passed from JavaScript to PHP as small as possible:

1. Combine common attributes and block supports.
   • Completed in version 9.9.
2. Use basic compression to substitute common text.
   • Coming in the next phase.

Combined Common Block Attributes

Many of the block attributes are the same across all 3 of the blocks. Features like accordions, styles and even some display options are identical. Previously, each block passed all attributes it supported individually. We found we could notably reduce the size of the block information by combining the common attributes into one property while maintaining the original implementation for each block’s individually supported attribute.

A new \Advanced_Sidebar_Menu\Blocks\Common class has been introduced to manage the common information to be shared across all 3 blocks. Some new filters have been introduced in the Common class which are for now considered internal so they have not yet been added to documentation.

Combined Common Block Supports

We also discovered that block support for the 3 blocks is identical so block support information has been combined into a single property using the new Common class.

Information not needed on the PHP side

It turns out block keywords serve no purpose on the PHP side so we no longer pass any keyword information in favor of setting the keywords directly in JavaScript.

The block description also serves no direct purpose in PHP. We left it intact in case other plugins use the description the same way for filtering in PHP, but we no longer pass this information from PHP to JavaScript.

A few methods around this logic have been deprecated so if you are maintaining an extension for this plugin, be sure to enable WP_DEBUG mode and follow any instructions for updating the extension’s code.

Results

After phase 1 we’re seeing a reduction of just over 41% in the size of the passed information.

New Block Attributes Registration System

Over the past couple years we have been strategically and incrementally moving our plugin from an inheritance architecture to one based on composition. Why the long timeline? We account for various versions of the basic and PRO plugins being installed together. We also continue to support 3rd party extensions. Giving ample time for our users to update their plugins means we change architecture slowly over time.

Version 9.9.0 was another iteration of moving toward composition but also introduced the beginning of a new initiative; moving from associative arrays toward Object Oriented Programming.

WordPress has always used large associate arrays for registration and configuration. A theory is, back when WordPress was first created, PHP did not yet support advanced OPP approaches in a simple way. PHP is nearly the only programming language which supports associative arrays for good reason. Associative arrays are difficult to validate and maintain. With modern PHP support for objects there is really no excuse left to use associative arrays.

Beginning in version 9.9 we are working to translate any uses of associative arrays into strictly typed, validated objects for passing around information. This will allow us to make changes faster in a more reliable way. Not to mention open up new opportunities for expanding our unit tests.

The first implementation of this approach is the new \Advanced_Sidebar_Menu\Blocks\Register\Attribute class. The Attribute class translates a PHP associative array of a block attribute to an object. When calling register_block_type the Attribute class translates the class properties back into the required array that WordPress uses for registration. The Attribute class may also be composed directly using properties and methods instead of passing an array.

If you look closely in the code you’ll find a new JS_Attribute class. While not technically used yet, it is an easter egg nod toward the next phase of block optimization.

New Block Icons

All 3 of the plugin’s blocks have always had the same block icon which matched the logo of the plugin. Now each block has a slightly different icon to allow a keen eye to detect a difference. You will notice the icons now have a teal color which matches the plugin’s branding.

Can you tell which icon is for which block?

Display Posts Improvements

Version 9.9 includes enhancements to the Categories block Display Assigned Posts Under options. We’ve improved the UX and added some new options.

The new options are also available on the “Advanced Sidebar – Categories” widgets in case you are still using widgets.

New Order By option

The Categories block has always supported displaying assigned posts under categories, but now you may also choose the order the posts are display in using block settings.

To begin with, you may order posts by:

1. Comment Count
2. Date
3. Date Modified
4. Title

We will add more options as they are requested. Want another option? Let us know.

New Order option

Along with the “Order By” option, you can select if you would like to order the posts by either ascending or descending.

Limit post type options to supported post types

The Display Posts “Post Type” dropdown used to include all post types supported by the Categories block. Now the list of post types will automatically filter to include only post types supported by the taxonomy selected in the block.

Instead of selecting a post type and wondering why the menu is empty, you will now only be able to select supported post types.

Fixes

• Prevents display everywhere parent category from resetting unexpectedly.
• Prevents display everywhere parent page from resetting unexpectedly.
• Fixed initial show hide of display posts field.
• Fixed translation generations for display posts field.
• Fixed accordion icons during previews.
• Prevents category counts clicking from browsing the page during previews.