[wp-trac] [WordPress Trac] #32606: Plugin data migration
WordPress Trac
noreply at wordpress.org
Wed Jun 10 18:00:06 UTC 2015
#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
More information about the wp-trac
mailing list