Ideally we could do this without session, but pragmatically
we still need it, because of the inflexible routing system,
and because of performance considerations.
Example: The tree is lazy loaded via a generic URL (admin/pages/treeview).
While we could add ?ID=<currentpage> to make the view (more or less) stateless,
it would trigger a full tree reload on every tree navigation action.
Instead, we assume that all "reachable" nodes are already cached,
and simply mark a different one as current. For this to work, we need
shared session state between CMS controllers.
See http://open.silverstripe.org/ticket/7815 for detail.
Related to #7740. The sort field gets stale if the current
record is moved in the tree. Since the sort value can't
be altered by interacting with the form, its not required
as a hidden field, either.
Was fetching the record from live (and its direct URLSegment),
but all of its parents from the current stage, which might be draft,
leading to "mixed" draft/live nested URLs which might no longer
be reachable in live mode.
VirtualPageTest was adding fields to Page via a decorator, but Page might
not have any fields itself. This changed Page from not having a table
to having a table, which then caused a problem on tearDown
By renaming fields to "StageLink" and "LiveLink",
which means they don't get influenced by the model getters
on Form->loadDataFrom(). Its also a more accurate
name for the field value, since it contains a full (nested) URL
rather than just a segment. Only used internally, so no API change.
Removed ineffective FieldGroup->subfieldParam setting,
replaced with a specialised template, as well as a new "stacked" styling
(both added to framework codebase)
Installer was feeing the title "Title" to the template. Template
rearranged for usability concerns (people were missing the email and
password when going to the CMS login page)
Happens to work for the width of the english label,
but breaks on any other language with longer labels.
Don't make the button absolutely positioned.
Partially reverts 1e25637a.
translations were not added in the same translation group, and the
translation module didn't work. Also commited changes in the translation module, which will need this commit.
Called for each subclass by the collector,
so we don't need to aggregate here.
In fact, its harmful because it causes entities
to be placed in the wrong definitions file.
The <class>.DESCRIPTION entity was always placed in cms/lang/en.yml,
regardless of the original location of the file containing the class.
Was inferred by the containing file previously,
which is deprecated behaviour, because it obscures
the fact that renaming an template file or copying
template code will change the context of the translations.
While it would be nice to use shorter and more readable namespaces,
this change would remove all existing translations.
Since there is no (easy) migration of entities to a new namespace,
having verbose template code is the lesser of two evils.
