RFC `replaces` directive to completely disable and replace another yml block

[tractorcow]

Given this config

---
Name: somecoreconfig
---
SomeClass:
  extensions:
    - SomeExtension
---
Name: myconfig
replaces: '#somecoreconfig'
---
SomeClass:
  extensions:
    - AnotherExtension

The "merged" config would only contain

SomeClass:
  extensions:
    - AnotherExtension

This would work similarly to before and after, but would only work with a single named block #somename.

Other blocks that are before / after the named block would not break, but the replacement would be substituted in place of the original in the original position.

You cannot use replaces with before / after

[micobarac]

This use case covers disabling extension defined by the original configuration.
To replace class name by another and attach it to the extension, the configuration should go in two steps:

• disable extension for class set by original extension configuration *.yml file
• enable the same extension for another class, other than the original one

It would be ideal to do this in the same custom /mysite/_config/*.yml file.

[tractorcow]

Yes, so in your case the usage would be:

---
Name: mycomments
replaces: '#commentssitetree'
---
SilverStripe\Blog\BlogPage:
  extensions:
    - SilverStripe\Comments\Extensions\CommentsExtension
  comments:
    enabled_cms: true

(assuming we implement this feature)

[GuySartorelli]

@tractorcow This is a good idea - I've been considering something along these lines for a while, didn't realise there was already an issue for it.

How do you think this should work if the config block being replaced has more configuration in it? e.g.

---
Name: somecoreconfig
---
SomeClass:
  extensions:
    - SomeExtension

SomethingElseEntirely:
  some-config: 'something'

---
Name: myconfig
replaces: '#somecoreconfig'
---
SomeClass:
  extensions:
    - AnotherExtension

What is the end result? Do we get both SomethingElseEntirely.some-config = 'something' as well as SomeClass.extensions.AnotherExtension? i.e. does only the config that is mentioned in the second block get replaced?

Or does the block get entirely replaced, and we only have SomeClass.extensions.AnotherExtension at the end?

I can see good arguments for both scenarios - it depends what the developer is trying to do.

Currently there's no way to unset configuration (as mentioned briefly in silverstripe/silverstripe-framework#11757) so this could sort-of do that - but it feels like a bit of a blunt tool.
But if the developer is just trying to replace the one piece of config and leave the rest of the block in tact (which I think would be the more common use case), then we should only replace the one part that's being re-defined in the new block.

If we go with only replace whatever is redefined, then replaces is probably a misnomer (since we're not necessarily replacing the whole block).

The idea I had originally was a no-merge: true where anything in this block overrides existing configuration and doesn't merge in - but doesn't target a specific configuration block. So you'd have something like

---
Name: myconfig
no-merge: true
---
SomeClass:
  extensions:
    - AnotherExtension

And anything in the extensions configuration array for SomeClass that got processed before this block would be dropped. Though again, depending on what exactly the developer is trying to achieve, that may end up being too blunt a tool.

[tractorcow]

Or does the block get entirely replaced, and we only have SomeClass.extensions.AnotherExtension at the end?

This one. Otherwise, if you want the earlier behaviour, you would use named extensions, and the "after" existing behaviour would work perfectly fine for that case.