Closed mstrelan closed 8 years ago
Yeah I agree that we do it with an update hook. I think that we'd also have to keep pathauto_persist in the codebase for at least one release until we could be assured that everyone has had the opportunity to uninstall the module.
Could we follow a similar approach to that in #50 whereby we disable/uninstall pathauto persist (and remove it from the list of modules allowed to be enabled) in an update hook in one release. Then, in a following release we can remove it from the repo.
I don't think module_uninstall() exists. This also wouldn't cover the case where someone updates two versions in one hit.
We'd have to use drupal_uninstall_modules()
. For the govCMS platform, each site would be updated concurrently so no site would miss an update.
You'll also have to make sure pathauto_update_7006() runs before the govcms_update_N() function.
For the govCMS platform, each site would be updated concurrently so no site would miss an update.
Theoretically anyone can download the installation profile from drupal.org and update as they please, so I guess it depends if you want to support that or not.
Pathauto 7.x-1.3 now includes the functionality of Pathauto Persistent State which is now obsolete. We should update to the latest version.
I'm not sure what to do about removing the old module from govCMS. The pathauto update safely migrates the pathauto_persist data and disables the module, but it doesn't uninstall it. If you simply remove the module then you can't uninstall it. Perhaps manually uninstall it via a hook_update_n() in one of the govcms modules?