roots.io

Spin up a @rootswp Bedrock site in your browser 🌐 Powered by php-wasm, ghostty-web, Astro on Cloudflare Workers (Extremely alpha phase & still in a private repo. Got a decent roadmap but time is tight atm - it'll eventually support Acorn and Sage) playground.roots.io

PSA for Acorn users: skip transients, reach for Laravel Cache — roots.io/acorn/docs/laravel-… Just caught Claude Code reaching for a transient & updated Radicle's PHP style guide to be more explicit about this. Official 𝚂𝙺𝙸𝙻𝙻𝚂.𝚖𝚍 files for our major projects coming soon!

Using ACF made sense in 2019 but it doesn't mesh with modern WordPress development. I just inherited a site that heavily uses ACF and it's a complete mess. - Use 𝚠𝚘𝚛𝚍𝚙𝚛𝚎𝚜𝚜⁠/⁠𝚋𝚞𝚒𝚕𝚍 with 𝚠𝚘𝚛𝚍𝚙𝚛𝚎𝚜𝚜⁠/⁠𝚌𝚘𝚖𝚙𝚘𝚗𝚎𝚗𝚝𝚜 for modern WordPress settings (𝚋𝚞𝚒𝚕𝚍 is the successor to 𝚜𝚌𝚛𝚒𝚙𝚝𝚜, been using it all week and it's great — no more webpack) - Native blocks are more powerful with a better, modern UX. You can use dynamic server rendered blocks where it makes sense, and WordPress 7.0's PHP block registration can replace most ACF blocks - Use the Block Locking API so clients can't break the layouts you build - Use extended-cpts for CPT/taxonomy management ACF repeaters and flexible layouts aren't the way. InnerBlocks + nested native blocks do this with a better UX. Build some boilerplates using 𝚠𝚘𝚛𝚍𝚙𝚛𝚎𝚜𝚜⁠/⁠𝚌𝚘𝚖𝚙𝚘𝚗𝚎𝚗𝚝𝚜 for settings pages (ACF settings pages look out of place compared to this), native blocks, etc. and let agents use them to produce better interfaces quickly I've been doing this for years on hybrid themes and haven't looked back (not using FSE, it's not the right setup for the designs I work on) "But ACF is faster" — not anymore. Agents close the gap, and reviewing their diffs helps you see what modern WP actually looks like.

Shipped a public status page for WP Packages — every 5-minute build, package changes, and hourly closure checks are now fully transparent wp-packages.org/status

WP Packages now supports immutable dev-trunk installs for every WP plugin that doesn't have tags reflecting the latest version. Unlike WPackagist's approach (mutable zip with a cache-busting timestamp, causing unexpected plugin updates), we pin dev-trunk to a specific SVN rev.

No more crazy composer.json workaround needed anymore, just: composer require wp-plugin/example-plugin:dev-trunk Every plugin now has a example-plugin~dev.json file on the CDN

~12% of WordPress plugins are "doing it wrong" — releasing via SVN trunk without tagging versions. We now flag every one of them with workarounds for Composer users. wp-packages.org/untagged

Clarifying some things I’ve seen about WP Composer/Roots this week: – We started working on a WPackagist replacement last August, long before any recent attention – RTs/posts by dot org are unrelated to our motivations, but we do appreciate the extra visibility – Roots has been an independent open source org in the WordPress ecosystem since 2011, with one goal: improve the WP developer experience – We’ve never been an agency or owned by a hosting company, just a team and community focused on open source – I do sell one product, Radicle, to help fund that work, along with past products like screencasts and the Sage book – WP dot com has been a sponsor since 2021, and others, including Pantheon, have supported Roots over the years, with no influence on our roadmap – WP Engine hasn’t been involved with Roots, no sponsorship or collaboration to date, including support and documentation for Sage 11 – When critical ecosystem infrastructure ends up controlled by a private equity-owned company, especially when that platform still has gaps in Composer support, we think the community deserves an open alternative

FYI Composer repos can include an ‘info’ field in packages.json that displays messages to every developer on install/update. Any repo maintainer could use this to push ads, upsells, or whatever else directly into your terminal wp-composer.com will never do this

Glad WPackagist found a home, but tooling this central to the WP Composer workflow probably shouldn’t be owned by a private-equity backed company. I started building a prototype of a WordPress Composer registry (w/ mirror support) for @rootswp late last year, and I’m now more motivated for us to get it launched sooner and keep it community-owned.

roots/wp-config v2 is coming soon, a new fluent API for WordPress configuration github.com/roots/wp-config