WordPress Idea – GSOC 2009

Being a regular user of wordpress has inspired me to pick up the Blog Import/Export project idea for my Google Summer of Code project proposal. The idea listed at http://codex.wordpress.org/GSoC2009 is as follows

Blog Import/Export

Mentors: Alex Shiels, Beau Lebens, Nick Momrik, Thorsten Ott

Importing and exporting blog content is an important function within WordPress. Create a WordPress import/export process that doesn’t need a file, but connects directly to the blog for the content transfer instead.

The idea on what should be done:

Currently the WordPress to WordPress blog trnsfer is achieved by exporting an xml file from the source blog and importing it in the next blog. This process can be converted to a direct import export as follows:
1. Connect to the source blog from the current blog by asking the user his login credentials.
2. Access the wpdb object of the source blog and call its export function.
3. Use the autogenerated xml file as a temporary source for import or convert the export function to give an xml response instead of creating the file.
4. Call the import functionality of the destination blog with this xml response/temporary file.
5. Terminate connection to source blog and update current blog.

WordPress API’s parts that will be dealt here:

1. The login functionality to for authentic entry of the user to the source blog

2. The wp-db class to access the wpdb of the source blog

3. The Export functionality should be called from the source blog.

4. The import functionality should collect the information exported in the earlier step in the destination blog.

Export/Import as a core feature:

Since the export functionality gives an xml file like $filename = ‘wordpress.’ . date(‘Y-m-d’) . ‘.xml’ this can be easily modified to provide an xml response having the same contents like this file would have. This response hould be fed into the import functionality. This totally removes the need for a file. But I would like to suggest an alternative way without making any core changes as a User might still want to use the xml file for backup purposes. So at this specific condition of Import/Export the following can bed one

Export/Import as a non core feature:

Instead of modifying the creation of xml file at the export functionality use it as a temporary file on the server itself. Feed that xml file to the import functionality and once successfully imported the temporary file can be removed. This will help maintain the provision for users to se a file backup when required but relieve them of the tedipous pain of downloading the file and then connecting to destination site and uploading it again in case of Import/EXport

~ by Kiran on April 3, 2009.