On IE8, camel case element attributes are NOT included in the object returned
by $(elem).data(), meaning attrs defined in DateField.php (jqueryDateformat and
isoDateformat) are NOT seen by the code in DateField.js (ie the "config" var
doesn't have these set). Causing IE8 to fall back to using US date (mm/dd/yyyy)
formats. This can subsequently cause validation issues if the user's date
format is different.
DateField.js already explicitly checks for jquerydateformat (all lowercase)
so DateField.php has been modified to reflect the correct case for this
attribute name
In locales other than en_US, as a result of missing jQuery locale
files, the DatePicker defaulted to English whenever day and monthnames
were used, breaking validation. Needed to change official locale files
before adding, because Zend_Date and jQuery day/monthnames not matching
again breaks validation.
Removed hard setting the names to uppercase, breaking validation for
other locales
Changed order in convert_iso_to_jquery_format(), to prevent EEE(E)
settings from being overwritten
Added a check for existing locale files, and made DatePicker fallback
to ISO yyy-MM-dd if a missing locale file would otherwise break
validation.
Added documentation for the DateField
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.
In some places source is referenced directly and assumed to be array, while in some places the getSource() method is used instead.
By changing this you have more freedom when extending these classes
While 'y' in PHP means 4 digits year (e.g. 2012), jquery date picker means 2 digits (e.g. 12). That's all fine until then but when you pass the 2 digit year value back to PHP it all goes awry.
For exmple, defatult date format in en_US is 'MMM d, y' so in jquery date picker it's something like this 'Aug 22, 12' and eventually PHP will convert that value to '0012-08-22' which completely wrong.
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
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).
The classnames on the add-new button and breadcrumbs were not
translated due to the use of singular_name() instead of
i18n-singular_name() in GridFieldAddNewButton and GridFieldDetailForm.
