Starting with WordPress 6.8, speculative loading is enabled by default, prefetching pages that users are likely to navigate to. As a result, using navigation:auto within @view-transition{} in CSS sometimes leads to an issue in Chrome (and likely other Chromium based browsers), where pages load so fast the view transition is skipped and the browser console reports a general view transition error.

Local by Flywheel compounds this using Cache-Control: no-store on all responses, which seems to conflict with Chrome’s prefetch cache.

WordPress exposes a wp_speculation_rules_configuration filter to control speculation behavior. Switching from prefetch mode to prerender resolves the conflict. I wrap this with a local conditional check, allowing the defaults be used in other environments.

add_filter( 'wp_speculation_rules_configuration', 'apm_configure_speculation_rules' );

function apm_configure_speculation_rules( $config ) {

    if ( wp_get_environment_type() === 'local' ) {
        $config['mode'] = 'prerender';
        $config['eagerness'] = 'conservative';
    }

    return $config;

}

For a recent project with en email component I planned to fire up a month of my on-again off-again Litmus.com subscription for testing. Unfortunately, their new enterprise-focused pricing model put a quick stop to that. Call to learn about pricing? No thanks.

Enter Testi@.

My requirements for an email testing platform aren’t complex:

• tests against all popular email clients
• has generous testing limits
• has sharable test results
• has an editor/previewer UI
• offers some level of feedback on potential issues in code

Testi@ checks all the boxes, and it’s tough to beat their $16/mo pricing. I may still kick the tires of Email on Acid at some point. But, for now, I’m all set.

PHP Notice: Function _load_textdomain_just_in_time was called incorrectly.
Translation loading for the wp-migrate-db domain was triggered too early.
This is usually an indicator for some code in the plugin or theme running
too early. Translations should be loaded at the init action or later.
Please see https://developer.wordpress.org/advanced-administration/debug/debug-wordpress/
Debugging in WordPress for more information. (This message was added in
version 6.7.0.) in /.../wp-includes/functions.php on line 6121

The log becomes useless for your own testing and debugging if it’s cluttered with other people’s garbage, and simply disabling the plugin isn’t always feasible.

Fortunately, there’s an action/hook you can leverage to selectively filter stuff out of the debug log, but you must configure the hook as an MU (must-use) plugin.

<?php
/**
 * Plugin Name: Suppress Errors
 * Description: Prevents certain errors from being logged in WordPress
 */

 add_action( 'muplugins_loaded', function() {

    // Override WordPress error handler for this specific case
    $original_handler = set_error_handler( function( $errno, $errstr, $errfile, $errline ) use ( &$original_handler ) {
        
        // Check if this is our specific error
        if ( str_contains( $errstr, '_load_textdomain_just_in_time' ) ) { 
            // Suppress this error only
            return true;
        }

        // Use the original handler for all other errors
        if ( is_callable( $original_handler ) ) {
            return call_user_func_array( $original_handler, func_get_args() );
        }

        // Default error handling
        return false;

    } );

}, 0 );

I’ll try to come back to this post later and step through what’s happening in this function, but for now, know the str_contains conditional is where you’ll check a bit of text that’s unique to the error you’d like to disable. Add multiple conditions as necessary.

I don’t recommend using this in a production environment. It could have performance implications or conflicts. I only occasionally use it my local dev environment, and only if I really have to. This should be considered a very temporary measure. Don’t block errors or notices indefinitely. Let the developers of the offending plugin know about the error. In the case of my example above from WP Migrate Pro, the issue was fixed before I was even able to publish this article.

1. Custom Fields
2. Editor
3. Revisions

The custom post type must also be accessible to the WordPress REST API.

Aside from this github pull request (which outlines the above prerequisites) I couldn’t find documentation on footnote requirements for custom post types. But, enabling those post type options seems to do the trick.

If you’re attempting to leverage ACF block bindings, don’t forget to enable REST API access in the Field Group Settings panel. On each field you wish to expose, enable the “Allow Access to Value in Editor UI” option under the Presentation tab.

I have a project on the docket that will utilize a hybrid theme (block editor + php templates) atop an existing database, and this feature will allow us to save some time by referencing existing meta data via block variations.

The sessions I attended were solid. Toby Cryns had great tips for making more money as a freelancer while not increasing workload. Tracy Apps presented a well-considered thesis on AI (artificial intelligence) and our social responsibilities when considering its application it to our work. Gary Kovar demonstrated how WordPress is used at scale on nasa.gov. David Wolfpaw talked custom block development, and Jon Christensen discussed 10up’s approach to block-based themes. Finally, Jennifer Dust and Eli Frigoli talked accessibility, offering practical tips and a demonstration of using Wave for testing.