It looks like a module file gets included during uninstallation of a module, however at this point the dependencies might be already disabled too. This might lead to fatals when the module is making use of a class from the dependency, as it is the case for profile2 + entity see #1023526: Failure uninstalling Profile 2 if entity disabled.
I don't think drupal should ever include the .module file without the dependencies being met.
Comment | File | Size | Author |
---|---|---|---|
#88 | uninstall_ftl_aleph0.patch | 20.42 KB | chx |
#83 | uninstall-1029606-80.patch | 20.42 KB | catch |
#80 | uninstall-1029606-80.patch | 20.38 KB | David_Rothstein |
#74 | uninstall.patch | 19.61 KB | catch |
#73 | uninstall-1029606-73.patch | 20.26 KB | David_Rothstein |
Comments
Comment #1
rschwab CreditAttribution: rschwab commentedUninstall functions are always in .install files, right? If so, should drupal ever include a .module file when uninstalling, regardless of dependencies?
Comment #2
fago>If so, should drupal ever include a .module file when uninstalling, regardless of dependencies?
I don't know whether there is a cause to do so, but if it does it has to make sure dependencies are met.
I just ran over the issue another time with rules, see: #1019982: Uninstallation of rules fails
Comment #3
David_Rothstein CreditAttribution: David_Rothstein commentedInteresting bug. It looks like the offending code in drupal_uninstall_modules() is this:
Not really sure what to do about that off the top of my head. It's definitely problematic code.
Comment #4
catchIs that code even necessary? We already have:
in _menu_navigation_links_rebuild();
Comment #5
Damien Tournoud CreditAttribution: Damien Tournoud commentedIt looks to me like bad practice to have a class referencing the class of another module in a .module. Including a module file should be harmless, as much as possible.
Comment #6
Yaron Tal CreditAttribution: Yaron Tal commentedDon't you think you should be able to depend on a module if you say you do in your .info? Otherwise you'll have to put everything between if (module_exists()) statements which makes the dependencies statements in the .info useless.
I think #4 is right and the code isn't needed because the menu is rebuild anyway.
Comment #7
Damien Tournoud CreditAttribution: Damien Tournoud commentedClasses are autoloaded. The .module file should be loadable without side effect in any context. It has always be the case and should remain that way.
Comment #8
fago@damien:
Just because we can use autoloading for classes, it doesn't mean we have to.
>The .module file should be loadable without side effect in any context. It has always be the case and should remain that way.
While this makes sense, as module developer I'd expect my dependencies to be met when the module is included.
ad #3:
Ouch, so we even invoke code from an uninstalled module, for which the dependencies might not be met. Unfortunately the code in #4 relies upon $path being determined by that.
From a short look, I've seen that there is already a 'module' tracked for each menu item. However, its values seem to be only 'menu' or 'system', but not the module providing the menu item. So if we'd manage to properly track the source module for menu items, existing installs would need an update.
So what about another approach: Just join menu_router with menu_links to identify deprecated links?
Comment #9
fagook, let's see what the bot thinks of that.
Comment #10
catchSee #4, is that doing anything that menu_rebuild() doesn't do already?
Comment #11
fagoah! Sry I didn't realize this stems from _menu_navigation_links_rebuild() before.
The query is a bit different though, so custom menu links would survive the rebuild, but get deleted upon uninstall with #9. That said, I think it still makes sense.
Comment #12
Alan D. CreditAttribution: Alan D. commentedIsn't this effectively an api change?
I can not remember seeing anything that requires the use of *.install files with Drupal 7 ports. Many small modules use the *.module for the installation hooks which will no longer be included with this change. Also, there could be code sharing between the files, meaning *.install would now need to call drupal_load('module', $module) manually.
IMHO, the bottom line is that it should be safe to always include the *.module file.
Comment #13
Alan D. CreditAttribution: Alan D. commentedMaybe looping is required to only uninstall modules that are not listed as dependencies during each loop? I think there was a similar installation issue which installed the modules out of sync with dependencies...
Comment #14
drunken monkeyCan't say for sure, but using .install files certainly is best practice and what other people reading your modules will expect (as well as being better for performance reasons).
On the other hand it is, I'm pretty sure, nowhere stated that a module needs to explicitly check whether it is enabled when functions inside its .module file are called, which just is a major WTF. I came across this, too, when using my own objects in
hook_menu()
— during uninstallation, the autoloading of these objects wouldn't work anymore, of course, resulting in a fatal error.The patch looks good to me, and the test bot is also happy. Probably someone more at home with the menu system should set this to RTBC, though.
Comment #15
bojanz CreditAttribution: bojanz commentedRan into this bug myself.
Comment #16
rszrama CreditAttribution: rszrama commentedJust wanting to add a +1 here, as this issue hits us with Commerce modules... we have UI modules that implement bundle edit forms for entities defined in corresponding API modules. So, we're using hook_menu() in w/ a call to the API function, which seems to be playing havoc with general uninstallation. More info, including my disbelief b/c I wouldn't have imagined this being an issue, here: #1017006: Unable to uninstall due to PHP fatals because hook_menu() is called by core when uninstalling
Comment #17
fagoPatch in #9 is fine afaik, however it could need a review of someone with more knowledge of the menu system.
>Isn't this effectively an api change?
hm, I thought having uninstall/install hooks in .install is a requirement nevertheless. If it isn't, then yes - we would need to keep the "drupal_load('module', $module);" line. The rest of the patch wouldn't be affected though.
Comment #18
mgiffordI just pulled this down from git to see if I could apply the patch still:
mgifford@asus-laptop:~/rules$ git apply drupal_uninstall.patch
error: install.inc: No such file or directory
Not sure what's up, but would like to be able to reliably uninstall modules when I need to.
Comment #19
bfroehle CreditAttribution: bfroehle commentedmgifford: git apply -p0 ...
Comment #20
mgiffordThanks @bfroehle - I think that this pointed out a few flaws in my previous approach.
I was still thinking of this as a rules issue and not a core issue.
I don't have a git repository (yet) for D7 or D8. I had thought I could keep with the D8 version, but probably not.
Nice to know that the -p0 carries forward from the CVS days! Now I just need to set up a repository for it:
http://drupal.org/node/3060/git-instructions
This needs to be updated so that it redirects to the git or states clearly that it's an archive:
http://drupal.org/documentation/cvs
Thanks!
Comment #21
Damien Tournoud CreditAttribution: Damien Tournoud commentedThis doesn't look right: at the minimum we need a condition('module', 'system') in there.
But anyway, just forcing a menu rebuild should do all this already. In addition, those modules are *already* disabled, so they should not have any dandling links anyway. I suggest we just completely remove this code.
Comment #22
bojanz CreditAttribution: bojanz commentedHere's a patch that just kills the offending code.
Comment #23
Damien Tournoud CreditAttribution: Damien Tournoud commentedLet's pull the trigger.
Comment #24
David_Rothstein CreditAttribution: David_Rothstein commentedWhat about @fago's comment in #11?
If your site has customized menu links, it seems like after this patch they will remain in the database forever (even after the module they point to has been uninstalled). The consequences of that probably aren't too serious, but it looks like this makes it so we are failing to clean up correctly...
Comment #25
catchIt's not inconceivable to replace the router path of one module with the router path of another (especially with views or something). In those cases, I'd rather keep the customized menu links then have them cleaned up for me.
Not moving back to RTBC, but I agree with the current patch.
Comment #26
Damien Tournoud CreditAttribution: Damien Tournoud commentedWhen you disable a module, the customized menu links pointing to one of its router paths get orphaned: their 'router_path' column is emptied in the {menu_links} table.
As a consequence, the removed code was *always* a no-operation: there cannot be any menu link with a router_path of a disabled module, and modules have to be disabled before possibly getting uninstalled.
Fago's patch in #9 remove all the orphaned links from the database, regardless which module has initially created them: it will affect all disabled modules, not only those that are getting uninstalled. This is just not acceptable. The only thing we can do is ignore the issue and accept orphaned links to remain in the database forever. As described, it is not a regression. Just accepting the current situation as the best we could possibly do.
Comment #27
David_Rothstein CreditAttribution: David_Rothstein commentedDamien, that's not what I see happening at all. When I disable a module, the 'router_path' column for its menu links is not emptied, nor is the uninstall code being removed here a no-op.
Example:
So this patch definitely does have the effect of orphaning menu links that previously would not have been orphaned.
However, I think @catch makes an interesting point. There are cases where this failure to clean up actually winds up being a good thing...
Comment #28
Damien Tournoud CreditAttribution: Damien Tournoud commentedHm. Not sure what happened in my testing yesterday, you are right. Seems that menu links keep their router path on disabling a module.
Remains that we have no way to know that a given menu link created from a router item belong to a given module. At least not without restoring the module from its grave, and we cannot do that.
Comment #29
Damien Tournoud CreditAttribution: Damien Tournoud commentedRetitling. The core issue is that we are calling a hook from a disabled module :|
Comment #30
Damien Tournoud CreditAttribution: Damien Tournoud commentedSo I guess we have no choice, then to track the original module the link was created for...
Comment #31
rfaysubscribe - bit by this.
Comment #32
rfayWe have to get this in to 8.x before it can come back to 7.x. Assigning.
This is a critical for Drupal Commerce.
Comment #33
Anonymous (not verified) CreditAttribution: Anonymous commentedThis is also affecting SPARQL Views, so subscribe.
Comment #34
catchHow does original_module help here?
- tracker module defines a link
- admin customises the link (moves it to a different menu, renames or whatever)
- admin enables tracker2 or views and overrides it.
- admin disables then uninstalls tracker.
Looks like the code here would remove my customized link pointing to a valid router item. We could possibly join on menu_router and check if there's a valid router item or not as well, didn't look into this though.
I would go for #22, especially for D7. If it's a choice between data-loss and cruft, I'd go for cruft - it's not as if we don't have plenty of other places in core (like nodes) where uninstalling modules leaves things lying around.
Adding tags.
Comment #35
BerdirGot hit by this too. Has nothing to do with a class in my case, just the fact that I'm jusing an API function of a module that I depend on in hook_menu().
Comment #36
Damien Tournoud CreditAttribution: Damien Tournoud commentedI'm all for cruft. Let's get #22 in.
Comment #37
Damien Tournoud CreditAttribution: Damien Tournoud commentedWe don't need any test for #22. We are just removing broken code.
Comment #38
Dries CreditAttribution: Dries commentedThe patch in #22 no longer applies to 8.x and will need a quick re-roll.
Comment #39
Dries CreditAttribution: Dries commentedComment #40
bojanz CreditAttribution: bojanz commentedHere's the reroll for 8.x
Setting to RTBC since it's the same patch that got committed to 7.x
Comment #41
Dries CreditAttribution: Dries commentedCommitted to 8.x. Thanks. Moving to 7.x for @webchick.
Comment #42
Tor Arne Thune CreditAttribution: Tor Arne Thune commentedAlready committed to 7.x on May 14: http://drupalcode.org/project/drupal.git/commit/3a73639
Comment #43
Alan D. CreditAttribution: Alan D. commentedThe removal of the drupal_load() has cause one (probably two) errors in the uninstallation hooks in core, or 5% of core modules. So if that correlates to 5% of contrib., will there be 300+ broken uninstallation scripts out there.
Related to #1169894: Fatal error when uninstalling Shortcut module, where the shortcut module calls shortcut_sets() from shortcut_uninstall(). Also, not reported, the simpletest module calls simpletest_clean_environment() from simpletest_uninstall(). This should also cause the same error (or some magic autoloading is happening that should be removed if the fix is not to reinclude the main module file during uninstallation).
Simply having the module file included should not cause errors! So the solution is to re-include the module load IMHO. BTW I totally agree with the removal of the call to hook_menu().
Unrelated, but may have been left overs from this or a related issue, the taxonomy module is loaded from the forum_uninstall() for no apparent reason. Any ideas?
Comment #44
catchentitycache_uninstall() also broke due to this, but I know other module installs were broken without it due to missing classes from other disabled modules. Either way it's not going to be pretty. We could use a test that installs, uninstalls, then re-installs every core module - that should have caught the shortcut regression.
Comment #45
David_Rothstein CreditAttribution: David_Rothstein commentedI can confirm that both shortcut module and simpletest module are affected by this (both give a fatal error when uninstalling). From looking at the code, those are hopefully the only two examples in core. Yup, we should definitely have a test for that.
Trying to retitle this issue to encompass both the original problem and the new one... because yes, the original motivation for this issue was that the forced drupal_load() was breaking some modules, and now we know that removing the drupal_load() broke others.
Tough to figure out what to do here, but I think it might be best to just accept that this was an API change and fix the broken modules accordingly? Modules implementing hook_update_N() already have to deal with the fact that they might be disabled when that code runs (and therefore shouldn't use API functions, or at least must load the .module file themselves if they absolutely need to). It would make some sense if the same rules applied to hook_uninstall().
Comment #46
Damien Tournoud CreditAttribution: Damien Tournoud commentedWe fix bugs, and that uncovers other bugs. This is bound to happen.
The bug is definitely in the shortcut and simpletest modules here. A module cannot rely on having its .module loaded when uninstalling, has it is simply *not enabled* at this time.
Let's fix those and write a test on the lines of what catch has proposed in #44. But let's open a new issue for this. It's nothing more then a bug uncovered while fixing this issue.
Comment #47
David_Rothstein CreditAttribution: David_Rothstein commentedHere's a test that asserts all core modules can be installed and uninstalled. (It's not actually a new test; I just rewrote an existing one that was hardcoded to do this for the Aggregator module only.)
We should expect a few failures here associated with shortcut and simpletest.
Re #46, I mostly agree with that analysis and proposed solution. However, up until Drupal 7.2 modules could rely on the file being automatically loaded, so we introduced a non-backwards-compatible change in this issue, and we know it broke contrib modules too. A possible solution (which I don't agree with either, but which is not unreasonable) would be to add back the drupal_load() during module
installation[edit: uninstallation] and preserve backwards compatibility - i.e. to say that the original bug here is basically "won't fix" for D7. That's why it makes sense to continue the discussion in the current issue.Either way, I think the attached tests are what we want to make pass.
Comment #48
David_Rothstein CreditAttribution: David_Rothstein commentedMissing tag.
Comment #50
catchIf you can't require_once() a .module file unless the module is enabled there is something wrong with that module. However, between fixing all those modules and requiring some others to add a drupal_load('module', $module); to hook_uninstall(), I'd go for the latter, especially since this is already the case in 7.2.
Attached patch does this for simpletest and shortcut modules. I haven't reviewed the test changes in David's patch though, just confirmed this makes the tests pass.
Comment #52
catchOooh interesting, I actually got those locally but assumed it was my crufty local install. Since we weren't testing simpletest uninstallation prior to #47 I assume that's a real bug in simpletest_uninstall().
So let's define what actually needs to be done here, I'd say the following:
- Add some docs to hook_uninstall() to state that .module files aren't included.
- Add some docs to hook_uninstall() to show that the menu link magic removal no longer occurs.
- Add API change documentation on d.o for both of these.
- Fix shortcut_uninstall()
- Fix simpletest_uninstall()
- Add the tests from #47.
Comment #53
sunsubscribing
Comment #54
David_Rothstein CreditAttribution: David_Rothstein commentedIf most of us are in agreement that we should leave the original patch in and go ahead and fix this in the individual modules, perhaps we should reopen #1169894: Fatal error when uninstalling Shortcut module (and get that one fixed right away, without the tests).
Then we can continue to figure out what's wrong with the simpletest module here and add the tests once we get them passing.
There was some debate in the Shortcut issue about whether or not the above is a good idea. The alternative is to use a direct database query, rather than an API function that requires loading the .module file... Since direct database queries is generally what we recommend for hook_update_N() implementations, my thought was that we should do the same for hook_uninstall().
If we're going to add some documentation in this issue (as per #52) we should figure that out here.
Comment #55
David_Rothstein CreditAttribution: David_Rothstein commentedUm, not sure how that happened...
Comment #56
David_Rothstein CreditAttribution: David_Rothstein commentedBy the way, if I uninstall Simpletest module through the UI, I don't see any issues with the patch applied, so it definitely helps.
Maybe those 4 warnings seen in the tests only appear when you're running the uninstall from inside the testing framework.
Comment #57
catchFor Drupal 7 I don't think we can enforce drupal_load() vs. direct database queries - we are barely doing that for update functions and this is way after release (core updates still use some API functions, even if it's variable_get()). However if we're going to move to direct database queries (or possibly copying API functions to .install files) then we should stick to that in core at least. I don't really mind either way, IMO it should be safe to include a .module file whether it's enabled or not, and it's up to the module in question to decide whether it's safe to call any of its own API functions, but can live with it if others strongly disagree.
Comment #58
fagoNot including the .module file by default and leaving it up to the module to use API functions or direct queries sounds good to me + fits to how we handle update functions.
>Since direct database queries is generally what we recommend for hook_update_N() implementations, my thought was that we should do the same for hook_uninstall().
Makes sense, let's better recommend the safe-way and leave the drupal_load() approach for developers who know what they are doing.
Comment #59
Alan D. CreditAttribution: Alan D. commentedThis seems like a big discussion about a single line of code, but I'd just like to raise a couple of points for its' inclusion, in relation to the post removal of the direct call to hook_menu().
1) I haven't really read the issue queue on a regular basis, but when has loading the *.module file actually caused an error?
2) Since the module hooks are not called once the module is disabled, only "developers who know what they are doing" will have the danger of doing something stupid in the *.module file that results in a direct function call.
i.e.
All other developers will only code in functions and classes that mean there is no danger in simply including the function.
3) There has already been the suggestion to recreate the db_query()'s in the *.install files in core, creating direct duplication of logic from the *.module file. This has a number of negative issues; increases the amount of code that needs to be maintained, includes new code that will probably have minimal testing, etc.
Although I think the core developers are leaning towards drupal_load_include('module', *) solution, what does this say to contrib maintainers.
4) When can we rely on the module file being included? Since the same arguments for excluding the *.module file during installation as to uninstallation, so should we rely on have access to *.module files during installation in the future? Or only during enable / disable hooks?
Also will hook_schema() and hook_field_schema() be ignored in the future if they don't reside in *.install?
[As an aside, maybe these should be in a *.schema file to minimize the server load]
5) Update functions can not rely on a modules API as they have to be able to span branches that will almost certainly contain different APIs. Because we need to do this here, it doesn't mean it is the best approach.
6) Well it broke the standard behavior that even core developers were relying on. By this fact alone, the include should stay until Drupal 8.
Right, that is about the limit to what I can argue about in relation to changes in a single line of code. :)
Comment #60
catchTo answer the first question:
module a defines a class/interface
module b implements the interface or extends the class in its .module file
module a and b are disabled.
require_once b.module - fatal error.
To reproduce at the most basic level:
foo.php
Then
Both modules don't have to be disabled either - the enabled module could rename its interface, and the user who wants to uninstall the disabled module, is not going to be happy if they have to upgrade the module first just to get it to uninstall.
hook_schema() already has to be in a .install file, it is not guaranteed to work if it's in a .module file. I agree .schema files would be good to save peak memory, there's an issue for that somewhere.
I think we should just do drupal_load() here, at least for shortcut_uninstall() - it is an extremely annoying pattern not being able to use API functions in update hooks, and this is something we should eventually try to reverse rather than propagate everywhere - there's no good reason to not use the API function here unless your module does something weird.
On the API change issue, yes it is one (albeit small), but it's one that's already in Drupal 7.2, so I'm averse to changing it back again.
Comment #61
geerlingguy CreditAttribution: geerlingguy commentedSubscribe.
Comment #62
chrisjlee CreditAttribution: chrisjlee commentedSubscribe
Comment #63
pillarsdotnet CreditAttribution: pillarsdotnet commented@#45:
News to me, and perhaps to others. Posted a comment on the api page.
Comment #64
catchI'm bumping this to critical since it's a regression from 7.0 to 7.2 (in terms of the API change for contrib modules). Not being able to uninstall a core module is only borderline critical by itself, but I imagine the API change broke more contrib modules than it fixed so we need to get it sorted out and documented, ideally before the next point release in a couple of weeks.
Also the test added here should help with #1115510: Entity providing modules must call field_attach_delete_bundle() in hook_uninstall() (also marked critical) but it's not currently failing for that, however it will help to get that patch in to have the tests in place.
Comment #65
David_Rothstein CreditAttribution: David_Rothstein commentedThere can actually be some pretty subtle issues due to the module being disabled when the function is called - see #734710: API functions that invoke hooks don't work as expected when a disabled module is being uninstalled
Those issues likely don't affect the cases we're talking about here though. Also, for Shortcut the function we're calling here is pretty simple (just a wrapper around a direct DB query basically), but for Simpletest it's a much bigger function that we really wouldn't want to duplicate in the .install file. So in that case, maybe we just use the drupal_load() method for both, for consistency, and document why you would/wouldn't want to. I think that's fine for moving this issue forward.
Thanks! You might also be interested in #794192: Documentation of hook_update_N() should explain that certain functions cannot be called from there
Comment #66
pillarsdotnet CreditAttribution: pillarsdotnet commentedNote that I posted in that one too.
Comment #67
catchI found out why the test here doesn't fail for taxonomy module, it's because that bug is more of an edge case than I realised and needs its own test case (which I've now added over there).
Patch should fix simpletest_uninstall(), it is actually trying to delete all its files twice in hook_uninstall() so that is a real but minor bug that the test is picking up one way or another. I don't think we need all the drupal_set_message() malarkey when uninstalling either.
Comment #68
tstoecklerI thought I get why you should not call API functions from hook_update_N(), but hook_uninstall() seems different to me. Unlike hook_update_N(), hook_uninstall() should always contain the most recent version of code. Just like when you change your API you might have to change hook_schema(), you also change hook_uninstall(), but not any hook_update_N() (instead you add a new one). Could anyone elaborate on that?
Comment #69
catchRight hook_update_N() can't rely on API functions because you can't tell when an update hook will run - so if the API function depends on a schema, that schema may have changed.
In hook_uninstall() it's more complex, any API function that invokes hooks, especially if the hook is implemented by your module, may not include anything added by your module since it could be disabled, a good example of that is #1115510: Entity providing modules must call field_attach_delete_bundle() in hook_uninstall(). However some things will work OK, but it is a big mess and we can't fix it in D7 apart from patching up the worst bits of it.
Comment #70
David_Rothstein CreditAttribution: David_Rothstein commentedHm, I'm not sure I understand that... where is the code that deletes files twice?
Looking at it now, I actually wonder if the problem is just that simpletest_clean_temporary_directories() assumes that 'public://simpletest' will always exist? But if you install the Simpletest module and then immediately uninstall it (as these tests do), without ever having actually run any tests, then that directory will never have been created in the first place. If that's the case, we should actually leave the call to simpletest_clean_environment() in simpletest_uninstall() but fix this within simpletest_clean_temporary_directories() instead.
Besides that, looks like we're pretty close here? (I think we wanted to add some documentation also.)
Since we seem to have a plan of action, I'm going to un-postpone #1169894: Fatal error when uninstalling Shortcut module so we can at least make sure that one-line patch makes it into 7.3 (with or without the rest) - that's probably the ugliest part of the bug since Shortcut is turned on in the default profile so there will be more people (especially less experienced people) trying to uninstall it than Simpletest.
Comment #71
catchsimpletest_uninstall() runs both simpletest_clean_environment() - which tries to remove files from the simpletest tests directory, then and later calls file_unmanaged_delete_recursive() on the same directory, that's the 'twice'.
Since simpletest_clean_environment() does a lot of stuff that is superfluous to uninstalling the module, so I just copied the database table cleanup from there, that's the only bit of code that's relevant to uninstall that's not already covered by simpletest_uninstall() already.
If we wanted to keep the use of that function in simpletest_uninstall(), I'd want to see it converted to a proper API function without the drupal_set_message() etc. It would also have to deal with removing the directory as well as just emptying it, which it currently doesn't.
I have no interest in doing that as a requirement to having this issue fixed but if you really feel strongly about it then go ahead ;)
Not sure what documentation should be added to core, I was thinking http://drupal.org/update/6/7 for this.
Maybe http://api.drupal.org/api/drupal/modules--system--system.api.php/functio... to explicitly point out that the .module file is not automatically loaded when hook_uninstall() runs and you should drupal_load() it yourself if you need it?
Comment #72
David_Rothstein CreditAttribution: David_Rothstein commentedBut the test failure comes from the first attempt, so the duplication can't be the cause of the bug (and it's not really duplication so much as an overkill way to delete the leftover empty directory, as you said). I think to fix the bug directly we just need an is_dir() call or similar.
Ideally we should keep simpletest_clean_environment() in there, since it's the "right" API function to call in order to clean things up; the drupal_set_message()/etc is ugly but cleaning that up is definitely a separate issue.
Exactly. That is more or less what you suggested in #52 also :)
Comment #73
David_Rothstein CreditAttribution: David_Rothstein commentedHow about this? It should pass the tests and seems like a direct fix of the bug @catch found. I also added the documentation to hook_uninstall().
Comment #74
catchYeah I'm not claiming the duplication is the cause of the bug, rather that it is needless (and the call to the function happens to cause those exceptions). I really have no interest in looking into it any further - it is four exceptions, for files that don't exist, in simpletest_uninstall(), which are only triggered during test runs, which have nothing whatsoever to do with the critical regression from 7.0-7.2 that this issue concerns. I'm not going to work on it, review patches about it, or discuss it any more, you're welcome to if you like but I also think this issue is not the place to do that.
Added the docs to hook_uninstall(), reads like a lot of apologetics but that's all that can be said for the broken mess that is disabled modules.
Comment #75
catchCrossposted. I said I wouldn't review it, but you're still trying to delete some files in a directory, then trying to delete the whole directory if you do it that way.
Comment #76
chx CreditAttribution: chx commentedUm. The limitations of hook_uninstall (class foo extends bar_from_already_deleted_module kaboom fatal) is extremely far reaching apparently. We should document at least in hook_uninstall but also possible in the .info files documentation where we speak about files[] = we should recommend putting classes that inherit from elsewhere or no uninstall for you.
Comment #77
catchI opened #1187074: Document that extending/implementing classes can not be safely placed in .module files, hook_uninstall() is by far not the only place that limitation exists, hook_boot() is another.
Comment #78
David_Rothstein CreditAttribution: David_Rothstein commentedIt isn't limited to test runs. You can see the same PHP warnings in the UI (for example, by clicking the "Clean environment" button). I thought it preferable to get the tests passing by fixing the source of the bug, rather than avoiding it in the uninstall code only.
Anyway, it looks like both patches do pass the tests right now.
Comment #79
catchWe cold do both, fix the bug in simpletest_clean_environment(), but also not use it in hook_uninstall().
Comment #80
David_Rothstein CreditAttribution: David_Rothstein commentedThat sounds reasonable. The attached patch does both.
I also merged the docs we wrote for hook_uninstall() (both said almost the exact same thing anyway).
Comment #81
catchNew docs look great, I don't think I can mark this RTBC since I proposed the drupal_load(), despite the bulk of the patch being David's code, but +1.
Comment #82
chx CreditAttribution: chx commentedWhile the core patch itself is very small (like, two drupal_load commands), the testing benefit is big and #1187074: Document that extending/implementing classes can not be safely placed in .module files will take care of my documentation concerns which truly do not belong here. Go for it!
Comment #83
catchD7 patch does not apply due to #1136130: Regression: Reinstate WATCHDOG_* constants and document why they are necessary., I seem to remember someone pointing out this would happen shortly after it was committed.
Fortunately a find and replace on the patch file works in this case, so here's that.
Comment #85
webchickSwitching version temporarily to 7.x so the testbot can have a crack at that patch.
Comment #86
webchick#83: uninstall-1029606-80.patch queued for re-testing.
Comment #88
chx CreditAttribution: chx commentedHere's a patch (I lost count of the number of folllowups hence the file name)
Comment #90
webchick#88: uninstall_ftl_aleph0.patch queued for re-testing.
Comment #91
webchickOk, those failures are just a random thing that happens with testbot sometimes. See #1188880: Comment module test fails randomly. So I took a chance.
Committed to 8.x and 7.x! Yay!! :D
Comment #92
webchickOops, wait. I lost my comment in all that retesting.
These tests are simply awesome, and EXTREMELY comprehensive. Thanks so much for the hard work on those!!
Comment #93
HnLn CreditAttribution: HnLn commentedsub