If the _config folder exists as a top-level directory, treat the project
root as a module too. This is useful, e.g. when initialisation a
SilverStripe environment within a module.
This is only a first cut. Modules in the vendor directory are excluded.
Most likely, we will need to search the vendor folder for modules with
type = silverstripe-module in their composer.json.
The location of composer’s vendor/autoload_real.php file is a good
indicator of the root of a project, and can be used to derive a
BASE_PATH
This gives us more flexibility about where the framework module is
installed relative to a project root. It also lets us use the framework
module as a project root, e.g. in test runs.
THIRDPARTY_PATH and ADMIN_PATH are calculated relative to this, and
the FRAMEWORK_DIR, THIRDPARTY_DIR, and ADMIN_DIR are relative to the
BASE_PATH.
The 'admin' module will be split off from 'framework',
where 'framework' only provides (mostly) frontend-agnostic PHP classes.
For example, HTMLEditorField.php has a TinyMCEConfig.php driver,
but doesn't come with its own JS includes.
Core.php can rely on composer’s autoloader now that classes are PSR-4
compliant.
If you stuck to the core modules, you could even remove ClassLoader’s
autoloader, but this would break any module that hasn’t been updated
to support PSR-4, so I’ve left it in.
In the future, it would be good to apply SilverStripe’s auto-loader
only to those modules that aren’t coded to use PSR-4, as it would
make class loading more predictable.
