Hi!

I've run into an issue with a DataObject that is related to a Page. A minimal reproducible example is the following.

I have a TestObject which extends a DataObject

class TestObject extends DataObject{
    
    static $db = array(
        'Name' => 'VarChar(255)'
    );
    
    static $has_one = array(
        'LinkedPage' => 'SiteTree'
    );
        
}

Then I have a page that has a list of TestObjects

class TestPage extends Page{
    
    static $has_many = array(
        'TestObjects' => 'TestObject'
    );
    
    function getCMSFields() {
        $fields = parent::getCMSFields();
        
        $fields->addFieldToTab('Root.Main', new GridField('TestObjects', 'TestObjects', $this->TestObjects(), GridFieldConfig_RecordEditor::create()), 'Metadata');
        
        return $fields;
    }
    
}

class TestPage_Controller extends Page_Controller{
            
}

Now create a Page of type TestPage and add a new TestObject to it. The TestObject edit-page does not show a TreeDropdownField, instead it shows the title of the TestPage. It appears that the TreeDropdownField is there, but it is automatically set to readonly. After saving the TestObject, the column in the database shows a reference to the TestPage containing the TestObject.

There appears to be a workaround for the issue. If one adds another has_many relation of type SiteTree, the editor now shows a non-readonly TreeDropdownField below the first readonly TreeDropdownField.

Am I overlooking something here or is it a bug?

You want a GridFieldConfig_RelationEditor rather than a GridFieldConfig_RecordEditor.

Thanks for your reply. I think you're right about the config. I've tried it, did a rebuild with a flush (to be sure), but it does not solve the problem.

However you made me rethink the whole issue (so thank you!). And I figured that data-technically you'd need a has_one relationship from the TestObject to the page in order for the page to have a has_many relationship with the TestObject. Therefore I tested the scenario with leaving out the has_one relationship and indeed, Silverstripe throws an error with "No has_one found on class 'TestObject'" In my code, such a has_one relationship was there, coincidentally, because my intention was to use it for something else.

So my conclusion is that if you have a Page (or any other object for that matter) that has a has_many relationship to another object, the latter should have a has_one relation to the first. This is all quite obvious, but the part where it gets tricky is that Silverstripe takes whatever it can get. So any relation that matches the Class of the one defining the has_many relationship is matched with it. In my code example, this was LinkedPage.

This issue many other have run into and a solution to this problem is described in this topic.

I hope that this helps someone else when running into a similar issue.