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.
I've just updated i18n to 7.1.3 and I now have a WSOD when I try to edit a node.
I tried to reproduce in a fresh new drupal 7 install :
- I create a vocabulary in my fresh default install
- I attach a "term reference" field to article content type
- I add a term "foo" to the new vocabulary
- I add an article "bar" and set the "foo" term to it
- I download and enable i18n and i18n_taxonomy
- Then I don't touch anything but I disable i18n_taxonomy
- I try to edit my article "bar" and I have a WSOD due to "Call to undefined function i18n_taxonomy_allowed_values()"
After that the only way I found to no longer have the WSOD is to remove the "term reference" field attached to the article content type.
I set priority to critical because if anyone have enabled i18n_taxonomy once and decided to disable it, it will break the site.
Comments
Comment #1
nikosnikos CreditAttribution: nikosnikos commentedIn fact I think that there's two cases.
The first case is due to
i18n_taxonomy_disable
, it usesfield_update_field
to update the field butfield_update_field
uses the prior field values for 'settings' (from wherei18n_taxonomy_allowed_values
is called) :The second case is due to
i18n_taxonomy_update_7002
that addi18n_taxonomy_allowed_values
callback to the taxonomy fields even if i18n_taxonomy module is disabled. It could be fixed with a condition likeif (function_exists('i18n_taxonomy_allowed_values'))
:Comment #2
nikosnikos CreditAttribution: nikosnikos commentedActually there's a simple patch to fix that.
If the patch work, if you have the WSOD and want to get your site back without i18n_taxonomy :
Comment #3
webflo CreditAttribution: webflo commentedAssigning to me for review.
Comment #4
webflo CreditAttribution: webflo commentedComment #5
webflo CreditAttribution: webflo commentedAdded a regression test.
Comment #7
webflo CreditAttribution: webflo commented#5: undefined-function-i18n_taxonomy_allowed_values-1410070-5.patch queued for re-testing.
Comment #9
webflo CreditAttribution: webflo commented#5: undefined-function-i18n_taxonomy_allowed_values-1410070-5.patch queued for re-testing.
Comment #11
webflo CreditAttribution: webflo commentedComment #12
webflo CreditAttribution: webflo commented#5: undefined-function-i18n_taxonomy_allowed_values-1410070-5.patch queued for re-testing.
Comment #13
webflo CreditAttribution: webflo commentedComment #14
webflo CreditAttribution: webflo commentedThanks! Commit 6c71e27 on 7.x-1.x
Comment #15
ytsurki disabled i18n on a website in BETA ..,
and added this if to fix the issue ..
how could i delete the field-setting from the DB without re-enabling and disabling he patched module ?
Comment #16
webflo CreditAttribution: webflo commentedDownload the latest i18n dev. Enable and disable i18n_taxonomy again. This should fix the issue. Your core hack is not right ...
Comment #17
nikosnikos CreditAttribution: nikosnikos commentedCool ! The patch applied in dev fix the first case described in #1. But the committed patch don't fix the second case of that issue.
Test case :
drush dl i18n-7.x-1.2
drush en i18n_taxonomy
drush dis i18n_taxonomy
drush dl i18n --dev
drush updatedb
Here's a possible patch on dev version.
ytsurk if i18n_taxonomy isn't uninstalled (just disabled), you can fix the issue by applying the patch to dev version of i18n and do an updatedb.
Comment #18
nikosnikos CreditAttribution: nikosnikos commentedOops ! I forgot the patch... Here it is.
Comment #19
nikosnikos CreditAttribution: nikosnikos commentedAnd I forgot to change the status too...
Comment #20
webflo CreditAttribution: webflo commentedBut hook_update_N() is called for active (enabled) modules only. Right?
Comment #21
nikosnikos CreditAttribution: nikosnikos commentedThis is not clear in api documentation but in my test in #17
the update is applied on i18n_taxonomy when it is disabled but not uninstalled.
If I look in drupal core code, the
update_get_update_list
which is called byupdate.php
perform the update on any installed schemas :So it seems to me that
hook_update_N()
is called if a module is installed, this module can be enabled or disabled there's no check on this.Comment #22
ytsurkagree .. ;)
just wondered if there would be some known rows to delete from the DB.
Comment #23
webflo CreditAttribution: webflo commented@ytsurk: this setting is serialized in {field_config}.data and {field_config_instance}.data
Comment #24
Jose Reyero CreditAttribution: Jose Reyero commentedCommitted the patch with some changes (reusing i18n_taxonomy_disable())
Comment #26
BParticle CreditAttribution: BParticle commentedI tested the patches in this thread without success. I tried it on the development branch and the latest dev version, database update is not doing anything though. But I still get this WSOD. When I put error messages on in index.php it says:
Fatal error: Call to undefined function i18n_taxonomy_allowed_values() in /var/www/my-site/modules/taxonomy/taxonomy.module on line 1485
Comment #27
BParticle CreditAttribution: BParticle commentedComment #28
BParticle CreditAttribution: BParticle commentedI can't get my head around this one. This problem appears when reverting a features that has content types with multiple taxonomy terms. I tried to just remove all references to i18n, but the problem persists. Another clue I get from drush is the following:
Creating default object from empty value entity.module:825
Never saw that before and I don't know if it is related, but it started showing when I got this blank screens problem.
Hope someone out there has a solution or something to go on!
BP
Comment #31
minorOffense CreditAttribution: minorOffense commentedUpdate patch to apply to latest dev.
Comment #32
Kristen PolI tried to reproduce this issue with the instructions in the issue summary but had no luck. If someone has been able to reproduce this recently and the instructions are different from the issue summary, please update the issue summary with the correct steps. Thanks!
Comment #33
Kristen Pol@minorOffense I'm not clear why you have your code in a
hook_update_N
function. This will get called if update.php (or drush updatedb) are called prior to the module being disabled as well, e.g.Are you covering the case when hook_disable wasn't fired properly for some reason but the module is disabled? Thanks!
Comment #34
minorOffense CreditAttribution: minorOffense commentedI was just fixing an early patch in comment https://www.drupal.org/node/1410070#comment-5503344 to work against the latest dev.
Comment #35
minorOffense CreditAttribution: minorOffense commentedYou're right though. The fix should detect a version of something or whether it ran at all.
Comment #36
Jose Reyero CreditAttribution: Jose Reyero commentedI don't think this issue exists anymore.
Maybe only for sites where i18n_taxonomy was disabled before the patches above were applied?
The easy workaround may be just enabling/disabling i18n_taxonomy again.
Comment #37
leistiko_texvet CreditAttribution: leistiko_texvet as a volunteer commentedI was getting this error and stumbled across this comment thread. #36 tipped me off to (what turned out to be) the easy-peasy solution (in my case).
Enable the "Translation" and "Taxonomy Translation" modules.
I hope this helps some people in the future.
Comment #38
jasonglisson CreditAttribution: jasonglisson commentedApplying the patch (#31) and turning on Taxonomy Translation worked for me.