Upgrading Enabled Modules from Drupal 5 to Drupal 6

Reference

Converting 5.x modules to 6.x
http://drupal.org/node/114774

Upgrading your menu system from 5.x to 6.x
http://drupal.org/node/103114

Changes specific to the Enabled Modules module

Description replaced with a serialized info column in system table.

6_enabled_modules ben$ cvs commit -m "revised Drupal 6 upgrade, addresses change in system table from description field to serialized info field including description element"

cvs commit: Examining .

Changes tricky for any module

The biggest gotcha was the need to use hook_theme – enabled_modules_theme – in order for the existing theme() functions to work such as getting theme_enabled_modules_list() to be seen and used.

Functionality problem, due to what must be a change in the way the modules page save function, one save lists all modules not explicitly checked as enabled as disabled– whether they are on the page or not. So the trick to find enabled but missing modules no longer works.

Recently Enabled Modules block now possible... or not

That's all you need to know, but here's a long IRC chat where this usability need came up again and we discovered it would indeed be possible:

JacobSingh: I'm going to be taking a look at progress on wizards for contrib modules upon install. looking at http://drupal.org/project/awesome_install
[01:57am] JacobSingh: Is anyone enthused about this and wants to fill me in on the best people / places to look nowadays?

benjamin-agaric: JacobSingh: no resource or people recommendations i can think of but enthusiastic cheering from the sidelines!

JacobSingh: benjamin-agaric: heh, thanks. I think cwgordon was on to something, but the problem is too large to tackle in one go. I want to find something functional and useful in one day
[02:06am] JacobSingh: I'm thinking about simply a little block which would show when a module was enabled, but was not configured
[02:07am] JacobSingh: when the module says it is configured, it would drop off that list
[02:07am] JacobSingh: and just let that block follow the admin around
[02:07am] JacobSingh: seems like a simple first step that would help, yes?
[02:07am] benjamin-agaric: JacobSingh: that exact block was always my intent with my enabled_modules module
[02:08am] JacobSingh: benjamin-agaric: Is that code worth trying to port and wrestle with, or should I just start from #! ?
[02:08am] JacobSingh: benjamin-agaric: oh looking at the code
[02:09am] benjamin-agaric: but i never got around to that part, 'cause modules didn't have timestamps, and in 5 there was no way to hook into the enabling process to give it a timestamp. In 6 there is though, so you could both check for when something is enabled and ... i'm not sure how, but check on their settings pages
[02:09am] JacobSingh: this looks very much like what I am doing
[02:09am] JacobSingh: You have a 6 alpha there it looks like
[02:09am] benjamin-agaric: JacobSingh: it was ported to 6 but not the block part-- just a list of enabled modules page
[02:09am] benjamin-agaric: and there's some issue there, too
[02:09am] benjamin-agaric: want co-maintainership?
[02:11am] JacobSingh: benjamin-agaric: hah! I've fallen for that trick before
[02:11am] benjamin-agaric: JacobSingh: Damn! i've got my finger on the trigger
[02:11am] JacobSingh: Let's see where I get to

JacobSingh: Today is Acquia Gardening day (all engineers work on general improvements to Drupal, or other FOSS stuff)
[02:12am] JacobSingh: I'm pretty focused on usability improvements, and I'd like to make some headway on this one...
[02:12am] chunmun: JacobSingh: Thats nice.. didnt know about that..
[02:14am] JacobSingh: chunmun: We do 2 per sprint (every 3 weeks). Some of us are anyway contribing to modules as part of normal work, but for this stuff we get to focus on core issues or larger problems. It's fun, but I never get too far. Looking for iterative stuff
[02:14am] benjamin-agaric: JacobSingh: I'm certainly thrilled we've identified the same need, and would love to help get such a block into core
[02:15am] JacobSingh: http://drupal.org/node/230059
[02:15am] Druplicon: http://drupal.org/node/230059 => Can we create a configuration hook for contrib modules? => Drupal, install system, normal, active, 6 IRC mentions
[02:15am] JacobSingh: Good thread on the same
[02:15am] benjamin-agaric: some way that would allow conscientious module makers to have the same message (with configuration links) that they put in the install function get reused in a recently-enabled help block would go a long way

JacobSingh: http://drupal.org/node/406944
[03:05am] Druplicon: http://drupal.org/node/406944 => Show new modules in a list with config links, provide facility to remove => Enabled modules, User interface, normal, active, 1 IRC mention
[03:06am] benjamin-agaric: JacobSingh: you have CVS access
[03:06am] benjamin-agaric: and cool!
[03:06am] JacobSingh: benjamin-agaric: hah. Okay, I think it's not a great solution, and hopefully "features" will take this over at some point
[03:06am] JacobSingh: but might be a small and useful enhancement
[03:08am] benjamin-agaric: so we can add our own submit handler to the first page called for each module you think? 'cause sadly it is a menu link, not a form, that we'll know about. But that'd be very slick!
[03:10am] JacobSingh: benjamin-agaric: There is a bad way to do it
[03:11am] JacobSingh: which is to add a flag along with the link, and then throw a hidden var in the form
[03:11am] JacobSingh: but of course, if the user gets there from some other source, it doesn't work
[03:11am] benjamin-agaric: so we'd be form_altering every form and looking for the flag? hehehe
[03:12am] benjamin-agaric: a bad way in contrib can provide the proof of concept for a good way in core
[03:12am] JacobSingh: Yeah, well, we can form_alter every form
[03:12am] JacobSingh: and just throw a little switch at the top to check if we're on a system_task for one of the new modules
[03:12am] JacobSingh: and if not quit out. I don't think there will be much overhead from that
[03:13am] JacobSingh: benjamin-agaric: but yes, fugly
[03:14am] benjamin-agaric: it's true-- technically i guess form_alter runs for everything already
[03:14am] benjamin-agaric: hey, *i'd* nominate it for best use of form_alter
[03:18am] JacobSingh: So to throw in a "non-configured" flag for new modules... what is the best practice?
[03:19am] JacobSingh: It's weird... I've never tried to do this, but there doesn't seem to be a hook fired when new modules are enabled...
[03:19am] benjamin-agaric: I'm promised there is in 6
[03:19am] benjamin-agaric: There was not in 5
[03:19am] JacobSingh: I'm looking through the code... maybe I should update, I'm on 6.3 or something
[03:22am] JacobSingh: benjamin-agaric: http//api.drupal.org/api/function/module_enable/6
[03:22am] JacobSingh: http://api.drupal.org/api/function/module_enable/6
[03:22am] benjamin-agaric: no...
[03:22am] JacobSingh: Doesn't look like it
[03:22am] ugerhard left the chat room. (Read error: 104 (Connection reset by peer))
[03:22am] Jaza_ left the chat room. ("Duty is heavier than a mountain, Drupal lighter than a feather.")
[03:22am] smok left the chat room. (Read error: 110 (Connection timed out))
[03:23am] benjamin-agaric: It's not until D7!
[03:23am] benjamin-agaric: if (!empty($invoke_modules)) {
[03:23am] benjamin-agaric: // Invoke the hook_module_enable after all the modules have been
[03:23am] benjamin-agaric: // enabled.
[03:23am] benjamin-agaric: module_invoke_all('modules_enabled', $invoke_modules);
[03:23am] benjamin-agaric: }
[03:24am] benjamin-agaric: (oop sorry, IRC etiquette fail) http://api.drupal.org/api/function/module_enable/7
[03:24am] arianek joined the chat room.
[03:24am] JacobSingh: benjamin-agaric: Well, that scres up this plan, doesn't it
[03:24am] benjamin-agaric: yeah, that's what stopped me last time
[03:24am] smok joined the chat room.
[03:24am] JacobSingh: I guess I'll start building it for 7...
[03:24am] benjamin-agaric: but hey, if we're going to do this with form_alter
[03:25am] benjamin-agaric: we just have to record when the modules page is submitted
[03:25am] benjamin-agaric: and grab what's being enabled there. with apologies i guess for those of us using drush
[03:25am] JacobSingh: Yeah, it is a little inaccurate
[03:25am] arianek left the chat room. (Client Quit)
[03:25am] benjamin-agaric: a tad
[03:25am] JacobSingh: We'll have to actually grab the confirm page
[03:25am] JacobSingh: and if there is an error installing...
[03:26am] benjamin-agaric: I *still* can't believe there isn't a timestamp and a uid in the system table already!
[03:26am] JacobSingh: seriously...
[03:26am] JacobSingh: at least a timestamp seems like a good idea
[03:27am] • benjamin-agaric looks again
[03:27am] JacobSingh: Anyway, I'm going to do a bit more thinking about this. Perhaps something really silly and simple like a modal JS window which will show you that you just enabled modules X,Y,Z, and they have these configuration options
[03:27am] bertboerland joined the chat room.
[03:28am] JacobSingh: Or another screen post module install with a list of config pages and a bit of help. Something is better than nothing
[03:29am] benjamin-agaric: JacobSingh: There *is* a datestamp serialized in the info field
[03:30am] JacobSingh: benjamin-agaric: Oh, I didn't see that...
[03:30am] benjamin-agaric: neither did i, for all i know it is in 5 and i never saw it
[03:30am] JacobSingh: we can totally use that, just need to probably extract and cache, don't want to be doing that routine everytime we want to build that block...
[03:30am] • benjamin-agaric has irrational (?) hatred of serialized data
[03:31am] JacobSingh: benjamin-agaric: It is not irrational at all.
[03:31am] benjamin-agaric: good
[03:31am] JacobSingh: I don't mind serialized data so much, but it is overused IMO in Drupal. Plus, I'd prefer a non-PHP centric serialization
[03:31am] benjamin-agaric: getting the info from that to have the time-ordered listing is slightly better than a confirm page that says "save these links! believe us, you'll be looking for them shortly"

JacobSingh: In the future, would be ideal to have modules simply implement hook_config_wizard or something
[03:32am] JacobSingh: which would be a series of forms or tutorial, whatever
[03:33am] JacobSingh: and then when the user completes the wizard
[03:33am] JacobSingh: we update the system table to say "configured"
[03:33am] JacobSingh: and post install of a single mod, we just push them to the wizard, post install of several, we chuck them in the block we're building now and it follows them around till they do it...

JacobSingh: benjamin-agaric: I don't see the timestamp in info...
[04:07am] JacobSingh: Are you talking D6?
[04:08am] benjamin-agaric: ugh, maybe it's module-specific. i saw it for adminrole
[04:08am] JacobSingh: heh, I don't remember writing that in
[04:08am] JacobSingh: Anyway... I guess this one is going back on the shelf
[04:09am] benjamin-agaric: aww-- i think it is all contrib modules though
[04:10am] benjamin-agaric: i didn't see it in core ones but i see it in advanced help
[04:10am] benjamin-agaric: so i'm two-for-two in contrib
[04:11am] benjamin-agaric: 3-for-3 in contrib
[04:15am] JacobSingh: Weird...
[04:15am] JacobSingh: http://pastebin.ca/1365052
[04:15am] benjamin-agaric: 3-for-4. it's not automatic, the better modules seem to have it but not the really stripped down ones
[04:15am] JacobSingh: That's contrib.. don't see it there
[04:15am] benjamin-agaric: but for all i know the datestamp is when the module was made, or when the maintainer was born
[04:15am] JacobSingh: I'm working a simple core patch to system_admin
[04:16am] JacobSingh: to just show the links to tasks after you enable the module. Better than nothing
[04:16am] benjamin-agaric: sounds good-- and frankly, getting the hook_modules_enabled in D7 backported to D6 is exactly the kind of non-API-breaking but possibility enhancing changes we should allow in point releases

Resolution