The developer notes and I worked on / reviewed for WordPress 6.0. There is much work that goes into these.
The team at XWP has written a great case study of the web stories plugin, I have been working on since 2019. Well work a read.
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.
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!
I am happy to announce that I am now officially a maintainers of the REST API in WordPress Core. I join a list of very well respected names in the WordPress community.
The reason I have done this, is that the REST API is important to the future of the WordPress project and the open web. The block based editor, gutenberg was only possible because of the REST API. It is no secret that I think that the REST API is important. I have spoken about REST API Authentication at WordCamp US 2019, built a plugin to expose block data in the REST API and worked heavily on the REST API over different releases.
I hope to bring many improvements to the REST API in the coming releases. Watch this space for updates. If you are interested in supporting my work consider sponsoring me.
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.
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.
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.
This post is extremely late to publish, but I thought I would see publish it anyone, as someone might find it useful. Here are a list of important tickets in the WordPress 5.1 release.
So this is a post that I have been meaning to write for a long time. I think that the fields API and how core handles meta is without doubt the most important problem that is facing the WordPress project. But looking the work done to date on the fields api, it can get a little confusing, the project has changed owners and scope a number of times. In this post, I hope to clear up a little of the history and explain my ideas for the fields API going forward.
So what is the fields api anyway and not having it is such a problem?
The fields API is a bit of a different name for what it really is. It is in short, a library to build custom meta boxes and UI to interact with meta data. The first reference to field api goes all the way back to 2011, in ticket 18179 – WP_Meta_Box. Basically the original idea what to make the need for plugins like advanced custom fields, fields manager and CMB 2 mute by making it easy for developers to register meta boxes and UI for post meta data in core. This would make the job of plugin / theme developers much easier, as it would make adding new fields the post screen extremely easy and would mean that testing on WordPress core updates, much simpler. Plugin / theme developers have long wanted this, as building out custom meta, is a key part of the developing anything custom for WordPress. I believe it true to say, that it is the first thing that most WordPress developers do when building a project, is to set up either ACF or CMB 2. This setup is normally a manual process, as currently there is no way to require interdependencies with plugins (if this plugin /theme is installed, then install this library / plugin). This gives developers two choices. Either hard code the meta boxes / fields that you want and build out their own libraries or bundle a meta box library in with their plugin. Either solution is not great. First, building your own meta boxes, takes time and testing. It means that whenever WordPress core updates itself, that plugins require retesting. Option 2, means having a whole library in the plugin, that adds overhead. If any other plugin is including the same library, it may mean that having both plugins activate at once will break your site.
So having the a fields api in core seems to make sense, from both a user and developer level. It makes developers lives easier and makes WordPress a more usable piece of software for users. But the fields api should not just be limited to post meta, users, terms and comments all to have meta in core. Also multisite too, will have some meta tables, with some work that I am currently working on, by adding site (blog) and network ( site ) meta. So my previous blog post on the subject on site (bl0g) meta and check on the tickets for site and network meta. It is possible to make the fields api the interface for all meta data in core. However, I have also seen people discussing the idea of using the fields api, as a general api for drawing UI for any data stored in the database. That would mean it could also be used in on the core objects like Posts, Users and Options. Where on the face of it, this may seem like a good idea, I am a strongly against this. For me, this muddies the water of the fields api and makes the scope of the project limitless. It makes the project a silver bullet for the project and nearly impossible to ship. The fields api project has been going since 2013 and has had a number different versions and teams working on it. For some reason, this project hasn’t taken hold or got the support it should have. What is worse, is with Matt’s three focuses of customiser, editor and API that this and many other projects are being sidelined.
An API driven future
The reason for limited meta support in the core endpoints is explained in Ryan Mccue’s post The (Complex) State of Meta in the WordPress REST API. In short, meta data isn’t added core endpoints for two reasons.
- Protected data
Core developers have no idea of knowing what data is private / sensitive and should not be displayed publicly.
- Serialised data
WordPress can store serialised objects in meta data and these can be a security problem. There is no way of knowing data type
There is much more to Ryan’s post, do check it out. But it comes down to one problem, meta is not registered anywhere, so there is no way to know, if it should be in the api or not, it’s data type, what are valid values and permissions to read / edit / delete are not defined.
A new hope
In WordPress 4.6 Jeremy Felt made some changes to a little known function called register meta. These changes were designed to allow developers to register some details about the meta data. It allows for some important information to be registered, such as.
- Authorization callback
Adds a permissions call to each meta key. Allow for secure meta data
- Sanitize callback
Allows for meta data to formatted on save, meaning data meta can be trusted to be the correct format / data type.
Does type hinting, so gives core an idea of what data type of data stored.
Allows developers to flag weather or not this meta data in the api at all.
As you might understand, this is a big step forward for meta data. For the first time, meta data is much more control on it’s processing, handling and saving.
It also makes improvement to multisite a lot easier. Multisite has been missing a settings api for a long time. As under the hood, network settings are just (site) meta data, the fields api could replace the need for a network settings api.
This doesn’t even mean that plugins like ACF would die as a plugin. I would still have a place, support fields that core didn’t like repeaters and google maps. But under the hood ACF could be converted to use the fields api, converting many sites already using this plugin, a more structured data set in the database.
With the fields api in core, we can work on having the user experience an enjoyable and consistent user interface across all platforms. With form fields being generated from one place, we can make the process of translation and accessibility much easier, making aWordPress and much more user friendly piece of software. It would allow those using the WordPress via apps or third party connected software, have a much consent experience and hopefully mean less breakable in the future.
But this gets down to the core issue, I have with the WordPress project. The user comes first. All the work that is currently being done on core, is about making end user experience better. I understand this desire, but it forgets one simple thing, that developers are users too. That a part like having a fields api, is a problem for both developers and users, and WordPress would be better if we solved this problem ahead of other things. The fields api, makes things cleaner, faster and more reliable for custom development. It means that developers, can save time and add value to the projects they are working on in other ways.
I would like to thank some people for their tireless work to date.
So as part of the Nijmegen WordCamp, I run the core team at the contributor day. Even through this took up a lot of my time, I still had a little time to work on networks endpoint for core. There was an existing ticket for this and it is on the Multisite roadmap that we have been working on. But of the two require endpoints for full support of the multisite is core (sites and networks), networks may seem like the less important of the two. After all, networks are created rarely (in most cases only once) compared to sites, where sites can be created all the time. However, there is one important feature of multisite that doesn’t have api rest endpoint that really needs it and that is network options. Adding a networks endpoint would add an api not only for networks but also it’s options (meta) as well.
Network options, a history
Network options (or site options as they are sometimes known) different from site level options and are not a feature of WordPress that many people know about it. Network level options are used to core network level configuration in multisite, however not many plugins bother with network level settings. This is partly because many developers do not bother to test their plugins with multisite. The other reason is there isn’t currently a developer api to add network pages and settings easily. For single site WordPress, there is a settings api that makes it easy for developers to build out there own settings panels in the admin terminal. However, there is nothing like this for multisite. Currently the process adding a network options is manual, adding to manual posts requests and manually saving values in the database. This means that developers have to do all their own data sanitation and escaping themselves. There is a ticket to add a similar network settings api written by one Joost de Valk the creator of WordPress SEO however this ticket at time of writing is over 7 years old. With a new endpoint for networks in core, we have an opportunity to improve the whole network options interface. Once there is api for networks, developers can use the CRUD (create, read, update and delete) methods to interact with options and not need to have to do all the data sanitation themselves. We can can extend this more, by creating a network settings interface, that allows developers to register settings to network settings pages. There network settings pages, then become a single page application written in React or similar. This could result in some really nice user interface and make network settings a better than site level settings.
Blocker to this bright future
Even through there is now a patch up for a networks endpoint, there is a lot of work to be done. Currently the first patch, only has read methods. This is because in core there are not currently create, edit and delete network functions. To add this functionality to the api, the functions must be added to core. There is a ticket for this that are based on some of the code in WP Multi Network plugin. The reason these functions have no been added before, is because it would then mean that WordPress core officially support multi network setups. Core has unofficially support multi network for a while, with many commits (#40486, #40590, #40591) going in the last couple of releases. Adding these functions to add a maintenance cost as well, the multisite codebase is large and only has a couple of maintainers work on it at any given time.
Another blocker are the current CRUD functions for network options. Currently there are following functions
I worked on these functions as part of the 4.2 release and were introduced in #34777 . However, these functions were just a simple replacement for the existing *_site_options functions. I wanted to go further with these functions and use it as a chance to leverage the meta api. Under the hood, network options are stored in a sitemeta table. This means that data is structured like meta in the database. This means that the meta api used by post / user / comment / term meta could be used here. It adds a number of key benefits, including
- Improved caching profile
- New filters and actions
- Enables use of register_meta
- All improves to meta api, filter down to network options.
- Possible integration with fields api
I have been working on a ticket for a while now, however this is not a small change. It fundamentally change network options and that has effect on every piece of code that uses them. An example of the effect is if code is saving network options for id 0. It is impossible to have a network with id 0, however some plugins have been using 0 as a way to store global settings. This would break if we use the meta api doesn’t allow for 0 or negative numbers.
As you can see, there is a lot of work to done to make this a networks endpoint happen, but I think it is really worthwhile. Once this work is done, it will make developing for multisite much easier.
How you can help
The key tickets that need feedback and code review are
- Introduce a REST API endpoint for networks / network options
- Use metadata api in *_network_options
- Add multi-network helper functionality
Any help with these tickets is more than welcome. You can also join in on a weekly multisite meetings on slack in the #core-multisite channel every Tuesday at 4pm UTC.