Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Yes, I wondered the same. That's why I said it's a way to fix it, among others. It may not be the best. In any case, Title should not alter the way the label is generated when default title field is not overridden. This is true for i18n_taxonomy, but potentially for other modules too.
At least Title should do more checks before it changes the label callback, to do it only if really needed.
Decreasing module weight might be another way? So that i18n_taxonomy_entity_info_alter() is called after title_entity_info_alter()?
Actually, it looks like this kind of "hook competition" problem can only be solved on an individual case basis.
Actually, it looks like this kind of "hook competition" problem can only be solved on an individual case basis.
Yes, I am afraid we cannot escape from a certain level of "structural" incompatibility. Anyway you solution might be good after all if we "standardized" it somehow:
+++ b/title.module
@@ -69,6 +69,10 @@ function title_entity_info_alter(&$info) {
+ if (isset($info[$entity_type]['label callback'])) {
+ $info[$entity_type]['label fallback'] = $info[$entity_type]['label callback'];
This way we could have a sort of label callback chain where every element would be responsible for a single fallback. Btw, Title is very likely to be the last module altering entity info since it has a very low weight and it does http://drupalcode.org/project/title.git/blob/refs/heads/7.x-1.x:/title.m....
Minor:
+++ b/title.module
@@ -69,6 +69,10 @@ function title_entity_info_alter(&$info) {
+ // Store the original label callback for compatibility reasons (i18n_taxonomy etc.).
Let's skip the example to fit into the 80 chars :)
Comments
Comment #1
GaëlGTitle and i18n taxonomy modules both use hook_entity_info_alter() to change the label callback. Here's a way to fix the problem.
Comment #3
plach#1: i18n_taxonomy_compatibility-1865604-1.patch queued for re-testing.
Comment #4
plachWouldn't it be simpler to just skip registering the label callback if there is already one defined?
Comment #6
GaëlGIt's simpler but I'm not sure it fits every context. It would make Title unavailable for any bundle already having a label callback.
Comment #7
plachSorry, I missed that the patch is calling the fallback function only when fields are not replaced.
Anyway, I'm not sure about generalizing this approach: what if another module had the same need? Should it define a 'label fallback fallback' key?
I don't feel strong about this, but perhaps I'd prefer something dealing explictly with i18n. Related issue: #1661348: I18n Taxonomy integration.
Comment #8
GaëlGYes, I wondered the same. That's why I said it's a way to fix it, among others. It may not be the best. In any case, Title should not alter the way the label is generated when default title field is not overridden. This is true for i18n_taxonomy, but potentially for other modules too.
At least Title should do more checks before it changes the label callback, to do it only if really needed.
Decreasing module weight might be another way? So that i18n_taxonomy_entity_info_alter() is called after title_entity_info_alter()?
Actually, it looks like this kind of "hook competition" problem can only be solved on an individual case basis.
Comment #9
plachYes, I am afraid we cannot escape from a certain level of "structural" incompatibility. Anyway you solution might be good after all if we "standardized" it somehow:
We could have:
This way we could have a sort of label callback chain where every element would be responsible for a single fallback. Btw, Title is very likely to be the last module altering entity info since it has a very low weight and it does http://drupalcode.org/project/title.git/blob/refs/heads/7.x-1.x:/title.m....
Minor:
Let's skip the example to fit into the 80 chars :)
Not sure why tests are failing.
Comment #10
GaëlGAll right. Like this?
Comment #11
plachCommitted and pushed with minor changes, thanks.