The motivation for this was to allow module developers to change what parser is used to parse SilverStripe templates.
This change enables people to compile their own version of the SilverStripe template parser and use it without modifying core files.
For instance, this happens when these criteria are met:
1) No casting has been specified for a method in $casting.
2) A template accesses the field without any casting
3) Any casts by the template will now yield an empty object.
After a brief look at the commit history, it can seem like this bug is several years old, unless it is a side-effect of other changes in the code.
== Steps to reproduce ==
Add two methods to be accessed by a template. Make sure you do not define an entry in $casting for them:
public function Testus() {
return "Te<x>t1";
}
public function Testus2() {
return "Te<x>t2";
}
Add this to a template:
<p>
First access:<br />
"$Testus" : "$Testus.XML"<br />
"$Testus2.XML" : "$Testus2"<br />
</p>
<p>
Second access:<br />
"$Testus" : "$Testus.XML"<br />
"$Testus2.XML" : "$Testus2"<br />
</p>
Open the page in a browser, and you will get:
First access:
"Tet1" : ""
"Te<x>t2" : "Tet2"
Second access:
"Tet1" : ""
"" : "Tet2"
We see that any cast can yield an empty string.
FIX: Ensure SSViewer::hasTemplate() is aware of themes.
To do this, RequestHandler::definingClassForAction() has been created, splitting out the code that looks up the class that defines a given action into its own method. This is then overridden in Controller to look at templates.
This allows someone to extends Requirements_Backend and plug in their own minification
of files, including CSS minification. It also allows them to override whether or not
the header comment is written for each file.
API: CompositeDBField::setValue() may be passed an object as its second argument, in addition to array.
These changes provide a 15% - 20% performance improvement, and as such justify an small API change in the 3.0 branch. It will likely affect anyone who has created their own composite fields, which is fortunately not all that common.
The parser could sometimes generate invalid code if the
source-file-comments were enabled, this moves the comments outside the
html-tag to circumvent these problems, update test as well.
Since we can't influence the setting of configuration values,
we also can't set/unset the 'custom_theme' value based on which
theme is set. This means the 'custom_theme' value goes stale,
and we can't rely on it e.g. in FilesystemPublisher.
The 'theme_enabled' toggle is a cleaner solution to the same problem,
since the 'custom_theme' was really just a way to remember the original
theme, while still disabling it. The toggle makes this more explicit,
but also requires users of the 'theme' setting to check for it.
The template-parser files were not in sync, there were some lines added
in SSTemplateParser.php from 3334eafcb1
and 0a9f3b75a9 , I readded those parts
into the SSTemplateParser-include-file and recreated the
SSTemplateParser.php to get to a synced state...
This means that you dont have to worry about casting it
as HTMLText again when using the result in a template or other context
However in some situations code might be assuming it can
check with is_string, in which case you now need to use instanceof HTMLText
Ideally we'll have region-less locales like en.js as fallbacks,
but for now this prevents the UI becoming non-operational
e.g. when both i18n::set_locale() and i18n::default_locale()
are set to 'en_NZ'.
The entire framework repo (with the exception of system-generated files) has been amended to respect the 120c line-length limit. This is in preparation for the enforcement of this rule with PHP_CodeSniffer.
The Requirements class currently treats only absolute URLs as URLs, and
tries to interpret anything else as a filesystem path. This prevents
using scheme-relative URLs for requirements.
Example:
<% require javascript(//ajax.googleapis.com/ajax/libs/jquery/1.7.2/jquery.min.js) %>
This forces the unfortunate choice of not using a CDN for common
scripts, always using an https absolute URL, or accepting that some
browsers will throw a security warning when viewing the site in https.
This change allows scheme-relative URLs & updates RequirementsTest.
Use third party tools like XHProf instead.
Removed defunct or unnecessary debug GET parameters:
debug_profile, debug_memory, profile_trace, debug_javascript, debug_behaviour
2.4 used to use a manifest to find css. One side-effect of that is that even without explicit support,
css files in module-specific themes (/themes/{theme}_{module}/) would get picked up. This broke in 3.
This fix does still require the module name to be explicitly passed as a parameter to themedCSS, but if
you do, and a css file of that name exists in the module-specific themes css directory, that will
be included in preference to the theme or module provided css