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.
Pull requests are always on a branch, and this branch
typically is not present on the installer.
This changes means we need to be careful when merging into 3.1
and master, but that's a necessary evil.
Pull requests are always on a branch, and this branch
typically is not present on the installer.
This changes means we need to be careful when merging into 3.1
and master, but that's a necessary evil.
Pull requests are always on a branch, and this branch
typically is not present on the installer.
This changes means we need to be careful when merging into 3.1
and master, but that's a necessary evil.
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.
allowed_actions is now only allowed to reference public methods defined
on the same Controller as the allowed_actions static, and
the wildcard "*" has been deprecated
This will prevent empty passwords to set the encryption to 'none',
which in turn will store any subsequent password changes in cleartext.
Reproduceable e.g. with ConfirmedPasswordField and setCanBeEmpty(true).
Controller (and subclasses) failed to enforce $allowed_action restrictions
on parent classes if a child class didn't have it explicitly defined.
Controllers which are extended with $allowed_actions (through an Extension)
now deny access to methods defined on the controller, unless this class also has them in its own
$allowed_actions definition.
This will prevent empty passwords to set the encryption to 'none',
which in turn will store any subsequent password changes in cleartext.
Reproduceable e.g. with ConfirmedPasswordField and setCanBeEmpty(true).
Controller (and subclasses) failed to enforce $allowed_action restrictions
on parent classes if a child class didn't have it explicitly defined.
Controllers which are extended with $allowed_actions (through an Extension)
now deny access to methods defined on the controller, unless this class also has them in its own
$allowed_actions definition.
Shortcodes have traditionally had a problem that they are inside <p> tags,
but generate block level elements. This breaks HTML compliance.
This makes the shortcode parser now mutate the DOM based on the "class" attribute on
the shortcode to insert the generated block level element at the right place in the DOM
- for "left" and "right" elements it puts them just before the block level
element they are inside
- for "leftAlone" and "center" elements it splits the DOM around the shortcode.
The trade off is that shortcodes are no longer "text level" features. They need
knowledge of the HTML they are in to perform this transformation, so they can
only be used in (valid) HTML
