[Resolved] Migration from other Custom Field and Taxonomy plugins

[Author]

Posts

[saint]

Tell us what you are trying to do?

Two questions:

1.) I'm wondering if it possible, or if there are any plans to have some type of a Toolset migration tool that allows you migrate the custom fields, custom taxonomies, and term metas generated in other plugins (e.g. Pods, ACF, etc.) and smoothly into and replicated in Toolset?

2.) I noticed in the Toolset theme integration, you have Genesis, Divi, etc. But wanted to know if you guys integrate with Astra theme? If not, could we put in a request for this integration? It's extremely well-crafted and gaining grounds in popularity.

Thanks,

[Shane Supporter Languages: English (English ) Timezone: America/Jamaica (GMT-05:00)]

Hello,

Thank you for contacting our support forum.

In response to your questions.

1. Unfortunately there isn't a way to migrate the information however you should be able to bring them under types control by following the instructions in the link below.
https://toolset.com/faq/how-do-i-convert-existing-custom-types-and-fields-to-types-control/

2. Our Plugins are already compatible with the astra theme as this is what we currently use to do our demo sites on discover-wp.com

Thanks,
Shane

[saint]

Hi Shane,

Thanks for your response.

1.) Will I need to have the previous plugin still installed once I've brought it all under Types control? I am trying to minimize my plugin footprint.

2.) Could we put in a feature request to have a migration tool like this? I believe this would help Toolset gain even more users if there is a simple way to port over from their existing solutions that they may be unhappy with.

3.) Re: Astra theme - awesome, thank you!

[Shane Supporter Languages: English (English ) Timezone: America/Jamaica (GMT-05:00)]

Hi Saint,

1. So long as the previous plugin doesn't remove the items when it is disabled then it should work. All thats needed is a reference to the field in the database and bringing the field under types does this.

2. There was a migration tool available but I believe during some point in the development it was simpler to reference the fields using Types .

Thanks,
Shane

[saint]

Thanks, Shane. I am currently using PODS, but am planning to switch to Toolset. I _believe_ PODS follows best practices and leaves it alone, but not 100% sure. Do you know if once I switch over, and disable PODS, the fields would be referenced just fine?

Secondly - I've also created a lot of bi-directional relationships between CPTs in Pods. Is this something I'm able to carry over and/or re-create in Toolset (via the Post relationships update that's slated for release in 2 weeks?)

Best,

[Shane Supporter Languages: English (English ) Timezone: America/Jamaica (GMT-05:00)]

Hi Saint,

I doubt it should. What you can try is to disable the plugin and then recreate the CPT in Types using the same slug and all your data should re-appear.

Next with the relationships you will need to remake them as Types uses different way of doing the Post Relationships .

Thanks,
Shane

[saint]

Hi Shane,

"I doubt it should."

As in, you DON'T believe the fields would be referenced just fine once I've ported everything over from PODS and use Types to reference the slug? Or, you do?

"with the relationships you will need to remake them as Types uses different way of doing the Post Relationships"

Curious, if I use ACF to create these fields, and Types for CPT, will I be able to have the ability to toggle related content? Or, will I need to create the custom fields in Types as well?

For example: hidden link

This is an example of a Post Layout that I've customized to display, but we have the ability to toggle and choose what type of related content to query in PODS.

Thanks,

[Shane Supporter Languages: English (English ) Timezone: America/Jamaica (GMT-05:00)]

Hi Saint,

Sorry for the confusion. I meant that I doubt that the PODS plugin would delete the custom posts from the database after it is removed. So once you reference the CPT with the same slugs then it would work.

The ACF custom fields work well with our plugins but i'm not entirely sure of what you're asking, could you clarify this for me.

For the reference of the Post Relationship, why I say its different is because we use a hidden field in a particular naming convention. PODS i'm certain doesn't use the same method we use.

Thanks,
Shane

[saint]

Hi Shane,

No worries. Basically I plan on creating custom fields with ACF, but tie that with Types/Views and Beaver Builder (or Elementor.)

But, with PODS, you have these deep integrations with BB that allows you to query relational data, and display them on the frontend with advanced post capabilities.

hidden link

Please let me know if this helps provide some visibility into what I mean.

Thanks!

[saint]

Hi Shane,

Wanted to also ask, is there an intuitive UI/UX/frontend design that allows you to contextually edit related CPTs that's been linked via relationships inside a given CPT record?

There are a few features that I would like to learn if Toolset is able to provide, please see below video for some context:

hidden link

Thanks,

[Shane Supporter Languages: English (English ) Timezone: America/Jamaica (GMT-05:00)]

Hi Saint,

Thanks for the videos.

For the first video here hidden link

Now our plugins do it similarly but ofcourse our methods are different. So we use Types to control the setup of the CPT, Taxonomies, Custom Fields, CPT Relationships ETC.

For content display we use our Views plugin. Now views is integrated with Beaver Builder and you can display your content. Now with views you can perform your various queries and then you can use Beaver Builder to format the display from the content views provides.

Here is a link of our documentation to what i'm referring to specifically.
https://toolset.com/documentation/user-guides/view-templates/

Now a content template is if you want to customize your single post and then you can apply that template to multiple posts. Now i've never used PODS but from your video I can see that our Views plugin provides a more powerful solution for querying and displaying the content.

Here is some information about our Beaver Builder integration and views.
https://toolset.com/documentation/user-guides/using-toolset-with-beaver-builder/

https://toolset.com/documentation/user-guides/#integration-themes-plugins

For this video here: hidden link

Yes our Types plugin does provide this in a similar manner. With our Pending Types 3.0 update coming we would see a major improvement in the relationship model on how its done.

For the custom fields and the post associations we do these in groups so you will generally create a field group and then associate that field group to a CPT and within that group you can then populate the various custom fields that you want on that CPT. Now there are different field types as you have then in PODS.

https://toolset.com/documentation/user-guides/many-to-many-post-relationship/

https://toolset.com/documentation/user-guides/create-a-custom-post-type/

https://toolset.com/documentation/user-guides/using-custom-fields/

So as you can see with the links i've provided. Toolset does provide the same or similar functionality but our workflows are different.

Please let me know if this helps and if there is anything you would like me to clarify for you.

Thanks,
Shane

[saint]

Hi Shane,

Thanks for your note.

1.) I'm reading the examples and am curious about it's UX of the functionality below (e.g. the contextual list that shows up which you can drill into the other CPT _right from the original CPT_, add/edit, then close out and be back to the original CPT screen.)

hidden link

2.) For bi-directional relationships, is there also an option to create Foreign Key fields and tie them together in addition to, or instead of, using the Wizard?

I feel much more comfortable using Foreign Keys to tie together fields, because it would be much easier to also reference if I want to pull back fields manually. E.g., foo_fk.bar to pull back the field "bar" from the table "foo" via the "foo_fk" field in that CPT.

In Toolset videos re: post relationships at: hidden link

I noticed that everything was done with these buttons in the editor. If I want to, could I create a custom field for each CPT and bi-directionally link them like how I showed in the videos with PODS?

3.) Re: Views with BB - That's great to hear, from what I understand, what you're saying is that you can use Views to build a query and pull back a resultset, but then you can use BB modules to display that resultset. Is that interpretation correct?

b.) Are there any videos showing how BB/Elementor/etc. styles & displays the resultset built from the Views query?

4.) Also, are there deep integration with Ultimate Addons for Beaver Builder, Ultimate Addons for Elementor, and Astra theme as well, so that their Advanced Posts module (and other modules) can display the resultset queried from Views?

5.) I saw in the post-relationship video that there are "intermediary objects" that helps bridge between two CPTs.

a.) Is this an outdated concept now with the upcoming release of Types 3.0?
b.) Theoritically, is there a way to "daisy-chain" between posts using relationships? E.g. CPT #1 <-> CPT #2 <-> CPT #3 <-> CPT #4 if there is no relationship between CPT #1 and CPT #4, but there are relationships that could get you there with in-between CPTs?

[Shane Supporter Languages: English (English ) Timezone: America/Jamaica (GMT-05:00)]

Hi Saint,

I must apologize for the delay in response.

1. Unfortunately no our user interface is more general. Meaning you will create the Field groups and Fields but you're not able click the icon like in PODS.

2. There is a way to do this but each relationship would need to be done manually and retrieved manually. Lets say you want to get the parent custom field from a child post. You will need to write some custom shortcode to do this since you are using a different field to do your relationships. Normally you can get the parent value with something like [types field='my-field' id ='$my_parent_slug'] [/types]

3. That is correct. Views can use BB to build its templates.

4. Unfortunately the only thing i'm aware of with BB is that views is able to use BB to build the template. There wasn't any mention of the addons. However if the addons hook directly into BB then it might be possible to use these addons but I cannot say for sure as I haven't tested this.

5. Yes for Many to Many relationship we use the intermediary CPT to make this kind of relationship possible.

a.) Actually no this is not an outdated concept but the implementation will be different. The good thing is that if the relationship was built with an older version of Types then the new version will automatically migrate your old relationships to the new setup.

b.) Yes daisy chaining is possible but lets say you want CPT#4 ancestor which would be CPT#1 then you would need to do a 3 level nested view in order to get the values of CPT 1 but it is definitely possible.

Thanks,
Shane

[saint]

Hi Shane,

No problem, we're just getting up to speed so definitely appreciate you helping us understand the nuances of Toolset. It seems incredibly powerful and well thought out. I've referenced below for context.

1. Unfortunately no our user interface is more general. Meaning you will create the Field groups and Fields but you're not able click the icon like in PODS.

==> Ok, I see, could we put in a feature request to improve the UI/UX to make it easier to access and edit relationship linked CPTs more contextually from within a CPT? I know UX improvements has been something everyone has been talking about for quite some time now and it'd be great to see a facelift on that front in the near future.

2. There is a way to do this but each relationship would need to be done manually and retrieved manually. Lets say you want to get the parent custom field from a child post. You will need to write some custom shortcode to do this since you are using a different field to do your relationships. Normally you can get the parent value with something like [types field='my-field' id ='$my_parent_slug'] [/types]

==> I am interested to learn more about how this works, because I plan on referencing relationally linked fields and custom taxonomy term metas.

a.) I notice the slug is usually 'my-field' with a dash. What is the actual database field name called -- 'my_field'?

b.) If I were to reference them in the HTML markup like below:

[fl_builder_insert_layout slug="[wpbb post:pods_display field='hero_reassurance_row']"]

Which is a:

- Nested shortcode
- Main shortcode is a Beaver Builder shortcode (e.g. [fl_builder_insert_layout slug="???"]
- To a CPT Custom Field in PODS
- Which is the slug to a Beaver Themer Layout

Apologize for this "Inception-level" setup, hope this makes sense and happy to elaborate if it doesn't.

How would I build this in Toolset? Would it be something like:

[fl_builder_insert_layout slug=" [types field='hero-reassurance-row' id ='$my_parent_slug'] [/types]"]?

My main confusion right now is the "$my_parent_slug" value. What should this be? Trying to frame a Types example in the context of how we currently do it in PODS to better understand how it fits.

GOAL: Any video examples of how to manually pull back fields and term metas from another CPT or custom taxonomy that we can create on-the-fly in the HTML markup modules of Beaver Builder or Elementor is what I'm looking for.

4. Unfortunately the only thing i'm aware of with BB is that views is able to use BB to build the template.

==> The add-ons are actually modules that are created by the Astra theme team.

hidden link
hidden link

If there is not any integration between Toolset and addons created by the Astra team, may I put in a feature request to deep integrate with them? They produce a fantastic suite of high-quality addons for BB and Elementor that would benefit Toolset to leverage.

5. Yes for Many to Many relationship we use the intermediary CPT to make this kind of relationship possible.

a.) Actually no this is not an outdated concept but the implementation will be different. The good thing is that if the relationship was built with an older version of Types then the new version will automatically migrate your old relationships to the new setup.

b.) Yes daisy chaining is possible but lets say you want CPT#4 ancestor which would be CPT#1 then you would need to do a 3 level nested view in order to get the values of CPT 1 but it is definitely possible.

Great. Do you foresee any performance problems with chaining across multiple CPTs? Also, are there any video walkthroughs of chaining?

Appreciate your taking the time going through this with us!

Thanks,

[Shane Supporter Languages: English (English ) Timezone: America/Jamaica (GMT-05:00)]

Hi Saint,

1. Yes you can put in a feature request for this but you will need to create a separate ticket that outlines the details and you can share a video of what exactly the feature should do.

2. Currently the relationships are referenced using a hidden custom field in the format _wpcf_belongs_{cpt-slug}_id where the {cpt-slug} would be the replaced with an actual slug. In practicality it would look something like this _wpcf_belongs_property_id if the CPT slug is property.

a) you're actually not limited to just hyphens but you can use underscores as well. So you can use my_field or my-field. It all depends on how you initially defined it.

When the field is saved however it is given a wpcf- prefix so it would be saved like this wpcf-my_field.

b) If this setup was to be done in Toolset it would look like this [fl_builder_insert_layout slug="[types field='my-field' output='raw'][/types]"]

I added the output='raw' as this will give the data unformatted from the database. For some of our custom field they are returned in wrappers. So a link custom field if returned without the raw attribute you will get a clickable link and not the raw url.

The id = '$my_parent_slug' attribute is only if you want the value from the parent CPT to be passed in.

3. So if you have 2 CPT's Cars and Manufacturer where Manufacturer would be the parent of Cars. Lets say the slug for Manufacturers was defined as manufacturer when the cpt was create.

Now if i'm on a single car page and i've link that car to a manufacturer. If I was to get the name of the manufacturer then I would do something like this [wpv-post-title id='$manufacturer'] (this is going to change in the types 3.0 update) but in our current stable release this is how its done.

For the chaining of CPT, we only have tutorials of how to create a one to one relationship and its the same method using to chain each subsequent child.

https://toolset.com/documentation/user-guides/creating-post-type-relationships/#creating-a-post-relationship

4. If you have these addons, you can provide me with a copy of it as well as BB so I can test and give a definite answer.

5. No I don't see any issue if you are to start using the new methods. I can say that issues will occur for customers using previous versions and updating to this version as they may have custom coding that involves the post relationships.

Thanks,
Shane