The Publishing Project

Axios toolkit for WordPress API: Working with custom post types

The last two articles on using Axios with the WordPress REST API has worked with standard items in the WordPress world like post and pages. WordPress also gives you the option of creating your own content types with Custom Post Types (CPTs) We create custom post types in PHP, either in a theme’s functions.php or in a plugin. When working with the REST API, the important configuration is show_in_rest. Specifying this attribute with a value of true will make the custom post type available in the WordPress API. The CPT definition for an essay CPT looks like this: <?php function

Axios toolkit for WordPress REST API

As I’m learning the deep workings of the WordPress REST API I’m also learning how to use Axios as a replacement for Fetch. While I discovered that this will not work with Nuxt and the WordPress REST API, it’s still a good starting point if you want to work with vanilla JS and templating engines. I am still researching how to make it work in Nuxt.js. Another thing that’s important to note. Other than getJWT() all other functions require authentication and I’ve chosen to use JSON Web Tokens (JWT) to authenticate the requests. The WordPress site uses the JWT Authentication

Evergreen browsers and looking for a sane JS baseline

The term “evergreen browser” refers to browsers that are automatically upgraded to future versions, rather than being updated by the distribution of new versions from the manufacturer, as was the case with older browsers. from Techopedia — Evergreen Browser The concept of an evergreen browser is an interesting one from a development perspective but it’s not without its drawbacks. In an evergreen world, developers don’t have to worry about what version of a browser a user has because it automatically updates to the latest version. Most major browsers are evergreen, either via auto-updating (Chromium browsers and Firefox) or via OS

New research into block development

While researching block-based themes I found more information about blocks themselves and how to write them in a way you can submit them for inclusion in the WordPress directory. Most, if not all our blocks, will not be dynamic so we won’t cover them in this post, just mention them in case that’s what you’re looking for. See creating dynamic blocks for more information Creating blocks with external metadata The block type metadata provides an external means to declare our block API that will also be necessary if you decide to submit it to the block directory. The metadata is

Gutenberg Full Site Editing and Block-Based Themes

Note Right now block-based themes and full site editing are still work in progress. I write about it because, sooner rather than later, themes will take advantage of full site editing and they will become a new tool in the arsenal for WordPress developers. These features are not part of Core WordPress, they require the latest Gutenberg plugin (not the version that is bundled with WordPress), and the APIs discussed in this post may change before they are merged into core and become official parts of WordPress. An experimental feature available in recent versions of Gutenberg is the ability to