In practice we find that intra development updates are not supported except by following instructions similar to #379854-128: The site map is not being populated. IMO, we should remove this module completely.

CommentFileSizeAuthor
#9 issue-456736.patch1.14 KBAnonymous (not verified)
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

apaderno’s picture

I can find a reason to keep a shell module, for the moment.
If we would simply remove the files, there could be somebody who would have the old files with the full uninstall function (it's already happened, even if the instructions suggest to completely remove the old files); if the user would uninstall xmlsitemap_term.module, xmlsitemap_taxonomy.module would stop to work because it doesn't find its database table.

Anonymous’s picture

if the user would uninstall xmlsitemap_term.module, xmlsitemap_taxonomy.module would stop to work because it doesn't find its database table.

Huh? If the user follows the instructions xmlsitemap_taxonomy would install the xmlsitemap_term table again. I suppose 5.x-2.x upgrade could be an issue? We should add a step to xmlsitemap_taxonomy.install to remove the entry from the system table. However, I don't think we want to keep the shell xmlsitemap_term module.

apaderno’s picture

What I meant is that the user updates to the latest version (therefore, xmlsitemap_taxonomy.module doesn't install anything), and then he uninstalls xmlsitemap_term.module (which, for some unknown reasons is the version containing the full uninstall code), then xmlsitemap_taxonomy.module would stop to work.

My assumption here is that when we remove the files there is a higher probability the user still has the old file (it should not happen, or happen in rare circumstances); not removing the files, but simply removing the code from them, would avoid that circumstance.

I am not saying that the shell module will be keep for too long.

EDIT: It's not the right day to write in English, today; I should rather try in...

Anonymous’s picture

I am saying that it's too confusing, isn't needed and your scenario should never happen if the instructions are followed. Dave, can you weigh in here please?

apaderno’s picture

Never say never.
There are issues that should have been happened, but still some users reported errors about function that were present, but Drupal was not able to find them (and the code calling them was not executed in hook_init(), or hook_exit() hooks).

The module is reported to be deprecated (as visible in the modules page), and the code disables it. If then a user would uninstall it, he would not cause damage because the uninstall code has been removed.

Anonymous’s picture

You know, this scenario fits the one that Drupal had when in D5 there is a watchdog module that was renamed to dblog in D6. The table remained named watchdog. There is no watchdog shell module to protect the innocent from not following the instructions.

apaderno’s picture

I didn't say it should be left there for many time. The comparison made doesn't fit our case because in the Drupal case the change has been done in the passage from Drupal 5 to Drupal 6; we are making a module exchange staying on Drupal 6.

Anyway, I am fine with, or without the shell module. I have been asked why there was a module shell, and I replied. So far, I have not heard any good reason to not keep it until the first release candidate.

apaderno’s picture

Status: Active » Fixed

The empty module is not present anymore.

Anonymous’s picture

FileSize
1.14 KB

I added the attached patch to this issue.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.