Saltar navegación

[Resuelto] Repeating parent fields in a list with wpv-for-each in Types 3.0

Este hilo está resuelto. Aquí tiene una descripción del problema y la solución.

Problem: I would like to loop over repeating fields in a parent post using wpv-for-each.

Solution: You should create a View that shows the parent post, then use wpv-for-each inside the View's Loop Output editor. The wpv-for-each shortcode is not designed to show fields from a parent post.

This support ticket is created hace 6 años, 6 meses. 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.

Sun Mon Tue Wed Thu Fri Sat
8:00 – 12:00 8:00 – 12:00 8:00 – 12:00 8:00 – 12:00 8:00 – 12:00 - -
13:00 – 17:00 13:00 – 17:00 13:00 – 17:00 13:00 – 17:00 13:00 – 17:00 - -

Supporter timezone: America/New_York (GMT-04:00)

Este tema contiene 4 respuestas, tiene 2 mensajes.

Última actualización por Stephen Vaughan hace 6 años, 6 meses.

Asistido por: Christian Cox.

Autor
Mensajes
#911804

Hi,

I am running through the documentation to see how the new post relationships works. I am using the Album/Song (Beatles/Revolver) as a test.

So there is a screen shot:

enlace oculto

Emulating this I set up a view template to show most of the related data in a table. Normally for repeating fields that I want to display as a list I would use something like the following:

    [wpv-for-each field='wpcf-composer']

  • [types field='composer' item='@track.parent'][/types]
  • [/wpv-for-each]

That's not working for me so I am mocking this up with the following instead:

<td style="width: 70%;">• [types field='composer' separator='<br>• ' item='@track.parent'][/types]</td>

It seems that using item='@track.parent' to query up to the song field doesn't want to work with wpv-for-each. Is this a known problem?

One other question. Something that I am trying to get my head around, though I am sure there is a good explanation, is the fact you can only get the intermediary post types to appear in the menu and other places (selectable in views) when you set up the relationship. There are a number of instances where this could be problematic.

Firstly you need to be 100% sure of the functionality you are targeting in terms of perhaps having to edit fields in the intermediary type in the future. So for example the client enters data incorrectly on creation of a song in album scenario, they enter the wrong track and because the type isn't accessible there is no way now to go in and edit it. The only workaround is to delete the instance and recreate the song on album with correct track number.

If you have an extensive catalogue already entered (many many songs on many many albums) and a new field is required in the intermediary post, yes you can add the field but how to you go back and get access to it per song/track post.

Even if you started well with the intermediary post type visible in the menu, if you go to view the records you get a list of Tracks: Song ID - Album ID. Not very informative. So even if you want to correct the data in a specific track number field it wouldn't be easy to correct. It would be nice to see the relationship explicitly displayed as Track: Song name - Album name.

Perhaps I am overlooking some things?

#912070

It seems that using item='@track.parent' to query up to the song field doesn't want to work with wpv-for-each. Is this a known problem?
It's the expected behavior. The wpv-for-each shortcode is not intended to be used to show one post's repeating fields from the context of another post. If you want to loop over a related post's repeating fields, you should first create a View that shows the parent post. Then inside the View's Loop Output, you may include the wpv-for-each shortcode and loop over the parent's repeating fields within the context of the parent post.

Let me know if you have additional questions about this, or if I misunderstood your request.

#912078

Ok, Thanks Christian. That's what I Thought.

Extrapolating out, you could of course add a bands type and then a band members type, which leads me to my next question. I see in the documentation that you can go as far as grandparents when pulling in information for views and templates. Can you go to Great-grandparents as well?

I might be getting a bit cryptic so I won't go any further!

On my enquiries regarding when to show or not show the intermediary post types in menus etc. and what do do if you all of a sudden realise that this is needed, months into the project. Can you give me some insight into the logic and rational on why we are restricted to only having the option when creating the relation? Also why the post types in the intermediary post types are not more informative i.e Intermediary Post Type Name: parent name - parent name instead of Intermediary Post Type Name: parent ID - parent ID. It would be far more useful.

Let me know if I am supposed to post a new ticket for these questions.

#912430

I see in the documentation that you can go as far as grandparents when pulling in information for views and templates. Can you go to Great-grandparents as well?
Of course, in the same way you can access a Grandparent post from a Parent post by nesting Content Template contexts, you can access a Great-grandparent post from a Grandparent post. Nested Content Template contexts allow you to display information from any generation ancestor post.

Let me know if I am supposed to post a new ticket for these questions.
Yes please create separate tickets for each question, as our support policy is to address one issue per ticket and I would prefer to keep this one focused on repeating parent fields.

#912438

Hi Christian,

Thanks again. I will post my other questions again. I have another one on the list. There are some gaps in the documentation. Hopefully we can plug these as we go.