opensource

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.

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.