If there's validation errors in the ChangePasswordForm, the user
is taken to the BackURL because redirectBack() will go there if
it's set.
Instead of this, just redirect back to the "changepassword" action
on the Security controller.
Broke after I optimized it to work with a TreeDropdownField
which assumes <li><a> structures that thie "preview" dropdowns
don't have. I also failed at the recursion assignment, causing
infinite loops...
Without this change, a call to Cookie::get() immediately after Cookie::set()
won't return the value provided. This creates some unintuitive edge-cases,
although to date it looks like they have been worked around.
The patch doesn't have a test because our testing framework doesn't deal
with cookies well.
SQLQuery->setLimit(0, 99) should result in "SELECT ... LIMIT 0 OFFSET 1".
In fact it does "SELECT ..." without a LIMIT clause at all,
which is unexpected. This is regardless of the $offset value.
There is no reason to try to run test cases of a class that is abstract. By
skipping them we allow developers to create abstract test case classes that
have test functions in them. This is especially helpful when someone is
testing multiple implementations of the same service interface. Most of their
tests can be in the abstract class, and then they can create concrete test
classes for each of their implementations and inherit all of the testing that
is built into the abstract class.
This caused problems when duplicate() was used in the CMS UI
to duplicate a SiteTree object. Since every object of this type
has a ParentID relation, it copied this empty relation into
new "ghost page".
See https://github.com/silverstripe/silverstripe-cms/issues/689
Periodically check for inline changes when focused,
since TinyMCE's onChange only fires on certain actions
like inserting a new paragraph, as opposed to any user input.
This also works around an issue where the "save" button
wouldn't trigger if the click is the cause of a "blur" event
after an (undetected) inline change. This "blur" causes onChange
to trigger, which will change the button markup to show "alternative" styles,
effectively cancelling the original click event.
This is a necessity for any further 3.1 pushes of master files to getlocalization.
Because we'd otherwise remove existing master strings for CTF etc,
which means we can no longer backport new translations to 3.0
(and there's no way for users to contribute translations to 3.0 via getlocalization).
It's still a very monolithic class, but at least I've refactored it to return
all collected strings without writing it to files (for easier testing).
