[wp-trac] [WordPress Trac] #22435: Export API

[WordPress Trac]

#22435: Export API
--------------------------+------------------------------
 Reporter:  nbachiyski    |       Owner:
     Type:  enhancement   |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Export        |     Version:
 Severity:  normal        |  Resolution:
 Keywords:  dev-feedback  |
--------------------------+------------------------------
Description changed by nbachiyski:

Old description:

> From experience and from tickets (#19864, #19307, #17379) it's evident
> that we need to update the export API.
>
> High level goals:
>  * To be usable from different parts of the code. From the web backend,
> from a CLI script, from an async job.
>  * To allow more control of the output format – serve over HTTP, write a
> single XML file to disk, split it and write many smaller XML files, write
> a big zip with many XML files, etc.
>  * Keep {{{export_wp()}}} for backwards compatibility without the need to
> keep all (even any) of its code.
>
> Here's my idea for the part of the API 99% of the developers touching
> export would use and be happy:
>
> {{{
> #!php
> <?php
> // WP_WXR_Export is an aimmutable representing all the data needed for
> the export and allows us to have it in multiple formats
> $export = new WP_WXR_Export( array( 'start_date' => '2011-10-10',
> 'post_type' => 'event', … ) );
>
> backup( $export->get_xml() ); // string
>
> $export->export_to_xml_file( 'mom.xml' );
> send_to_mom_to_import( 'mom.xml');
>
> $export->serve_xml(); // with all the headers and stuff
>
> $export->export_to_xml_files( '/files/exports-for-my-awesome-website/',
> 'export-%02d.wxr.xml', 5 * MB_IN_BYTES );
> }}}
>
> Before I dive into implementation details (in the comments, not to
> pollute the ticket), I'd like to hear what use cases for extending this
> code you have in mind and where should we draw the line. Adding more
> output writers? Adding custom export data? Adding formats different from
> WXR?

New description:

 From experience and from tickets (#19864, #19307, #17379) it's evident
 that we need to update the export API.

 High level goals:
  * To be usable from different parts of the code. From the web backend,
 from a CLI script, from an async job.
  * To allow more control of the output format – serve over HTTP, write a
 single XML file to disk, split it and write many smaller XML files, write
 a big zip with many XML files, etc.
  * To allow exporting the data without querying all the posts at once, so
 that we can fit the exports to memory.
  * Keep {{{export_wp()}}} for backwards compatibility without the need to
 keep all (even any) of its code.

 Here's my idea for the part of the API 99% of the developers touching
 export would use and be happy:

 {{{
 #!php
 <?php
 // WP_WXR_Export is an aimmutable representing all the data needed for the
 export and allows us to have it in multiple formats
 $export = new WP_WXR_Export( array( 'start_date' => '2011-10-10',
 'post_type' => 'event', … ) );

 backup( $export->get_xml() ); // string

 $export->export_to_xml_file( 'mom.xml' );
 send_to_mom_to_import( 'mom.xml');

 $export->serve_xml(); // with all the headers and stuff

 $export->export_to_xml_files( '/files/exports-for-my-awesome-website/',
 'export-%02d.wxr.xml', 5 * MB_IN_BYTES );
 }}}

 Before I dive into implementation details (in the comments, not to pollute
 the ticket), I'd like to hear what use cases for extending this code you
 have in mind and where should we draw the line. Adding more output
 writers? Adding custom export data? Adding formats different from WXR?

--

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/22435#comment:1>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software