A lot of people use WP CLI to script the setup using Bash scripting. Here are some articles that discuss this. Another approach is to hardcode PHP scripts with embedded SQL to do the setup. A third approach is something I have been working on recently; a set of PHP objects to make setup and … Read more
That would be a task for oomphinc/composer-installers-extender. With that you can specify the directory where a package should be installed to. And it’s case-sensitive. Composer otherwise is case-insensitive. { “extra”: { “installer-paths”: { “my/themes/Divi/”: [“satispress/divi”], } } }
The current WP versions expose interface for this and store locale in WPLANG option. Depending on your tools you could set it up during your spin up process (for example with WP CLI). Older version used WPLANG constant in wp-config.php. I think it should still work on a fresh install (if you don’t have option … Read more
Without more context from you, I can only assume and show you what I have done that works for me using PSR4 Autoloading. Example: Assuming that all my custom class directories and files is in ./inc folder In your composer.json, add this “autoload”: { “psr-4”: { “Inc\\”: “./inc” } } Inc is the vendor name … Read more
Basically in “common” WordPress setup you have two things inside the folder that aren’t part of the core itself: content folder and wp-config.php configuration file. So you are on completely right path: You configure content folder to be elsewhere, outside of core folder You place wp-config.php one directory level above the core folder (WP will … Read more
You are overthinking this. The namespace structure applies at the level of individual package. There is no need or push to treat the whole site as such package. Also one of the benefits of using autoload in first place is that it makes location of classes in file system largely irrelevant. So the simple and … Read more
There are still very few WP plugins/themes that are being developed Composer-first. You can take a look at Laps case study (one of mine) for practical example. Essentially if you plan for plugin to be publicly distributed you need to take care of both cases – running it as part of whole-site Composer stack and … Read more
So there are one or two things to keep in mind: There should only be 1 vendor folder There should be a primary composer.json that’s in your project root, that would pull in all the dependencies You always check for and load the autoloader in the current directory, there’s no guarantee it is or isn’t … Read more
TL;DR If you want to support Composer, adding a composer.json is better then just let WPackagist create a package for you. There are several reasons, no one is really important, but considering that to create a composer.json does not require much effort, it probably worth it. composer.json Benefits Below a non-exhaustive list of benefits of … Read more
The answer is — you can’t because WordPress can’t. There is no dependency management concept in WP and it was the same case before Composer had even existed. The rise of autoload (Composer or otherwise) slightly helps with it, since you might just be getting different copy loaded (hopefully close enough) rather than outright fatal … Read more