Previously relied on the presence of a last column which wasn't filterable,
commonly a GridFieldEditButton. If this wasn't present, the filter buttons
were never added, leading to the GridField JS reload request being sent
without the required button form action, so GridFieldFilterHeader->handleAction()
was never called.
Cleanup of framework's use of @package and @subpackage labels and additional of labels for classes missing packages.
Moved all GridField related components to the one name.
Countless spelling fixes, grammar for other comments.
Link ClassName references in file headers.
Fixes http://open.silverstripe.org/ticket/5577.
Uses Zend_Locale_Format::isNumber(). Includes unit test for NumericField. Does not include testing work on DBField underlying NumericField to ensure that works consistently.
This prevents it from failing for proxied values
like BlogEntryForm, where the field name doesn't exist,
and rather gets processed and saved into a different field.
Caused the UploadField rows to show "[Object object]" because
it tried to pass through a PHP object to JS without string casting
(the return used to be a string).
This is related to how Zend_Date returns year for YYYY & yyyy format. Detailed explanation is here http://framework.zend.com/issues/browse/ZF-5297
Sample code (adapted the Datetimefield setValue() method) to highlight the problem:
include 'framework/thirdparty/Zend/Date.php';
$userValueObj = new Zend_Date(null, null, 'en_US');
$userValueObj->setTimezone('GMT');
$userValueObj->setDate('2012-01-01', 'YYYY-MM-dd');
$userValueObj->setTime('00:00:00', 'HH:mm:ss');
echo $userValueObj->get('YYYY-MM-dd HH:mm:ss', 'en_US'), "\n"; // returns 2011-01-01 00:00:00
echo $userValueObj->get('yyyy-MM-dd HH:mm:ss', 'en_US'), "\n"; // returns 2012-01-01 00:00:00
Rendering potentially 1000s of nodes can exceed the CPU and memory constraints
of a normal PHP process, as well as the rendering capabilities of browsers.
Set a hard maximum for the renderable nodes, deferring to a "show as list" action
in the main CMS tree. For TreeDropdownField, we don't have the list fallback option,
so ask the user to search for the node title instead.
Also makes both the "node_threshold_total" and "node_threshold_leaf" values configurable
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.
The deprecations are supposed to denote the release where
the functionality will be removed, as opposed to the one where
its deprecated. Having 3.1 as a target for recent changes
in popular methods like Object::add_extension() causes
too many short-term hassles, there's no "grace period".
Extracted common code out to SS_HTMLValue and made abstract, then
put HTML 4 specific code in SS_HTML4Value. Its now possible to
replace HTMLValue with one designed for HTML 5 or XHTML
Requires a code change from new SS_HTMLValue to
Injector::inst()->create(HTMLValue)
When saveInto is called on ListboxField and CheckboxsetField,
UnsavedRelationList should be an acceptable relationship type. This is
leading to relations not being saved on initial creation of Member
objects
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
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.
RequestHandler#handleAction now exists. It takes the request, and
the action to call on itself. All calls from handleRequest to call an action
will go through this method
Controller#handleAction has had it's signature changed to
match new RequestHandler#handleAction
RequestHandler#findAction has been added, which extracts the
"match URL to rules to find action" portion of RequestHandler#handleRequest
into a separate, overrideable function
GridField#handleAction has beeen renamed to handleAlterAction and
CMSBatchActionHandler#handleAction has been renamed to handleBatchAction to
avoid name clash with new RequestHandler#handleAction
Reason for change: The exact behaviour of request handling depended heavily
on whether you inherited from RequestHandler or Controller, and whether the
rule extracted it's action directly (like "foo/$ID" => 'foo') or dynamically
(like "$Action/$ID" => "handleAction"). This cleans up behaviour so
all calls follow the same path through handleRequest and handleAction, and
the additional behaviour that Controller adds is clear.
We shouldn't pass it to the child fields since it ends
up showing the description three times in the default
"inline" mode. If the description is required as a hover/focus effect,
it can be set individually on the fields.
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.
