php – composer – how to install/prioritise specific packages first before the other packages?-ThrowExceptions

Exception or error:

I’d been setting up WordPress and obtaining its required plugins via composer for some years now, it works great, but I’ve given up trying to hack or be tricky when it comes to installing plugins that does not know how to use WP_SITEURL and also PaaS that doesn’t support non-standard WordPress folder structure.

So I am wondering if I can still use composer to setup WordPress-core (or any other package) but I want it to be installed first.

Say in your composer.json, you have the following packages:

    "name": "test/composer-install-order",
    "type": "project",
    "repositories": [
    { "type": "composer", "url": "" }
    "require": {
        "php": ">=7.2",
        "composer/installers": "~1.6.0",
        "johnpbloch/wordpress": "^4.9",
        "wpackagist-plugin/better-search-replace": "*",
        "wpackagist-plugin/bugherd": "*",
        "wpackagist-plugin/disable-emojis": "*"
    "extra": {
    "installer-paths": {
        "public_html/wp-content/plugins/{$name}/": ["type:wordpress-plugin"],
        "public_html/wp-content/themes/{$name}/": ["type:wordpress-theme"]
    "wordpress-install-dir": "public_html"
    "config": {
        "preferred-install": "dist",
        "optimize-autoloader": true,
        "sort-packages": true

The composer.json above says you required 3 plugins: better-search-replace, bugherd, and disable-emojis

But when you hit composer install:

➜  temp1 composer install
Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations: 7 installs, 0 updates, 0 removals
- Installing composer/installers (v1.6.0): Loading from cache
- Installing johnpbloch/wordpress-core-installer ( Loading from cache
- Installing wpackagist-plugin/better-search-replace (1.3.2): Loading from cache
- Installing wpackagist-plugin/bugherd ( Loading from cache
- Installing johnpbloch/wordpress-core (4.9.8): Loading from cache
- Installing johnpbloch/wordpress (4.9.8): Loading from cache
- Installing wpackagist-plugin/disable-emojis (1.7.2): Loading from cache
Writing lock file
Generating optimized autoload files
➜  temp1

You’ll only get 1 plugin inside wp-content/plugins folder. The reason for this is because when you check the print above, the 2 plugins better-search-replace and bugherd where installed first BEFORE the WordPress core files johnpbloch/wordpress. So even composer extracted those 2 plugin packages to its correct folder, the johnpbloch/wordpress has removed them because it overwrote the wp-content/plugins folder.

The only way for this to work is if I install johnpbloch/wordpress first before the plugins, but I do not know if its possible since composer install via the composer.lock content.

How to solve:

Maintainer here. As suggested, OP opened an issue here:

I wanted to link to it (and copy it below) here so that if anybody happens upon this issue in the future there’s an answer that sheds some light on what’s going on. 🙂

Response copied from the github issue:

Hi The Wolf,

Thanks for asking your question. The issue at root here is a conflict
between how Composer works and the default way WordPress works.

If you want to use Composer to manage WordPress core as a dependent
package, you have to use a specific non-standard installation option
for WordPress in which core is installed in a subdirectory and the
wp-content directory is set to a location outside of the core package.
Rarst has a great microsite detailing the optimal
. You can also check out my sample
WordPress package starter
inspiration. You can read more about installing core in a

and moving

on the codex.

If you’re interested in reading a little more about the reasoning for
this issue, please see this thread in the installer

in which the topic gets a bit more lengthy treatment.

Hope that helps!


the johnpbloch/wordpress has removed them because it overwrote the wp-content/plugins folder

When packages start to behave like this, I do not know what people even expect anymore. I would recommend you submit an issue or a pull request to modify this behaviour, because it seems questionable at best, and just plain malicious if I am being honest.

Are you positive this is not a misconfiguration error on your side in regards to plugin paths or wordpress installer paths?

Leave a Reply

Your email address will not be published. Required fields are marked *