Recently, a discussion came up about some new feature that will need to be added to a client website and it quickly became clear that we need to track the some variables in the session state. Now, I had always been told that WordPress, in trying to present a stateless solution, didn’t support tracking sessions variables without custom cookies.

Well after a little Googling (thank you Larry and Sergey) i found the following article on Session Variables in WordPress and it has a very elegant and simple solution to the problem.

Just add the following code to your theme’s function.php and you are good to go:
function THEMENAME_init_session()
{
session_start();
}
add_action('init', 'THEMENAME_init_session', 1);

This is exactly what I needed so now we’ll be able to store and access $_SESSION[] variables.

Having to move data from Drupal 7 to WordPress 3.x is not as easy as I had hoped it would be. Initially found a plugin that didn’t work. Then found a project on GitHub but it was for Drupal 5 or Drupal 6 (not sure really) but the jump to 7 comes with enough schema changes that the above wasn’t going to work.

While not a perfect script, this certainly did give me the ability to move articles/posts/pages from a Drupal 7 site to a current WordPress site. You’ll find the original article at http://fuzzythinking.davidmullens.com/content/moving-from-drupal-7-to-wordpress-3-3/

I made some changes here and there to accommodate the vagaries of the original database I was working with and to correct the types of quote marks used for data fields but other than that, it worked pretty well. If you need access to it, here’s the details (in case his original post disappears):

AS ALWAYS, BACK UP YOUR DATABASES FIRST!

#Run these in blocks and remember to change wordpress to the name of your wordpress
#database/schema and drupal to the name of your drupal database/schema.
#
# Block 1
# TAGS
# Using REPLACE prevents script from breaking if Drupal contains duplicate terms.
REPLACE INTO wordpress.wp_terms
(term_id, `name`, slug, term_group)
SELECT DISTINCT
d.tid, d.name, REPLACE(LOWER(d.name), ' ', '_'), 0
FROM drupal.taxonomy_term_data d
INNER JOIN drupal.taxonomy_term_hierarchy h
USING(tid)
# INNER JOIN drupal.term_node n
# USING(tid)
WHERE (1
# This helps eliminate spam tags from import; uncomment if necessary.
# AND LENGTH(d.name) < 50 ) ; INSERT INTO wordpress.wp_term_taxonomy (term_id, taxonomy, description, parent) SELECT DISTINCT d.tid `term_id`, ‘post_tag’ `taxonomy`, d.description `description`, h.parent `parent` FROM drupal.taxonomy_term_data d INNER JOIN drupal.taxonomy_term_hierarchy h USING(tid) # INNER JOIN drupal.term_node n # USING(tid) WHERE (1 # This helps eliminate spam tags from import; uncomment if necessary. # AND LENGTH(d.name) < 50 ) ; #Block 2 INSERT INTO wordpress.wp_posts (id, post_author, post_date, post_content, post_title, post_excerpt, post_name, post_modified, post_type, `post_status`) SELECT DISTINCT n.nid `id`, n.uid `post_author`, FROM_UNIXTIME(n.created) `post_date`, r.body_value `post_content`, n.title `post_title`, r.body_summary `post_excerpt`, n.type `post_type`, r.entity_id `rid`, <- There is an issue here. Haven’t had a chance to fix this yet. IF(n.status = 1, 'publish', 'private') `post_status` FROM drupal.node n, drupal.field_data_body r WHERE n.vid = r.entity_id ; #Block 3 # POST/TAG RELATIONSHIPS INSERT INTO wordpress.wp_term_relationships (object_id, term_taxonomy_id) SELECT DISTINCT nid, tid FROM drupal.term_node ; #Block 4 # Update tag counts. UPDATE wordpress.wp_term_taxonomy tt SET `count` = ( SELECT COUNT(tr.object_id) FROM wordpress.wp_term_relationships tr WHERE tr.term_taxonomy_id = tt.term_taxonomy_id ) ;
In my case, I ended up not running the taxonomy or the comments commands as we didn't have any comments to worry about and the taxonomy failed hard.

Either way, thanks to the writer at this blog post for pointing me in the right direction so I could stop wasteing time getting this data converted.