3

I know very well how hook_form_alter() is working in Drupal 7 and in Drupal 8, but the main topic here is how to do things OOP way.

How would you solve the following problem the OOP way?

Suppose you have a random form, for example the user login form.

  • custom_module_A adds a checkbox to the form and a custom validation handler
  • custom_module_B adds a textfield to the same form and another custom validation handler

The OOP way of altering the form is:

  1. intercepts the original UserLoginForm and directs to a CustomModuleNewForm- an extended class from user_login_form class
  2. Write a class that extends the user login form

I am unable to "grokh" how this can be solved the OOP way, by extending the form in custom_module_A and not having custom_module_A as a dependency for custom_module_B.

Basically, I am looking for OOP hook_form_alter() replacement.

Improve this question
1
  • I don't think that you can do this without making module A a dependency of module B. But if you figure out a way, I'm definitely interested in seeing it.
    – Jaypan
    Apr 6, 2017 at 13:20

3 Answers 3

Reset to default
4

Good question. The alter hooks will eventually be replaced, not by extending form classes, but by symfony events. Events are coded in OOP and they have a proper priority handling. See https://www.previousnext.com.au/blog/alter-or-dispatch-drupal-8-events-versus-alter-hooks

Improve this answer
1
  • Thanks a lot for the answer. While I didn't exactly get a concrete example it helped me find a resourse I am going to share in a bit.
    – Oleg Videnov
    Apr 6, 2017 at 13:07
2

A way to do it is with this module.

https://www.drupal.org/project/hook_event_dispatcher

I still have to test it in detail.

Another interesting resource I've found. https://www.sitepoint.com/drupal-8-hooks-symfony-event-dispatcher/

Improve this answer
2
  • 2
    The module is good for demonstration purpose, but doesn't help much in the priority handling, because it is using the original alter hooks to dispatch the events and so can't control the order of form alter hooks from other modules. So we have to wait until the form api is changed from a hook to a event system. On the client side of the api you don't have much of a choice.
    – 4uk4
    Apr 6, 2017 at 13:30
  • Good point @4k4, I didn't think about that. This kind of system would indeed work only if hook_event_dispatcher is the only module that implements alter hooks. So If I understand correctly the "proper" solution here would be to add the code inside those alter hooks (the hooks inside hook_event_dispatcher) into the appropriate core files.
    – Oleg Videnov
    Apr 6, 2017 at 13:46
1

Since Drupal 8 is still using hook_form_alter() and hook_form_FORM_ID_alter(), altering a form just using a class is not yet possible. Allowing all the modules to change the class associated to a form is a bad idea, since that would just create conflicts between modules that are not that easy to resolve, if not by using complicated if() statements to verify which module has earlier replaced the class handling the form. Plus, there would be a conflict with Drupal core, which still allow modules to use hook_form_alter() and hook_form_FORM_ID_alter().

As 4k4 said, the right direction is using events, but for that we need to wait for a future Drupal version, which will probably replace hooks with events and event handlers. (I am not sure all the hooks are going to be replaced, thought; maybe the alter hooks will be kept, even if I hope we are going to use just events and event handlers, which are more OOP than the actual code.)

Drupal 9 didn't replace hooks with events; hook_form_alter() is still the way to alter forms implemented by other modules.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.