Normalise removal of fields from project config field layouts

[rynpsc]

Currently when using project config plugins and modules have to take care of cleaning up deleted fields when implementing a field layout. Throughout Craft this is done via a pruneDeletedField method across the various services. Looking at them they are all mostly the same except for the the path prefix. Taking a look at plugins they also reuse the same code as Craft.

Could this be cleaned up a little and moved to either a project config helper method or an Event? The purpose of this is to try and reduce some of the boilerplate required when dealing with project config.

Helper

Event::on(Fields::class, Fields::EVENT_AFTER_DELETE_FIELD, function(FieldEvent $event) {
    \craft\helpers\ProjectConfig::pruneDeletedField(ProjectConfig::PATH_GLOBAL_SETS, $event);
    \craft\helpers\ProjectConfig::pruneDeletedField(ProjectConfig::PATH_CATEGORY_GROUPS, $event);
    // ...
}

Events

I've used the existing field event with a new projectConfigPaths property to demonstrate but it could be a new event?

Event::on(Fields::class, Fields::EVENT_AFTER_DELETE_FIELD, function(FieldEvent $event) {
    $event->projectConfigPaths[] = ProjectConfig::PATH_GLOBAL_SETS;
    $event->projectConfigPaths[] = ProjectConfig::PATH_CATEGORY_GROUPS;
    // ...
}

As an aside is the path being provided to $projectConfig->remove correct? The paths contain referecnes to .fields., should that be .elements.?

https://github.com/craftcms/cms/blob/2ccbe5a875cbcb3767aaead3e293aeb48fd50e1c/src/services/Categories.php#L642=

[brandonkelly]

As an aside is the path being provided to $projectConfig->remove correct? The paths contain referecnes to .fields., should that be .elements.?

Doh… looks like we forgot to update these methods when we refactored field layouts in Craft 3.5, so they’ve been pointless ever since then.

I explored the idea of centralizing the pruning of deleted fields from field layouts when looking into #11333, but unfortunately there’s just not a clean & reliable way to do it, without risking unexpected data deletion.

In the end, I decided it’s best to just let the field layouts continue to reference the deleted fields, and to stop logging a warning when instantiating a field layout with one.

I’ve also deprecated all of the existing pruneDeletedField() methods in Craft and Commerce (b9bca47, craftcms/commerce@901802b) for the next release, removing the precedence for third party plugins to try to be proactive about it.

[brandonkelly]

Craft 3.7.51 is out with the same changes, as the pruneDeletedField() methods turned out to be the culprit for #9567.