This is a collection of scripts, bash functions, and config files that help me do WordPress core development.
/wp
: parent folder/wp/svn
: SVN checkout/wp/git
: Git checkout/wp/{ git | svn }/wp-test-config.php
: see attached file
const { blocks, plugins } = wp; | |
const { dispatch, select } = wp.data; | |
/** | |
* When a selected block is being disposed during a hot module reload, persist | |
* its clientId so it may be reselected after the new module version loads. | |
* | |
* If the block being unloaded is currently selected, clear that selection to | |
* avoid a Gutenberg error that occurs when unregistering a selected block. | |
* |
/* eslint-disable no-console */ | |
/** | |
* A little module that adds a wpapi() method to the window object. | |
* | |
* wpapi() takes an API path (e.g. /wp/v2/posts), optionally containing string query parameters, | |
* or a query-less API path and a hash object of query param objects. | |
*/ | |
( context => { | |
const { root, nonce } = context.WP_API_Settings; |
/* | |
------------- | |
mkdirp usage: | |
------------- | |
var mkdirp = require('mkdirp'); | |
mkdirp('/tmp/foo/bar/baz', function (err) { | |
if (err) console.error(err) | |
else console.log('pow!') |
var albumArt = (() => { | |
// Helpers | |
// (e.g. DOM shortcuts and class-checking utilities) | |
var qsa = ( container, selector ) => [ ...container.querySelectorAll( selector ) ]; | |
var nodeHasClass = ( node, str ) => node.classList.toString().indexOf( str ) > -1; | |
var whereNodeHasClass = ( str ) => ( node ) => nodeHasClass( node, str ); | |
var wherePropertyLike = ( obj, str ) => { | |
const key = Object.keys( obj ).find( key => key.indexOf( str ) > -1 ); | |
return key ? obj[ key ] : null; |
{ | |
"root": true, | |
"env": { "es6": true }, | |
"extends": [ | |
"eslint:recommended" | |
], | |
"parserOptions": { | |
"sourceType": "module" | |
}, | |
"rules": { |
In the year since 4.8, confusion about how to properly expose meta information through the REST API has been one of the most prevalend issues we've seen in support posts and tickets.
Most developers try to use register_meta
with show_in_rest => true
; unfortunately register_meta
works on object types, not subtypes, so you cannot pass a custom post type name into register_meta
like you can with register_rest_field
. Worse, if you register meta for the type 'post'
, then that meta key is registered not just for core posts, but for every single custom post type. Meta almost never applies across all post types, so this behavior forces developers to use register_rest_field
for REST API data modeling instead of taking advantage of the API's built-in meta handling.
there is no way to and this behavior makes it impossible for a developer to register meta that is specific to their single post type. and requires any REST API data modeling to use register_rest_field
[...document.getElementById('authors').querySelectorAll('li')].forEach(li => { | |
const author = li.querySelector('strong').innerText; | |
const select = li.querySelector('select'); | |
const options = [...select.querySelectorAll('option')].map(node => ({ | |
value: node.value, | |
name: node.text, | |
})); | |
const match = options.reduce((match, option) => { | |
if (match) { | |
return match; |