[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
includes.
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
threads.
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