API: Deprecate SS_Datetime.
The DBField subclasses are have all been renamed to start with “DB” and
be in the SilverStripe\Model\FieldType namespace. To keep DataObject
definitions concise, the original short variations of their names are
preserved as service definitions. Most of the field generation code
doesn’t need to change, but where field classes are referenced directly,
changes will be needed.
SS_Datetime, which is commonly referenced outside the model system
itself, has been preserved as a subclass of DBDatetime. This has been
marked as deprecated and can be removed in SilverStripe 5.
A few places that referred to $db and $casting values weren’t using
the Injector to instantiate the relevant classes. This meant that the
remapping we have created as part of moving classes into a namespace
didn’t work.
- Adds ES6 support via Babel
- Transforms existing JavaScript to UMD modules
- Adds module bundling via Browserify
- Existing JavaScript converted to UMD modules
- lib.js and leftandmain.js are bundled using browserify
- JavaScript minifying of bundles handed by gulp
Default to "yyyy-MM-dd" for date format, and "H:mm" for time_format.
Switched to config API for setting/getting values.
Avoid using "MMM" in particular, since it causes
inconsistencies in month names between jQuery UI and Zend_Locale_Format.
Fixes https://github.com/silverstripe/silverstripe-cms/issues/544
Due to the recent change of translations to transifex, some
locales changed their names, which prompted a fix to
i18n::get_available_translations() (see 00ffe7294).
This caused a regression where short locales are determined
from the YAML file names (e.g. "en"), but weren't matched up
with fully qualified locales from get_available_translations() (e.g. "en_US").
Since this list is used in the admin/myprofile dropdown for the Member.Locale value,
it didn't match up with any entries and defaulted to the first one ("Africaans").
Note that the behaviour of admin/myprofile is still a bit weird:
It defaults the locale on new members to the one set for the current administrator.
So if a site defaults to en_US in _config.php, but the admin happens to view
his backend in de_DE, all members he creates default to de_DE as well.
Thanks to @tractorcow for contributing and peer reviewing!
When submitting a Datefield with no value but with a min / max config date, the validate() function attempts to access a function on $this->valueObj (which is a non-object)
Introduced new FormField->castedCopy() method
which tries to replicate the existing form field instance
as closely as possible.
Primarily, the fix was targeted at consistently passing
through FormField->description to all of its variations.
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.
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.
day/month/year values, valueObj on DateField will contain erroneous values.
Check that all the value inputs aren't null or empty values BEFORE
calling Zend_Date on the value.
API CHANGE Removed several unsed JavaScript globals: sprintf(), Number.prototype.CURRENCIES, Number.prototype.toCurrency(), String.prototype.ucfirst(), jQuery.fn.clearFields(), jQuery.fn.clearInputs()
MINOR Removed prototype_improvements.js and jquery_improvements.js files, now contained in individual component code (or removed altogether)
