javascript

Announcing the Classic Menu Block plugin

Today I am happy to announce a new plugin I have been working on called classic menu block. This is a very simple plugin that adds a new classic menu block to the gutenberg editor. The classic menu block, allows you to embed all the existing menus you have setup on your site, using the existing core function, wp_nav_menu by rendering the block’s output in PHP. This means for those using menus with super custom walkers and plugins that hook into the existing menus filters, these can now be used within, blog posts, block based widget areas and even within full site editing. This differs from the new navigation block, which takes existing menu data and migrates to nested navigation link blocks. For information, checkout the announcement blog post.

This plugin requires WordPress 5.9 to function, as it relays on the new menus endpoints added in this function. This is something near and dear to my heart, as I worked on the menus endpoints for nearly 2 and half years to get them into core. More details on this announcement can be found on the make.WordPress.org blog.

For those that wish to customize attributes passed to the wp_nav_menu, there is a filter called classic_menu_block_attributes. This would allow you change any attributes passed to the wp_nav_menu function.

/**
* Filters menu attributes.
*
* @since 0.1.0
*
* @param array $menu_attrs Menu attributes.
* @param array $attrs Block attributes.
*/
$menu_attrs = apply_filters( 'classic_menu_block_attributes', $menu_attrs, $attrs );

The plugin currently only comes with very basic styling of the menu block. Styling for this block, should come from the theme. However, if you are interested in contributing, please feel free to submit a pull request on github.

I wrote this plugin, to help those that are dipping their toes into the full site editing world. I hope this solves a problem for some people.

Detect if video has audio

While working on the Web Stories for WordPress plugin and working on functionality to mute videos, there was a need to detect if a video already had audio or not. But doing some quick googling, I noticed there none of the answers I found online works well or at all. Worse yet, the answers were not written using modern javascript, either not using promises or using jQuery. So today, I am sharing this gist, in hopes that the next person who comes across this problem, has a workabout solution.

function hasAudio(video) {
return (
video.mozHasAudio ||
Boolean(video.webkitAudioDecodedByteCount) ||
Boolean(video.audioTracks?.length)
);
}
function hasVideoGotAudio(src) {
const video = document.createElement('video');
video.muted = true;
video.crossOrigin = 'anonymous';
video.preload = 'auto';
return new Promise((resolve, reject) => {
video.addEventListener('error', reject);
video.addEventListener(
'canplay',
() => {
video.currentTime = 0.99;
},
{ once: true } // Important because 'canplay' can be fired hundreds of times.
);
video.addEventListener('seeked', () => resolve(hasAudio(video)), {
once: true,
});
video.src = src;
});
}
export default hasVideoGotAudio;

What am I working on

This is the first in a series of posts about what I am working on in the open source community. I am currently in a maintainer on WordPress core and have a number of open source projects on the go at any given time. I thought I would start to highlight some of the code / tickets I am working on lately.

Use metadata api in *_network_options (WordPress Core)

This is a ticket that has been in the works for a while. Basically under the hood, the network options for WordPress multisite are stored in a meta table. This is standardised format for storing meta data on objects and is used elsewhere in core. The rest of the meta functions (such as get_post_meta) used a defined meta api. However the network options functions do not. This patch seeks to convert the network options over to use the meta api for CRUD functions.

Replace $wpdb->siteid with get_current_network_id() (WordPress Core)

The helper function get_current_network_id() was introduced in 4.6. It is already used in a number of places, however there was still references to $wpdb->siteid throughout the core. Accessing the siteid from the wpdb class, is an outdated way of accessing current site.

Site meta (WordPress Core)

Site meta is the idea of adding a new table to WordPress multisite that would allow you to easily extend the WP_Site object. This global store for multisite, as many uses, including replacing domain mapping and blog versions tables.

Add caching to get_adjacent_post (WordPress Core)

The get_adjacent_post functions are used in for the next and previous posts functions in core. Currently this function has no caching by default. It can be an expensive query, as it is doing a date based sql query.

Add caching to WP_Query (WordPress Core)

Current the main query class WP_Query doesn’t have any caching on it. It does have a number of filters and actions, which make it easier to do as a plugin. I worked on a plugin while at Time inc called enhanced post cache. However, I believe core should have this functionality built in. This is a hard ticket to work on, as it effects nearly everything in core. However, I think it is worth while.

Version 1.2 (Echo js Lazy load)

Improvements include.

  • Updated Echo.js to 1.7.3 from 1.7.
  • Use data url instead of 1px gif saving another request.
  • Don’t do replacement in REST API.
  • Formatting for tests.

WP Concatenator ( wp-concatenator )

Very much a work in progress, but I plugin seeks to make less requests on the server for javascript and css. This will hopefully make the page load much faster, as there are less requests and DNS lookups. If you wish to help me finish this plugin, please get in touch, as I need help code reviewing and testing.

There are other things I am always working on, but these things have been my focus of late.