Welcome to the grand finale of our AI Content Writing 2.0 series. This is where we separate the hobbyists from the elite. In Part 1 , we mastered the art of the

Automate WordPress admin tasks with Automator 7.3: schedule plugin updates, automate site health reports, and hand off the day-to-day of site maintenance to AI.

Live in the Gutenberg plugin since version 22.7, the proposed knowledge layer gives every site a permission-controlled, non-public store for voice and tone standards, per-block guidelines, and author-...

Airtable has two different token strings. Most people copy the wrong one.

LocalWP simplifies WordPress development by creating local sites in minutes. It includes built-in tools, flexible environments, and an easier workflow for developers and designers.

Developers favor builders for undisclosed affiliate revenue. Block themes now match builder design systems through theme.json version 3 and core extensions.

Static generators and vibe-coded websites do not satisfy the security, accessibility, and maintainability obligations that professional client work demands.

Ditch JS, React, and complex build steps. Master Gutenberg blocks with pure PHP and deploy custom blocks to WordPress in minutes.

WordPress Core is built by thousands of contributors working together on an open-source platform. With that scale comes complexity: at any given time, there are thousands of tickets in WordPress Trac reporting bugs, requesting features, and proposing enhancements. Triage—the process of reviewing, organizing, and prioritizing these tickets—helps contributors focus on the work that matters most. […]

Find out about the new Studio CLI in WordPress Studio 1.7.0 for managing local sites more efficiently.

## **Customizable Navigation Overlays** are a new feature for WordPress 7.0 that gives you full control over “mobile” navigation menus using blocks and patterns. We’re inviting the WordPress community to test this feature and share feedback. **We’d love to hear from you by February 9, 2026** to allow time for refinements before the feature freeze. ## Why This Change? Mobile navigation overlays have been a significant pain pointPain point Pain points are “places where you know from research or analytics that users are currently getting hung up and have to ask questions, or are likely to abandon the site or app.” — Design for Real Life for WordPress users. Users have had very **little control** over the design and content of their mobile navigation menus. When someone taps a hamburger menu on mobile, they’ve been stuck with WordPress’s default overlay – no ability to customize branding, add promotional content, adjust styling, or control the layout. This creates real problems: * Sites can’t maintain brand consistency on mobile * No way to add calls-to-action or promotional content in the mobile menu * Mobile navigation feels disconnected from the rest of the site design * Users resort to complex workarounds or custom code **Custom Navigation Overlays** addresses this by giving users full control over their mobile overlay menus using the familiar blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. editor. ## What’s New? Navigation Overlays enable users to: * **Create custom mobile overlay menus** using blocks and patterns * **Control overlay design, content, and behavior** – add branding, images, calls-to-action, and more * **Manage multiple overlay variations** – create different overlays for different contexts Custom overlays are saved as template parts, which means they’re reusable components you can manage alongside your other theme templates. As such Themes can also provide their own Overlays suited to their particular design and use case. This feature is targeting **WordPress 7.0** and represents the first iteration of customizable navigation overlays. We’re shipping a solid v1 foundation that solves the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. user need, with plans to expand capabilities in future releases based on community feedback. ## We’d Love Your Feedback We’re inviting the WordPress community to test this feature before it ships in 7.0. Your feedback will help us: * Catch bugs and edge cases * Validate the user experience is intuitive * Ensure compatibility across themes and use cases * Identify what works well and what needs refinement **Timeline:** We’d appreciate feedback by **February 9, 2026** (this gives us time to address issues before the February 19 feature freeze) ## How to Test ### Testing Environment **Quick Start with Playground:** 1. Open this Playground instance. 2. Confirm the **“Customizable Navigation Overlays”** experiment is enabled. 3. You’re ready to test in the Site Editor. **What you’ll need:** * Latest Chrome, Firefox, or Safari browser * A Navigation block inserted to access overlay controls ## What to Test We’ve outlined three testing scenarios below. **You don’t need to test everything** – pick what interests you or matches your use case. * * * ### Scenario 1: Create Your First Custom Overlay **Try this if you:** Want to experience the feature as a first-time user **Steps:** 1. Insert a Navigation block on a page or in a template 2. Look for the overlay customization controls in the block settings 3. Create your first custom overlay 4. Preview it in the editor 5. View it on the frontend in mobile view **What we’d love feedback on:** * How easy was it to discover the overlay controls? * Was the creation process clear and intuitive? * Does the overlay look correct on mobile? * * * ### Scenario 2: Build a Custom Overlay from Scratch **Try this if you:** Want to design a custom overlay with your own blocks and styling **Steps:** 1. Create a new overlay starting with blocks (not a pattern) 2. Add various content: headings, images, buttons, navigation links, etc. 3. Style your overlay: colors, spacing, typography 4. Test submenu behavior 5. View on frontend mobile **Bonus:** Try creating multiple overlay variations and switching between them. **What we’d love feedback on:** * Can you build the overlay design you want? * Are the design controls sufficient? * Does switching between overlays work smoothly? * * * ### Scenario 3: Test Edge Cases **Try this if you:** Want to help us find bugs and boundary conditions **Ideas to test:** * Try creating an overlay without a close button – what happens? * Test with different WordPress themes * Delete a custom overlay and see how Navigation blocks handle it * Add multiple close buttons to one overlay * Test with complex block combinations **What we’d love feedback on:** * Does anything break or behave unexpectedly? * Are error messages (if any) helpful? * How does the feature handle edge cases? * * * ### Testing Tip: Try Both Editor and Frontend For any scenario you test, it’s helpful to check both: 1. ✅ **Editor experience** – Does it work while editing? 2. ✅ **Frontend experience** – Does it work on the live site (especially mobile)? You can use browser DevTools device emulation or resize your browser to mobile width to test. * * * ## SEO and AccessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) Feedback Wanted We’re actively discussing the technical implementation of overlay markup and **would especially value input from SEO and accessibility experts**. **The question:** Where should the overlay markup be placed in the HTMLHTML HTML is an acronym for Hyper Text Markup Language. It is a markup language that is used in the development of web pages and websites.? Current options under consideration: * **Within the Navigation block’s`<nav>` element** * **Outside the`<nav>` element** (as a sibling) * **At the top of the page’s HTML markup** * **At the bottom of the page’s HTML markup** Each approach has potential implications for: * **SEO** : How search engines crawl and index content * **Accessibility** : Screen reader behavior, navigation landmarks, focus management * **Performance** : Initial page load and rendering If you have expertise in SEO or accessibility, we’d appreciate your perspective on which approach would best serve users. Feel free to share relevant standards, best practices, or real-world considerations that should inform this decision. **Relevant discussion:** https://github.com/WordPress/gutenberg/issues/74583 * * * ## How to Share Feedback **Comment on this post** with your findings, or create GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ issues in the WordPress/gutenberg repository and link to them in your comment. **Helpful to include:** * Browser and device/theme used * Screenshots or recordings (visual evidence is super helpful!) * Clear steps to reproduce any issues * Your assessment of severity (if reporting a bug) **Example:** Browser: Chrome 131, macOS Theme: Twenty Twenty-Five Issue: Overlay close button not visible on dark backgrounds Steps to reproduce: 1. Create overlay with dark background 2. Add default close button 3. View on frontend mobile Expected: Close button should be visible Actual: White close button disappears against dark background Severity: Medium - workaround is to add custom close button [Screenshot] ## Known Limitations (v1) This is the **first iteration** of Navigation Overlays for WordPress 7.0. Some capabilities are intentionally out of scope for this release and will be considered for future versions: * Mega menus * Dialog-block reuse for overlays * Inline editing overlays directly in main canvas (currently must edit via template part editor) * Custom mobile breakpoints See the complete scope: https://github.com/WordPress/gutenberg/issues/73084 We’re focused on shipping a solid foundation that solves the core user need. Future releases will expand capabilities based on community feedback and real-world usage. ## Resources * Demo Video: Navigation Overlays Walkthrough * WordPress 7.0 Roadmap * GitHub Tracking Issue #73084 * * * **Thank you for testing! 🙏** Your feedback will help ensure Navigation Overlays provide a great experience for WordPress users managing mobile navigation. This is a v1 release, and your input will shape future iterations of the feature. #call-for-testing #wordpress-7-0 #navigation +make.wordpress.org/core/ ### Share this: * Click to share on Threads (Opens in new window) Threads * Click to share on Mastodon (Opens in new window) Mastodon * Click to share on Bluesky (Opens in new window) Bluesky * Click to share on X (Opens in new window) X * Click to share on Facebook (Opens in new window) Facebook * Click to share on LinkedIn (Opens in new window) LinkedIn * Click to share on Pocket (Opens in new window) Pocket * * Login to Reply ### Like this: Like Loading...

Learn how to transform your WordPress 404 error page from a bounce-heavy dead-end into a helpful resource by automatically parsing URLs to display relevant content.

Support for PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher 7.2 and 7.3 will be dropped in WordPress 7.0, currently scheduled for release in April 2026. The _minimum recommended version_ of PHP will remain at 8.3, but the new _minimum supported version_ of PHP will be 7.4.0. The minimum supported version of PHP was last raised in July 2024 to 7.2.24. Since then usage of PHP 7.2 and 7.3 has dropped below 4% of monitored WordPress installations. Historically, the project has used 5% as the baseline usage percentage that a PHP version must fall below before it can be considered for a well-earned retirement. Now that usage of PHP 7.2 and 7.3 combined has fallen well below that, the process to increase the minimum supported PHP version can proceed. The goal of increasing the minimum supported version of PHP is to ensure the long-term maintainability of WordPress. The benefits to increasing the minimum supported PHP version manifest over time across multiple areas, including the pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party and theme ecosystem, tooling and libraries for AI, the long-term perception of the WordPress project, developer relations, and eventually within the WordPress codebase itself, including its developer tooling and automated testing infrastructure. Discussion around this minimum version bump can be found here on the Trac ticket. ## What about PHP 8 and higher? WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. is fully compatible with PHP 8.0 to 8.3 and is beta compatible with PHP 8.4 and 8.5. A full breakdown of which PHP versions are compatible with each version of WordPress can be found in the WordPress Core Handbook.. ## What about security support? Sites that are running PHP 7.2 or 7.3 will remain on the 6.9 branchbranch A directory in Subversion. WordPress uses branches to store the latest development code for each major release (3.9, 4.0, etc.). Branches are then updated with code for any minor releases of that branch. Sometimes, a major version of WordPress and its minor versions are collectively referred to as a "branch", such as "the 4.0 branch". of WordPress once 7.0 is released. While only one branch officially receives security updates, fixes are backported down to WordPress 4.7 as a courtesy when possible. ## What about the GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ plugin? The minimum supported version of PHP will also be increased to 7.4 in the Gutenberg plugin. ## Going forward There are no plans to bump the minimum supported PHP version on a set schedule. The Core team will continue to monitor PHP version usage and work with the Hosting team to encourage users and hosting companies to upgrade their versions of PHP as swiftly as possible. The 5% usage threshold will continue to be used as the standard for the foreseeable future. At the time of publishing, the PHP version usage is as follows: * 8.5: 0.23% * 8.4: 4.90% * 8.3: 16.74% * 8.2: 27.29% * 8.1: 15.39% * 8.0: 5.69% * 7.4: 22.20% * 7.3: 2.04% * 7.2: 1.81% ## Update PHP today If you need more information about PHP or how to update it, check out this support article that explains more, guides you through the process, and provides instructions for contacting your web hosting provider for assistance. _Props to all those that have contributed to this discussion recently. Thanks to @desrosj, @westonruter, and @jorbin for feedback and proof-reading this post_. #7-0, #dev-notes, #php ### Share this: * Click to share on Threads (Opens in new window) Threads * Click to share on Mastodon (Opens in new window) Mastodon * Click to share on Bluesky (Opens in new window) Bluesky * Click to share on X (Opens in new window) X * Click to share on Facebook (Opens in new window) Facebook * Click to share on LinkedIn (Opens in new window) LinkedIn * * Login to Reply

The `github-proxy.com` was created previously to Blueprints, load branches, pull requests, and commits on GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ without CORS issues and add a dynamic packaging functionality. This service is hosted and maintained by a community contributor, Christoph Khouri, and **he will end this service at the beginning of 2026** (but your Blueprints are safe). **The good news:** The Playground team has introduced an automatic migrationMigration Moving the code, database and media files for a website site from one server to another. Most typically done when changing hosting companies. layer in WordPress Playground. If your Blueprints currently rely on github-proxy.com, they will continue to work automatically. ## What is changing? When Playground encounters a `github-proxy.com` URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org in a Blueprint, it will now automatically rewrite it to use native Playground resources like `git:directory`. Your Blueprints will continue to work, but you’ll see a console warning to update them. Update your Blueprints to use native resources for future compatibility and to remove these warnings. ## How to migrate The automatic migration handles several patterns: **github-proxy.com pattern**| **Migrates to** ---|--- `?repo=owner/name`| `zip` wrapping `git:directory` at HEAD `?repo=...&branch=trunk`| `zip` wrapping `git:directory` with branch ref `?repo=...&pr=123`| `zip` wrapping `git:directory` with `refs/pull/123/head` `?repo=...&commit=abc`| `zip` wrapping `git:directory` with commit ref `?repo=...&release=v1.0`| `zip` wrapping `git:directory` with tag ref `?repo=...&directory=subdir`| `zip` wrapping `git:directory` with path `?repo=...&release=v1.0&asset=file.zip`| `url` to GitHub releases download `?repo=...&release=latest&asset=file.zip`| `url` to GitHub `/releases/latest/download/` `https://github-proxy.com/https://...`| `url` with the inner GitHub URL Here is how you can update your Blueprints to match the native implementation: ### 1. Repositories, Branches, and Pull Requests The old proxy returned a ZIP file of a repository. You can now achieve this natively using the `git:directory` resource. **Old:** { "resource": "url", "url": "https://github-proxy.com/proxy/?repo=user/repo&branch=main" } **New:** Use the `git:directory` resource directly in your steps (like `installPlugin` or `installTheme`). { "step": "installPlugin", "pluginData": { "resource": "git:directory", "url": "https://github.com/my-user/my-repo", "ref": "main" } } You can target specific commits or pull requests using the `ref` property: * **Pull request:** `"ref": "refs/pull/123/head"` * **Commit:** `"ref": "abcdef123456..."` ### 2. Release Assets If you were using the proxy to fetch a specific asset (like a pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party zip) from a GitHub release, you can now use the resource `zip` with an `inner` object. **Old:** { "resource": "url", "url": "https://github-proxy.com/proxy/?repo=user/repo&release=v1.0&asset=plugin.zip" } **New:** { "resource": "zip", "inner": { "resource": "git:directory", "url": "https://github.com/owner/repo", "ref": "main" } } ## Why is this better? The proxy was vital in Playground’s early days. Recent infrastructure improvements, Playground’s built-in **CORS proxy,** and **Git Git Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency. Git is easy to learn and has a tiny footprint with lightning fast performance. Most modern plugin and theme development is being done with this version control system. https://git-scm.com/. over HTTPHTTP HTTP is an acronym for Hyper Text Transfer Protocol. HTTP is the underlying protocol used by the World Wide Web and this protocol defines how messages are formatted and transmitted, and what actions Web servers and browsers should take in response to various commands.** support now enable native GitHub repository access. This removes the dependency on third-party services and improves stability. A huge thank you to Christoph for keeping this service running and stable over the past years. It played a massive role in making Playground useful early on. Please check your Blueprints today. If you have any questions, please get in touch with the Playground Team via the #playground SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. channel. ### Share this: * Click to share on Threads (Opens in new window) Threads * Click to share on Mastodon (Opens in new window) Mastodon * Click to share on Bluesky (Opens in new window) Bluesky * Click to share on Facebook (Opens in new window) Facebook * Click to share on X (Opens in new window) X * Click to share on LinkedIn (Opens in new window) LinkedIn * * Login to Reply ### Like this: Like Loading...