Causes field to change width after first display,
as the .hasDatepicker class is added dynamically on first field focus.
Since we don't add an icon by default, there's no difference
between an <input> field with date picker, an input field for dates,
and a simple input field. Fall back to global (or CMS specific) rules.
No longer necessary as we've fixed the Chosen.js width
settings, which means the <select> fields can inherit
their settings and determine width automatically.
Rather than disabling the links altogether, which is
counter-intuitive to most users.
See https://github.com/silverstripe/sapphire/pull/638.
Also hide a duplicate $SilverStripeNavigator on the previewed
website (in case it has been manually applied to the template).
It is possible to specify before and after rules on config fragments
that conflict - A before B and B before A isnt possible to solve.
This used to just throw an error with no way to debug. Now if you
specify debug as a GET parameter and the site is not in live mode
youll get a basic dump of the remaining DAG graph
When specifying a specific before rule and a wildcard after rule (or
vice versa), the config system was filtering out any fragment
from the list of fragments that matched the wildcard if it matched
_any_ componenet of the specific rule, not all of them.
Fixed, and added handling of two semi wild-card rules, where a
rule with less wildcards wins over a rule with more.
See http://open.silverstripe.org/ticket/7765 for more
You should be able to specify multiple before and after rules in
a config fragment. This was intended to be a comma seperated string
but that wasnt being split properly
Now if you provide a comma seperated string it is split properly,
but you can also provide an array, which is actually cleaner
ADDED: HTTP_Request::params() to retrieve all (shifted) params used in the request
FIXED: Issue where route-table level arguments would not be accessible without using non-deprecated API.
ADDED: Test case to test the above items
UPDATED: Extended Director::test to allow for the retrieval of the request object
UPDATED: Deprecated notice on Director::urlParam and Director::urlParams
REMOVED: Unused variable
FIXED: Coding convention conformity
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.
Config system used to provide an add_static_source method, which was intended for
use by Extensions to add statics. But extensions for a class arent initialised
until at least one instance of that class is created, so before that the
Config system didnt include values from extensions
This patch reverses the control flow, so that the Config system explictly asks
each Object for its additional config sources via the new method
get_extra_config_sources. This method returns an array that can contain
string names of classes and also raw associative arrays.
The developer visible change is that Extension#add_to_class has been
deprecated. Instead there is a new method, get_extra_config, which has
the same method signature but needs to guarantee that it doesnt
cause side effects. Additionally there is no need to call
parent::get_extra_config - this is handled automatically.
Fixes the handleAction function of GridFieldDeleteAction which wasn't differentiating between a 'deleterecord' action and an 'unlinkrelation' action.
Fixes http://open.silverstripe.org/ticket/7801
Hierarchy#liveChildren was generating a list of all IDs of all pages
on staging. When a site had lots of pages, this basically killed the
tree.
Fix by adding new versioned mode, stage_unique, which uses a
subselect to only return items from a stage that are in no
other stage.
Wasn't refreshing after ajax save operations on existing
content, as the URL didn't change, and hence the CMS
didn't reload the view. Return the view directly instead,
unless we're dealing with new records (= changed URL).
