This shifts the behat test run to be triggered form composer activity
within the framework module directly,
* silverstripe/serve is used to provide a webserver, based on the
php -S command
* se/selenium-server-standalone is used to install selenium rather than
a download command
Because we’re using serve, the behat configuration can be locked down.
Further refinements could be made on this:
* the behat-extension could be responsible for installing and
starting/stopping selenium, making these tests more portable
* xvfb initialisation could be provided with another bin tool in the
begat-extension: vendor/bin/xvfb 1024x768
* The bootstrap-file argument to serve could be provided as part of a
composer.json setting. This would make it easier for developers to
start a dev server simply by running vendor/bin/serve
* the behat-extension could be responsible for installing and
starting/stopping silverstripe/serve, removing the need for
specifying base_url at all, and possibly utilising the same bootstrap
file between serve and behat.
The SilverStripe project structure complicates the travis test run, and
the goal of this branch is to prevent it from being necessary.
- Unit tests can be run simply with PHPUnit.
- Behat test can be run with the silverstripe/serve module
Note that initially this commit doesn’t cater to the behat tests.
As part of this, we allow dev packages to be installed when testing
These settings don’t affect projects that use framework, only when
framework’s composer install / require calls are used themselves.
Since SS4 is pre-stable, these are important. They can probably be
removed once SS4 stable (and stable versions of support packages) have
been released.
Standardise template locations
Move CMSSettingsController class to SiteConfig module
Fix CMSMenu behaviour for namespaced admin sections
Split classes into one per file
Manual fixes and cleanup
API CHANGE: Debug::showError(), Debug::showLines(), Debug::log(), and Debug::header() removed
NEW: Logging provided
ZendLog has been removed and monolog introduced instead as a dependency.
The “ErrorLogger” injection point is now the used as the logger that
errors are fed into, and implements PSR-3’s Psr\Log\LoggerInterface.
The SS_ERROR_LOG setting expect a Monolog Logger to be provided as the
ErrorLogger.
Moved to end of requirements, to work around a bug in composer - see https://github.com/composer/composer/issues/1147. This caused the dependencies to be installed in the wrong folder because the custom 'silverstripe-module' instructions hadn't been loaded at the time the core modules were installed via composer.
