Oh Drupal... sigh

Max Allowed Packets Insanity

chrisyakimov — Mon, 23 Feb 2009 23:32:47 +0000

Been having issues trying to use PHPMyAdmin to re-import my whole Drupal installation. Was running into the Max Allowed Packets error. It is a MySQL configuration that you can’t edit through PHPMyAdmin. Could find no help on the MySQL site (no surprise there – horribly indexed in my opinion). Then I stumbled across this nugget of pure gold:

http://smokinggoat.wordpress.com/2008/12/09/max-allowed-packet-problem-with-mamp/

Go there to read the solution (give him the traffic he deserves)

In case it’s down…

1. Find “my-small.cnf” in Applications/MAMP/LIbrary/Share/MySQL/

2. Copy it to the regular MySQL folder in MAMP: Applications/MAMP/db/mysql/

3. Rename it to: “my.cnf”

4. Open it with a text editor and go hunting for Max Allowed Packets (Edit>>Find etc.)

5. Bump the 1M default a bit higher. My drupal sql file was 18MB (mostly taken up by huge node and user tables), and Max Allowed Packets at 2M was sufficient.

PhpMyAdmin export quirk?

chrisyakimov — Thu, 12 Feb 2009 16:24:12 +0000

Not sure if this is an issue wtih PhpMyAdmin, or MySQL, but I discovered today that I can no longer export my whole Drupal database in one shot (for backup purposes). Specifically: I can’t export to a zipped file. PhpMyAdmin gives me a warning:

“cannot file http://localhost/phpmyadmin/export.php”

I fiddled around in Apache’s confg file and discovered that the paths and aliases were all good. Tested a different db and it all worked fine. So I figured this error may not be what the error said it was. Tried changing the max queries way up – didn’t help.

Solution?

Selected tables from A->M and exported as one file. No probs.
Did N->Z (which I thought would be problematic since Node and Users are in that half). No probs.

Strange… But hey, it worked. Got my backup. *yay :S

Web typography and style

chrisyakimov — Wed, 04 Feb 2009 17:54:59 +0000

Just reading an awesome summary about web typography design standards. Don’t wanna forget it!

http://www.alistapart.com/articles/howtosizetextincss

Input Filters and CCK

chrisyakimov — Wed, 04 Feb 2009 00:33:30 +0000

So it seems that input filters only intelligently work with information being extracted from the body column of node_revisions. Any information extracted from a CCK generated data table is strictly escaped. :s

Housekeeping

chrisyakimov — Tue, 03 Feb 2009 21:23:48 +0000

Wow – all the data is migrated.

Gotta remember that when I created the new profile fields, I did not ensure that certain “options” on lists conformed to available options in the sagro database. So where exisitng customers will have an “e” in their database, new ones will have “email.” I have to go change that.. Kay, and more’s coming back tome, so here’s a list:

Clean up E’s to “email” etc. in profile_values.
Make sure all nodes have teasers in node_revision
All nodes in node have content types and “” for language.
user PASSWORDS… temporary measure of some sort – php script? – find out where Drupal does this.

UREKA!

chrisyakimov — Mon, 02 Feb 2009 19:13:01 +0000

Thanks to this post: http://drupal.org/node/213714

I have discovered that migrating time information will be a breeze. In a nutshell:

MySQL timestamp is of the format yyyy-mm-dd hh:mm:ss

MySQL unix_timestamp() is of the form: xxxxxxxxxx where x is an integer (there are 10… currently). I believe this is a reference to the amount of seconds from the epoch time, which is some time in 1970. Drupal likes to store time in this format.

Converting from one to the other is as simple as these two rules (and functions – all in MySQL).

unix_timestamp(MySQL timestamp) = xxxxxxxxxx
from_unixtime(unix_timestamp()) = yyyy-mm-dd hh:mm:ss

If you have a date in the format of 2009-01-21 11:39:14 and you need that to be a 10 digit integer, just update the MySQL database with unix_timestamp(’2009-01-02 11:39:14′). And if you have a 10 digit integer representing time, and you need a regular timestamp, wrap it in the function, from_unixtime(), like this: from_unixtime(’1232566754′)

Node Import…

chrisyakimov — Mon, 02 Feb 2009 18:34:49 +0000

Don’t know why I thought that the current release DID support CCK content types when the project page makes it very clear that it doesn’t.

So… looks like I need to delve into the way Drupal sets dates in order to harness that into a PHP based database import. Youch. Big project for me, being pretty NEW to PHP. My hunch is that I need to:

Make a db mysqli connection
Write queries to draw from the correct tables, put the data into variables, and insert them into the destination tables, but with…
.. .something that intercepts the date-based information and converts it to Drupal-happy date infor

What is Drupal-happy date info?

Profile

chrisyakimov — Wed, 28 Jan 2009 00:32:21 +0000

After much effort, I’ve managed to port over most of the necessary content from the old site into the Drupal one. Profiles really does make it a bit more… challenging.

End of the day and I’ve stumbled across two very promising modules:

Content Profile.

Creates profiles as nodes, opening them up to modules that work on nodes, including the CCK.

Issues:

It’s beta, and I’m not sure if it will be rc before we need to get our first iteration live.
It may require a completely different migration of data.

Profile Roles.

Allows me to specify which profile fields are exposed to which roles, which is the primary reason I’d want to enhance what Profiles currently does. I need to have Instructors filling out the additional details only when they are instructors! It’s smaller, but it’s ready now.

Issues

This continues to use the problematic Profile module (in terms of data storage)

Gotta figure out what to do when I get back: I need to go check out the status of Content Profile, then make my decision.

More cleanup notes

chrisyakimov — Tue, 27 Jan 2009 18:11:53 +0000

So it looks like Drupal uses the users.created field to determine how long a user has been with the site. I would like to migrate that information from the old site; however, at the old site, the information was stored in MySQL as datetime, whereas Drupal uses scripting to convert date information into an 11 character numeric string. It looks like I’m going to have to write a PHP script to do the translation. So I might as well roll all the SQL into one executable import script (and make sure to build in a check to see if the script has been executed so you can’t do it more than once).

Drupal Diary, January 2009

chrisyakimov — Tue, 27 Jan 2009 17:39:31 +0000

Just some housekeeping so I don’t lose track of what I need to do. If any of you are reading this, and you’re not me, please forgive me singularly ego-centric writing: this blog is primarily designed to be a notepad for me to keep myself in check. If any information here helps you out – awesome (and I’m happy to respond to questions/comments etc.).

Rad, here we go.

Importing Users has become rather complicated. I considered the User Import module, but it isn’t built for Drupal 6. Node import might work, but I had memory issues configuring it. It’s working now, but in the interm, I have mapped the database to database migration that needs to take place, and am executing SQL to make that happen.

User Profile Module is just… non-conformist! I wish there were some code out there integrating User Profile with CCK. I guess I could experiment with a Profile content type, but I wonder how to limit each user to only one… Wishlist content.

So:

My Current Isse: Sending old users a new drupal login string with a new temp password.

Options:

1. MD5(“temp”) for all of them – send list generated email with that info. Very insecure.

2. Employ Drupal’s “forgot password” functionality – provide instructions on the first page to log in to generate a temp password for themselves. This actually sounds like a fantastic option as I have all the emails and login information, and have managed to migrate that into the users database. But I gotta test it and my development environment is not setup to send mail. So I have to get this live.

REMINDER

Set one of the imported accounts to “active” once the migration has ocurred flawlessly. Test that account to see if a live installation will functionally send a temp password for the imported account and get everything running.