joemaller

Input: Any Processing Instruction element, eg. <? string >?

Output modified Processing Instruction element

Expected Processing Instruction element passed through unchanged.

---

joemaller

Use Prettier to format HTML & PHP with a single VS Code command

Prettier is a fantastic tool, but doesn't natively support PHP. The Prettier PHP Plugin helps, but fully takes over formatting of PHP files and skips HTML in mixed documents.

There is a command-line solution (add --parser html), but most of the time I'm formatting on-the-fly in VS Code, so dropping out to the command line would be a huge slowdown.

Which brings up another problem: The Prettier VS Code extension hasn't worked with Prettier plugins since August 2023.

But, there's a solution to which works really well, even if it's a little slow.

joemaller

Plane questions

• Q. How to run vitest with full breakpoint debugging in vscode?

  Open JavaScript Debug terminal from the VS Code terminal dropdown menu. Run the tests normally.

• how to increase the collapse limit for nested objects in the js console when dumping from vitest?

  This works, but it's gross:

import util from "node:util";

joemaller

Patterns are proving to be exceptionally useful, but there is some confusing, bug-like behavior with the core/query Query Loop block where patterns assigned to newly inserted blocks discard the pattern's query and fallback to the block's defaults. (as of March 2025).

1. Insert a Query Loop block, click Choose, select pattern.
   Expectation: Use the specified pattern's query.
   Actual: The pattern specified in the query is ignored, query reverts to defaults (postType, perPage, order, etc.)
   

2. Configure a Query Loop Block, then click Replace to choose a pattern
   Expectation: Either use the query in the pattern, or offer an option to replace the query?
   Actual: Existing query is preserved.
   This situation is not clear. Existing behavior makes some sense, since we've already configured the query. However there is still a query in the pattern which is being ignored.

joemaller

WordPress 6.6 introduced support for custom Aspect Ratios for image blocks. Image Aspect Ratio options can be configured in the WordPress Block Editor by providing a list in the settings.dimensions object.

There's no easy way to remove individual aspect ratios from the list. The only options are to extend the existing list or fully replace it.

So, something like the following will produce a menu with 12 Aspect Ratio choices.

{
  "$schema": "https://schemas.wp.org/trunk/theme.json",
  "version": 3,

joemaller

<?php


/**
 * Experiment to rewrite the render_callbacks of the pagination prev/next blocks to swap the arrow for something else
 */
add_filter('register_block_type_args', __NAMESPACE__ . '\\swap_render_callback', 10, 2);

/**
 * Replace the pagination-prev/next render_callback with a function which wraps the native function's return value

joemaller

Kind of a silly breakthrough, but I seem to have finally nailed down how to access Post data inside a custom block with useSelect. I'm not going to bother quoting the official docs, they're extensive but hard to follow. Instead, here's the chunk of code I wanted to document and remember, it exposes the full Post object to the Block Editor:

const post = useSelect(
  (select) => select("core").getEntityRecord("postType", postType, postId),
  [postId]
);

Let's walk through that, outside-in:

joemaller

<?php 

function validateGF_Token($token)
{
    global $wpdb;
    $gf_drafts_table = $wpdb->prefix . 'gf_draft_submissions';
    $table_check = $wpdb->get_var("SHOW TABLES LIKE '{$gf_drafts_table}'");
    if ($table_check !== $gf_drafts_table) {
        return false;
    }

joemaller

Creating Block Varitions from core/groups

Recently we had a Block Variation which needed to be switched from core/columns to core/group. Should have been easy enough, but the identity of the variation, its name and icon, would never show up. No matter what, the variation's isActive method was not even being called.

The problem

It turns out that the various layouts available to the core/group Group Block are all Block Variations. Each has it's own isActive function, which simply checks the Block's layout.type attribute and sometimes it's layout.orientation.

The problem is that all of the isActive functions for each of the Block's variations are run in order until one returns true, at which point WordPress stops checking. This is documented in the very last paragraph of the Block Editor Handbook's [V

joemaller

import { exec } from "node:child_process";

export function callExec() {
  return new Promise((resolve, reject) => {
    exec(`ls -la`, (error, stdout, stderr) => {
      if (error) {
        reject(error);
        return;
      }
      if (stdout) {