Wordpress Full Laravel Package

Getting Started

roots/wordpress-full is a Composer-installable mirror of a WordPress release, including the default wp-content (bundled themes such as Twenty Twenty-Four, Akismet, Hello Dolly). It is infrastructure, not a library: the low star count reflects that it is an auto-generated artifact used indirectly by thousands of Bedrock projects, not a lack of maintenance.

Minimal setup in an existing project:

{
  "require": {
    "composer/installers": "^2.2",
    "roots/wordpress-core-installer": "^1.0",
    "roots/wordpress-full": "^6.6"
  },
  "extra": {
    "wordpress-install-dir": "web/wp",
    "installer-paths": {
      "web/app/plugins/{$name}/": ["type:wordpress-plugin"],
      "web/app/themes/{$name}/": ["type:wordpress-theme"]
    }
  },
  "config": {
    "allow-plugins": {
      "composer/installers": true,
      "roots/wordpress-core-installer": true
    }
  }
}

Then composer install. Confirm three things immediately:

1. web/wp/wp-load.php exists (the installer moved core out of vendor/).
2. web/wp/wp-includes/version.php reports the $wp_version you expect.
3. web/wp/wp-content/themes/ contains the bundled themes — this is the difference from roots/wordpress-no-content.

First use case: replacing a committed or manually downloaded WordPress tarball with a locked, reproducible core version. Commit composer.lock, gitignore web/wp, and let deploys run composer install --no-dev --optimize-autoloader.

Implementation Patterns

Bedrock-style layout. Core lives in web/wp, but Bedrock sets WP_CONTENT_DIR to web/app, so themes and plugins are installed via installer-paths into web/app/*. That means the bundled wp-content inside web/wp is effectively inert under Bedrock — see the gotcha below when choosing between full and no-content.

Choosing the variant.

• Use roots/wordpress-full for quick starts, non-Bedrock layouts where wp-content is the real content dir, or when you want default themes available without installing them yourself.
• Use roots/wordpress-no-content when every theme and plugin is Composer-managed. Smaller installs, fewer irrelevant files in web/wp, cleaner wp core verify-checksums output.

Update workflow. Treat core as a dependency:

composer outdated roots/wordpress-full
composer update roots/wordpress-full --with-dependencies
wp --path=web/wp core version

Pair this with Renovate or Dependabot, grouping roots/wordpress-* into a single PR, and run a smoke test (boot the site, hit /wp-admin/, run your test suite) before merging. Core patch releases are frequent; automating the PR saves real time.

WP-CLI. Run it from the project root with an explicit path: wp --path=web/wp plugin list, wp --path=web/wp core version. Never use wp core download or wp core update — Composer owns that directory.

CI smoke test. A cheap guard against bad installs:

composer install --no-dev --prefer-dist
php -r "require 'web/wp/wp-load.php'; echo \$wp_version;"
wp --path=web/wp core verify-checksums

Environment parity. Keep composer.lock in VCS and run composer install (not update) in staging and production. Use composer install --dry-run -vvv on a deploy box if paths look wrong.

Gotchas and Tips

• wordpress-install-dir is required. Without it, core lands in vendor/roots/wordpress-full and your web server 404s. The installer plugin reads extra.wordpress-install-dir from the root composer.json only.

• Composer 2.2+ allow-plugins. If composer/installers or the core installer is not allowed, Composer silently skips the install step and you get an empty web/wp. Run composer install -vvv to see the installer messages.

• full's wp-content is dead weight under Bedrock. With WP_CONTENT_DIR pointed at web/app, the bundled themes are never seen by WordPress. If you expected Twenty Twenty-Four to appear in wp theme list, install it via WPackagist into web/app/themes instead.

• Anything you add under web/wp disappears. composer update/install replaces the core directory. Never hand-edit wp-config.php, drop a plugin into web/wp/wp-content/plugins, or patch a core file there. Use web/app, or a patches plugin, and accept the fragility.

• Disable WordPress's own updater. Otherwise wp core update or background auto-updates will fight Composer and be reverted on the next deploy. In wp-config.php:

  define('AUTOMATIC_UPDATER_DISABLED', true);
  define('WP_AUTO_UPDATE_CORE', false);
  define('DISALLOW_FILE_MODS', true);
  

• Package rename history. Bedrock previously required roots/wordpress; current scaffolds use roots/wordpress-full (or -no-content). If you're following an older tutorial, the constraint and package name may not match what's in your lockfile. composer why roots/wordpress-full clarifies what pulled it in.

• Version constraints. Versions track WordPress exactly (6.6.1, 6.6.2). ^6.6 allows any 6.x, which is usually what you want for security patches; use 6.6.* if you want to stay on a minor line, and avoid bare * in production.

• Update lag. The mirror is republished automatically, but there is a window (minutes to hours) after an upstream WordPress security release before the Composer package exists. Don't assume composer update on release day has the fix; check the package's release page.

• wp core verify-checksums verifies core files only; bundled wp-content is not part of the checksum API, so discrepancies there are expected and harmless.

• Debugging installs. composer diagnose, composer install -vvv, and inspecting vendor/composer/installed.json for the resolved version are the fastest paths when the install looks wrong.

• Extension points. The only supported knobs are extra.wordpress-install-dir, installer-paths, version constraints, and allow-plugins. For a patched core, a path repository pointing at a fork works but puts you off the auto-update path — a real trade-off, not a casual choice.