[wp-trac] [WordPress Trac] #32606: Plugin data migration

[WordPress Trac]

#32606: Plugin data migration
-----------------------------+-------------------------
 Reporter:  freetheweb       |       Owner:
     Type:  feature request  |      Status:  closed
 Priority:  normal           |   Milestone:
Component:  Plugins          |     Version:  4.2.2
 Severity:  normal           |  Resolution:  maybelater
 Keywords:                   |     Focuses:
-----------------------------+-------------------------
Changes (by boonebgorges):

 * status:  new => closed
 * resolution:   => maybelater
 * milestone:  Awaiting Review =>


Comment:

 Thanks for the ticket, freetheweb. I'm a member of the BuddyPress team in
 addition to the WordPress team, so I'm acutely aware of the importance of
 decent import/export tools for custom data.

 That being said, there's little that WP can do all by itself. As noted in
 the thread above, plugins store data in many different ways: custom post
 types, custom metadata for posts and users, custom options, custom
 database tables. WordPress can't predict all of these, which means it'll
 be nearly impossible to build a general tool that is able to recognize and
 identify all types of data created by plugins.

 And recognition/reading is the easy part. It's one thing for WordPress to
 look through the database, recognize non-native data, and show it to the
 user (this is the "export" part of the equation). But because each
 "import" plugin expects data to be in different formats, there's literally
 no way for WP to know where to put it.

 The best that WP can do is to improve its import and export APIs in the
 following ways:
 * Better support for arbitrary data types and data structures, including
 support for various open data standards.
 * A way for plugins to tell WP that a given piece of data is of a given
 type. So: BuddyPress might decide to represent "friendship" data using
 FOAF. WP's API would have a way for BP to announce this, so that the data
 is properly formatted in the xml/json file that's generated as part of the
 export. Then another plugin could announce to WP that it can ingest FOAF
 data from such a file.
 * UIs that support the workflows described above.

 Some technical foundations for kind of workflow are proposed in #22435.

 I'm going to close this ticket as maybelater on the basis of the above. If
 we get a more robust export/import API, we can then start talking about
 what it would mean to support standardized data types. Only then will WP
 be able to play middleman in the types of migrations you've proposed here.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/32606#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform