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..)
When adding the deps straight into the file (recommended),
the onchange handler in file-upload isn't firing properly when a file is uploaded through
the <input type=file> button - it falls back to default behaviour, which submits the
containing form, failing because the upload is handled by a different URL.
https://facebook.github.io/react/downloads.html says:
"By default, React will be in development mode. To use React in production mode, set the environment variable NODE_ENV to production (using envify or webpack's DefinePlugin). A minifier that performs dead-code elimination such as UglifyJS is recommended to completely remove the extra code present in development mode."
These were originally copied from node_modules via an "npm run thirdparty" task,
in order to have them loadable with oldschool <script> tags.
Since webpack supports CommonJS-style loading, that's no longer required,
we can simply inline those scripts into the bundle.
We need to use imports-loader though, in order to ensure
that "define" is not available in some module scopes,
which triggers AMD behavior that's not compatible with Webpack's loaders.
See http://webpack.github.io/docs/shimming-modules.html
I've had to pin to the exact versions used in the 3.x CMS,
since jquery-upload has introduced an AMD wrapper sometime
between 6.0 and 6.9 (the latest version NPM automatically pulls in).
This AMD wrapper confuses Webpack, since it's trying to resolve the
dependencies contained in it. We could create shims for those instead,
but the easiest way was to simply revert to the versions already used
before the Webpack migration (since the newer versions in node_modules
were never actually copied into thirdparty, they weren't used before).
This has been made obsolete, since those files are all included in the main bundle (see bundle-lib.js).
They should not be referenced individually (e.g. through Requirements::block() or Requirements::javascript()).
Many of these are now inline via Webpack's url-loader plugin (https://github.com/webpack/url-loader),
and a tonne were legacy references (e.g. leftovers from ComplexTableField).
Some of these might still be used in other modules like userforms,
but we're removing support for "hotlinking" images in core - they're not an API.
We've disabled this previously because it was interfering with JS sourcemaps and breakpoints.
After some spot tests, this no longer seems to be the case with webpack generated sourcemaps.
Responsibility for finding and referencing images and fonts is now
given to webpack. All the url references are now relative to the
component scss file, and point to font & images files in src/, rather
than assuming someone else will place them in dist.
This makes the source more modular, and makes it easier to, for
example, inline images are data URIs, or create a new build script that
builds several modules for a project in a single pass.
Workaround for bad font path in bundle.css:
ExtactTextPlugin didn’t work as well with a subfolder reference in the
filename. This is just a short-term fix and could probably be improved
to put bundle.css back in the styles subfolder.
Webpack handles images & fonts:
Responsibility for finding and referencing images and fonts is now
given to webpack. All the url references are now relative to the
component scss file, and point to font & images files in src/, rather
than assuming someone else will place them in dist.
This makes the source more modular, and makes it easier to, for
example, inline images are data URIs, or create a new build script that
builds several modules for a project in a single pass.
Clarify docs on spriting and webfonts:
We've decided to remove sprity since it comes with hundreds of dependencies,
and needs compilation within the "npm install" - dragging out the already overweight
install process, and making the resulting node_modules/ folder less portable between systems.
API: Remove InlineFormAction::includeDefaultJS()
Developers must now take responsibility for including the necessary JS
and CSS themselves. This has been implemented in the admin, but not
in other use-cases.
The bundle is generated by running “webpack” directly - gulp is no
longer needed as an intermediary. The resulting config is a lot shorter,
although more configuration is pushed into lib.js.
Modules are shared between javascript files as global variables.
Although this global state pollution is a bit messy, I don’t think it’s
practically any worse than the previous state, and it highlights the
heavy coupling between the different packages we have in place.
Reducing the width of the coupling between the core javascript and
add-on modules would probably be a better way of dealing with this than
replacing global variables with some other kind of global state.
The web pack execution seems roughly twice as fast - if I clear out my
framework/client/dist/js folder, it takes 13.3s to rebuild. However,
it’s not rebuilding other files inside dist, only the bundle files.
CSS files are now included from javascript and incorporated into
bundle.css by the webpack. Although the style-loader is helpful in some
dev workflows (it allows live reload), it introduces a flash of
unstyled content which makes it inappropriate for production.
Instead ExtractTextPlugin is used to write all the aggregated CSS
into a single bundle.css file. A style-loader-based configuration could
be introduced for dev environments, if we make use of the webpack live
reloader in the future.
Note that the following features have been removed as they don't appear to be
necessary when using Webpack:
- UMD module generation
- thirdparty dist file copying
LeftAndMain.js deps: Without it, ssui.core.js gets loaded too late,
which leads e.g. to buttons being initialised without this added behaviour.
When you want to add a button to the CMS but don't want LeftAndMain to apply jQuery UI button to it we add the `data-button="true"` attribute to our button.
The `onadd` function checks that this attribute does not exist before calling `this.button()`.
The `onremove` incorrectly checks that this attribute does exist before calling `this.button('destroy')`. This should be checking that this attribute does not exist, just like the `onadd` function.
What this causes is when you have a button with the `data-button` attribute a button is not created, but when you leave the page `destory` gets called on an item which doesn't exist. We end up with the following error:
> Uncaught Error: cannot call methods on button prior to initialization; attempted to call method 'destroy'
The other issue with this logic is buttons are never getting destroyed when `onremove` is called.
The whole issue is caused by a missing `!` in the if statement. This change adds it in to fix the problem.
