Competing usage of get parameter 'ID' causes malfuction of FormField actions

[sb-relaxt-at]

Module version(s) affected

3.1.6

Description

There is a fallback behavior in LeftAndMain#currentRecordID that uses the get parameter 'ID' to determine the current record. On the other hand FormFields like the TreeDropdownField may use get parameters like 'ID' to transport information in a request. This may lead to errors as the TreeDropdownField sends a certain ID and LeftAndMain tries to load a record with this ID.

In most cases this seems to be irrelevant as the fallback is not triggered (LeftAndMain#show sets setCurrentRecordID which makes the fallback irrelevant), but it happens if we use a SingleRecordAdmin like SiteConfigLeftAndMain. The relevant part of the implementation is

public function getEditForm($id = null, $fields = null): ?Form
    {
        if (!$fields) {
            if (!$id) {
                $id = $this->currentRecordID();
            }
…

As no id is passed to getEditForm it will make a lookup via currentRecordID which in turn triggers the fallback behavior (which might be unnecessary at all in a SingleRecordAdmin?).

How to reproduce

How to reproduce:

1. Create has_one to Page on SiteConfig (and render a TreeDropdownField as FormField for management)
2. Create three levels of nested Pages
3. Navigate the TreeDropdownField to level 2 -> the request will fail

e.g. https://www.example.com/admin/settings/EditForm/field/SomePageID/tree/?ID=2&format=json

I can't handle sub-URLs on class SilverStripe\Forms\FormRequestHandler.

Note how every ID but 1 (which is the default SiteConfig record ID) will fail.

Possible Solution

I am uncertain whether it is a bug in LeftAndMain (is there really a case where we need to pass ID as a GET parameter?) or maybe one in SingleRecordAdmin? On the other hand one could argue that the TreeDropdownField is to blame and all FormFields should only use some kind of namespaced GET parameters like '?TreeDropdownField_ID=…".

Validations

• Check that there isn't already an issue that reports the same bug
• Double check that your reproduction steps work in a fresh installation of silverstripe/installer (with any code examples you've provided)