Closed dzuelke closed 7 years ago
The second case could generally be avoided if johnpbloch/wordpress
were to "provide": "wordpress/wordpress"
, and all themes and plugins, even on wpackagist.org, were to require wordpress/wordpress
, but that's a completely different topic, and the first problem always remains, as Composer is simply not aware of such subdir trickery :)
Composer packages are not meant to be ever nested inside one another. That's just trouble trouble trouble.
That's correct, but WordPress does use this structure by default, so... ¯\_(ツ)_/¯
I am of opinion that WordPress defaults of such kind shouldn't be dragged into a Composer stack. WordPress can work with extension directories separated, it's not a roadblock.
Hi @dzuelke. First of all, thanks for taking the time to send code over. I appreciate the time and effort you've taken to improve this package.
This isn't a feature that I'm interested in introducing into the installer. @Rarst hit the nail on the head that some WordPress defaults simply don't make sense in a Composer-managed stack. For example, the default WordPress way of installing, updating, and deleting plugins and themes (and core itself) doesn't make sense in a composer stack. I don't think it's unreasonable to make a blanket decision to not support the WordPress defaults that don't make sense in a Composer stack.
I'm not going to close this quite yet. I'm interested in hearing your counter-argument, if any.
I believe do have counter-arguments ;)
wp-content
by changing WP_CONTENT_DIR
, then the johnpbloch/wordpress
package no longer works out of the box, because the themes that are bundled are not there;wp-content/…
is still web accessible - right now, you can just point the document root to wordpress/
, and it all works immediately.Of course WordPress gets managed differently once Composer is thrown into the mix. That's what WP-CLI and friends are for :)
My goal is to build as minimalist and standard a Twelve-Factor WordPress setup as possible (I am aware of Bedrock of course), in particular with the ability to both bundle themes and plugins from the same local project (using a Composer path
repo), or from an external repo, without having at least two levels of nesting with web/app/…
and web/wp/…
(like Bedrock does).
Right now, that working minimal setup consists of only a .gitignore
, a composer.json
, a wp-cli.yml
and a wp-config.php
.
As a result, it's relatively easy to explain to somebody with a pure WordPress background - all you essentially have to convey is that Composer installs dependencies, WordPress lives in wordpress/
, and the root folder wp-config.php
gets picked up automatically. Which is nice, if you want to get people to learn about Composer, Twelve-Factor, how convenient Docker/PaaSes can be, etc :)
if you move wp-content by changing WP_CONTENT_DIR, then the johnpbloch/wordpress package no longer works out of the box, because the themes that are bundled are not there;
You can register core–bundled themes as additional theme directory and they will work even if content directory is elsewhere.
you then have the additional challenge of having to set up more complicated web server configs or rewrites
You don't?.. wordpress
and wp-content
folders in web root, no rewrite involved or needed.
Regarding the default themes, you have two options: you could always ship an mu-plugin to register the default themes directory, or (probably even better) since you're shipping a composer manifest anyway, you could always just add the twenty*
themes there and then they'll install into the correct default location anyway, especially since twenty sixteen doesn't even ship with the core package.
Regarding rewrites, they're not required unless you want to omit the wp subdirectory from URLs for admin/includes resources, but that's entirely optional. Just create an entrypoint index.php
script to route traffic to WP. It does require the extra step of running the WP installation in the subdirectory and then changing the 'home'
option to omit the subdirectory, but all of this could be scripted with WP CLI (maybe included as a dependency and using composer scripts?) and/or through wp-config constants.
I'm Closing the pull request. This isn't a workflow that this package will support. Thanks again for your contribution and for the time you put into improving the project.
This allows an
installer-paths
entry for WordPress themes or plugins to be a subdirectory ofwordpress-install-dir
, which is nice, because it means no messing withWP_CONTENT_DIR
andWP_CONTENT_URL
is necessary:Without this change, running
composer update
to get a new version ofjohnpbloch/wordpress
updates only that package, a process which wipes the wholewordpress/
directory, and, with that, the `wp-content/themes/' and 'wp-content/plugins/' directories that contain dependencies installed using Composer, so an additional 'composer install' is necessary to bring them back:Furthermore, it may happen that a plugin or theme is "alphabetically smaller" than "johnpbloch/wordpress", in which case a
composer install
from the lock file would result in such a package getting installed first, and then get overwritten because thewordpress/
folder gets replaced entirely:The event handler fixes both cases, and supports all three
composer/installers
mapping types forinstaller-paths
(literal package names,type:
prefix, andvendor:
prefix).