WordPress 6.9 is being released today and brings a set of meaningful improvements to the block editor. The focus this cycle has not been on headline features but on the practical refinements that make daily publishing easier, clearer, and more collaborative. This post highlights the most useful changes for editorial teams, along with important technical notes for developers who build custom blocks, particularly with ACF’s block.json workflow.

Editor Improvements That Matter

1. Block Notes: Contextual Comments Inside the Editor

WordPress 6.9 introduces block-level comments, referred to as Notes. These allow editors, writers and designers to leave comments attached to specific blocks in a piece of content. This solves a long-standing problem in the editor: feedback no longer needs to be passed around through email or external documents, and reviewers no longer have to reference “the third paragraph” or “the image halfway down the page.”

This pushes WordPress closer to a modern collaborative editing environment while keeping everything inside the platform itself.

How does it work?

In the editor, you’ll see a new item in the block settings for “Add Note”

When a block has a note, you’ll see a Gravatar image indicting it.

When you click that, you’ll open the notes sidebar view.

Notes can be replied to, edited or resolved.

2. Hide Blocks Without Removing Them

Another welcome addition is the new visibility control that allows any block to be hidden from the front-end without deleting it. This is useful when preparing alternative layouts, temporary content, seasonal sections, or work-in-progress elements that are not ready to publish. Hidden blocks remain fully editable and can be restored at any time.

This feature is simple but has a real impact on day-to-day editing. It gives teams more flexibility in drafting and staging content without touching version history or removing markup from posts.

How does it work?

In the editor, you’ll see a new item in the block settings for “Hide”

When a block is hidden, a new icon appears in the document overview to indicate it’s status.

n.b. The block is also hidden in the editor, which was a suprise to me. You can only see hidden blocks in the Document Overview panel.

"supports": {
    "notes": false
}

The post What’s New in WordPress 6.9? appeared first on Andy White, WordPress Developer.

That might sound like another quiet standards update, but it’s actually a big deal for digital accessibility. WCAG has always guided how we make the web usable for everyone, but ISO status gives it real global weight. It means the principles and success criteria that designers and developers already follow now have formal recognition as part of international law and policy frameworks.

What WCAG 2.2 Adds

WCAG 2.2 builds on the foundation of 2.1 and introduces nine new success criteria designed to improve accessibility for people with cognitive and mobility impairments, and for users on mobile devices.

Some key updates include:

• Focus not obscured (2.4.11 & 2.4.12) – making sure focus indicators stay visible when elements overlap.
• Focus appearance (2.4.13) – requiring stronger visual indicators for keyboard focus.
• Dragging movements (2.5.7) – ensuring users can perform actions without complex dragging.
• Target size (minimum) (2.5.8) – defining minimum touch target sizes for buttons and links.
• Consistent help (3.2.6) – keeping support options easy to find throughout a site.
• Redundant entry (3.3.7) – reducing repeated data entry for users with memory or mobility challenges.
• Accessible authentication (3.3.8 & 3.3.9) – making login and verification easier for all users.

One older rule, Parsing (4.1.1), has been retired. The rest of WCAG remains backward-compatible, meaning a site that meets WCAG 2.2 at Level AA also meets 2.1 and 2.0 at the same level.

Why ISO Status Matters

When WCAG becomes an ISO standard, it steps into a different league. ISO standards are used in national legislation, procurement, and certification across the world.

That means:

• Governments and large organisations can now directly reference WCAG 2.2 as a formal standard, not just a recommendation.
• Public sector tenders and digital contracts can point to ISO/IEC 40500:2025 for accessibility compliance.
• International consistency improves, helping align accessibility laws and digital regulations between countries.

For developers, designers, and agencies, it’s a signal that accessibility is no longer a nice-to-have. It’s a requirement backed by international consensus.

What to Do Next

If your site or app already follows WCAG 2.1, you’re in a good position. But it’s worth auditing against the new criteria, especially for focus, touch, and authentication features.

Here are some practical steps:

1. Update your accessibility statement to reference WCAG 2.2 Level AA (ISO/IEC 40500:2025).
2. Test your forms, buttons, and focus states against the new success criteria.
3. Check mobile usability and ensure all interactive targets meet minimum touch sizes.
4. Review authentication and login processes to make sure they’re inclusive.
5. Inform clients and teams that WCAG 2.2 is now the global standard.

Looking Ahead

The publication of WCAG 2.2 as ISO/IEC 40500:2025 gives accessibility work more credibility and structure than ever before. It reinforces that inclusive design isn’t optional. It’s a core part of professional web development.

If you’re maintaining or building WordPress sites, this is the perfect time to review your accessibility practices and align your projects with the latest international benchmark.

The post WCAG 2.2 Becomes an ISO Standard: What It Means for Web Designers and Developers appeared first on Andy White, WordPress Developer.

It’s AI browsers – led by OpenAI’s new Atlas ChatGPT browser, which can read, interpret, and summarise your site the way a human (or a search engine and a researcher) would.

Atlas doesn’t just display your website – it understands it. That means your HTML, schema, and information architecture now matter in a whole new way.

If you build or manage websites, this shift is as significant as the move from desktop to mobile. The goal is no longer just “make it look good”; it’s make it readable by humans and machines.

What is the Atlas ChatGPT Browser?

Atlas is OpenAI’s new integrated browser powering ChatGPT’s “Browse with GPT-5” mode.

Instead of rendering visuals for the user directly, it fetches and interprets your site’s structured data, metadata, and semantic HTML – transforming your content into something ChatGPT can quote, cite, and reason over.

Think of it as a cross between:

• A headless Chromium crawler
• A semantic parser
• A researcher with perfect recall

When ChatGPT answers a user query, Atlas may retrieve parts of your website in real time – so the way you build it directly affects whether (and how) your content appears.

What “Atlas-ready” really means

Being Atlas-ready means your site is:

1. Machine-readable
   Clean, semantic HTML and schema markup
2. Crawl-able
   Content visible without JavaScript execution
3. Structured
   Headings, metadata, and summaries clearly identify key facts
4. Accessible
   WCAG-compliant, keyboard-friendly, properly labelled
5. Performant
   Stable, fast, and consistent

When Atlas visits your site, it should be able to tell the story of what the page contains: who it’s for, what problem it solves, and why it’s trustworthy.

Practical steps for developers

1. Use proper HTML semantics.
   Headings, lists, tables, and <article> tags communicate hierarchy.
   Avoid generic <div> soup — Atlas won’t infer meaning from class names alone.
2. Add structured data (JSON-LD).
   Schema for Article, Event, Person, and Organization helps AI systems classify your content accurately.
3. Expose your core content in HTML.
   If it’s hidden behind JS hydration, Atlas may miss it. Server-side rendering or static generation is your friend.
4. Write like a human teacher.
   LLMs thrive on clarity and context. Use short paragraphs, consistent entities, and natural language summaries.
5. Maintain accessibility.
   The same qualities that make a site accessible — labelled forms, alt text, keyboard navigation — make it understandable to AI.

Why this matters for your clients

In a few months, “How do I appear in ChatGPT results?” will be the new “How do I rank on Google?”.

Websites that are Atlas-ready will feed richer data into AI-driven summaries, answer engines, and future multimodal search.

That’s a competitive edge.

So I’ve created a free developer checklist to help you audit and future-proof your own builds.

The post Building Atlas-Ready Websites: Preparing for the ChatGPT Browser Era appeared first on Andy White, WordPress Developer.

Unfortunately, in its default form, WordPress’ skip link doesn’t actually work as intended.

The Problem? Scroll, but No Focus

The default skip link in WordPress simply scrolls the page to the <main> element.
It doesn’t move keyboard focus to that element – which means after activating the skip link and pressing Tab, focus jumps back to the top of the page (usually the logo or first menu item).

That’s frustrating and confusing for keyboard users, and effectively means the skip link fails its core purpose.

Here’s the relevant JavaScript snippet WordPress injects:

( function() {
  var skipLinkTarget = document.querySelector('main');
  if (!skipLinkTarget) return;
})();

It scrolls the viewport, but doesn’t assign focus.

To make it behave properly, you need to add a temporary tabindex="-1" to the <main> element and focus it when the link is activated:

document.querySelector('.skip-link').addEventListener('click', function(e) {
  var target = document.querySelector('main');
  if (target) {
    target.setAttribute('tabindex', '-1');
    target.focus();
  }
});

This ensures that keyboard users land inside the main content region, ready to continue navigating logically.

The Fix (and Best Practice)

To make WordPress’ skip link actually useful:

1. Give your main landmark a unique ID (for example <main id="main-content">)
2. Add a tabindex="-1" attribute dynamically (or permanently if appropriate)
3. Focus the target element when the skip link is activated
4. Remove the tabindex afterward if you wish to keep your DOM clean

Here’s a full working example:

( function() {
  var skipLink = document.querySelector('.skip-link');
  var target = document.querySelector('main');

  if (skipLink && target) {
    skipLink.addEventListener('click', function(e) {
      e.preventDefault();
      target.setAttribute('tabindex', '-1');
      target.focus();
    });
  }
})();

In Summary

The default WordPress skip link looks right – but fails silently for those who need it most.
A simple line of JavaScript and a tabindex attribute can make your site significantly more accessible and compliant with WCAG 2.2 AA.

Accessibility isn’t just about passing tests – it’s about building interfaces that respect everyone’s way of using the web.

The post Why WordPress’ Default Skip Link Doesn’t Actually Work (and How to Fix It) appeared first on Andy White, WordPress Developer.

This post explains why – and more importantly, how to do it properly and securely.

The problem

WP Engine’s file system is designed for security and performance.
Your WordPress install lives at:

/nas/content/live/{sitename}/

You can’t go “one level up” from here – it’s locked, and it’s designed that way.

That means /nas/content/live/{sitename}/../private/sf.key simply isn’t possible.

So where can you safely store non-public files such as:

• Salesforce JWT private keys
• API credentials
• SSH or service tokens

/home/wpe-user/

{sitename}@{sitename}.ssh.wpengine.net

ssh {sitename}@{sitename}.ssh.wpengine.net

/home/wpe-user/

mkdir -p ~/.ssh
chmod 700 ~/.ssh

nano ~/.ssh/sf_private.key

scp ~/Downloads/sf_private.key {sitename}@{sitename}.ssh.wpengine.net:/home/wpe-user/.ssh/

chmod 600 ~/.ssh/sf_private.key

$this->private_key_path = '/home/wpe-user/.ssh/sf_private.key';

curl https://yourdomain.com/.ssh/sf_private.key

$private_key = getenv('SALESFORCE_JWT_KEY');

The post How to Safely Store a Private Key on WP Engine (e.g. for Salesforce JWT) appeared first on Andy White, WordPress Developer.

1. Lower Hosting and Server Costs

Heavy websites come at a price. Every oversized image, bloated script, and redundant plugin increases server load and bandwidth usage. Multiply that across thousands of visits, and you’re paying more for infrastructure than you need to.

By contrast, lean, efficient websites:

• Require less bandwidth and storage.
• Scale more cheaply under traffic spikes.
• Run smoothly on modest hosting plans.

This directly translates into lower monthly server bills and reduces the need for expensive upgrades as your traffic grows.

2. Faster Sites = Higher Conversions

Speed isn’t just nice to have – it’s a conversion factor. Multiple studies show that:

• Every 1-second delay in page load can reduce conversions by up to 7%.
• 40% of users abandon sites that take more than 3 seconds to load.

By stripping away unnecessary weight, a low-carbon site loads faster, keeping visitors engaged and guiding them through funnels more effectively. For e-commerce businesses, this can mean a measurable uplift in sales and revenue.

3. Accessibility and Inclusivity

A faster, more efficient site isn’t just greener – it’s also more accessible:

• Lightweight pages work better on slower connections and older devices, reaching users often excluded by bloated modern sites.
• Simpler, more semantic code improves compatibility with assistive technologies like screen readers.
• Accessible sites reduce legal and compliance risks, particularly for businesses operating internationally.

Accessibility isn’t just a moral or regulatory checkbox – it opens your business to a wider audience.

4. SEO and Search Visibility

Google has been clear: speed and user experience are ranking factors. A low-carbon site that delivers faster load times and better accessibility gains an SEO edge, improving visibility in search results and lowering the cost of customer acquisition.

5. Brand Reputation and Trust

Today’s customers care about sustainability. A site that loads fast, wastes fewer resources, and demonstrates green values reflects positively on your brand. It’s a subtle but powerful differentiator in markets where trust and reputation drive loyalty.

The post Why Low-Carbon Websites Make Business Sense appeared first on Andy White, WordPress Developer.

How the Attack Works

1. Hiding in Plain Sight
   Attackers drop a malicious loader into the wp-content/mu-plugins folder. Unlike regular plugins, must-use plugins (mu-plugins) are auto‑loaded by WordPress but never appear in the admin plugin list. That makes them the perfect hiding spot.
2. Loader + Payload
   The loader looks like a harmless utility file but fetches and decodes obfuscated payloads (using tricks like ROT13 and base64). These payloads are stored in the database under innocuous option keys such as _hdra_core, avoiding file‑based scanners.
3. Reinstatement Mechanism
   If the malware is removed, the backdoor can reinstate itself – sometimes through a disguised plugin (php-ini.php) or by creating hidden admin users with elevated privileges triggered only when a special URL parameter is passed.
4. Admin Takeover
   Some variants overwrite or reset credentials for accounts like admin or root, ensuring persistent access even if legitimate admins try to lock things down.

Why This Matters

• Invisible to normal plugin audits – most site owners never check mu-plugins.
• Database persistence – by storing payloads in wp_options, it evades file‑integrity checks.
• Self‑healing – simply removing the malicious file may not kill the infection.
• Total compromise – once admin credentials are under attacker control, nothing else matters.

What You Can Do

• Audit mu-plugins regularly – add this folder to your monitoring scripts.
• Check the database – scan the wp_options table for suspicious keys containing base64 or ROT13 blobs.
• Audit users – review admin accounts and watch for hidden or unexpected ones.
• Enforce deployment hygiene – only allow trusted code to be deployed, and tighten write permissions on the server.

The Bigger Picture

This wave of attacks highlights how attackers evolve: when security teams catch one method, they shift to another. In this case, they’re exploiting the fact that even seasoned WordPress developers rarely think to check mu-plugins or dig into option keys.

It’s another reminder that WordPress security isn’t just about patching – it’s about knowing where attackers hide, and expanding your monitoring accordingly.

Final Thought

If you run or manage WordPress sites: don’t ignore this. Next time you clean up a malware infection, double‑check mu-plugins and your database. Otherwise, you might just be cleaning the surface while the real backdoor lives on.

The post A Stealthy New WordPress Backdoor: Why You Should Be Checking mu-plugins appeared first on Andy White, WordPress Developer.

The 2025 SEO pillars

• User intent – matching the reason behind the search.
• Core Web Vitals – LCP, CLS, INP are ranking factors.
• Accessibility – good for users, rewarded by Google.
• Structured data – helps search engines understand your content.

Optimising Core Web Vitals

Test with Google Lighthouse or PageSpeed Insights.
Fix:

• Slow LCP (optimise hero images, use preload)
• High CLS (reserve space for images/ads)
• Poor INP (minimise blocking scripts)

Adding structured data

Use schema markup to help Google display rich snippets.

Example:

add_action( 'wp_head', function() {
    echo '<script type="application/ld+json">' . json_encode([
        "@context" => "https://schema.org",
        "@type" => "Organization",
        "name" => get_bloginfo( 'name' ),
        "url" => home_url()
    ]) . '</script>';
});

Writing for intent

If someone searches “best running shoes for flat feet,” they want recommendations, not a sales pitch. Match content to intent to rank well.

Takeaway checklist:

• Focus on intent-driven content.
• Meet Core Web Vitals thresholds.
• Implement schema where relevant.
• Ensure accessibility for both users and crawlers.

The post What SEO Really Means in 2025 appeared first on Andy White, WordPress Developer.

The carbon-speed connection

• Fewer bytes = faster load.
• Efficient code = less CPU strain.
• Better hosting = greener energy.

A 3MB homepage is bad for both the planet and your bounce rate.

Measuring your site’s footprint

Use Website Carbon Calculator. It estimates:

• Grams of CO₂ per page view.
• Annual emissions based on traffic.
• Whether your hosting runs on renewable energy.

PorterWP and sustainable design

Because PorterWP ships without bloat:

• CSS is modular and minimal.
• JavaScript is used sparingly and only where needed.
• Image handling is optimised for screen size and device.

This means lighter pages, faster loads, and fewer server resources consumed.

Practical ways to cut carbon in WordPress

1. Optimise images with plugins like Imagify or ShortPixel (enable WebP/AVIF).
2. Audit scripts and styles – remove unused files with Asset CleanUp.
3. Limit font weights – load only what you use.
4. Lazy-load media – native in WordPress but worth verifying.
5. Choose green hosting – providers that use renewable energy.

Code example: Disabling unused WordPress image sizes:

add_filter( 'intermediate_image_sizes', function( $sizes ) {
    return array_diff( $sizes, ['large', 'medium_large', '1536x1536', '2048x2048'] );
});

Takeaway checklist:

• Test your site’s carbon impact.
• Optimise and resize all images.
• Strip unused CSS/JS.
• Use a minimal, efficient theme.

The post Low-Carbon Websites: Why Sustainability Means Speed appeared first on Andy White, WordPress Developer.

The most common accessibility fails

• Poor colour contrast: Text that blends into its background.
• Missing alt text: Screen readers can’t describe images.
• Unclear link text: “Click here” is meaningless out of context.
• Inaccessible forms: Missing labels, poor focus styles.

A practical tool: the Colour Contrast Checker

When working with AVE Design, I built a Colour Contrast Checker. It takes two colours, calculates their luminance, and outputs a contrast ratio with WCAG pass/fail results.

The maths:

Contrast ratio = (L1 + 0.05) / (L2 + 0.05)

Where L1 is the lighter colour’s luminance, L2 is the darker.

If that ratio is below 4.5:1 for body text, it fails WCAG AA.

Implementing WCAG in WordPress

1. Install an accessibility checker plugin like WP Accessibility.
2. Test your colours using the AVE tool or WebAIM’s checker.
3. Use descriptive link text (“Download the Annual Report” beats “Click here”).
4. Add alt text to all meaningful images.
5. Check with a keyboard – can you navigate the whole site without a mouse?

Takeaway checklist:

• Meet WCAG 2.2 AA as a baseline.
• Test colour contrast before design sign-off.
• Choose a theme that’s accessibility-ready.
• Test with both automated tools and manual checks.

The post Designing for Everyone: WCAG Compliance and the Tools That Help appeared first on Andy White, WordPress Developer.