This PR augments #4, with the goal to provide an even more flexible environment.
It decouples the Lando setup from the WordPress core instance used, allowing to develop on different core instances and easily exchange them. This has the following benefits:
Core can be contributed to via SVN (canonical source) and Git (what many people prefer). This PR sets up directories trunk-git and trunk-svn. By default the setup runs from trunk-git/build, but it can be switched to run from trunk-svn/build simply by adjusting an environment variable.
The environment variable can also be used to run from the respective src folder (which is now possible again for the most part).
Switching the core instance to run from can also help if you want to have different branches available on your system at the same time while not relying on Git/SVN branches.
You can of course also run from a regularly packaged WordPress version.
The benefits that the original PR #4 introduces remain in place. Plugins and themes can be developed in a separate content directory.
Further notes on the changes:
All directories mentioned above are relative to a public directory, which is the webroot. This ensures we can also have files outside the webroot, but as part of the development environment.
The above also allows to have a central index.php and wp-config.php that apply to wherever you run core from. There is also a centralized wp-tests-config.php.
Instead of relying on server configuration to make wp-content etc. work, this PR relies on PHP logic that has been established in existing configurations such as https://github.com/roots/bedrock.
In order to have our centralized configuration work, a few basic custom functions located in public/functions.php are loaded even before WordPress is loaded. These set constants dynamically accounting for the custom directory structure. Furthermore wp-config.php is set up to correctly work in multisite as well, where the URL of the current site only becomes available at a later stage in the bootstrap process.
Customization is possible via wp-config-local.php and wp-tests-config-local.php files as before. For the whole environment, variables can be set/adjusted via a .env file (a default version of which will be placed during setup). All these three files are gitignored. The .env file also fixes the need to have a weird workaround in .lando.yml when running PHPUnit.
Instead of copying themes from the core checkout to the custom content directory, a simple must-use plugin registers an extra theme repository, ensuring we have access to all of the default themes, in addition to custom ones.
Everything in public/content is ignored, except the mentioned must-use plugin, plus a few .gitkeep files that give people a better idea on how to use this.
To do: The docs in the readme need to be adjusted.
This PR augments #4, with the goal to provide an even more flexible environment.
It decouples the Lando setup from the WordPress core instance used, allowing to develop on different core instances and easily exchange them. This has the following benefits:
trunk-git
andtrunk-svn
. By default the setup runs fromtrunk-git/build
, but it can be switched to run fromtrunk-svn/build
simply by adjusting an environment variable.src
folder (which is now possible again for the most part).The benefits that the original PR #4 introduces remain in place. Plugins and themes can be developed in a separate
content
directory.Further notes on the changes:
public
directory, which is the webroot. This ensures we can also have files outside the webroot, but as part of the development environment.index.php
andwp-config.php
that apply to wherever you run core from. There is also a centralizedwp-tests-config.php
.wp-content
etc. work, this PR relies on PHP logic that has been established in existing configurations such as https://github.com/roots/bedrock.public/functions.php
are loaded even before WordPress is loaded. These set constants dynamically accounting for the custom directory structure. Furthermorewp-config.php
is set up to correctly work in multisite as well, where the URL of the current site only becomes available at a later stage in the bootstrap process.wp-config-local.php
andwp-tests-config-local.php
files as before. For the whole environment, variables can be set/adjusted via a.env
file (a default version of which will be placed during setup). All these three files are gitignored. The.env
file also fixes the need to have a weird workaround in.lando.yml
when running PHPUnit.public/content
is ignored, except the mentioned must-use plugin, plus a few.gitkeep
files that give people a better idea on how to use this.To do: The docs in the readme need to be adjusted.