Skip Navigation

[Résolu] Beta Types/Relationships API – Intermediate Post types – 2nd Class Citizens????

Ce fil est résolu. Voici une description du problème et la solution proposée.

Problem:

In the latest beta version of Types plugin, there is new many-to-many relationship, I am asking for / hoping for the titles of the intermediary post types to either:

A) Be accessible in the metabox when adding a relationship to posts

B) Auto generate using the parent post titles and not their post Ids

Solution:

Q1) Be accessible in the metabox when adding a relationship to posts

There isn't such a feature within Types Beta version. Currently, you can try this:
When you edit a single parent post, you can use the button "Connect existing XXX", see our document:

https://toolset.com/documentation/post-relationships/how-to-set-up-post-relationships-using-toolset/

screenshot:
https://cdn.toolset.com/wp-content/uploads/2018/02/toolset-post-relationships-example-departures-arrivals.jpg
button "Connect existing Flight"

Q2) Auto generate using the parent post titles and not their post Ids

At the moment, we don't support that in the GUI in a very nice way, but I think we can open that to debate
and the client should be already able to use the toolset_build_intermediary_post_title filter:

/**
         * toolset_build_intermediary_post_title
         *
         * Allow for overriding the post title of an intermediary post.
         *
         * @param string $post_title Post title default value.
         * @param string $relationship_slug
         * @param int $parent_id
         * @param int $child_id

Relevant Documentation:

https://toolset.com/documentation/post-relationships/how-to-set-up-post-relationships-using-toolset/

This support ticket is created Il y a 6 années et 2 mois. There's a good chance that you are reading advice that it now obsolete.

This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.

Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.

No supporters are available to work today on Toolset forum. Feel free to create tickets and we will handle it as soon as we are online. Thank you for your understanding.

Sun Mon Tue Wed Thu Fri Sat
- 9:00 – 13:00 9:00 – 13:00 9:00 – 13:00 9:00 – 13:00 9:00 – 13:00 -
- 14:00 – 18:00 14:00 – 18:00 14:00 – 18:00 14:00 – 18:00 14:00 – 18:00 -

Supporter timezone: Asia/Hong_Kong (GMT+08:00)

This topic contains 15 réponses, has 2 voix.

Last updated by Geoffrey Cleverley Il y a 6 années et 1 mois.

Assisted by: Luo Yang.

Auteur
Publications
#623618
Screen Shot 2018-03-03 at 4.59.29 PM.png
Screen Shot 2018-03-09 at 4.14.22 PM.png

I am a little concerned about the Intermediary Post Types being used in the New Many to Many relationships coming up in the next major version of Types.

I've been testing the Beta, and it seems that some functionality has actually gone backwards, and the new Intermediaries are very limited in their usefulness... 2nd class citizens.

This is worrisome, I have several big sites that are using the legacy Types relationships to full effect.

Many Post Types in complex many to many relationships that are required to handle in-depth content management and relationships.

An example.

My Movie Encyclopedia Site.

I have Movie People connected to Movies with two relationships - two intermediate (child) post types.

FIrst one - Character Casting
The second one - Movie Crew Roles

Now Movie Crew role will be fine as the new intermediate post type - The actual post title never gets called.

But Character Casting - this post type should actually have access to setting the post title via setting up the relationship.

With the new relationships, the post title is auto-generated in the following format:

'Character Casting: 10 - 11'

Not being able to set this title from the relationships wouldn't be so bad, if it wasn't auto-generating the title from the post id but it could auto-generate the title from the connected post titles, eg

'Character Casting: Enter The Dragon - Bruce Lee'

Then these intermediary titles could be searched. Which is essential for the admin of these sites. This would actually work really well for the movie crew role too:

'Movie Crew Role - Enter The Dragon - John Smith'

////////////

The workaround creating three cpts is no good either:

Movie
Person
Casting

And have one to many between both Movie + Casting and between Person + Casting.

But that is suboptimal by a large degree compared to the present situation.

You can see from the screenshot, in the current methodology (effectively doing this), in the post relationships box, when you attach a child to a parent, you have access to the other parent in a drop-down box. But with the new one to many, you don't have access to the other posts relationships.

-----

I guess I am asking for / hoping for the titles of the intermediary post types to either:

A). Be accessible in the metabox when adding a relationship to posts

B). Auto generate using the parent post titles and not their post Ids

or preferable both

?

-----

Also the new intermediary post types that are replacing the old use of child types to connect two parents, cant be used in any other relationships.

On many sites, the intermediary post types might be parents of another type, or child in another relationship.

This wouldn't be such a problem, as I could use one to many relationships, but as mentioned above... the create relationship interface doesn't show the other relationships in the metabox when creating.

----

Thanks for listenting

Jeff

#624138
names.JPG

Dear Jeff,

1) Be accessible in the metabox when adding a relationship to posts
There isn't such a feature within Types Beta version, if you agree we can take it as a feature request, currently, you can try this:
When you edit a single parent post, you can use the button "Connect existing XXX", see our document:
https://toolset.com/documentation/post-relationships/how-to-set-up-post-relationships-using-toolset/
screenshot:
hidden link
button "Connect existing Flight"

Q2) Auto generate using the parent post titles and not their post Ids
When you create the "Relationship", in the final step "Names", enable the options:
a) "Create an intermediary post type"
b) "Intermediary Post Type visible in WordPress admin menu",
see screenshot names.JPG
then you will access the Intermediate Post types as a normal post type, and setup the post slug as what you want.

#624215
screenshot1.png
screenshot0.png
screenshot2.png
screenshot3.png
screenshot5.png
screenshot4.png

Hey Luo.

Firstly, let me state that I only have the greatest respect for yourself, Nigel, Beda, Christian, Shane and the other Support Staff at OnTheGoSystems, you guys have saved me on many occasions, and I apologise if any of my frustration seeps through in this post.

The upcoming double whammy of Toolset about to update relationships coinciding with the impending drop of Gutenberg is proving, somewhat.... time consuming and difficult.

I also apologise for the length, but I would like to be very clear in any feature requests that I am making.

//////////

Q 1) Feature Request! Yes please. But I want to make sure we are clear about what I am requesting as a feature.

Without it, the new one-to-many relationships in the API are far less useful than the old ones. Better for DB queries fair enough, but far less functional in their primary purpose - connecting post types through relationships.

When your update goes live it is going to destroy the usability of several sites if I update the relationships, and I can't be the only one.

Please see my screenshot above. The screenshot you showed me has a button to connect another post type.

That isn't good enough.

In my screenshot in the original post, you can see that currently, you can add not only the other post type in the one to many relationships, but the other relationships of that added post type are available in a drop down.

Can you see how not including this functionality is a game changer for people using one to many relationships?

At present, from one post type I can create another child post type, and in the same interface select the other relationship for that child post type. Now all I can do is create or connect another post type. But If I create the child post type, I have no access to that other post types relationships. I can edit all the other fields, but have no access to the relationships metabox.

I imagine that this wasn't thought as necessary, because of the lovely new Many to Many Relationships.

Well, if the new Many to Many relationships didn't use crippled intermediaries, then that might be the case. But the new intermediaries are crippled.

By that I mean, they are only available in that one specific relationship.

But the beauty of the current system is that an intermediary can be an intermediary between three parents. Or it can even be the parent of another intermediary. The current intermediaries can be used in a very flexible way to connect together many different one-to-many and many-to-many relationships that have a virtually infinite complexity to match just about any given need.

The new ones simply can't

Unless of course you just string together lots of one to many relationships as a workaround. But then we have come full circle to my problem above - needing to click into every post individually to edit linked relationship settings.

For new clients, this isn't so bad (It's not great either, or even good). But as the client will never have seen a one-to-many relationship of the current sort, they will just have to get used to clicking into the actual other post and making connections - not knowing any better.

But how am I supposed to sell this to clients of the existing sites. They are used to the flexibility offered and shown in the screenshot. Now I need to somehow get them to think that this is an upgrade, adding extra steps to achieve the same thing, and not being able to view the same level of information from each post type.

An update is supposed to reduce friction, they are expecting an upgrade not a downgrade in experience.

///////////

Q2)

I am aware of this. My slugs and post types have been created. But please look at the second screenshot above, and added screenshots in this post.

I am not talking about the slug.

When I create a link in the new many to many relationships, between two posts. And I create the intermediary post, which fields do I have access to?

I only have access to the custom fields specified in the relationship.

In my screenshot (screenshot1) of a Casting intermediary between a Movie and Movie Person, you can see I have access to the two custom fields I have made:

Character name
Character Bio (BTW in the beta this information doesn't show in the post edit screen atm - see screenshot0)

Now currently, I have the character name as the Post name. But since I don't have access to the Post Title from the pop up window that creates the intermediary, I have had to add the character name as a custom field.

The actual post title of the intermediary is autogenerated by types in the following format:

intermediary-slug: parent_post_id - child_post_id

So in my demonstration example that is:

'Castings: 42 - 31'

You can see this in the screenshot (screenshot2).

So now if I want to have this intermediary post titled in any proper way, I would then need to go to the casting intermediary admin list, open this specific post entry, and change the name.

Again this is a downgrade in usability. I need to explain to clients this is the new 'better' way... it obviously isn't better because it is going to take several more steps and lots more time cumulatively.

However, I could live with just the intermediary custom fields being available when the relationship connection and intermediary post is created...

IF

The actual autogenerated name doesn't use the connected posts post_id, but instead uses their post_title.

In the following format:

intermediary-slug: parent_post_title - child_post_title

So in my demonstration, I have mocked this up and made a screenshot (screenshot3). It reads like this:

'Castings: Famous John - Big Movie'

(Famous John being the Movie Person CPT connected to Big Movie the Movie CPT)

It could even include both post_id and post_title, please see example screenshot (screenshot4)

'Castings: 42 Famous John - 31 Big Movie'

Otherwise, I am just going to end up with an admin list of intermediary posts that can only use the WordPress admin search to search by the Post IDs

Do you think any user is going to be aware of the parent Post IDs?

No... they aren't. But they will know which movies or people they want to search the intermediaries by.

As I say crippled.

Another thing, but I am sure this is going to be fixed, but currently, in the intermediary post edit screen it doesn't show which posts the intermediaries are connected to. Please see screenshot (screenshot5).

So I would say I have another feature request.

Am I correct in understanding that if the content is being created and submitted in the front end using a CRED form I will be able to use the CRED API to change the created intermediaries post title to use the connected parents post_titles instead of the post_ids?

That is something, but not really for site users using wp-admin, it doesn't help the situation.

Can you think of any other workaround to achieve the same thing in an automated way, from the admin?

///////////////////////

In summary

Feature Requests:

1). In the One to Many Relationships Metabox, include any other relationships of the post being attached alongside the other posts custom fields.

You have achieved something similar in your nested repeatable groups. it would seem like similar functionality - since they both share the same methodology of post types/relationships querying.

2). When creating the Intermediary post type during the connection of a many to many relationship from a Post type, either:

2a). Include the Post title as a field that can be edited directly in the pop up box.

or

2b). If the above isn't possible, then don't use the Post_ID to autogenerate the intermediary, or don't only use it. The autogenerated intermediary title should also at the minimum include the post titles of both parents so that they are actually useful in the wp admin screen.

As in, they can be searched using the wp admin search. - expecting people to search through intermediary posts by their post_id is..... insane.

ALSO

May I ask, if the new Types with Relationships isn't going to immediately fix or remedy these problems, am I going to be forced to use the new Relationships API? or will it be a case, as in the beta, of choosing to implement the new relationships API.

As in, if I upgrade, am I going to be able to choose to continue to use the legacy relationships?

If not then I have a third feature request:

3) Maintain the new Relationships API as an opt in feature until problems such as the above are fixed. Allow for feature parity with current relationships to be reached before forcing the upgrade to the new Relationships.

I use a variety of tools, from ACF to CMB2 to Toolset.

I have always relied on Toolset primarily for the relationships. If I just want custom fields or basic relationships, often other tools are more suitable.

But for relationships, bi-directional, one to many and many to many, Toolset has always ruled the others in my opinion. Even Pods, the interface of Toolset has always been far better for creating these highly complex relationships, without needing to be an expert myself on SQL and creating custom schema etc.

I must say, the new relationships API works very well for some of my sites, but not the more complex ones that Toolset was always the only choice. For these ones, in its current form, it is going to cause me some serious headaches with clients if I need to implement it and rebuild out their implementations.

Thanks again

Jeff

#624479

There are lots of questions in this thread, we can handle them one by one:
Q1) Can you see how not including this functionality is a game changer for people using one to many relationships?

I assume we are talking about the column "Movie People" of below screenshot:
hidden link

If it is, the screenshot is using many-to-many relationship, in the column "Movie People", you can connect current post to existed "Movie People" post, There isn't exact same feature within Types Beta version 2.3-b4, the only workaround is :
button "Connect existing XXXX" in the latest version of Types Beta version

After you click the button "Connect existing XXXX", you can search XXXX posts, and connect current post with existed "Movie People" post.

See my answer above:
https://toolset.com/forums/topic/beta-types-relationships-api-intermediate-post-types-2nd-class-citizens/#post-624138

Can you confirm it? Then we can move to other questions, thanks

#624518
screenshot1.png
screenshot2.png

Hey Luo,

Yes I think that is probably best.

So

Q1)

Yup, that's the point, this feature doesn't exist. I would like to stress why omitting it is important, and make a feature request.

The workaround isn't a workaround because it doesn't offer the same functionality either in:

1) Completing a task
2) Providing Clear access to information (the other relationships involved)

----------------

In the old (current?) behaviour, there is no such direct function as 'many-to-many' relationship. Users create them by connecting Parent CPTs to each other through Intermediary shared Child CPTs. yes?

However, those old intermediary CPTs were fully functional CPTs. They could be used as either parent or children in other one-to-many or many-to-many relationships.

And crucially, they had access to the full range of metaboxes when connecting them to their Parent CPT in the relationships Metabox.

Please see screenshot1.

In this screenshot, you can see when adding a 'movie-award-winner' child intermediary CPT to a 'Movie Person' CPT, I can also set all the other relationships for that intermediary. I can connect it to a 'Movie', 'Movie Person', 'Movie Character Casting', 'Movie Crew Member', etc etc

It is an intermediary that connects many different Parents, as it has relationships to many, and each of those parent post types has potential relationships to each other.

In the new Many to Many Relationships the intermediary is very limited. And this is not possible.

I could still achieve something that does the same by using one-to-many relationships.

But from each Parent, the relationship metabox that opens up the connected post (the intermediary) for editing only contains the custom fields for that other post.

It doesn't give you access to the other one-to-many relationships that the other post belongs to.

Please see screenshot2.

This is the new one to many relationship metabox. It is connecting a demo Character-Universe-Movie to a Movie.

However, the Character-Universe-Movie also has a one-to-many relationship with a Movie-Studio. I can't see that, and can only set it if I click in to edit the post type.

In the current relationship metabox, I could connect this post to both its direct child, and connect that child to its other parent.

With the update, this functionality is no longer available. Correct?

-------------------------------

Another example from just yesterday, where this came up as necessary.

A website for Fun Run Events Organisation, and their CPTs and relationships

Many to Many Relationship
CPT - Fun Run - Parent
CPT - Tasks - Parent
CPT - Task at Fun Run - Intermediary Child between 'Fun Run' & 'Task'

One to Many Relationship
CPT Fun Run - Parent
CPT Position at Fun Run - Child

Many to Many Relationship
CPT Task at Fun Run - Parent
CPT Position at Fun Run - Parent
CPT Task in Position at Fun Run - Intermediary Child between 'Task at Fun Run' & 'Position at Fun Run'.

All Fun Runs are top-level - define them once.
All Tasks (Road Marshal, Water Dispenser, First Aider) are repeatable and top level. Define them once

We need to allocate tasks to each Fun Run, so we have that as an intermediary. It is important though this is not just some second class post type. It is going to be used in another relationship.

Positions at Fun Run is a child of Fun Runs, they are specific to each Fun Run only, having a map embed, a time required etc.

Each Task needs to be allocated to a Position. So we are using a 'Task in Position at Fun Run' intermediary to allocate each task from its specific position for that Fun Run.

Using the new many-to-many relationships this relationship set up is impossible. As the 'Tasks at Fun Run' is an intermediary of the Many-to-Many relationship and is locked away. It can't be used in a relationship with any other post type.

So the only option is to use the current methodology. That is to say, use lots of one-to-many relationships. Connecting the Parent Post types together by Child Post types.

But as detailed with the screenshots above, this new way is worse than the old way. Instead of being able to connect a parent post to a child, and from the same metabox connect the child to its other parents. I need to click in to edit that child directly and make those connections from within the child post.

------------------

This has two major problems:

1). More steps - In a situation where a child is the child of 3 or 4 other post types, this is increasing workload 4x

2) Information accessibility - Currently, from each parent, I can see what other connections the Child posts have. I can see exactly how it fit's in the overall data structure. In the new structure, I am blind. I can see the child post that is being connected, but I don't know how that post is connected to other posts.

Would you agree, or am I missing something?

My big problem then is I need to 'upgrade' client sites to something that is actually going to create more work for them... Not sure how I sell that.

----------------

So my Feature request is:

In the one-to-many relationships metabox to add a post-relationship to another post. Make the other posts relationships available to be edited/set.

Basically provided an alternative to the limits of the new many-to-many relationships. There are going to be many sites that require a many-to-many relationship that has 3 or more parents connected by an intermediary. The new system is a very very big step backwards to the current system.

If I have been clear, let's move on.

Thanks

Jeff

#624555

Thanks for the input, for the request:

In the one-to-many relationships metabox to add a post-relationship to another post. Make the other posts relationships available to be edited/set.

Basically provided an alternative to the limits of the new many-to-many relationships. There are going to be many sites that require a many-to-many relationship that has 3 or more parents connected by an intermediary. The new system is a very very big step backwards to the current system.

I forward it to Minesh, he manages the feature request of Types plugin, our developers will evaluate it, but there isn't any ETA to apply it.

For other requests for Q2, I think there are below 4 requests for Q2, can you confirm it? thanks
Q2A) In the One to Many Relationships Metabox, include any other relationships of the post being attached alongside the other posts custom fields.

Q2B) Include the Post title as a field that can be edited directly in the pop up box.

Q2C) If the above isn't possible, then don't use the Post_ID to autogenerate the intermediary, or don't only use it. The autogenerated intermediary title should also at the minimum include the post titles of both parents so that they are actually useful in the wp admin screen.

Q2D) Maintain the new Relationships API as an opt in feature until problems such as the above are fixed. Allow for feature parity with current relationships to be reached before forcing the upgrade to the new Relationships.

#624590
1.png
2.png
3.png

Hey Luo,

So Q2A - is really the feature request already made - adding post relationships to the accessible fields in a one-to-many relationships metabox.

--------

Q2B & Q2C are connected and related to the intermediate post types created in the new many-to-many relationships. Both request are about using the post title of the intermediate.

---- Many-to-Many intermediate post type feature requests ----

----------

Feature Request 1:

Have the Post Title for the intermediate post type accessible to edit as well as it's custom fields, during a relationship connection.

The Post title of the intermediate should be editable from either of the connected Post Types.

When I connect one post type to another post type in a many-to-many relationship, the pop-up box only allows the editing of the custom fields of the intermediate post type.

Not being able to edit the Post Title is restrictive. Currently, the post title is autogenerated, and there is no option to change the title during the process of making the connection.

---------

Feature Request 2:

When an intermediary post type is created by the connection of two post types in a many-to-many relationship, the autogenerated intermediates post_title should at the very least include the post_titles of both of the connected parent and child post_titles

Currently, when a many-to-many relationship is established between two post types the intermediary post that is created has a title is autogenerated in the following format:

intermediate-post-type: parent_post_id - child_post_id

e.g

Castings: 31 - 43

This title is useless in the WP Admin. The native post search tool will only be able to find intermediate posts if you know their post_id.

A better format for the autogenerated intermediate post title would be:

intermediate-post-type: parent_post_title parent_post_id - child_post_title child_post_id

e.g.

Castings: Enter the Dragon 31 - Bruce Lee 43

This way, the intermediate can be searched for in the WP admin by either of its connected posts.

To be using the Post IDs alone in the title of the intermediary is suboptimal, especially if those titles aren't available to edit when creating the intermediary.

Intermediate post types connecting many to many relationships can be important in their own right, if you are going to be giving the option to include them in the WP Admin, what is the point in naming them in this way? It can't be that much more difficult to include the post_title if you are already including the post_id.

------

My final question was about whether or not the new relationships are going to be forced on users?

Thanks

Jeff

#624807

Thanks for the details, I forward them to Minesh too, our developers will evaluate them, and for the question:

My final question was about whether or not the new relationships are going to be forced on users?

Yes, you are right. the new relationships will replace old post type relationships.

#624821

OK

Well, as you may have gathered, I am non too pleased. This 'upgrade' is going to be incredibly flawed, and in many ways less useful than it should be.

Each of the features I've requested is not a new feature, it is just a request for a current feature that the upgrade is going to remove.

Current features that I am presently making use of, and I am pretty sure other people are too. So, brace yourself, I expect support to be receiving a lot of requests from surprised and flustered users when it drops.

Given these problems, the timing is also problematic. Such a breaking change at this time, so close to Gutenberg, is just going to compound things for many.

Your developers might not consider it a breaking change, as there is a new API, and a path to migrate old relationships to new ones. All the relationships will keep working etc etc

But that's not the only type of breakage, there is also breakage in site user interaction.

The following types of sites are going to suffer:

1. Sites that rely on many-to-many relationships which include an intermediary that is used in other relationships. Ie multi dimensional many-to-many relationships between 4 or more post types.

2. Sites that use Intermediary posts from many-to-many relationships as full citizens, those posts need to be exposed fully in WP Admin and need to be searchable by title using WP admin search.

I have 3 sites like this, that I can't see any way that the new Relationship API, as is, isn't going to screw them, and I was discussing a new site (Fun Run site), that I would have used Toolset for, but can't see any way to use it now - all I can say is, expect there to be many more.

Honestly, for these sorts of sites I am going to have to explore Pods again, see how their interface has developed recently. But I am not expecting much to be fair.

I understand how the new Relationships API will benefit database querying, but rushing to get it out before fixing these usability issues is a mistake, especially given the added plugin lockin resulting from moving relationships from post_meta.

I also understand how it improves usability for basic many-to-many relationships.

I have generally been an advocate for Toolset in a mostly pro ACF and pro Pods WordPress developer world (groups, forums, etc).

Anyway that would be my final Feature request:

Make the New Relationships an Opt-In feature upgrade, or provide some type of Opt-Out for some period.

Thanks for listening

Jeff

#624842

Thanks for the input, I will forward your words to our developers, and will update this thread if there is anything news.

#624846

Thank you Luo, it would be good to know if they respond, how they respond.

Cheers

#625122

I have escalated this thread to our 2nd tier supporters, and our developers are invited too, I will update this thread if there is any news.

#625485

Here is the feedback from our developers:

1) about IPTs being "second class citizens" - that is, in fact, correct. We use them to hold values of custom fields and as I mentioned before, tie their existence strictly to the connection between the two other posts (can't have an intermediary post without the association)

2) regarding setting the title of intermediary posts, at the moment, we don't support that in the GUI in a very nice way, but I think we can open that to debate
and the client should be already able to use the toolset_build_intermediary_post_title filter:

/**
         * toolset_build_intermediary_post_title
         *
         * Allow for overriding the post title of an intermediary post.
         *
         * @param string $post_title Post title default value.
         * @param string $relationship_slug
         * @param int $parent_id
         * @param int $child_id

Please let me know if you need assistance for this.

3) I'd also make the client aware that many-to-many relationships are a new added feature but nothing changes about one-to-many relationships in this regard
if the many-to-many doesn't fit to their complex case, they won't be robbed of any existing functionality even if they migrate to the new m2m data structures, we're starting with the minimal viable product and they can expect the set of the features to grow

#625517

Hey Luo, thanks for relaying my concerns.

And Hey Adriano and Mohammed.

Re 1)
I understand what a valuable new addition these are, in most of my sites they will suffice and be a great improvement. So thank you for that.

I can understand why they couldn't be an intermediary in another many-to-many relationship.

But I don't clearly understand why they can't be used within another relationship as either a parent or child in either a new one-to-many or many-to-many relationship. However, I, of course, defer to your far greater skills and knowledge.

Actually, none of this would really be an issue if the other two points were addressed.

-----------------

Re 2)
Regarding the toolset_build_intermediary_post_title filter - That is great news.

Even better to be available in GUI too, but knowing this feature is there makes the new many-to-many relationship intermediaries much better for some of my problem sites.

It would be great for Toolset documentation to include references to all these useful filters.

I found it starting line 64, in intermediate_post_persistence.php. I am going to put it to work immediately and will let you know if I have any problems.

Very much appreciated.

-----------------

Re 3)

This is for Adriano and Mohammed, apologies for all the questions.

they won't be robbed of any existing functionality even if they migrate to the new m2m data structures

I have to strongly disagree, and the fact that the devs think that shows a short-sightedness that requires me to go through this again.

But first let me state that, structurally, I completely agree that no functionality has been removed. I can create all the same relationship structures that I did before, and output them as such.

However, may I ask a question of the developers?

Do you guys agree that UX is also a part of functionality?

As we can see from 1) above, in some cases, I would need to forgo using the new many-to-many relationships and instead create more open many-to-many relationships by chaining together several one-to-many relationships.

(Doing it the legacy way effectively - as you suggested this 'functionality' remains - worsened experientially, but remains)

However, the legacy way had relationship meta boxes in the connected posts that provided access to the other posts other relationships.

Do you think that this is not reduced functionality?

Not with regards to creating the relationship structure, but reduced functionality in the way those structures can be created.

What do you think?

Luo is fantastic support, suggesting he says that functionality hasn't been reduced is putting him in a difficult position.

In such cases, it is going to take several more steps for a user to create the same relationship structures. The amount of steps depending on the complexity of the relationship structure.

Or am I wrong?

Not only that, but without being able to see the connected posts other connected relationships, the user of the site has access to less information about the overall data structure.

Is the ease of access to information not also functionality?

For new sites - less of a problem

For existing sites, can you see how it might be problematic to retrain the site owners in this new methodology?

They are going to ask why they need to do more to achieve the same result.

What do you suggest I say to these clients?

I also understand this is the MVP for the new structures. However, you are replacing a product that wasn't an MVP.

MVPs are more easily acceptable at the beginning of a products life cycle and release.

As I understand it, the repeatable field groups use the new relationship structures. They are custom post types with relationships. I am using the relationships API to output them in my templates.

And Repeatable Field Groups are also nestable, yes?

So we can nest groups inside of groups inside of groups.

So, on a post type with a deeply nested set of repeatable field groups, I have access to each level of field group for editing.

Is this not relative to having posts that are connected in a one-to-many relationship giving access to the other posts other relationships?

Anyway, without wanting to be a complete pain in the ass, I look forward to hearing what you think about this. And I hope I have taken you through my thinking with regards to the real world implications of the new structures and this MVP.

If you clear up these minor issues, I do actually look forward to the full project, it should be head and shoulders above the current competition.

-----

Given that you have the filter for changing the intermediary title I am happy with that.

So I guess my BIG BIG wish for a feature to be added to the developing product is:

In posts connected by one-to-many (or many-to-many but not urgen) relationships, in the relationship metabox, provide access to the connected posts other relationships.

----

Thanks again

Jeff

#625519

Since there are lots of questions in this thread, I am trying to answer them one by one, as usually, we create different thread for different question

For the feature reuqest:
In posts connected by one-to-many (or many-to-many but not urgen) relationships, in the relationship metabox, provide access to the connected posts other relationships.

I think it will handles most of problems in this thread, I forward it to Minesh, and our developers will evaluate it, thanks for your input

This ticket is now closed. If you're a WPML client and need related help, please open a new support ticket.