Tell us what you are trying to do?
I am using the Ultimate Member membership plugin and also Pods for some custom post types and taxonomies. I would like to replace both with Toolset plugins but keep the same metadata. I am not sure if Toolset will allow me to use the same meta names.
Is there any documentation that you are following?
No.
Is there a similar example that we can see?
On another website, I have set something similar with Pods, Buddy Forms, and Beaver Builder, and Themer, and that's what I want to do on another domain, only with Toolset plugins and I want to keep the metadata so it all stays in sync with my CRM ActiveCampaign > hidden link
What is the link to your site?
hidden link
I am not sure if Toolset will allow me to use the same meta names.
Hello, I assume you're referring to the slugs of custom post types, custom taxonomies, and custom taxonomy terms. Since the slug is how the database maintains the integrity of each of these components, the slug is the most important part when interchangeability and interoperability is concerned. In these cases I would expect your CPT slugs and Taxonomy slugs to be mostly interchangable between Types and other systems. The same is true for taxonomy term slugs. All of those are typically interchangeable when they follow WordPress naming standards, though there may be a few edge cases here and there where Types is more restrictive than other systems because of internal naming conventions. If you'd like to submit a CSV file containing your post type slugs, taxonomy slugs, and taxonomy term slugs, I'll be glad to review those for potential problems.
The main area where data is not usually interchangeable is in custom fields for posts, Users, and taxonomy terms. Those are also known as postmeta fields, usermeta fields, and term meta fields. You did not mention custom fields specifically in your original comment, so I'm not sure if these are sources of concern or not for your CRM system. Types field slugs always have a wpcf- prefix in the database that is not editable. In wp-admin, that prefix is not displayed to the admin user, but it is always present in the database. So if you create a custom field for posts with a slug of "address" in wp-admin, that custom field's slug in the postmeta database table will always be wpcf-address. When importing fields from other systems, you may be able to let Types control those existing fields, but the data format required by Types may be different from the data format for other systems. Simple data formats like plain text, numbers, and boolean values are usually well-suited for interchange between Types and other systems. More complex data formats like dates, serialized values like checkboxes, and repeating items are often not interchangeable. Post relationships in Types are not interchangeable, as they are managed in custom database tables.
I hope this information is helpful. If you need more detail about any of these components, feel free to ask and I'll do my best to get the information you need.
Thanks a lot for your detailed answer. Looks like it would require some serious work. Do you think that, for that particular site, I could keep Pods and the CPTs, tags, and taxonomies, and use Toolset Forms, instead of the plugin that I use now (Buddy Forms), to allow users to create and edit their profiles? The current plugin can recognize custom fields as well, I guess it's because they offer special integration for Pods. So O expects that custom fields wouldn't be supported. Thanks.
Do you think that, for that particular site, I could keep Pods and the CPTs, tags, and taxonomies, and use Toolset Forms, instead of the plugin that I use now (Buddy Forms), to allow users to create and edit their profiles?
I think you could use Toolset Forms to allow Users to create and edit their standard WordPress Profile information in this setup. You would be able to manage the standard WordPress fields like first and last name, email address, create a unique login, password, and user bio/description. Custom usermeta fields from 3rd-party systems would not be supported, as you already suspected.
I don't see any problem using Toolset Forms to manage these elements of User profiles when other systems are in play. You would be able to implement Toolset Forms using Forms shortcodes if you don't plan to use the Toolset Blocks plugin: https://toolset.com/documentation/programmer-reference/forms/cred-shortcodes/
