Wordpress No Content Laravel Package

Getting Started

roots/wordpress-no-content is a Composer-installable WordPress core, repackaged by Roots for the Bedrock stack. It removes the wp-content directory from the tarball so your project's web/app (or wherever you configure WP_CONTENT_DIR) stays the single source of truth for themes, plugins, and uploads. Every upstream WordPress release is auto-published as a tagged version, so composer update becomes your core upgrade path.

Install it as a dependency rather than cloning WordPress:

composer require roots/wordpress-no-content

You almost never install this by hand — it's pulled in transitively when you scaffold a Bedrock project with composer create-project roots/bedrock. If you're migrating an existing site, add the package and set WP_ENV, WP_HOME, and WP_SITEURL in .env before pointing your web server at web/.

Where to look first:

1. composer.json in your Bedrock root — confirm the roots/wordpress-no-content constraint and the wordpress-install-dir extra (web/wp by default).
2. config/application.php — this is where Bedrock wires WP_CONTENT_DIR to web/app and sets WP_CONTENT_URL.
3. vendor/roots/wordpress-no-content/ — the extracted core. You should not edit anything here; treat it as read-only vendor code.

Your first use case: bump a minor WordPress version. Run composer update roots/wordpress-no-content, deploy, and verify the wp-includes/version.php $wp_version on the server matches what Composer resolved. That's the whole loop.

Implementation Patterns

Pin a major/minor line, not a patch. Use constraints like ^6.6 or ~6.6.0 rather than exact pins. The package publishes a tag for every upstream release including security patches; you want those flowing in automatically and only want to review breaking bumps manually.

Deploy via composer install --no-dev --optimize-autoloader in CI, not composer update. Because core lives under vendor/, your typical build pipeline (Composer install → asset build → rsync or container build) already covers WordPress upgrades. Nothing WordPress-specific is needed in the deploy script — that's the main ergonomic win over managing core separately.

Keep Bedrock's directory contract. The package is designed for web/wp (core) plus web/app (content). Don't fight it by setting WP_CONTENT_DIR to something off-pattern unless you have a real reason; Bedrock's config/application.php and the roots/bedrock-config loader assume the standard layout, and plugins like WP-CLI and your mu-plugins loader resolve paths relative to it.

Compose with a version-alignment check. A cheap and effective CI pattern is a test that asserts get_bloginfo('version') (or $wp_version from web/wp/wp-includes/version.php) equals the version Composer resolved. This catches the surprisingly common failure where the deploy didn't actually update vendor/ or an old web/wp was rsynced over a new one.

Use it with roots/bedrock-autoloader or a mu-plugin loader. Since wp-content/plugins isn't shipped, plugin discovery falls to whatever loader you use. With Bedrock's autoloader, any plugin Composer installed into web/app/plugins gets activated without a DB write — pair that with this package for a fully Composer-managed core + plugins.

Local dev via wp server or DDEV/Lando/Trellis. WP-CLI respects ABSPATH from web/wp if you set it in wp-cli.yml:

path: web/wp

That single config line makes wp core version, wp plugin list, and wp db export just work against the no-content layout.

Gotchas and Tips

No wp-content means no default themes or plugins. Fresh installs will show "no themes found" until you composer require a theme (e.g. roots/sage). Same for Akismet/Hello Dolly — they're deliberately absent. Budget for this in onboarding docs; it surprises people coming from wordpress.org tarballs.

wp core update will fight you. Never run wp core update on a site using this package — it writes into web/wp underneath Composer's management and will either fail on permissions or leave the tree in a state Composer can't reconcile. Upgrades go through composer update. If someone did run it, composer install should restore integrity by overwriting, but check for stray files.

Version pinning and the auto-update cadence. The package tracks upstream releases with a short lag. If WordPress ships a critical security fix and you need it now, you can temporarily point at roots/wordpress or johnpbloch/wordpress-core at the exact tag, but the cleaner move is to wait hours, not days. Subscribe to the WordPress security mailing list so you know when to bump.

The wordpress-install-dir extra is authoritative. Bedrock's installer plugin reads extra.wordpress-install-dir from the root composer.json. If your web server docroot doesn't match (say nginx points at web/ but WP_SITEURL says /wp), you'll see 404s on /wp-admin even though files exist. Verify wp core is-installed and wp option get siteurl agree with your .env.

Symlinked deployments need care. If you deploy via symlink-swap (Capistrano/Trellis style), vendor/ changes per release, so anything caching absolute paths into web/wp (opcache with opcache.validate_timestamps=0, some object caches keyed on file paths) needs to be invalidated on deploy. Standard Bedrock/Trellis handles this, but custom setups often don't.

Debugging "white screen after upgrade". Since core is vendor code, a fatal in core looks identical to a fatal in a plugin. First step: wp --info to confirm WP-CLI can bootstrap, then check web/wp/wp-includes/version.php against composer show roots/wordpress-no-content. Mismatch means a deploy artifact problem, not a code problem.

Extension points are limited by design. This is a repackaging package, not a framework — there's no plugin/hook surface, no config file. If you need to customize core behavior, do it via wp-config.php, mu-plugins, or filters in config/application.php. Don't expect to patch the package; fork it only if you need a genuinely different directory layout, and be aware you'd own the auto-update pipeline.