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.
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.
Comment | File | Size | Author |
---|---|---|---|
#9 | issue-456736.patch | 1.14 KB | Anonymous (not verified) |
Comments
Comment #1
apadernoI 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.
Comment #2
Anonymous (not verified) CreditAttribution: Anonymous commentedHuh? 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.
Comment #3
apadernoWhat 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...
Comment #4
Anonymous (not verified) CreditAttribution: Anonymous commentedI 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?
Comment #5
apadernoNever 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()
, orhook_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.
Comment #6
Anonymous (not verified) CreditAttribution: Anonymous commentedYou 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.
Comment #7
apadernoI 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.
Comment #8
apadernoThe empty module is not present anymore.
Comment #9
Anonymous (not verified) CreditAttribution: Anonymous commentedI added the attached patch to this issue.