Fix two small bugs on module/theme enable/disable pages

While reviewing the module and theme enable/disable code (form submit handlers), I have found two interesting bugs.

• First, when themes are being handled, first all themes are disabled, then the requested ones are enabled. Regardless, a check in the inner loop checks for a theme going from 0 to 1 status to set block related properties. Every theme goes from 0 to 1 in the loop, since every theme is set to 0 status before the loop. So the SQL operations there should always return TRUE. We should first build a list of previously enabled themes and then work with that.
• The second bug is in the module/enable disable code. First existing, previously enabled/disabled modules are enabled/disabled as requested in the form, then a list of old modules is requested and then the new modules are installed with their install hooks. Then a list of new modules is requested, and compared to the list of old modules. If there is a difference, the menu and node type cache is rebuilt and a drupal message is printed to the user. The problem is that since the old module list is requested after the enable/disable actions, the menu/node type cache is not rebuilt and a message is not printed if there were no modules being installed. Although the menu cache and the node type cache should have been rebuilt (and IMHO a message is desired to ensure the user that the changes are saved).

I have actually found these two bugs, because I was looking at an easy way to get notified when modules and themes are changed (enabled/disabled/installed). This would be used in the autolocale module and install profile to let the system automatically import locale files when needed. After fixing these two bugs above, it was just a matter of two lines each to add module_invoke_all() calls to both places, so that other modules can get notified of changes. This way the block module code wired into system module was possible to get reworked into block module.

The new system_notify() hook accepts three parameters. Type is the type of components changes (theme/module); $disabled, $enabled; $new are the list (array) of components being affected, ie. disabled, enabled, installed. The last is not applicable to themes, since we are not supporting install hooks for themes as it seems from the code.

This is a very simple change given that most of the patch is just bugfixing. I would welcome the bugs being fixed and this functionality added to Drupal 5 to support internationalized user profiles a lot better, without extraneous code duplication. (System notification would also be good for eg. notifying system admins by email of theme and module related big scale changes; or a module informing you on the web interface that it has extra features now that another module is enabled). Although I have tested this patch extensively, it would be nice to get testers.

I also used this test function to look for proper working conditions:

<?php
function system_system_notify($type, $disabled, $enabled, $new = array()) {
watchdog('debug', 'System notification caught. Disabled: '. serialize($disabled) .'; Enabled: '. serialize($enabled) .'; New: '. serialize($new));
}