If you run tests outside of a composer autoloader-based environment, or
your autoloader isn’t pulling in Constants.php, everything will break.
This provides a more helpful error message.
PR builds are consistently failing because the version of framework
being used cannot be inferred. This environment variable provides the
answer.
It will need to be fixed for each major release, but I think that’s
less maintenance burden than complicating the build script to read this
from composer.json:extra.branch-alias.dev-master.
* Added Created field to File/Image editor
* switch default input value to null
Fix react errors and added a field description
* API Use new DBField::getSchemaValue()
As in front end jQuery would be redefined by users custom version. Also the script should use the scope variable ```$``` as it represents the instance of jQuery with all the requirements loaded.
SCSS linting now uses the node-based sass-lint tool, since we’re
shifting away from CodeClimate.
This has the benefit of not requiring a ruby gem on dev tools -
everything is provided as npm dev dependencies.
This was also necessary to run the linting inside travis.
The ‘npm run lint’ command will be used to run listing on Travis, which
can also be used on local dev environments. These can also be used with
editor plugins to highlight errors immediately.
The intention is that this can be used in place of codeclimate. The
benefits are that we use a single toolchain in both CI and local dev,
which is not entirely the case at the moment.
Note the sass-lint is provided by “sudo gem install scss_lint”. It’s
possible that we can move to a node-based sass-lint; I can’t recall
what the motivation for using the scss_lint gem was - I think it was
mainly that we had the AirBNB styleguide already implemented as a linter
config.
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.
themedCSS() and themedJavascript() files have previously been hardcoded
to reside in the css/ or javascript/ folder directly beneath the theme
path.
This short-cut still works, but you can also specify the theme-relative
path in its entirely, giving you more flexibility about your resource
layout.
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.
If another file is include main.php and has included composer already,
code might get weird. In particular, if the parent context includes a
different vendor/autoload.php than the one main.php expects.
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.
using ‘silverstripe/framework’ or ‘silverstripe/cms’ will resolve the
right path even if these folders are in the project root.
‘vendor/module:/sub/path’ theme references are also supported so that
the admin sub-theme can be accessed.
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.
When rewriting the i18n.js file from ES5 to ES6, the detectLocale()
call in the constructor was missed - meaning the lang files were loaded by the browser,
but never actually used.
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.
Multiple entry points can't result in a single bundle.css with a fixed filename, see
https://github.com/webpack/extract-text-webpack-plugin/issues/179
Until that's resolved, it's easier to keep the 'css' task separate in Webpack,
and have a single entry point for all CSS (bundle.scss).
Also partially reverting "Moved frontend assets into admin/ "module"",
which moved too many files: debug.css and install.css need to remain
as framework (not admin) deps. Split out into a separate `framework-css` Webpack
task in preparation for splitting off the module.
The JavaScript i18n functionality in SilverStripe is used in the CMS as well as form field implementations.
Form fields used to include their own JavaScript for usage outside of CMS. This now requires custom build tooling in a project.
Hence there's no need for an i18n shim (i18nx.js), since the CMS always uses i18n support.
We've removed the ability to directly reference JS and CSS files
for form fields and other SilverStripe features in favour of a common bundle built by Webpack.
The logical next step is to make the framework module free of frontend dependencies,
which should simplify its operation, and avoid another time intensive "npm install" on a module.
Used in iframe, so can't be rolled into other code.
Moved in admin/ since that's easier for now with Webpack entry points,
and we'll move all JS/CSS into admin/ anyway soon.
There's not a lot of benefit in packaging these separately in terms of initial CMS load size,
so let's simplify the setup. They'll eventually become lazy loaded chunks in a React-based setup
* cache currentUser query
Various modules can call a lot of time Member::currentUser(). We can avoid querying the database multiple times. Cache is implemented as a static array inside the method and store the data byID, in case the currentUserID changes within the same request (not very likely, but..)
