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
Since we can't influence the setting of configuration values,
we also can't set/unset the 'custom_theme' value based on which
theme is set. This means the 'custom_theme' value goes stale,
and we can't rely on it e.g. in FilesystemPublisher.
The 'theme_enabled' toggle is a cleaner solution to the same problem,
since the 'custom_theme' was really just a way to remember the original
theme, while still disabling it. The toggle makes this more explicit,
but also requires users of the 'theme' setting to check for it.
- Renamed $minNodeCount to more accurate $nodeCountThreshold
- The $minNodeCount attribute wasn't properly respected
during actual querying, so SilverStripe would always traverse
the entire tree (and load all objects into memory),
before then marking nodes as "unexpanded", which prevents
them from actually being rendered.
- Fixes nodes on search results to be expanded by default
- Fixes nodes on search results to correctly ajax-expand
Necessary to switch from tree view to list view programmatically,
which reloads the whole tabset and needs to enable the "list" tab.
Used for the new "Show list as children" functionality in the cms.
Fixed what I believe to be a few very minor CSS regressions, that appeared after the CSS restructure for the side-by-side preview.
- Reverted background of the right panel (and tab active state) to the slightly darker shade (as per 3.0) to keep each of the 3 panels visually separate.
- Slightly increased padding on ui-tabs-panel as felt a but too close for comfort. Had decreased since 3.0.
- Decreased padding for logged in user name in menu, felt too excessive. (3.0 was neater)
- Evened out padding above buttons in site tree sidebar
Screenshots showing changes:
3.0: http://spdr.me/xauh
3.1 before commit: http://spdr.me/jkIe
3.1 after commit: http://spdr.me/IxtB
This removes the need for a lot of boilerplate code
around DataObject->write() logic, and avoids generic 500 errors
on user-level failures. This should really be a per-project choice,
but at the moment request handling doesn't allow to configure
custom exception handling.
changed $ to jQuery, because without it the system would generate the following error:
Uncaught TypeError: Property '$' of object [object Window] is not a function
changed $ to jQuery, because without it the system would generate the following error:
Uncaught TypeError: Property '$' of object [object Window] is not a function
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.
