Upgrade path for new submodule names is broken

I have marked #595394: Module name conflict as duplicate of this report.

I will change the modules name to the correct names; I will also add code to change the information contained in the database table used by Drupal.

Are there any further steps that need to be taken, to be sure the modules status is kept, after they are renamed?

Subscribing

The last committed code changed the name of the modules, and this morning I removed the SQL query that was trying to update the module data contained in the system table.

The translation templates, and the translation files need to be updated, as their content is not synchronized with the code developed until now; it's not just a question of file names.

That is a different issue, anyway.

I have already tried that, but the code failed because Drupal was creating table rows for the new modules; that is why I dropped that code.

What I mean is that I implemented the code to update the existing rows in the table system (the first implementation contained a syntax error in the SQL query, so it didn't updated the data), but the update functions failed because a duplicate rows error.

The code should then update the information Drupal grabs from the file .info.

I will check about this part of the code, but at the actual state nothing is being lost.

I can change the status of this report, as the code has been already changed.

The update hook needs a drupal_set_message() to people re-enabling the submodules manually is required.

Which is what the code I before implemented did, but somebody (without to say exactly who is) suggested that it was the wrong method, and that he didn't want to manually enable the new module (I am still not saying who this person is).

To notice that nodewords.module has code to verify if there are any modules implementing meta tags, and in hook_requirements() it emits an error message if there are not such modules; schema version, and module weight are automatically set once the new modules have been enabled (the modules are really being installed, and there are no wonders such metadata are updated).

I have never changed a module name myself for the reason that I know the naming rules.

I remember also that you were trying to pass plain text, not handled as HTML through check_plain(). We are not talking of what you know, so let's move on that topic.

nodewords_basic_update_6104() is not executed inside hook_install.

That is perfectly normal; as that is an update function, it doesn't need to be executed during installation phase.

So on - this obsolete code needs to be removed.

See what reported in http://api.drupal.org/api/function/hook_update_N/6:

A good rule of thumb is to remove updates older than two major releases of Drupal.

That makes sense.
The code would call module_enable() for all the modules that handle the meta tags found in the database; the function would enable only the modules that are not already enabled, and that would help in simplifying the code, which doesn't need to verify if the module is already enabled, or not.
It could be possible to do it only for the modules of the Nodewords project, but that would be enough.

I am just wondering if it would work; if we cannot rely on the field status, how can we rely on code that checks the value of that field?

This logic will not rely on system table

As the module enables a module, it needs to call module_enable(), which in turn checks the table system.

function module_enable($module_list) {
  $invoke_modules = array();
  foreach ($module_list as $module) {
    $existing = db_fetch_object(db_query("SELECT status FROM {system} WHERE type = '%s' AND name = '%s'", 'module', $module));
    if ($existing->status == 0) {
      module_load_install($module);
      db_query("UPDATE {system} SET status = %d, throttle = %d WHERE type = '%s' AND name = '%s'", 1, 0, 'module', $module);
      drupal_load('module', $module);
      $invoke_modules[] = $module;
    }
  }
  // ...
}

If you are suggesting that the code should not call module_enable(), and not use the table system too, then I don't know how that can be accomplished.

I will test the code by installing nodewords 6.x-1.0, and updating it to 6.x-1.x-dev.
The code to test doesn't change the content of any tables used from the module, so it would be easy to be checked.

I have tested the update from 6.x-1.0, and I have not seen any problem, probably because the test site I used didn't have a lot of nodes with meta tags (but then, I tested it after I removed the update functions that were used for intra-development updates -- see the latest commits).

I will try both the updates.

I have tested the proposed code, but it doesn't work.
The update function finds the meta tags, and enables the modules; when I visit the modules page, the modules that handle those meta tags are still disabled.

The code correctly detects the meta tags, and enables the correct module; the problem it's another one.

I would set the report as fixed; so far, we have tried different solutions, but none of them works. It would have been better if the modules had the correct name from the beginning; in this way, there would not be any worries to find a way to automatically enable those modules that handle the currently saved meta tags.

I thought I passed an array to module_enable(), but I could be wrong.

If I don't have time in the next 30 minutes to commit the code, then I will commit it when I return from a short trip (that means on Monday).

Looking forward to the next official release with this. I'm still getting support requests for site_verify.module wondering why the interface isn't showing up when they've in face only enabled the Meta tags 'Site verification' module. Arg.

The code has been changed, and committed in CVS.

If you're going to do a SELECT 1 query, make sure you use db_result(db_query_range("SELECT 1 FROM ...", $module_tags 0, 1));

If you're going to do a SELECT 1 query, make sure you use db_result(db_query_range("SELECT 1 FROM ...", $module_tags 0, 1));

That is right; differently the query is going to return a row for each meta tag found, which could be a lot of rows.
I have already changed the query to use COUNT(1), which surely returns a single row.

I am not going to change the string used as query from the update function because it is supposed to be a SQL string; I prefer to use a SQL query, or a pseudo SQL query.

Hi, I have site_verify module and after installing the most recent dev nodewords (first time, but I see now its dangerous on future updating), this gave a conflict:

Site verification meta tags Disable one of the modules in modules pageArray
You have enabled two modules with similar purpose: site_verify.module and nodewords_verification_tags.module.

This problem was not there and site_verification existed first, before this conflicting feature was incorporated into the nodewords module:
http://drupal.org/node/607744

So resolving this; in .../admin/build/modules ticking off the:
Site verification meta tags 6.x-1.x-dev
Define site verification meta tags required by some web sites (mainly from search engines) to verify a web site. Depends on: Nodewords (enabled)

I suppose this is the favorite way of doing so? Anyway: I just made this change. And site_verification is better than this feature under nodewords? Are there motives for getting rid of site_verification and use nodewords_verification? When and when not?

Then this explanation about the conflict and what to do lacks on the modules page of both modules (what gave reason why I had to research it through 3 different issues and posted this)

Then the naming is pretty confusing; in my modules list of .../admin/build/modules it is not grouped under the modules name Node Words, but under Meta tags. OK, I´m getting pretty experienced in finding submodules in a haystack (over 200 real modules installed), but fear this might be a problem to instruct other people in future who have to run these systems I'm building, about how to find a 'hidden' submodule.

P.S.: I'm sorry; changing the overall status; maybe change it back after reviewing, so this issue keeps archived correctly under the proper/old issue?

The module nodewords_verification_tags.module is enabled only if you already set verification meta tags through Nodewords, which is not something I would have suggested to do, if you had already a module to handle such meta tags. If you prefer to use the other module that is fine, but you should disable nodewords_verification_tags.module in that case.

All Nodewords modules are listed under the category Meta tags, without any exception.

The name of the project was not the best choice, but the module names cannot be changed without to cause more confusion; the name of the directory containing the project files cannot be modified, and looking for a module called metatags.module inside a directory nodewords is not something that would make many users happy.

The topic of this issue is the upgrade path for new submodule names, which was already fixed. Reopening this issue could make somebody think that the issue has not been resolved, which is not true.

I am restoring the original priority.