Enabling i18n modules fail in install profile

Confirmed. Having the same problem...

I also need at least one module in the profile to trigger this bug. I'm attaching a minimal installation profile that triggers the bug, when installed with drush si.

The profile depends on i18n_block and i18n_node and contains a module that implements hook_node_info() to declare a single content-type.

This seems to be a regression that was introduced with http://drupalcode.org/project/i18n.git/commit/c27323d (found with git bisect).

Here's a patch that should fix those errors. The problem was that the drupal_static cache for i18n_object_info() wasn't emptied when new submodules of i18n were enabled. So even though some hooks from i18n_node were called i18n_object_info() didn't know about i18n_node which lead to the bug.

The patch adds drupal_static_reset() calls so that i18n_object_info() always sees the current set of modules.

#4: 1681414_static_reset_in_hook_install.patch queued for re-testing.

trying again with correct version.

#4: 1681414_static_reset_in_hook_install.patch queued for re-testing.

This patch worked perfectly for me. The coder module does not raise any new issues and a test-site on the same platform (using i18n) did not break ;)

The patch contains whitespaces, those should be fixed first

+++ b/i18n_block/i18n_block.installundefined
@@ -18,6 +18,8 @@ function i18n_block_install() {
+  ¶

Whitespace

+++ b/i18n_field/i18n_field.installundefined
@@ -13,6 +13,8 @@ function i18n_field_install() {
+  ¶

Whitespace

+++ b/i18n_string/i18n_string.installundefined
@@ -28,6 +28,8 @@ function i18n_string_install() {
+  ¶

Whitespace

+++ b/i18n_taxonomy/i18n_taxonomy.installundefined
@@ -20,6 +20,8 @@ function i18n_taxonomy_install() {
+  ¶

Whitespace

Patch without whitespace.

Great! (it will come green I presume)

Thanks to both of you!

@swentel: Did you use a tool to find and document the whitespaces in the patch? I tried drupalcs now, which can check the coding standards in the patched files, but not in the patch itself...

@Nebel54 - http://drupal.org/project/dreditor

#12: static_reset.patch queued for re-testing.

I think its better to reset i18n_object_info in a central location rather then any module that implements hook_i18n_object_info.

@torotil: I tested this patch with your i18n installation profile.

Oh yeah, that's much cleaner!

Committed the last patch. Commit 659c880 on 7.x-1.x

Thanks!

Ah, i just had this issue, updated to latest version and fixed.
Life can be good :)

Thanks!
tom

Seems to be a regression bug here.

Using i18n 7.x-1.10 and Drupal 7.26

I have install profile with:

dependencies[] = block
dependencies[] = contextual
dependencies[] = dashboard
dependencies[] = help
dependencies[] = image
dependencies[] = list
dependencies[] = menu
dependencies[] = number
dependencies[] = options
dependencies[] = path
dependencies[] = taxonomy
dependencies[] = dblog
dependencies[] = shortcut
dependencies[] = toolbar
dependencies[] = overlay
dependencies[] = field_ui
dependencies[] = file
dependencies[] = ctools
dependencies[] = variable
dependencies[] = variable_admin
dependencies[] = token
dependencies[] = i18n
dependencies[] = i18n_string
dependencies[] = i18n_block
dependencies[] = i18n_contact
dependencies[] = i18n_field
dependencies[] = i18n_menu
dependencies[] = i18n_node
dependencies[] = i18n_path
dependencies[] = i18n_redirect
dependencies[] = i18n_variable
dependencies[] = strongarm
dependencies[] = features
dependencies[] = link
dependencies[] = page_title
dependencies[] = googleanalytics
dependencies[] = page_manager
dependencies[] = panels
dependencies[] = panels_ipe
dependencies[] = panelizer
dependencies[] = pathauto
dependencies[] = xmlsitemap
dependencies[] = xmlsitemap_engines
dependencies[] = xmlsitemap_i18n
dependencies[] = xmlsitemap_menu
dependencies[] = xmlsitemap_node
dependencies[] = wysiwyg
dependencies[] = globalredirect
dependencies[] = link
dependencies[] = file_entity
dependencies[] = media
dependencies[] = media_internet
dependencies[] = mediafield
dependencies[] = media_youtube
dependencies[] = media_vimeo
dependencies[] = tablefield
dependencies[] = nodeblock
dependencies[] = multiple_node_menu
dependencies[] = menu_block
dependencies[] = ckeditor_styles
dependencies[] = transliteration
dependencies[] = metatags_quick
dependencies[] = metatags_quick_extra
dependencies[] = date
dependencies[] = date_api
dependencies[] = date_popup
dependencies[] = scheduler
dependencies[] = menu_attributes
dependencies[] = manualcrop
dependencies[] = jquery_update
dependencies[] = view_unpublished
dependencies[] = views
dependencies[] = views_ui
dependencies[] = robotstxt
dependencies[] = rules
dependencies[] = rules_admin
dependencies[] = rules_i18n

And I get this error when installing a new site:

An AJAX HTTP error occurred. HTTP Result Code: 200 Debugging information follows. Path: http://mysite.local/install.php?profile=myprofile&locale=en&id=1&op=do StatusText: OK ResponseText: ( ! ) Fatal error: Call to undefined method i18n_object_wrapper::strings_update() in /var/www/drupal/sites/all/modules/contrib/i18n/i18n_string/i18n_string.module on line 851 Call Stack #TimeMemoryFunctionLocation 10.0001656328{main}( )../install.php:0 20.00241317408install_drupal( )../install.php:26 30.128313459328install_run_tasks( )../install.core.inc:77 48.6445101120752install_run_task( )../install.core.inc:339 58.6454101291040_batch_page( )../install.core.inc:449 68.6461101325832_batch_do( )../batch.inc:80 78.6461101325832_batch_process( )../batch.inc:161 89.0692104095936call_user_func_array ( )../batch.inc:284 99.0692104096008_install_module_batch( )../batch.inc:284 109.0692104096520module_enable( )../install.core.inc:1595 119.3863105063760module_invoke_all( )../module.inc:499 129.3872104773672call_user_func_array ( )../module.inc:895 139.3872104774160entity_modules_enabled( )../module.inc:895 149.3927104985384_entity_defaults_rebuild( )../entity.module:956 159.5934110538656module_invoke_all( )../entity.module:945 169.5937110543648call_user_func_array ( )../module.inc:895 179.5937110544264rules_i18n_rules_config_defaults_rebuild( )../module.inc:895 189.5937110545744rules_i18n_rules_config_insert( )../rules_i18n.module:126 199.5937110545888i18n_string_object_update( )../rules_i18n.module:69

The i18n.module file cotains the patch:

/**
 * Implements hook_modules_enabled().
 */
function i18n_modules_enabled($modules) {
  drupal_static_reset('i18n_object_info');
}

+1 to @jjsuo

I can confirm the above two reports that this is still failing in certain conditions. Reopening the issue.

Replicating the problem

A simple way to replicate this issue is to make an install profile containing i18n_field, i18n_string and the Message module. When this install profile is enabled the following error occurs:

Error: Call to undefined method i18n_object_wrapper::strings_update()
in
/var/sites/ip-10-58-55-202.eu-west-1.compute.internal/bdf1f/sites/all/modules/paddle/i18n/i18n_string/i18n_string.module,
line 851 [241.19 sec, 110.42 MB]

Short summary of why this is still failing

If a module that uses an i18n object in its hook_install() or hook_enable() phase is enabled at the same time as the module that provides the object the error occurs. The current fix resets the i18n_object_info cache too late.

The gory details

Let's use the Message module as an example. In message_install() a field is created:

function message_install() {
  // Create the field holding the message text.
  ...
  $field = field_create_field($field);
  ...
}

1. If we now enable this module at the same time as the i18n_field and i18n_string modules module_enable() will loop over the modules that need to be enabled, and will enable the i18n modules before the Message module because of the alphabetical order.
2. The functions and hooks of the i18n modules will become available as soon as they are enabled, but the i18n objects on which they depend will not. Currently the i18n_object_info cache is cleared in hook_modules_enabled() which only runs after all modules have been enabled.
3. Next in line to be enabled is the Message module. It calls field_create_field() (see code snippet above).
4. During the creation of the field i18n_field_field_create_field() is invoked, which in turn calls i18n_field_field_update_strings(). Both of these hooks have been enabled just prior.
5. i18n_field_field_update_strings() calls i18n_string_object_update() which relies on the object, but since the i18n object cache has not been reset yet this doesn't yet contain the object. Kapow, fatal error.

Solution

The solution is to clear the object cache during hook_enable() rather than in hook_modules_enabled(). Earlier iterations of the patch took this approach (ref #12), but used hook_install() instead which is problematic as the fatal error might reoccur after disabling a module, clearing the cache, and then enabling it again.

This earlier approach was rejected in #19 and replaced with the current approach because it is cleaner and results in much less code, but unfortunately it does not cover this particular use case if the object being used during hook_enable() or hook_install().

I suggest we still keep the original patch in because otherwise we would break contrib. Third party modules that provide i18n object are not yet using this fix, so they would at least still have partial protection against this bug with the original approach. It would be good to make followup issues in third party modules to notify them of the problem.

Patch coming up in a few minutes.

So, apparently it is illegal to upload a patch called "*install.patch", renaming and giving it another shot.

I reviewed this patch and it fixed the issue.

Full disclosure: Me and pfrenssen work together, and we needed this fix because our Simpletests failed to start because of this issue.

I installed the patch, but I still got the same error. Is there anything else I need to do?

I've just applyied the patch and apparently this solved my same issue! Thanks for the patch!

Drupal 7.31
i18n 7.x-1.11

When installing a module these are the hooks invoked in order:

1. hook_install()
2. hook_enable()
3. hook_modules_installed()
4. hook_modules_enabled()

Flushing the cache in hook_modules_enabled() might simply be too late for some cases. The only way to be sure that the cache is flushed in time is to do it either in hook_install() or hook_enable() - depending on the module's needs.

hook_modules_installed() might be fine too with a sufficiently low module weight or a hook_module_implements_alter() that gets sure that the cache is flushed before any other hooks are called.

Also I'm wondering if this isn't something that drupal core should or would take care of. I guess it's a common need to refresh static caches during module_enable().

Since I'm not seeing any better option as described thoroughly in #26, I'm setting this to RTBC.

Honestly, I appreciate all this thorough research, but this is just too ugly, and also not a generic solution if any module implementing this hooks needs to do the same, I don't feel like committing it..

There should be some better solution.

Just wondering... but there are a lot of things going on after each module is enabled, can't we find a better place to do the static clean up? For instance, wouldn't it make sense/work to rebuild it after hook_entity_info() is invoked? or module_implements_alter... or anywhere..

See https://api.drupal.org/api/drupal/includes%21module.inc/function/module_...

Please, tell me there's some better solution for this issue... :-/

I think that the only proper solution is to patch core's module_enable function to do a global drupal_static()-reset before calling the install method of the module.

There was also a similar issue for payment and I'll bet i18n and payment are not the only modules. Maybe together we can build enough momentum to get that fixed in D7.

Possibly related: #1891356: D7: Reset drupal static caches when a module is enabled or disabled. #2403851: Drupal Commerce is broken with Rules 7.x-2.8 #2352739: Reset static caches on module enable/disable. and so on.