[wp-trac] Re: [WordPress Trac] #8999: Completely New LiveJournal Importer

WordPress Trac wp-trac at lists.automattic.com
Wed Feb 4 18:56:21 GMT 2009

#8999: Completely New LiveJournal Importer
 Reporter:  beaulebens               |        Owner:        
     Type:  task (blessed)           |       Status:  closed
 Priority:  normal                   |    Milestone:  2.8   
Component:  Import                   |      Version:  2.7   
 Severity:  normal                   |   Resolution:  fixed 
 Keywords:  needs-testing has-patch  |  
Comment (by beaulebens):

 Replying to [comment:26 ryan]:

 > They upload one file that goes through all of the various hooks and
 checks and receive attachment IDs.  I don't know of any importeres that
 write to the filesystem outside of that.

 True. The first time these files are created, they do use wp_upload_bits()
 (trying to play nice), then they are overwritten in place after that. I
 agree it's definitely not ideal tho.

 > serialize is scary too.  The main concern is doing a php include of this
 stuff later. Can it not go through the options DB, where we have some
 checks for proper serialization, at least, and where we don't have to do

 I ran into memory problems every time I tried collecting things in the DB.
 The (capacity) test journal that I was using has nearly 200,000 comments,
 so that adds up pretty quickly and maxes out MySQL's max query size.

 Each individual comment could perhaps be stored separately in wp_options
 with an option_name of something like lj_comment_xxx, but then you
 wouldn't be able to easily/selectively query them back out to rebuild

 I'm just pondering westi's idea a little more to see if there's a way the
 comments could be inserted into wp_comments, and use the other fields
 (perhaps comment_type/comment_agent/comment_karma to temporarily maintain
 the IDs sent from LJ, until threading is completed, then remove/set them
 back to defaults. Or is that just as hacky? :)

 (on the up-side, I just did some quick/non-extensive testing and it
 appears that var_export escapes things to the extent that if someone put
 PHP in a comment, it'd be malformed/non-executable when include()d during
 import -- still testing)

Ticket URL: <http://trac.wordpress.org/ticket/8999#comment:27>
WordPress Trac <http://trac.wordpress.org/>
WordPress blogging software

More information about the wp-trac mailing list