Blog

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.

Becoming a WordPress core committer.

As you may or not have seen from my original tweet or from the make WordPress blog, in November, it was announced that I am now officially a WordPress core committer.

It has been over a month, since I tweeted about this and a lot has happened. I have been very actively involved in the WordPress 5.9 beta process. Even commiting a number, 52342, 52286, 52268 of important bug fixes and feature of the part of this release. But I haven’t really taken the time to think about this massive honor that I have been given. I have been working on open source, since 2009 and have been actively contributing to WordPress since 2013. I have got many features and tweaks merged to core over this time. But I have always had an eye set on getting commit access someday. It is a goal I set for myself back in 2019. I remember talking to friends at Wordcamp US 2019 about it. Having a goal in life is important and I wanted to good enough to call myself a core committer. It is something I worked really hard at, helping wherever I could and just writing good, well tested code. I don’t take this honor lightly and I understand the pressures this put me under. But this is something that is personally very important to me. It is honestly one of the proudest moment of my life when I finally got this access. There are so many people that have helped me on journey, that if I tried to list them all, I would forget people. But I would like to make special shout out to Pascal Birchler, who nominated me for WordPress committer access and supported me all along the way.

I now understand much better, how much work goes into even the most simple patch. Checking, rechecking, run lints and unit tests. Even commiting a simple patch to core can take hours and hours of your life. I am not sure, that people really understand how much love and care go into WordPress. People build WordPress not code. I have a new found respect for all my follow committers.

If you are interested in sponsor my open source work, I have enabled sponsorship via github.

Thank you to everyone to help me along the way and he is to making 43% of the web better!

REST API Blocks plugin update

The REST API blocks plugin, has been available to download via github, since June 2019. You can checkout the original blog post where I discuss the use of this plugin here.

But I got a request from a user to add the plugin to the WordPress.org plugin repo. Normally, I don’t submit my plugins to the plugin repo, as they are developer focused, but in this case, it seems to makes sense to submit this one. So if you want to download this plugin, it can be found here. If you are using composer, I have also submitted it to packagist, so it can also be installed via composer.

Along with the plugin now easier to get than ever, I also released version 0.3.0. This update includes.

  • Improved handling of table blocks.
  • Improved translations.
  • Improved error handling, if composer install is not run.

The future of the plugin

I am currently actively maintaining the plugin and adding new features. If you have any feature request, please feel free to add them in as a github issue.

As of WordPress 5.8, there is a new block based widget editor. There is a pull request to a block data to the new widget rest api. I hope this functionality merged and get a version 0.4.0 out very soon.

I want to get to the point, there the unit test coverage is a such that it is a plugin that can be used widely. It is useful for others to use this plugin and help me find bugs and test the code. I hope in the future, that this plugin could be used to create a template for a WordPress core patch, meaning this functionality would be part of WordPress. But while blocks are actively changing and with full site editing around the corner, but feels like this functionality should live as a plugin, for the near future.

I hope you joy the plugin, if you have an feedback, please create a github issue. If you like my work and want to see more of it, I opened sponsorship via my github sponsor page.

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;

Open for sponsorship

I have been contributing to WordPress since 2015. In my 6 years of contributing I have worked on nearly all parts of core, spreading my contribution to the parts of WordPress I felt that needed me the most. In my time I have help land, some features I am really proud of. These include but are not limited too

  • White screen of death protection.
  • Default meta values
  • WP_Site_Query and WP_Network_Query.
  • Block types REST API
  • Lazy loading images.
  • WebP support.
  • And many more.

Today I announce that I’ve started accepting sponsorship via the GitHub Sponsors program. I am asking for sponsorship, so that I can continue to work on open source and dedicate more time to and not be restricted by limited time between client projects. This ensures that going forward, I continue to contribute and keep making the open web better.

I want to make it clear, even without sponsorship, I will continue to work on open source, but support will help me maintain my plugins and tools and keep them free for everyone.

What have I been working on in WordPress 5.5

WordPress 5.5 is fast coming around the corner and in my opinion, it is going to be a massive release. There is a lot in this release. With all the extra time I have on my hands, now that I am unable to travel, I decided to focus my energies on open source. This gives me something to do and hopefully helps the wider community. I thought I would highlight some of the tickets, I am especially proud to have worked on and will likely end up in the WordPress 5.5 release.

Menu / Menu item / Menu location REST API endpoints
This ticket has been over year in the making. The original first patch to the feature plugin was in June 2019. But it was then merged to the gutenberg plugin. These endpoints, will allow developers to get menus data. The plan is use to rebuild the menus screens in WordPress core. It will also help with developers that wish to use menu data in a headless WordPress front end.

Block Type REST API endpoint
The block type REST API goes along with another piece of work that the gutenberg team has been working to register all core blocks in PHP. The hope is to someday use this endpoint in the WordPress mobile app, to allow custom blocks to be supported on mobile.

Plugins REST API endpoint
This REST API endpoint, allows developers to install, activate and deactivate on single and multisite. This work was done for the block directory project. But my personal hope is that, it will be used for remote management tools.

Scripts and Style REST API endpoint
This REST API endpoint is again part of the block directory project. But has a lot of useful applications. One of which will be allowing for the gutenberg team to lazy load scripts and styles in core, enabling better performance.

Return all themes into the themes REST API
This is a simple extension to the themes endpoint, so all themes are received. This is a step towards, having all data for themes in the REST API.

Add default value to register meta
This has been in the works for nearly 2 years. Meta data, like post meta, does not support default values. This makes it a little outlier in core, as options and network options do support a default value. This change adds a new filter for default values and leverages, the register meta function.

Introduce wp_cache_get_multi()
This ticket is something I have been thinking about for 8 years. It is has been a lot of work to get this one into core. But it is massive possible performance benefits for WordPress core. It means that object-cache drop-ins can now, get multiple values in one request. The hope is that receiving values from cache will be much faster.

There are many other thing I have been working on, but these are my favours. Thanks to XWP for giving me time to work on these tickets. Here is hoping that all of them make into WordPress 5.5.