[2008-08-20] Overriding getCMSFields clashes with updateCMSFields about silverstripe-framework

[tractorcow]

The problem with swapping this order is that you then have the opposite problem; user code that extends getCMSFields is then no longer able to update fields added by extensions.

The real question is, does the convention need to change?

I would argue not, as the above solution can be solved by user code that determines when fields should be overridden or not.

See the blog module for an example of how this is done:

    function getCMSFields() {

        SiteTree::disableCMSFieldsExtensions();
        $fields = parent::getCMSFields();
        SiteTree::enableCMSFieldsExtensions();

        // do stuff

        $this->extend('updateCMSFields', $fields);

        return $fields;
    }

I think a better question is, can we make it simpler and easier for users to do the above? (rather than changing the convention).

Is this better?

SiteTree.php

    /**
     * Delays extension of getCMSFields
     * @param callable $callback
     * @return FieldList
     */
    protected function beforeExtendingCMSFields($callback) {
        if(!self::$runCMSFieldsExtensions) {
            user_error('Calls to SiteTree::beforeExtendingCMSFields cannot be nested', E_USER_ERROR);
        }
        self::disableCMSFieldsExtensions();
        $fields = call_user_func(array($this, "parent::getCMSFields"));
        $callback($fields);
        self::enableCMSFieldsExtensions();
        $this->extend('updateCMSFields', $fields);
        return $fields;
    }

MyPage.php

    public function getCMSFields() {
        $fields = $this->beforeExtendingCMSFields(function(FieldList &$fields){
            $fields->addFieldToTab('Root.Main', new TextField('Test', 'Test'), 'Content');
        });

        // after extending updateCMSFields
        $fields->removeByName('Root.GoogleSitemaps');

        return $fields;
    }

[wilr]

Like your thinking! That defiantly makes the code a bit more explicit as to what it's trying to achieve rather than the disable() calls.

[tractorcow]

Shame the code above doesn't work very well, but I'll rough something up and do some better testing.

The problem is that there's no object context in a closure, so calls to parent::getCMSFields is impossible, and workarounds are flakey.

[tractorcow]

Is there a way to flag issues on Github, or can someone assign this issue to me?

[simonwelsh]

Issues can only be assigned to people in the organisation.

[tractorcow]

Pull request is in the CMS module, including test cases. I've resolved the flakiness issue by adding a $parentClass specifier, allowing user code to tweak the behaviour where otherwise errors or infinite loops would occur.