It's defaulted to false. But when set to true, the JS is written to the end of the HTML, even though there are earlier scripts.
This results in faster page-loading if the JS isn't needed earlier-on.
When looking for a translation, the fallback solution (CurrentLocale -> defaultLocale -> fallbackString) does not work for cms/javascript/CMSMain.Tree.js as localization for this part was changed to short locale names (e.g. de_DE -> de). (Don't know why...)
The original fallback solution will not find a translation for e.g. "Tree.ShowAsList" in the de-language file. For this entry there is also no fallbackString defined, so the menu in the CMS (right click on a page) is broken for each language that does not have the translation included.
I added another fallback level where the short version of the default language (en_US -> us) is searched before falling back to the fallbackstring and then finally giving up...
getAttribute('value') behaves inconsistently with Selenium drivers
(fails on Travis and TeamCity, but works locally). Selenium2Driver
in Mink provides a JS wrapper for getting the value, which is more reliable.
This fixes "insert a link" failures, see https://travis-ci.org/silverstripe/silverstripe-cms/jobs/14281251
The following line is repeated in the section "Don't allow access to .yml files "
See [Apache](/installation/webserver) and [Nginx](/installation/nginx) installation documentation for details
specific to your web server
In the TEMPLATES ....sub-heading..Adding Database Fields ..
IN the line below..
Every time you run db/build to recompile the manifest........
change db/build to dev/build.
It's defaulted to false. But when set to true, the JS is written to the end of the HTML, even though there are earlier scripts.
This results in faster page-loading if the JS isn't needed earlier-on.
Technically a textarea DOM node doesn't have a 'value' attribute,
but rather a HTML content. This used to work, but likely broke either
by updated browser handling or updated selenium logic.
Fixes "Scenario: I can edit title and content and see the changes on draft"
Avoid unparsed HTML responses in case of httpError(4xx) or
httpError(5xx) in live mode. The SS_HTTPResponse_Exception constructor
automatically set "text/plain" a content type, which conflicts
with the later choice of Debug::friendlyError() to return HTML.
This is a hotfix, needs more work to properly separate
logic flow from presentation concerns (e.g. through request processors).
