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
