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.
Code was assuming that FRAMEWORK_DIR would always have a value. If it
doesn’t (because you’re running a test instance of a naked framework)
This caused URLs to be treated as root relative, which creates some
duplicate-inclusion bugs.
The use of ltrim() works, but is a bit clumsy. A more flexible approach
to including front-end assets of given modules would be preferable;
ideally something that also let you keep your code outside of the
web root.
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.
They were used for TreeDropdownField JavaScript tests but were never run
on CI, hence have been a bit of a wasted effort.
We're using a different JS unit testing solution now (geared towards React),
and running Jasmine in parallel on Travis for a few test cases
doesn't warrant the setup effort involved.
The TreeDropdownField component will eventually move to a React solution
which can be developed in a test-driven fashion.
Introducing <Tabs> component based on react-bootstrap
Better support for nested fields in FormBuilder
Tweaks to get FormBuilder working with frameworktest BasicFieldsPage fields
Added exception in FormBuilder when Component is defined but not found
Added check in SingleSelectField for empty value before adding one in
Added temporary workaround for CompositeFields with no name (another story to address the actual problem)
Added asset_preview_height for File image preview, matches the defined CSS max-height
Added documentation to DBFile::PreviewLink() method
API Remove DataList::applyFilterContext(), superseded by DataList::createSearchFilter()
API SearchFilter::getSupportedModifiers() added to support supported modifier inspection
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
