Contact forms are full of special handling for the personal form. And apart from the personal contact form, no special functionality can be added to contact forms: they're just plain forms.
Instead, we could add a new plugin type that provides custom functionality for a contact form. This would allow contrib modules to add new kinds of contact form, and remove a lot of the special case code from Contact.
We can probably do this in a backwards-compatible manner, as the special case code checks for the 'personal' bundle name a few times, and most of the time calls isPersonal() on the Drupal\contact\Entity\Message.
So isPersonal() could be changed to check the ID of the plugin, and return TRUE if it's the plugin that handles the personal contact form functionality. In essence, it becomes a backwards-compatibility wrapper.
Comments
Comment #2
larowlanI'd love to see per bundle entity classes instead
Comment #3
joachim commentedIs that more or less the same thing? But with plugins, you can choose to have several bundles (and so with different fields) that use the same plugin?
Also, do you mean for Contact module, or for entities in general?
BTW the pattern of a bundle config entity being powered by a plugin is the one we're using in Flag.
Comment #4
larowlanYeah all of them
#2570593: Allow entities to be subclassed using "bundle classes"
Comment #19
quietone commentedThe Contact Module was approved for removal in #3476879: [Policy] Move Contact module to contrib.
This is Postponed. The status is set according to two policies. The Remove a core extension and move it to a contributed project and the Extensions approved for removal policies.
The deprecation work is in #3520460: [meta] Tasks to deprecate the Contact module and the removal work in #3520466: [meta] Tasks to remove Contact module.
Contact will be moved to a contributed project after the Drupal 12.x branch is open.
Comment #21
andypost