How to disable extension by overriding *.yml config file?

[micobarac]

If some extension adds itself to SiteTree through the extension's *.yml config file, how do I disable the extension for SiteTree and allow it only for a custom MyClass by overriding, using custom *.yml config file in mysite/_config location?

I tried adding the following line in mysite/_config.php file:

<?php
SilverStripe\Security\Member::remove_extension('TheExtension');

but it didn't work.

I don't want to change the original extension's config file, for the sake of future upgrades.

Btw, I am using latest Silverstripe 4.1 CMS.

[dhensby]

i think this is the only way to do it, are you using the FQCN when passing it to remove_extension?

[micobarac]

Yes, I am using FQCN.

[micobarac]

There should be a feature to do this via *.yml files in the future. Right now, I am forced to edit the original extension's config file to make this work, which is a bad choice.

[dhensby]

If you're talking about the comments yml - that's not true, you can apply your yml to the extension directly rather than to the target class.

[micobarac]

What do you mean by applying yml to extension directly? I go to the extension _config folder i change yml file directly? If that's the case, than my statement is far for not being true. Please, correct me if I am wrong.

[robbieaverill]

I think if the extension has a key then you can set it to falsy (in SS4), e.g.

MyClass:
  extensions:
    MyExtensionAlias: My\Extension\ClassName

Then:

---
Name: myconfig
After: '#originalconfig'
---
MyClass:
  extensions:
    MyExtensionAlias: false

If you are just pushing an array with no keys then config will be merged and you will need to use PHP to remove it

[micobarac]

This is the original extension yml partial content:

SilverStripe\CMS\Model\SiteTree:
  extensions:
    - SilverStripe\Comments\Extensions\CommentsExtension

[robbieaverill]

If you modify the comments YAML file so it has an alias, are you able to remove it again via that alias?

[micobarac]

Yes, I can modify the comments yaml file, and change SiteTree into BlogPost. That's the easiest way. But I don't think that original extensions should be changed, but overriden instead, in case we need it.

[tractorcow]

There is an awkward hack you can use to do this.

---
name: resetextensions
---
SilverStripe\CMS\Model\SiteTree:
  extensions: null
---
name: restoresomeextensions
after: '#resetextensions'
---
SilverStripe\CMS\Model\SiteTree:
  extensions:
    - SilverStripe\ORM\Hierarchy\Hierarchy
    - SilverStripe\Versioned\Versioned
    - SilverStripe\Security\InheritedPermissionsExtension

This will clear all extensions, letting you re-add back only the ones you want to keep on SiteTree.

[tractorcow]

For comments module, we could do this

SilverStripe\CMS\Model\SiteTree:
  extensions:
    comments: SilverStripe\Comments\Extensions\CommentsExtension

This would allow you to disable that extension with only this code

SilverStripe\CMS\Model\SiteTree:
  extensions:
    comments: null

However, this would only fix the issue in one module.

Maybe we should make a convention that all extensions should be added with an alias?

[tractorcow]

How about a new yml block.

Instead of before or after we have replaces, which completely disables the prior named block? That would be sufficient correct?

[tractorcow]

Shifting to silverstripe/silverstripe-config#32

[micobarac]

Right now, the simplest approach is to edit the original extension's configuration file directly and do it again in case of updates in the future. No hacking, no bloated config files all around the project. It's a bad approach, but it works nicely.