rm.codes

Data loading in React based WordPress admin pages

Wed, 31 Jul 2024 10:19:53 GMT

I saw a twitter discussion recently that got me thinking.

This is really helpful, thanks! I’ve been using wp_localize_script() to pass the data from PHP to React. Is this bad?

— James Koussertari (@jkoussertari) July 30, 2024

When building plugins with custom admin pages, one of the more modern approaches is to build them in React, and re-use the Gutenberg component library for building out the UI so we get a nice native-feeling experience.

I’m all for this and doing it in all the plugins I’m working on at the moment, the upcoming version of Search & Filter heavily leverages this.

The discussion then turned to, “how to pass data from PHP to React” – I’ll be sharing my approach and answer to that question below.

Whats wrong with `wp_localize_script()` ?

Well, nothing at all. It’s a great way to attach JavaScript variables to your script or application and it’s been used forever across WordPress, and it’s relatively straight forward to use.

90% of the tutorials out there will show you this technique and I have nothing against it.

The only limitation is that it is loaded on page load, before your JavaScript is run, so the data is not interactive in anyway.

This leads me on to what I think is a better approach when building admin pages using React.

React and the `@wordpress/data` package

I’m assuming in this post you are already using React for your custom admin pages (or have started to), and you’re familiar with the REST API as a way to fetch data.

Now that’s out of the way, its worth mentioning (quite briefly) that one of the best ways to interact with the REST API in a WordPress based React application is via the @wordpress/data package.

Working with custom stores for your own REST API endpoints is complex in its own right and I’m not going to be able to explain it here quickly or succinctly, I’ll leave that to people before me who have already done it well.

One of my favorite and more technical introductions on the @wordpress/data package is this series from Darren Ethier (a la WooCommerce) – it’s a little out dated but it does go in quite deep and most of it still works correctly – it has certainly helped me out!

The official documentation has also improved and gives a good working example via their shop example at the above link.

If anyone has any better resources I’d be happy to include them here, just let me know.

To summarise my thoughts on this: the WordPress @wordpress/data package is the official WordPress supported way of interacting with data and the REST API in your React applications, and while it’s quite complex and has a learning curve, the rewards are well worth it in my opinion.

But there is one caveat when using this on custom admin pages, but first I’ll get to why we shouldn’t use it…

When shouldn’t we use `@wordpress/data`

I think the data package and it’s learning curve can be complete overkill for some use cases.

If your admin screens are not very interactive, or don’t need to use Ajax or the REST API, then I would recommend preloading your data and pass it into your app as a JavaScript object via wp_localize_script().

However, if you need interactivity, are using data that needs to be saved and updated, or doing anything with the classic WordPress Ajax hooks (wp_ajax_...) then I would recommend to start using the newer data package.

Back to the caveat: what if we want data on page load

Unlike wp_localize_script() , using the data package doesn’t inject data into your application on page load.

First your JavaScript application needs to initialize
Then a request is made the a REST API endpoint
Then we need to wait for the response to get our data

No one likes looking at loading icons after loading a page, its frustrating for everyone.

A possible solution could be:

Use wp_localize_script() for the initial data
Use @wordpress/data for the rest

I’m not a fan of this approach, I’ve tried it and have some thoughts:

What happens if the data you fetch via the REST API collides with the data you preloaded? Work arounds could be made but things can get messy quickly.
Why does an application need multiple methods of handling data? One streamlined API for everything would be ideal.

Surely there has got to be a better approach?!

Preloading our REST API endpoints

If we could preload specific REST API endpoints on page load, then we wouldn’t need to have multiple methods of injecting data in our application.

Fortunately, taking a browse through WordPress core gives us all the information we need to achieve this today.

The block editor is already using the preloading REST API endpoints technique extensively, I first discovered this via the hook block_editor_rest_api_preload which allows you to add your own endpoints for preloading requests in the block editor.

Without this we’d be staring at loading icons forever whenever we want to edit a post or page.

The secret sauce for how this all works is in the WordPress core function block_editor_rest_api_preload() found in wp-includes\block-editor.php

While it’s probably entirely possible to re-use this function “as is” on your own admin screen there are a couple of issues I have with it:

If you use this function on your admin screens, other plugins hooking into block_editor_rest_api_preload will load their assets and endpoints, probably not what you need or expected.
The second argument to the function is $block_editor_context, and while I don’t understand it fully, it references things like $block_editor_context->post , and I’m not dealing with posts on my admin screens, so I think this is just not meant for use in custom admin screens.

Creating a new preload function for custom admin screens

Taking the above code from core, and stripping out everything that does not seem relevant for my use case, I’ve come up with this function:

/**
 * Preload the API requests.
 *
 * @param array $preload_paths The paths to preload.
 */
function rmcodes_preload_api_requests( $preload_paths ) {
	/* Copied from core and modified - wp-includes/block-editor.php */

	// Restore the global $post as it was before API preloading.
	// Preload common data.
	global $post, $wp_scripts, $wp_styles, $post_id;

	/*
	* Ensure the global $post, $wp_scripts, and $wp_styles remain the same after
	* API data is preloaded.
	* Because API preloading can call the_content and other filters, plugins
	* can unexpectedly modify the global $post or enqueue assets which are not
	* intended for the block editor.
	*/
	$backup_global_post = ! empty( $post ) ? clone $post : $post;
	$backup_wp_scripts  = ! empty( $wp_scripts ) ? clone $wp_scripts : $wp_scripts;
	$backup_wp_styles   = ! empty( $wp_styles ) ? clone $wp_styles : $wp_styles;
	$backup_post_id     = $post_id;

	$preload_data = array_reduce(
		$preload_paths,
		'rest_preload_api_request',
		array()
	);
	//phpcs:ignore WordPress.WP.GlobalVariablesOverride.Prohibited
	$post = $backup_global_post;
	//phpcs:ignore WordPress.WP.GlobalVariablesOverride.Prohibited
	$wp_scripts = $backup_wp_scripts;
	//phpcs:ignore WordPress.WP.GlobalVariablesOverride.Prohibited
	$wp_styles = $backup_wp_styles;
	//phpcs:ignore WordPress.WP.GlobalVariablesOverride.Prohibited
	$post_id = $backup_post_id;

	wp_add_inline_script(
		'wp-api-fetch',
		sprintf(
			'wp.apiFetch.use( wp.apiFetch.createPreloadingMiddleware( %s ) );',
			wp_json_encode( $preload_data )
		),
		'after'
	);
	wp_add_inline_script(
		'wp-api-fetch',
		'window.apiResult =  ' . wp_json_encode( $preload_data ),
		'after'
	);
}

And I use this in the admin_enqueue_scripts hook:

/**
 * Preload REST API endpoint.
 *
 * @param string $hook Hook suffix for the current admin page.
 */
function rmcodes_enqueue_admin_script() {
	// Don't load it on every admin screen (!), check and return early...
	// The REST API paths to preload.
	$preload_paths = array(
		'/rm-codes/v1/admin/data',
		'/rm-codes/v1/admin/pages',
		'/rm-codes/v1/another-endpoint',
	);
	
	rmcodes_preload_api_requests( $preload_paths );
}
add_action( 'admin_enqueue_scripts', 'rmcodes_enqueue_admin_script' );

And that’s it! Now you can preload your own REST API endpoints on your admin screens, streamlining the flow of your data when using the @wordpress/data package.

You can use `apiFetch` without the data package

That’s right, you don’t actually need to use @wordpress/data at all…

This approach short circuits the WordPress apiFetch() javascript function, which means any type of data fetching via the REST API with WordPress’ apiFetch should be compatible.

It is still recommened to use a store of some kind rather than running apiFetch in your components, data fetching and management shouldn’t really be done in a components useEffect hook.

Further thoughts

It would be great if WordPress could provide a base function like this, a possible name could be wp_rest_api_preload() which passes in the current admin screen as an argument, for developers to tap into. This function could then be reused for things like the block editor and the block_editor_rest_api_preload() function.

It’s clearly becoming more and more common for developers to use React for custom admin screens and giving a nice integrated way to do this would be a big help.

If you have any alternative approaches or thoughts I’m keen to hear them!

WCEU Torino – a first timers experience

Tue, 25 Jun 2024 10:26:49 GMT

So it seems to be the thing to do a write up after a WordCamp experience. I hope I’m not adding noise to the already great articles I’ve read out there, I thought it would be a good idea to do a small write up from a first timers perspective.

While I’ve been “in” the WordPress community for over a decade, I’ve really not been very active, or visible (classic developer mindset?).

So this all changed when I decided to attend WCEU, as a necessary part of growth on a personal level, but also on a business level – I wanted to get my name and face out there as well as my brand and while this kind of thing has traditionally been out of my comfort zone it was time to change things up a bit. I also had a great support network from my mastermind group which made things 10x easier.

Travelling to Torino

My journey started in the north of Spain, a region called Asturias. There are not too many international flights from here so I needed to catch two flights to make it to Torino with a change over at Frankfurt.

All was going well until I was about to board the connecting flight in Frankfurt. Patrick, a friend from my mastermind group had just messaged me, telling me how lucky I was that I didn’t have any issues as a lot of flights from Frankfurt had been cancelled recently.

And guess what, within 60 seconds of his message (and 5 minutes until boarding) my flight got cancelled. I know exactly who I blame for this catastrophy… 🤨

Fortunately a replacement flight was arranged and I managed to make it to Torino only 2 hours late, not too bad. I took a couple of pictures as we were landing at night only to discover that the one of them captured the Lingotto center perfectly – the venue hosting WCEU.

Flight was cancelled but only delayed 2 hours in the end…

But did I get lucky and take a photo of the Lingotto center?#wceu pic.twitter.com/uGAzi4m2md

— Ross Morsali (@rossmorsali) June 12, 2024

Day one / contributor day

My first full day was Thursday, aka contributor day. I had always looked forward to joining a contributor day as I’ve seen countless people talking about the positive atmosphere of them over the years, it sure sounded like a lot of fun!

Unfortunately I didn’t realise that it was a requirement to register to participate in contributor day – I had assumed that anyone who got there a day early could join in… how wrong I was!

So instead of joining the masses for what sounded like a fantastic contributor day, me and a few friends from my mastermind group decided to do a city escape tour – we downloaded an app which took us on a kind of role playing journey around the city – while I wasn’t too into the game I did enjoy going around the city and visiting some of its landmarks – my best photos were from this part of the trip.

This was also my first taste of real Italian pizza 😋

It was really great getting to know Maarten + Ine (from Studio Wombat) and Patrick Posner (from Simply Static and Ollie WP) in real life!

Later that evening we headed over to the Freemius Makers Meet event. This was my first experience being surrounded by so many people from the industry and so many familiar faces I’d seen on Twitter over the years – it was a bit overhelming at times and I mostly opted to stay quiet rather going around making big introductions to people I’d recognised – I think I just needed to get warmed up!

After the Freemius party we headed over to the Elementor Party and managed to snap my first #MichelleAndMe! I just know there will be many more of these to come! (Please ignore the typo, it was the beer I promise).

A verrry late night #MichelleAndMe 🙃

It was a please meeting you @michelleames (with @patrickposner_ ) pic.twitter.com/D7hySCytCC

— Ross Morsali (@rossmorsali) June 13, 2024

I also managed to meet the people behind Dynamic.ooo – Giovanni and his awesome team. I’ve collaborated with them for several years now bringing Search & Filter to some of their Elementor widgets so it was good to chat about whats coming next in Search & Filter version 3 and what they’ve got coming up (🔥).

It really is great to get to meet the people you’ve been talking and working with virtually for years!

Day two

So this was the first proper day of the conference. I didn’t really know what to expect, for the most part my plan was to go around and check out the various sponsor booths and dip into a few talks or workshops.

With my Search & Filter plugin, we have a lot of integrations with other plugins which made it easy to go upto many booths and start chatting – it was really cool to meet the people behind the plugins and get some useful contacts in those businesses.

I’ve tried reaching out to some of our integration partners in the past, and often you might not get introduced to the right people at the right time. The sponsorship booths helped me cut the line and make direct connections with the people I need to be in contact with – this really was one of the biggest benefits of the whole experience for me.

Again I have to tip my hat to my friends from the mastermind group, whenever I got tired or a little bored, I could always return the to the Studio Wombat booth to find familiar (and friendly) faces. We spent so much time there I was made an honarary member.

Later that evening I went for a meal where I sampled some more amazing fresh pasta, followed by the WooCommerce event just around the corner. This was probably one of my favourite, larger, events – the music wasn’t too loud so you could chat and everyone was having a great time.

I also managed to finally meet one of my oldest customers – Brian and his amazing team from digicube. They’re not only one of my longest customers, I actually hired them to build the new Search & Filter website (yet to be released). It was so nice to meet them in person, all round good vibes.

I finished the night over in the next building for the Yoast PRIDE party – I didn’t stay too long as I was very aware of my need wake up early the next day and be in good form.

Day three

The final day of the conference – that was quick! For the most part it was much the same as the day before, walking around meeting and greeting people, suprisingly there were still plenty of people I hadn’t yet connected with.

I also managed to catch the talk from Katie Keith + Matt Cromwell (who co-host WP Product Talk) which was great despite a fair few technical issues!

In the evening I had the privilege of being invited to a small WooCommerce dinner. This was one of the highlights of the trip for me, we got speak to some of the team directly who were very candid and open to all kinds of conversations and questions.

A large part of the userbase of Search & Filter are of course WooCommerce users, so it was super insightful to hear about what’s coming next and to be honest, to see the team so open to receiving feedback and being willing to engage with the community was a real confidence booster.

What a lovely dinner and deep conversations. I’m excited about the future of WooCommerce. https://t.co/RHxiQ02v51

— Ross Morsali (@rossmorsali) June 16, 2024

Thanks to James Kemp and Darren Ethier for inviting me and setting this up!

Following the dinner we headed straight to the official party back in the Lingotto Center. It was a nice space where people could let their hair down and unwind.

But I’m very picky about music, so I mostly enjoyed the conversations outside!

Notable introductions

There are some people in the WordPress space we all know and love, and while I may not have spent much time with them it was really great to meet them in person, finally. In no particular order:

Courtney Robertson
Michelle Frechette
BobWP
Nathan Wrigley aka WP Builds
Mark Westguard from WS Form
Amber & Chris Hinds
And I’m sure many more, if you’re not on this list it’s probably a mistake on my part!

Mastermind

As I mentioned a few times already, the experience wouldn’t have been the same without the support from my mastermind group – Maarten, Ine and Patrick! I particularly like this photo of us all (and the clear shot of the Search & Filter logo is just a bonus!):

Note: If you’re a product maker and not part of a mastermind, I encourage to start your own or find one! The advice and moral support I’ve been getting from them has been invaluable – I guess I hope I’m returning some of that back to them too.

Summary

All in all it has been an incredible experience, I loved the city of Torino and the events in and around the conference have been fantastic.

I really couldn’t have had a better experience from my first attendance at a WordCamp, I’m grateful to everyone who welcomed me and made the experience what it was.

Some tips from a first timer:

It really helps if you already know some people who are going, for me this was my mastermind group – its always nice to know you have somewhere to return after you run out of steam from so many conversations.
Be open to talking to anyone and everyone, without an agenda.
Extend your trip by a day or two on either side – I learnt my lesson this time, I wish I could have experienced a little more of Torino.
Make sure you follow the lists of events (wherever they’re posted) and sign up to them EARLY, especially contributor day (!).
Try not to eat more than one pizza per day 😅

If you’ve also written a summary post, I’d like to read it, so send it my way!

SlotFills and fillProps in the block editor

Fri, 26 May 2023 11:27:29 GMT

When building blocks or working with the Gutenberg APIs you might have come across SlotFills.

They’re really useful and allow you to insert components in different locations from seemingly disconnected parts of your application.

A quick explanation

The way it works is, a <Slot /> component will be added somewhere in an application – and then in other parts of the application you can use a <Fill /> to “send” content to the slot.

Under the hood they use React Portals so often appear somewhere else completely in the DOM.

Gutenberg uses these under the hood for things like sidebars and block controls, if you’ve built blocks before then you’ve likely used BlockControls and the InspectorControls for building out your block admin UI.

The great thing is we can also use our own SlotsFills for things like custom admin screens, making them extensible – Nick Diego has a great article explaining how he’s used them on his custom admin screens and then extended those screens via another plugin.

Example

Here’s a quick example showing how to use Slots and Fills – checkout the Gutenberg docs for a more detailed example.


import { createSlotFill } from '@wordpress/components';
const { Fill, Slot } = createSlotFill( 'MyList' );

// The main component.
const MyComponent = () => {
	return (
		<>
			<ListComponent />
			<ListExtensionComponent />
		</>
	);
};

// A list component, that we want to be extensible.
const ListComponent = () => {
	return (
		<ul>
			<li>A list item</li>
			<Slot />
		</ul>
	);
};

// A seperate component, which uses the Fill to extend the list.
const ListExtensionComponent = () => {
	return (
		<Fill>
			<li>Another list item</li>
		</Fill>
	);
};

The rendered HTML will look something like:

<ul>
	<li>A list item</li>
	<li>Another list item</li>
</ul>

Passing props (fillProps)

The reason I wanted to write this article was because I came upon an issue that took me a little while to figure out.

I have a Slot in a dropdown menu so that it can be extended from different parts of my application – so far so good. But for a specific button (one that opens a modal) I wanted to close the dropdown menu on interaction.

This meant that the button needs access to the onClose() function from the parent dropdown component – so I needed to find a way to pass props to the Fill. Que fillProps.

After a too much trial and error I started combing the Gutenberg source code and found that there was an easy way to do this all along, it’s just not documented very well.

If we pass fillProps to our Slot, then we can access that in the Fill.

Lets say we have a closePopup() function:

function closePopup() {
	console.log( 'Close the popup!' );
}

Here’s what the Slot would look like when we use fillProps:

<Slot fillProps={ { closePopup } } />

And then the Fill can consume those props if we pass a function as the Fill content:

<Fill>
	{ ( { closePopup } ) => {
		<Button onClick={ closePopup }>Close</Button>
	} }
</Fill>

It’s similar to how we can pass functions as children in React.

Here I’m using the SlotFill to add the Export All button to the dropdown, and then I’m using the fillProps to pass the closePopup function so that the popup menu is closed when clicked, which is then followed by opening the modal.

In the end all it took was some digging in the Gutenberg source code to find a prop, and the rest is already done!

I’m sure there are plenty of use cases for this, I’d be interested to hear yours.

Installing WordPress Coding Standards

Tue, 28 Feb 2023 15:41:46 GMT

… as a project dependency.

A problem I came across recently when working on a project with a colleague was setting up WordPress Coding Standards (WPCS) with PHP Code Sniffer (PHPCS).

I already had it setup on my development machine, with PHPCS installed globally as well as the WP Coding Standards. But lets say we want to encourage use of WPCS in a project where we might have different team members involved, then I think its a good idea to install it as a dependency.

What are the WP Coding Standards, and what is PHPCS

The WP Coding Standards are a set of guidlines to follow when building a plugin or theme on top of WordPress. In this post I’m referring to the PHP Coding standards.
PHPCS – is a command line tool to detect issues in your PHP code by comparing it against a set of rules that you can define. In this case the WordPress coding standards rules. You can also configure it to format your PHP files for you.

To get PHPCS to understand and apply the WPCS rules to your code, there is the WordPress Coding Standards PHPCS repository which we’ll be installing via Composer into your project, it comes with a copy of PHPCS.

Prerequisites

This post assumes you already have Composer setup on your machine and that you’re familiar with creating repositories and adding composer to your project via the command line.

I’m also writing this from a Windows machine, so you might need to fiddle with paths etc if you’re using something else – double check the installation paths of your packages when using Composer.

Setup

Add the package to your project

If you haven’t setup composer in your project yet, at the command line run:

composer init

And follow the usual prompts to configure your project.

Then require WordPress Coding Standards which will also give you a local copy of PHPCS, run:

composer require wp-coding-standards/wpcs

Add WPCS rules location to PHPCS

Once that is installed we need to tell PHPCS the location of our WordPress rules, we can run:

vendor/bin/phpcs --config-set installed_paths ../../wp-coding-standards/wpcs

Note: I’m using a relative path of the rules to the PHPCS installation **../../wp-coding-standards/wpcs**. You can use an absolute path too.

Automating this for developers

When developers setup your repository and install the projects dependencies via **composer install** it might be nice to simplify the above step by running it automatically after we run the install – via a post install script.

This requires adding a “scripts” section after your “require” section in **composer.json**, so this:

"require": {
	"wp-coding-standards/wpcs": "^2.3"
},

Would become this:

"require": {
	"wp-coding-standards/wpcs": "^2.3"
},
"scripts": {
    "post-update-cmd": [
        "vendor/bin/phpcs --config-set installed_paths ../../wp-coding-standards/wpcs"
    ]
}

Once you’ve added that, you can be sure the next team members on your project will automatically get PHPCS configured with WPCS out of the box.

Configure your IDE (VS Code)

If you’re using VS Code, I would recommend the PHP Sniffer extension by wongjn which allows us to format the code on save too.

Once installed, open the extensions settings and take note to switch the workspace tab.

I was happy with the defaults, the only thing we need to do is add our executable folder as **vendor\bin**.

If you check your workspace settings, it should look like:

{
	"phpSniffer.executablesFolder": "vendor\\bin",
}

Note: instead of setting a path, you could let PHP Sniffer try to autodetect this for you:

Personally, I like the re-assurance of specifying the location.

Auto formatting on save (phpcbf)

To tell VS Code we want to format on save, we just need to include the editor.formatOnSave directive in our workspace settings:

{
	"phpSniffer.executablesFolder": "vendor\\bin",
	"editor.formatOnSave": true,
	"[php]": {
		"editor.defaultFormatter": "wongjn.php-sniffer"
	},
}

Depending on your setup, you might also want to tell VSCode to use the extension specifically for formatting php files using the **[php]** property and then defining **editor.defaultFormatter**.

Configure the WordPress Coding Standards

We can configure the extension to use the WordPress rules directly or (which I prefer), we can instead create custom rules based on the WPCS rules which will allow us to customise them at a later date – we’ll call our custom ruleset **RmCodesRuleSet**.

To do this we can create a **.phpcs.xml** file in the root of our project with the contents:

<?xml version="1.0"?>
<ruleset name="RmCodesRuleSet">
    <rule ref="WordPress"/>
</ruleset>

The phpcs extension will automatically read this file and the **<rule ref="WordPress">** so it knows to inherit the WordPress Coding Standard Rules.

The VS Code PHP Sniffer extension (as well as many others) will usually load a .phpcs.xml file automatically.

Excluding some rules

Finally, if you want to exclude specific rules we can do that by using the exclude <exclude> tags.

I often exclude the filename restrictions as I’m usually using namespaces these days (with a different file structure) and the yoda conditions I’ve heard will be removed from the coding standards at some point anyway.

<?xml version="1.0"?>
<ruleset name="RmCodesRuleSet">
    <rule ref="WordPress">
        <!-- Exclude the filename restrictions assocatied with class name -->
        <exclude name="WordPress.Files.FileName"/>
        <!-- Exclude the requirement to use Yoda conditions -->
        <exclude name="WordPress.PHP.YodaConditions.NotYoda"/>
    </rule>
</ruleset>

Taking it further

Aside from setting up PHPCS + WPCS in your repository and IDE, we could also configure it to run on push via Github actions.

But that’ll probably be another article…

Creating sidebars for the post and site editors

Mon, 30 Jan 2023 11:22:15 GMT

There are multiple articles on how to create a sidebar in the block editor but something you might not have seen is how to do that for the site editor (aka Full Site Editing, aka FSE).

It’s a nearly identical setup to create a sidebar for the site editor but it is not yet documented, I recently discovered the code burried in a github reply.

To clarify the terms site editor and post editor:

The post editor is used on any screen where we can edit a post, page or CPT.
The site editor is available only in the latest themes that support full site editing and allows you to edit parts of your site that are not related to post content.

Both of these use the block editor by default.

Lets start with adding a sidebar to the post editor:

import { registerPlugin } from '@wordpress/plugins';
// The edit post PluginSidebar.
import { PluginSidebar } from '@wordpress/edit-post';
import icon from './icons/rm-codes'; // Link your own icon.

const RmCodesSidebars = () => (
	<PluginSidebar
		name="a-sidebar"
		title={ 'A sidebar' }
		icon={ icon }
		className={ 'rm-codes-sidebar' }
	>
		Sidebar Content goes here.
	</PluginSidebar>
);

// Register `rm-codes` plugin.
registerPlugin( 'rm-codes', {
	render: RmCodesSidebars,
} );

And now the code for registering a sidebar in the site editor:

import { registerPlugin } from '@wordpress/plugins';
// The *edit site* PluginSidebar.
import { PluginSidebar } from '@wordpress/edit-site';
import icon from './icons/rm-codes'; // Link your own icon.

const RmCodesSidebars = () => (
	<PluginSidebar
		name="a-sidebar"
		title={ 'A sidebar' }
		icon={ icon }
		className={ 'rm-codes-sidebar' }
	>
		Sidebar Content goes here.
	</PluginSidebar>
);

// Register `rm-codes` plugi.
registerPlugin( 'rm-codes', {
	render: RmCodesSidebars,
} );

The only difference here is that PluginSidebar is loaded from **@wordpress/edit-site** rather than **@wordpress/edit-post**, presumably the main difference is the slotfill that is used to get the sidebar to show up in the right place.

Note to self: maybe we can create a single PluginSidebar that works across all editing contexts.

Further thoughts

It should be possible to add a sidebar wherever we have a full block editor experience, while this covers off the two most common use cases there is still one area where adding sidebars is not possible: the classic widgets screen.

Since WordPress 5.8 hybrid themes or classic themes have access to a new block editor powered widgets screen:

The block editor powered classic widgets screen.

Unfortunately there is no mechanism to add a sidebar here at the moment.

For consistency across all block editor implementations I would hope to see this added at some point, presumably under the package **@wordpress/edit-widgets**

There is an issue open for this but as of yet it has not gained much traction.

Creating Cron jobs in WordPress plugins

Tue, 03 Jan 2023 15:30:03 GMT

This topic has been covered plenty already but I always find myself googling this or looking at an old codebase when I need to create cron jobs in WordPress.

So this is more of a note to self (as I imagine many future posts will be) of how to do this as a self contained example, in a WordPress plugin.

Here’s the code, with comments:

// Setup the interval/frequency for the cron job.
add_filter( 'cron_schedules', 'rm_codes_cron_schedules' );
function rm_codes_cron_schedules( $schedules ) {
	// Create a 12hrs interval.
	if ( ! isset( $schedules['12hrs'] ) ) {
		$schedules['12hrs'] = array(
			'interval' => DAY_IN_SECONDS / 2,
			'display'  => __( 'Once every 12 hours', 'rm-codes' ),
		);
	}
	return $schedules;
}

// Attach the cron job setup to plugin activation
register_activation_hook( __FILE__, 'rm_codes_cron_activate' );

// Setup the cron job to run at the specified interval.
function rm_codes_cron_activate() {
	// If the cron job is not scheduled, schedule it.
	if ( ! wp_next_scheduled( 'rm_codes_cron' ) ) {
		wp_schedule_event( time(), '12hrs', 'rm_codes_cron' );
	}
}

// Remove the cron job when the plugin deactivates.
register_deactivation_hook( __FILE__, 'rm_codes_cron_deactivate' );

// Deactivate the cron job.
function rm_codes_cron_deactivate() {
	wp_clear_scheduled_hook( 'rm_codes_cron' );
}

// Add the cron job task action.
add_action( 'rm_codes_cron', 'rm_codes_cron_run_task' );
// The task to run.
function rm_codes_cron_run_task() {
	// Run the task...
	// ** error_log() won't usually work in cron for debugging,
	// better use file_put_contents.
	file_put_contents( WP_CONTENT_DIR . '/debug.log', 'Cron job ran at ' . gmdate( 'M d Y H:i:s' ) . PHP_EOL, FILE_APPEND );
}

Remember, don’t do anything time critical with WP Cron as it will only be run when a visitor hits your site and the interval has passed.

For further reading checkout the docs on WP Cron.

How to add a Mastodon verified link without a plugin

Mon, 02 Jan 2023 11:02:43 GMT

You can add Mastodon verified links to your WordPress site without using a plugin by adding a code snippet (below).

If you’re not sure what a verified link is, they look like this, with the check:

First make sure to use the core Mastodon social link block and add a link to your Mastodon profile:

Then add the following code snippet to your child theme’s functions.php:

// Filter the Mastadon social link and add rel=me
function add_mastodon_rel_me( $block_content, $block ) {

	if ( $block['attrs']['service'] !== 'mastodon' ) {
		return $block_content;
	}

	$block_content = preg_replace( '@<a(.*)>@U', '<a$1 rel="me">', $block_content );
	return $block_content;
}

add_filter( 'render_block_core/social-link', 'add_mastodon_rel_me', 10, 2 );

I’m using this for the link at the bottom of this site ⬇

Disclaimer: all Mastodon links (via the social link block) will be updated with the rel=”me” attribute – probably fine for personal sites but maybe not if you are using multiple Mastodon profile links.

Update: I’ve been kindly informed that with Gutenberg 14.5 the link block comes with a rel attribute option in the UI, this is not yet released in core (my guess would be WP 6.2) but you can get it today by installing the Gutenberg feature plugin.

Hello world 2023 edition

Mon, 02 Jan 2023 10:52:34 GMT

If you’re seeing this message then its likely you’ve found this site while it’s still in development.

This is currently a playground for testing out some new WordPress features (such as FSE) and occasionally blogging about WordPress and web development in general.

So 👋 happy new year and bye for now.

rm.codes

Data loading in React based WordPress admin pages

Whats wrong with wp_localize_script() ?

React and the @wordpress/data package

When shouldn’t we use @wordpress/data

Back to the caveat: what if we want data on page load

Preloading our REST API endpoints

Creating a new preload function for custom admin screens

You can use apiFetch without the data package

Further thoughts

WCEU Torino – a first timers experience

Travelling to Torino

Day one / contributor day

Day two

Day three

Notable introductions

Mastermind

Summary

SlotFills and fillProps in the block editor

A quick explanation

Example

Passing props (fillProps)

Installing WordPress Coding Standards

What are the WP Coding Standards, and what is PHPCS

Prerequisites

Setup

Add the package to your project

Add WPCS rules location to PHPCS

Automating this for developers

Configure your IDE (VS Code)

Auto formatting on save (phpcbf)

Configure the WordPress Coding Standards

Excluding some rules

Taking it further

Creating sidebars for the post and site editors

Further thoughts

Creating Cron jobs in WordPress plugins

How to add a Mastodon verified link without a plugin

Hello world 2023 edition

Whats wrong with `wp_localize_script()` ?

React and the `@wordpress/data` package

When shouldn’t we use `@wordpress/data`

You can use `apiFetch` without the data package