Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Problem: Because this module uses HOOK_form_alter to modify the NODETYPE_node_edit form, and because uniqueness happens to be alphabetically high, the alter function runs AFTER most other module's alter functions. This makes it impossible to use a form_alter function to affect what uniqueness injects into the form. The workaround for this is quite awkward -- use an alter to set an after_build function and modify the form in the after_build. This can have unforeseen consequences on the form element's build id's if the changes are enough that the element needs to be rebuilt.
Solution: The alternative is simple: Instead of merely injecting new form elements, add form elements to anything already in the form (which may have been placed there by another module, either in the form definition or an alter that runs earlier).
Use case: I use this to customize the form based upon content type, although this could be used for other things, including considering the content of the node itself.
// In your form definition or _form_alter:
if (module_exists('uniqueness')) {
$form['uniqueness']['#title'] = t('Blah Blah Blah with similar names');
}
Patch coming....
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | uniqueness-edit_form_alter-1893280-1.patch | 1.14 KB | danchadwick |
Comments
Comment #1
danchadwick commentedComment #2
bforchhammer commentedYou can usually affect the order of hook invocation by adjusting your module's weight (increase it to run later) or implementing hook_module_implement_alter() (see example on API page).
Comment #3
danchadwick commentedPS Thank you for your nearly-instantaneous commits and pushes.
Comment #4
danchadwick commentedYes, I am aware of this, but it is fraught with danger. One's module may need (for other reasons) to be run early or late. Editing the order in which it runs opens the possibility of third-party module interactions (Module A changes order that Module B runs; Module C is affected).
What I am proposing is both simple and has the advantage of a) not requiring using module weights or editing the alter groups and b) works whether the code runs before or after uniqueness.
Comment #5
bforchhammer commentedI agree it's not ideal, but I think it's fairly unlikely that you have more than one module trying to adjust the uniqueness part of the node form. So
hook_module_implements_alter()actually looks fine to me. That's also the solution I've seen being used in other modules... (considering that it's on the core API docs, one could argue that's it's an accepted pattern for this type of thing).Either way, what is it that you're actually trying to adjust? If it's just the title we could probably also introduce a respective alter hook for you to implement. Adding the content type name into the title sounds like something that others may want to do as well. (e.g. "Articles with similar title" instead of "Related content").
You're very welcome! Thanks for putting your time into improving the module!
Comment #6
danchadwick commentedIt's not that more than one module may want to change uniqueness, but that changing the order of uniqueness may affect another module which is depending upon it's order relative to uniqueness. I currently have needs to be both early and late (for various other reasons). I'm trying to work through all the places where I need to be late and address them otherwise so as to insulate myself from these ordering problems.
What we are essentially talking about is altering another alter. This is in general not a good idea. The beauty of my proposal is that the order doesn't matter!
Yes we could introduce a uniqueness_alter, but that seems like overkill.
Yes, one of the things I am changing is node-type-specific title. We discussed adding this to the UI (and we still could), although the UI is a little complex because each content type needs two form elements: a) Want to override the general description? and b) what node-type-specific description do you want. A bit ugly. The alternative is to just default what every content type gets, but then once you've customized it, you can't "uncustomize" it without editing the variable table.
I *was* also changing the themed output. Because modules can't directly override theme functions, I've now gone to the trouble of implementing HOOK_registry_alter so that I can insert my module's replacement theme function for uniqueness's. Another module developer might not be so motivated.
So I suggest that we do this simple change to give module developers flexibility at essentially no complexity or execution cost, even if something additional is done later. I believe that *adding* to a form element in an alter is always the correct design pattern (just as one would when adding, for example, a submit handler).
Comment #7
bforchhammer commentedI'm still not 100% sure I understand why it's so bad to change the execution order for that one hook and your module, but it's a fairly simple change that shouldn't hurt, so I have now committed a slightly adjusted version of the patch above...