Caused by SS loading a URL with html entities (&)
through the Requirements API, which only works when directly
inserted into the HTML template (standard behaviour),
but garbles the URL GET parameters when loaded via the jQuery.ondemand
JavaScript/XHR logic.
It didn't fail the request, just meant that tiny_mce_gzip.php wasn't
getting all the required options from the GET parameters.
And since this newly loaded file contains the same JS globals,
it would override previously loaded (correct) state.
This bug was introduced with the new nested CMS actions
around December 2012, but wasn't noticed until now
because checkAccessAction() would wrongly return TRUE
before the dataFieldByName() check was reached.
At the moment form actions (buttons) have the classes 'action action' as default. This is because the extraClass function adds 'action' and then calls the parent method. The parent then includes the $this->Type() ('action') again.
So I've remove this overloading of extraClass
Sometimes has-one UploadFields can get confused about whether or not there is an existing file that needs deleting. This setting lets you make a more robust has-one UploadField, where any existing file will be replaced. It more closely mimics simple single-file upload fields.
This is the companion setting to canUpload, letting you control whether existing files from the asset store can be referenced. It's particularly useful when using UploadField on the front-end.
Although editing meta-data or deleting permanently would require File editing/deleting permissions, merely linking to a record does not. This change is important for allowing front-end use of UploadField; or, more importantly, use of UploadFile by people without CMS rights.
The new config setter restores the 2.4 behaviour of including <input type="hidden"> with a field. Although as a default, this option has security flaws; it is useful in a few circumstances and, if nothing else, is handy to make upgrading sites easier.
This hook is useful so that you can add additional fields / actions in a gridfield form that are not available in other settings (e.g. additional actions: previous / next / save and publish / unpublish / etc
Function unset() preserves numeric keys and method removeRequiredField() will give a PHP notice about nonexistent array key and loop won't iterate throughout all elements in array on second method call (and all subsequent).
So it's better to use foreach loop and array_splice() function (it doesn't preserve numeric keys).
The existence of .ss-tabset triggers JS which applies $.tabs(),
and in turn interprets the first available link as the tab navigation.
jQuery UI subsequently tries to ajax-load this link, which is not
desired. Instead, $.tabs() should *only* be applied to a container
DOM element with .cms-tabset applied.
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
