I'm always annoyed when I register for a web site only to have my user ID mysteriously disappear. The "scouting.org" web site has recreated itself about four times in the past decade. Each time has led to re-registration by the entire user community.
Therefore I decided to make a strong effort to retain my user community while migrating my site. The easy part was to contact those who provided email addresses and tell them what was happening. The hard part was to deal with passwords.
Step 1: Export the WordPress User List
The first step was to export the user database from WordPress. For this I installed the AmR Users plug-in produced by one AnMari, a WordPress developer. This plug-in provides an interface to construct tailored lists of registered users. I configured a list to display user IDs, "readable" names, email addresses, URLs, and comment counts. Unfortunately I could not display OpenID credentials, so I didn't have a clean way to incorporate them into the Drupal user database.
Another problem: I couldn't transfer user passwords. The passwords were safely stored in a hashed format. In a perfect world, both Drupal and WordPress would have used an identical hashing mechanism. Perhaps the mechanism could have been a standard PHP function used by both packages. In fact, each rolled their own. There were hacks that might have allowed using WordPress hashes on Drupal, but that would have required PHP coding.
A perfect world would have also allowed me to transfer the OpenID credentials. All I should have needed to do is store the appropriate information in the Drupal user database, and everything would have worked.
But that's not how things are. Maybe things will move more smoothly in a few more years.
Step 2: Clean up the user list
Like most webmasters, I get a lot of spam comments. I relied on Akismet to identify them on my WordPress site. I continue to use that service on my Drupal blog via the AntiSpam module.
Akismet killed thousands of bogus comments on Cryptosmith. To post those comments, the spammers had to create user accounts. So I had a lot of bogus accounts. I sorted the wheat from the chaff by retaining only those users whose comments had actually been kept.
I also had to delete a bunch of escaped quotations that the exported AmR User list included in its CSV format.
And I deleted users who hadn't provided email addresses. After all, existing users couldn't retrieve lost passwords without a working email address.
Step 3: Import the user list to Drupal
I installed the "User Import" module to do this. Now, this may simply reflect my ignorance of Drupal, since there seem to be some very general-purpose import mechanisms. It may be that users are a special case of "nodes" or "taxonomies" or some other basic Drupal thing, and that I could import a list of users as a special case of one of those.
In any case, the User Import module accepted the CSV from AmR User, after I massaged it with Excel and a text editor.
Drupal may - or may not - automaticaly send email to new users as soon as they are activated. I chose not to send such emails, since I imported the user list into my Drupal clone system while the main Cryptosmith site was still running WordPress. The automated message would have arrived too soon. Instead, I had a chance to review the imports and make sure that they looked correct. I also tested a few imported users.
Step 4: Tell the users about the transition
Shortly before I shut down the WordPress site, I sent an email to everyone who provided an email address to the site. The message announced the change, and assured everyone that the site contents would still be available without logging in first. I also explained that I would retain login names for users who had posted comments.
Then I performed the transition. I'll talk about that experience elsewhere.
Once the transition was finished, I sent an email to all registered users. Since the updated site was based on Drupal, I needed to install a module to send the email. I chose the "Mass Contact" module. Basic Drupal includes a "Contact" module that provides a web page for contacting the site administrator or other users (depending on how it's configured). The Mass Contact module provides a similar interface to contact specific classes of site users. I configured it to send email to all site users.
Surprising features of Mass Contact
Those of you who received the email were subjected to some of the, well, surprising implications of emailing from Drupal.
- The Mass Contact module, working with a WYSIWYG editor, does best at producing HTML email.
- I have this prejudice in favor of raw text email. Mass Contact allows you to select raw text email.
- You can't really produce raw text with a WYSIWYG editor. The editor naturally inserts HTML tags to indicate the required formatting. If the only formatting consists of newlines to produce line and paragraph breaks, then you still get the tags to produce those breaks.
Thus, my bias in favor of raw text email produced a jumble of text and HTML tags in my first attempt. The Mass Contact also uses some weird scheduling discipline so that it doesn't send too much email at once, and this produces delays in email transmission. In some cases you have to wait a while to see the results of a Mass Contact email, because they aren't always transmitted immediately.
