johnpbloch / wordpress-core

Other
169 stars 40 forks source link

option to disable wordpress-core to overwrite/remove existing files? #14

Closed arvilmena closed 5 years ago

arvilmena commented 5 years ago

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

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

{
    "name": "test/composer-install-order",
    "type": "project",
    "repositories": [
    { "type": "composer", "url": "https://wpackagist.org" }
    ],
    "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 (1.0.0.2): Loading from cache
- Installing wpackagist-plugin/better-search-replace (1.3.2): Loading from cache
- Installing wpackagist-plugin/bugherd (1.0.0.0): 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.

Hopefully there's an option to disable wordpress-core to overwrite/remove existing files?

P.S. I only opened this issue as it was recommended in StackOverflow

Regards,

johnpbloch commented 5 years ago

Hi @arvilmena,

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 setup. You can also check out my sample WordPress package starter package for inspiration. You can read more about installing core in a subdirectory and moving wp-content 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 repository in which the topic gets a bit more lengthy treatment.

Hope that helps!

johnpbloch commented 5 years ago

@arvilmena it just occurred to me that your question was slightly different than I had understood. You're familiar with the "standard" way to run a wp/composer stack, but you wanted to know if there's a way to use composer to manage dependencies inside a normal wp stack.

Short answer: no, not with this package.

Long answer: Basically, that install structure is not supported by Composer itself. Now, it's possible you might be able to write a plugin package that hooks into pre-install/update/delete events and uses wp cli to download, update, and install/update wordpress core into the correct directory while allowing a dummy package to get installed into vendor. Before I made this package I was playing around with a Composer plugin that dynamically added package definitions for WordPress core into an in-memory repository for Composer to use, but that proved to be too brittle at the time. You may be able to get it to work now. I'm not sure. But that's not something I'm interested in doing with this package.

johnpbloch commented 5 years ago

https://github.com/johnpbloch/wordpress-core-shim This is the plugin package I'd built. Like it says in the readme, I only ever got it working using global installation, and it was pretty brittle. Hopefully it can provide some inspiration if you decide to make a composer plugin to make standard stacks work correctly. I think it's a pretty exciting idea! 😄

dd-asghar commented 1 year ago

For git managed custom folders, a workaround is adding post install script that undo the deletion.

In composer.json

    "scripts": {
        "post-install-cmd": [ "chmod +x ./reset-deletion.sh && ./reset-deletion.sh" ]
    }

In reset-deletion.sh

#!/bin/bash

git checkout public/wp-content/