The reason the issue is difficult to solve expeditiously is because the challenge sits at the border of where data duplication plugins and Pods meet:
- Pods defines a data structure. For some complex data types, such as images, more than one WordPress core field is used to store data in cases where WordPress core data structures would not support certain functionality
- Many third-party plugins provide a quick “duplicate” button for duplicating data. Most of these plugins do not check for extra associated data.
For the problem to be solved by the Pods team, we would have to either take on the challenge of maintaining patches or notifications for all other plugins, or would have to change data structures in significant ways, potentially introducing new problems for many thousands of sites and applications.
WordPress core import/export works fine with Pods data structures for duplicating or importing data.
Likewise, WordPress multisite for translation and WordPress core localization functions work correctly with Pods.
Unfortunately, it is not within plugin scope, nor within our realm of authority, to change features provided by other plugins.
The relevant data structures, for those writing their own import/export/duplicate scripts is that for a given field with wp_postmeta or wp_termmta meta_key field_name, there will be an additional field named _pods_field_name containing enriched data for the Pods admin interface.
Pods API provides the pods()->save() method as one way to save data quickly for custom scripts.
WordPress core import/export also works correctly, as it copies/migrates all data associated per post without making assumptions as to the meaning or use of data structures.
