Image Lightbox (WordPress 6.4)

In WordPress 6.4, the core image block now comes with a lightbox toggle, labeled as “Expand on click.” Activating it for your image will produce the result below.

The documentation also mentions that you can enable it site wide through the Site Editor. However, if you’re running a non-block/hybrid theme, you don’t have access to that functionality. What else can you do?

Well, it turns out you can also enable it via the theme.json file, under the settings.blocks section like so.

"settings": {
    "blocks": {
        "core/image": {
            "lightbox": {
                "enabled": true
            }
        }
    }
}

Using this code will automatically enable the toggle on all newly added images, but won’t turn on the lightbox functionality for any previously added core image blocks.

One other note: while you can also turn it on individually for each image in a gallery, it does not allow users to move between the images using arrow keys or swiping. Each image lightbox is still treated individually, though I believe enhancements are being planned for WordPress 6.5!

4 Exciting WordPress 6.3 Updates for Developers

WordPress 6.3, the latest update for the blogging/CMS platform, arrived on August 8th, and with it came a number of changes & enhancements. Below are a few of the ones I’m excited about, but be sure to read the field guide to get all the details!

async and defer Script Attributes

To help assist with script loading strategies for performance, the wp_register_script and wp_enqueue_script functions have been updated to allow the $in_footer parameter to be “overloaded,” meaning it can take its normal attributes of true or false, OR it can now be passed an array containing the loading strategy of async or defer. You can also still pass whether you want it in the footer or not via the array.

// Old method
wp_enqueue_script( 'script-name', 'script-path.js', array( 'dependencies' ), 'VersionNumber1', true );

// New method
wp_enqueue_script( 'script-name', 'script-path.js', array( 'dependencies' ), 'VersionNumber2', array( 'in_footer' => true, 'strategy' => 'async' ) );

For clarification, using defer essentially means the script, even if it’s located in your site’s <head>, behaves like it’s being called right before the closing </body> element. Scripts enqueued this way will still load in the order they were added to the DOM, allowing dependency management.

Using the async strategy means your script will load as soon as the browser encounters it, but does not have to load the script in a particular order. It’s like telling the browser, “Hey, I might take a moment, but don’t hold up the rest of the site on my behalf. Keep going, I’ll get done eventually.”

Image Performance Enhancements

WordPress now adds fetchpriority="high" to the image it determines to be the largest one that is within the viewport. This means that image will now be prioritized by the browser to render earlier, thus helping decrease the largest contentful paint metric.

WP Core also now includes the wp_get_loading_optimization_attributes() function to help apply additional loading attributes. Because WordPress has instituted the new function everywhere in core that handles images, it adds consistency to the way fetchpriority and loading attributes are handled for images. Note: currently, the new function only applies to images and iframes.

Lastly, images that appear before the_loop now count towards the threshold for which images get the loading="lazy" attribute, and the threshold has been updated from 1 to 3 to account for multi-column layouts with images.

Layout Supports

Another new addition is you can now add layout support to your custom blocks via properties in the block.json file. This is meant for blocks that contain inner blocks which need to be positioned a particular way, such as in columns. The simplest method to get started is by adding the following code in your block.json’s supports section.

"supports": {
    "layout": true
}

By default, this uses the “flow” layout, which shows the “Inner blocks use content width” toggle, turned off to start. However, you can also pass an object for layout instead of a boolean value, and utilize several subproperties.

Say you want to default the inner blocks toggle to On instead, aka the “constrained” layout. You can do so by setting the default subproperty type to constrained.

"supports": {
    "layout": {
        "default": {
            "type": "constrained"
        }
    }
}

You also can specify types of "flex" and "grid", though there is a caveat. From my testing, if you only set the type to one of those values, the inner blocks toggle still appears, and clicking on it will remove the options that are specific to flex and grid. To get around that, you can add the layout subproperty of allowInheriting with a value of false, which turns off the toggle.

"supports": {
    "layout": {
        "default": {
            "type": "grid"
        },
        "allowInheriting": false
    }
}

New Blocks

Last but not least, WordPress 6.3 comes with 2 new blocks added to core: Details and Footnotes.

The Details block is essentially outputting a details/summary element into the page, with the ability to set whether it’s open or closed by default.

The summary text

You can place as much text & other blocks inside the details block as you wish. For example, I’ve added a YouTube embed inside a Group block with a background color below.

The Footnotes block by itself only adds a section that will display any footnotes added inline inside it. You can move it around wherever you wish inside your content, but if you apply a footnote1 via the block toolbar to inline text without adding the block, it will append the block for you at the end of the content.


So that does it for this roundup, but what do you think of the improvements? Drop me a message and let me know if there’s any that you’re excited to use. Until next time!

  1. The footnote number links here, and the following link brings you back to the respective text. ↩︎

How to verify yourself on Mastodon (for free!)

In this day and age, proving you are who you say you are on social media feels like an uphill battle. Particularly if you don’t have $1,000 to do so.

That’s why I’m happy to report that you can verify1 yourself on Mastodon for the low, low price of FREE. Let’s see how!

I want to thank Eric Meyer for his lovely walkthrough which was my gateway into this, and to the commenters from that article who added more context. Please go read his writeup first, then come back for some additional pointers.

Set up on Mastodon

Following Eric’s breakdown, you’ll have located where to add your links to the Profile metadata in your Profile settings, and found the Verification section showing an example code snippet to use on your site. You can copy the code in that example, but the main pieces you really need are:

  1. Your profile URL
  2. The rel="me" attribute

Set up on your website

<a rel="me" href="https://your-mastodon-url-here"/>Mastodon</a>

If you use the code provided from Mastodon, it can be placed anywhere on your site that a normal text link would appear: header, footer, navigation menu, content, etc. You can replace the “Mastodon” text with other text, or even an image or icon (though for accessibility I recommend including alt text or visually hidden text to describe what the link is for). Eric does this by including alt text on the image inside his link.

However, you aren’t actually limited to sticking a visible link somewhere on your page. If you’d prefer a more invisible one, you can add the following code into the <head> of your page/site, and it functions just the same for verification! It also means a screen reader user/keyboard user doesn’t have to interact with an additional link that may only be there for verification purposes.

<link rel="me" href="https://your-mastodon-url-here"/>

Multiple verified users

Something that isn’t clear on first glance in Eric’s article is that you can add multiple links on a site to verify more than one person. If you include multiple <link>‘s in your site head, each person represented can be verified for that site/page on Mastodon.

<link rel="me" href="https://mastodon-user-1-profile-url"/>
<link rel="me" href="https://mastodon-user-2-profile-url"/>
<link rel="me" href="https://mastodon-user-3-profile-url"/>

For instance, you could:

Github

In Eric’s article, he mentions that verifying with Github requires a bit of a workaround, as there was only 1 available URL field for profiles. As of that writing, Github has added 4 more fields for “Social Accounts”, which all include the rel="me" attribute when saved (Twitter announcement). This allows you to have the best of both worlds, showcasing a main portfolio (or any other link prominently), along with linking to Mastodon and being verified.

Verification

One issue I ran into initially is if I had already entered a URL in my profile metadata before adding the link to my website, Mastodon wouldn’t update to show the verification. It’s likely due to results being cached on save, but it might confuse first time users. The quickest way to get around this is to simply remove the URL in Mastodon, save your profile, and then add it back in and save again. This seems to force Mastodon to run the test again, and should now show the coveted green checkmark!

Follow up?

If anyone is interested, I’m tossing around the idea of a tutorial on how to add Mastodon links to WordPress profile pages and output them for author archives.


1Verify here means creating a link between your social profile and an external site you control to prove that it is, indeed, your account.