Do I need the premium version to use post-relationship fields?

Do I need the premium version to use post-relationship fields?

Yes.

It’s available at Toolset.com

If you first want to contact us and talk about if it’s a fit for your site or not, you can do so here.
https://toolset.com/toolset-free-consultation/

ok I see, thanks!

though even if I cannot create new relationship fields, it looks like the importer plugin has created the field correctly within Types, and in the post editor I can see the posts from the other post-type, and if I select them then they are correctly stored and remembered..

is the free version missing some core functionality to handle the relationship fields or is it just missing the backend UI to create/manage those fields?
I am asking because there might be some other reason why the importer is not populating those fields, and that won’t work even if I purchase your premium plugin…

thanks for your help!

Hi

I refer to our previous message (part of):

… and I can see them in the post editor, but they are not being populated by the import…

The suspicious thing is that if I go to edit the post fields I cannot see those fields from your admin page… and I don’t seem to be able to create a brand new relationship field if I wanted. …

1. The fields are visible, and editable, in the single Post Edit Screen, but not visible in Toolset > Post Fields > any_group > edit

Then those fields you see in the single post edit screen are not Types fields, but other Custom Fields.

2. Relationship Fields, or “Post Reference” Fields, as we call them in Toolset Types, are only available in the paid, Toolset Types 3.xx versions, not in any lower (or free) version.

I think hence, that this AddOn Plugin you used, is creating some Custom fields, eventually counting with the paid Toolset Types?

I am not saure about this as we do not produce that migration tool.

If you own Toolset Types in paid version, the issue should be discussed over here:
https://toolset.com/forums/forum/professional-support/

Now relating to your last comment, you can – even with the free Toolset types, create Post Relationships.
This is described in depth here:
https://toolset.com/documentation/user-guides/create-a-custom-post-type/#parent-child-relationships

These are however not custom fields that you set up, instead, its done on the Post Type basis (where you edit Post Types).

It is possible that the relations you see are the Post Relationships and not the Post Reference Field as is available only in the Paid versions.

Hi Beda,
thanks for your detailed reply!

so, in the end we’ve purchased the premium Toolset Types but unfortunately it appears that the importer plugin is actually not supporting the premium post-reference fields and doesn’t even create those fields in backend (while with the free version of Types those fields where created in backend, and correctly populated with the list of posts from the other post-type).

That’s probably because, as you say, the post-reference fields are technically a different thing which is available only on the premium plugin, but the importer plugin probably assumes the structure and fields of the free Types in order to import Drupal’s Entity Reference Relations, and behind the scenes it probably uses something like the post-relationship workaround.

So at this point I guess (I’m still talking with them too about it) the problem could be that these fields are actually part of a bigger structure involving Drupal’s Organic Groups module. And the import is failing to setup the relations because it doesn’t understand the Organic Group structure…

in any case, many thanks for your help!

Please let me know how this develops.

As well I want to mention, legacy relationships are stored basically in one, hidden custom field:
_wpcf_belongs_{your_parent_post_type_slug}_id
That will be stored in each child post and hold the single parent post ID.

But, as said, that is not visible in the backend as fields – instead, it’s present as the Post Relationships

Since you purchased Toolset you can as well reach us there.

yes, indeed I’ve noticed that if I select something in the Brand dropdown and then save the post, it gets assigned a postmeta named:
_wpcf_belongs_brand_id

so I was thinking to code something which would set that metafield in bulk for different groups of posts.
so if I do something like

update_post_meta($post_id, '_wpcf_belongs_brand_id', $brand_id);

then I will see the brand selected in that dropdown within the post’s edit page. Am I correct?

fortunately the import-plugin is storing the original drupal ID as postmeta for each post, hence I can export a list of ids from the original site, and then code something which would update the brand metafield to the corresponding wp post_id.
Hacky but should do the job. ??

yes, indeed I’ve noticed that if I select something in the Brand dropdown and then save the post, it gets assigned a postmeta named:
_wpcf_belongs_brand_id

This is done by Types, in the Legacy (Free Types) Post Relationships.
It means, you have a parent post type “brand” and the currently edited post to which that field belongs to, is child of such a post (of which the ID is stored in the Field)

so I was thinking to code something which would set that metafield in bulk for different groups of posts.
so if I do something like

update_post_meta($post_id, '_wpcf_belongs_brand_id', $brand_id);

You can do that, and update the hidden custom field of the current post with the ID of a parent.
Remember that each Post can have only One Parent of a Kind.
That means, each of the _wpcf_belongs_{type_slug}_id fields can have only one ID of a parent post.

All you need to make sure is:
– To have a Parent/Child Post structure (Lets say, Brands is parent of Products)
– Each product can hence have only one field of meta key _wpcf_belongs_brand_id, and that field is populated with the ID of the Parent Brand post.

Always backup first, so have some data to restore in case the code doesn’t work at first.

The problem will be to feed your code with the correct data for the import.
The code you suggest supposes you are on the current child post, and have the parent Post ID stored in the $brand_id.

We cannot help here with custom code about how to create such logic.

As well, it is to note that the Free Types plugin is to be deprecated soon (by end of 2018)
Do you have plans for the after-time?

The problem is, that this Free Version of types, will not be supported or debugged/fixed anymore later.
https://toolset.com/2017/11/types-plugin-is-moving-to-be-a-part-of-the-complete-toolset-package/

Since you purchased Toolset, I really suggest to not proceed with Free Types, neither the product, nor the support here, but instead, download Types 3.x and get (dedicated) support here:
https://toolset.com/forums/forum/professional-support/

We might even be able to help you to solve the issues using Types 3.x as we do have some DOC’s about imports of related data, that might help you to solve this issue from another approach (using a Import Plugin and CSV data)

I can support here only Free Types features, which will as well stop by end 2018.

ok I see, thanks!

though we really need those fields just for the import/migration, because then we will re-structure the entire website and use a different approach for the brands/sections.

in any case, excluding the relationship fields, I assume that if we switch to the premium version after the import, the other Types fields will still work even if they have been created/populated with the free version, is this correct?

p.s. the import plugin is adding a postmeta to the posts with the original drupal id, hence I can export a list of drupal ids from the db, filtering by brand, and then use that list in my code to populate the brand-relation field and also to add the posts to a category (which will be the new way to handle the sections).

many thanks for your help and precious information!