Forum Moderators: open
There are some modules so complex that it's better left to the module developer or development team to update that module. I'm thinking Views and CCK with thousands of lines of code and many sub-modules. Even if you could get it working on D6, you might make your module incompatible with the upgrade path for the official module and you'll end up stuck. Not worth it. Now, though, Views and CCK are now fully workable despite being labelled Release Candidates. They've been solid and reliable for me on a testbed server, so I finally just made them live.
Once those are done, though, you might still be held up by smaller modules that you consider essential for your site. Many modules aren't that complex, but for one reason or another, the maintainer either has no time or no inclination to do the upgrade. What can you do? Actually, a lot, even if you have modest coding skills. Meaning, that it helps to understand basic PHP, but you don't need to be a code guru by any means.
There are a few major changes between Drupal 6 and earlier versions and a long list of tasks for upgrading a module [drupal.org], but there is help! Here, in three steps, is how to use three drupal helper modules to get your needed module ready for your site, even without an intimate knowledge of drupal. I'm assuming here that you have a drupal 5 version of the module installed on your site. If not, do so.
Step 1. Clean out the dead wood. There are 80 items in the list I mentioned earlier and many of these are just tedious search and replace type of things. Uggh. Except for the fact that the Deadwood module [drupal.org] will parse the old code and make a lot of these changes for you automatically. You need to create two directories in your drupal /files directory: deadwood and goodwood. Copy the Drupal 5 version of the module to the deadwood directory, run deadwood on it and look to the goodwood directory for the output.
In many cases the deadwood module can't figure out how to make some of the more complex changes (updating the forms API, schema and menu system for example). Typically, in those cases, it writes a relatively detailed TODO comment in your file. You can search for these and make those changes. But don't, because there's also the coder module (we'll get to that in step 3). For now, take the "goodwood" version of the module and copy it to your /sites/all/modules directory as usual (or wherever you'll keep the module). The next two steps will work on it there. Don't, of course activate it.
Step 2. Update install files to the new schema system. Install files now use a platform independent "schema". This is a bit complex so it can't be fully automated with Deadwood, but here again there's help. The schema module [drupal.org] will examine your database and generate the code that you need to put in a drupal 6 module.install file in order to bring it up to D6 standards. So if you haven't already, install the Drupal 5 version of the module so that it generates the needed DB tables.
Install the schema module. Then, under admin -> site building ->schema, you'll get to the schema page. If you look at the "Inspect" tab, it will give you the schema for any given table. Since you likely don't have a schema declared yet, the table will be "unknown" rather than associated with a module. Once you create your schema in your install file, these tables will be listed with the right module. At this point, just open the .install file for any module that creates database tables and has been updated to drupal 6. Study the new format and using the deadwood output and the schema module output, build your install file.
Step 3. Run the Coder module [drupal.org]. This is the real business. It will go through and look for anything in your module that is not compatible with drupal 6 or violates drupal coding standards. Once you get no errors in the coder module output, your module is probably working more or less. At the very least, it should run without crashing your system. You may need to do a little debugging.
Go to your modules admin page and notice that with the coder module activated, you now have a "Code Review" link next to every module. Click that link for the module in question and it will give you a lot of choices. You want to start by choosing a specific module, checking the drupal 5->6 upgrade and only major notices. The generated output will either explain fully the change you need to make, or will have a link to the drupal.org page that details how to update, for example, to the drupal 6 forms API or the drupal 6 menu system (those are the two more complicated changes).
Keep iterating through step three until you have no more notices. If you want to be really in tight with the drupal way of doing things, you can now check to have coder find minor problems and bring the whole thing in alignment with drupal coding standards.
And voilą, you should have a working module or be quite close.
Thanks for the steps. I'll probably pull the trigger and start the upgrade to 6 if I get a big enough raise next month lol.
Well that would certainly make me hesitate too. I have updated some forms and my recollection is that if you get it wrong, you'll get a fatal error.
I think the thing to do is make sure it generates exactly the same HTML since that's the only thing that should be affected by the forms API. You would, of course, want to check any and all validation too.
Good luck!
