I understand the desire to move folks to the include_condition argument in a standard use of the add_to_serializer method, i.e. to add their own methods to serializers.
However there are some instances in which a plugin may want to add an include_* method to a serializer that don’t match that case, i.e. when you’re not determining whether your own custom attribute is included, but you’re overriding an include_* method in a core serializer, e.g.
I appreciate that that particular use could be re-thought to not require an override of the site serializer method, or the override could be achieved in other ways, but I’m wondering whether there’s an inherent downside in allowing such use of the add_to_serializer method in this way, and whether the deprecation will lead to a removal of the use of the method in this way.
We’ve recently introduced a new system for ‘plugin modifiers’, which are super cheap extension points which are similar to DiscourseEvent but they take an input value and return a value. So in your case, you could make a core PR to add a DiscoursePluginRegistry.apply_modifier call in the relevant include_ method, and then you can use register_modifier in your plugin to override the value.
It’s likely we’ll eventually block it completely, yes. Plus you really don’t want to be using a method that’s printing deprecation noise in the logs.
If you really must override a method without co-operation from core, then modify_class would seem to be the better choice. The main reason we have a dedicated add_to_serializer is because it auto-defines an include_* method so that it only applies when the plugin is enabled.
That means that the code snippet you linked is currently defining two methods. include_wizard_required? and include_include_wizard_required?