Wordpress reinstalls on every `composer require`

[pxlrbt]

When I add new packages to my composer file via composer require my wordpress is re-installed every time. Is this behaviour intended?

composer.json (Part)

"require": {
    "ffraenz/private-composer-installer": "^2.0",
    "johnpbloch/wordpress": "~5.0.3",
    [...]
  },
  "config"      : {
    "vendor-dir": "wp-content/vendor"
  },
  "extra"       : {
    "wordpress-install-dir": "wp-tmp"
  },

[johnpbloch]

Hi @pxlrbt, thanks for your question. I'm not sure what you're referring to when you say

wordpress is re-installed every time

Could you please clarify? What is the expected behavior, and what is the actual behavior you're seeing? Also, it might help if I had a bit more of your composer.json file (specifically the extra section).

Thanks!

[pxlrbt]

@johnpbloch Thanks for the fast response and your help.

Here's my composer.json

What I did:

• I installed wordpress with composer
• I added plugins with composer via wpackagist
• Whenever I add a plugin via composer require wpackagist-plugin/plugin-name WordPress installer is running and copying the same version of WordPress to my WordPress install dir.

I expect the installer only to download the files if I upgrade to a new WordPress version. Maybe this is caused by the fact, that I download the files to a tmp dir and copy them manually into my WordPress folder? I thought the WordPress installer would use the .lock file for this.

Example:

$ composer require wpackagist-plugin/contact-form-7
Using version ^5.1 for wpackagist-plugin/contact-form-7
./composer.json has been updated
Loading composer repositories with package information
Updating dependencies (including require-dev)
Package operations: 2 installs, 0 updates, 0 removals
  - Installing wpackagist-plugin/contact-form-7 (5.1.1): Downloading (100%)
  - Installing johnpbloch/wordpress-core (5.0.3): Loading from cache
Writing lock file
Generating autoload files
> rm -rf wp-tmp/wp-content/plugins/*
> rm -rf wp-tmp/wp-content/themes/*
> rm wp-tmp/composer.json
> cp -r wp-tmp/* ./ && rm -rf wp-tmp
> cp custom-index.php index.php
> curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar && mv wp-cli.phar wp
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 5294k  100 5294k    0     0  1755k      0  0:00:03  0:00:03 --:--:-- 1755k
> ln -s wp-content/themes/custom theme

I expect this to be 1 install as WordPress 5.0.3 is already installed.

[johnpbloch]

Ah, I see the issue now. The post-install and post-update scripts are removing the package from its installed location, so yes, this is the behavior I would expect given the composer.json you're using. Composer is looking for WordPress in wp-tmp and doesn't find it there. When it finds a package missing, it installs it.

I wonder if you could achieve the desired effect by changing the scripts to do the following instead:

  "scripts": {
    "setup-wordpress": [
      "[ -d wp-tmp/wp-content ] && rm -rf wp-tmp/wp-content/",
      "mv wp-tmp/composer.json wp-tmp/composer.json-wp",
      "cp -r wp-tmp/* ./ && rm -rf wp-tmp/*",
      "mv composer.json-wp wp-tmp/composer.json",
      "cp custom-index.php index.php"
    ],
    "post-update-cmd": [
      "@setup-wordpress",
      "curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar && mv wp-cli.phar wp",
      "ln -s wp-content/themes/custom theme"
    ],
    "post-install-cmd": [
      "@setup-wordpress"
    ]
  },

I haven't tested this at all, so I don't know how it will perform, but I think composer just checks for the composer.json file. So in theory, renaming composer.json and copying it with all other files, then putting it back in place should work.

I also moved the script commands that operate on WP core into their own script and then referenced it from post-install/post-update so there's only one set of commands to have to update, had it check for the existence of wp-content, then delete the folder altogether. Hopefully you can use some of that regardless of whether this prevents WP from installing every time.

[johnpbloch]

Also, regarding the .lock file, that only records the results of dependency resolution, not what's installed. It's a way for composer to skip dependency resolution (which is time consuming) for a known set of dependencies. If you're interested in more detail on this topic, here's a good article breaking down the lock file and its purpose.

[pxlrbt]

Never thought about this being an composer issue since removing packages from the vendor path normally isn't a thing. Your scripts work like a charm. Thank you very much and sorry for bothering with issues unrelated to your great installer.

[johnpbloch]

No bother at all!