Mixed-up relationships. Relationship from one field to multiple fields?

I think this can be simpler:

Series is associated with lessons, and lessons is associated with speakers. That way in your series pages, you can query for its lessons, which will return the speakers for each lessons. With that, you can display a list of lessons, and whose speaking in each, as well as a list of speakers from every lesson.

I think that’s what you need right?

That also let’s you on a speakers page, query what lessons they are teaching, which will provide you with what series that lesson is a part of.

Josh, thanks for giving your thoughts on this. I agree…that would be a simpler setup, and thankful it can be set up this way! Very helpful.

It would be cool if I could setup tri-directional relationships, though I’m not sure if that would help or just complicate things!

I’m new to Pods, so I’ll be figuring out how to accomplish those things you stated above. The one that’ll give me the most trouble, I’m guessing, is the Speaker page, particularly displaying the series the speaker has contributed to (without listing any series more than once). The same might go for the Series page (without listing any speaker more than once on that series).

I appreciate your help and the work Scott, Jim, you, and the others are doing. Looking forward to the integration with CMB2, as well!

Joe-

Glad to help.

I see what you mean about duplicate display, but that just means you will need to collect all series for a speaker, and then eliminate duplicates. Shouldn’t be too hard.

Please let us know if there is anything else we can do to help.

Take care,
Josh

Josh —

Okay, I’ve set up my three Pods CPT fields the way you suggested. Just one quick question.

Setup: My Speaker CPT’s lesson_speaker_name field is related to my Lesson CPT’s lessons_speaker field. When I’m adding a lesson, I can choose the Lesson Speaker from all Speakers that have been added to the Speaker post type.

Question: When I add a Speaker, though, I just want the lesson_speaker_name field to be a Plain Text field. I don’t want it to be an autocomplete field pulling from the Lesson CPT, since every speaker that’s added will be unique. How can I do that?

I hope that makes sense.

Thanks —
Joe

P.S. Another consideration is to hide the Speaker CPT lesson_speaker_name field from the UI (hence, only using it as the related field) and use the Speaker CPT’s post title as the speaker’s name. Is that the best solution?

P.P.S. And, is it common practice to use related fields with the sole purpose of relating CPTs, then hiding those fields from the UI?

When I add a Speaker, though, I just want the lesson_speaker_name field to be a Plain Text field.

You mean in the admin right? If so, it can either be autocomplete, checkboxes or dropdown.

Another consideration is to hide the Speaker CPT lesson_speaker_name field from the UI (hence, only using it as the related field) and use the Speaker CPT’s post title as the speaker’s name. Is that the best solution?

I think calling it lesson_speaker_name is making this conceptually harder. It’s not really the speaker name, its the speaker itself. I’d call it speaker. Through that field you can access any fields of the related post, such as post_title, which would be the logical place to store the speaker’s name.

P.P.S. And, is it common practice to use related fields with the sole purpose of relating CPTs, then hiding those fields from the UI?

Not sure really. But if it makes sense, and it might, do it. I can see why you might want to hide it on one side.

Thanks, Josh. The reason I want a plain text field on the Speaker side is that I only want it to be a uni-directional relationship. I don’t want Speakers added through the Add Lesson page. Maybe that’s what I should have mentioned in the beginning. Is a uni-directional relationship possible?

Yes, a uni-directional relationship is possible. You create a field on one side, related to the other Pod, and don’t select a bi-directional field.

I’m a dope. I didn’t even attempt to make a relational field without adding a “Related Field”! I may be alone here, but it would be a nice touch to add Required indicators on the required fields. Again, thanks for your help, Josh.

The only two fields that are required in the Pods editor are label and nam. Name is auto-created from label, so we don’t mark anything required as that is relatively straight forward and you will get an error if you leave them blank.

That said, I can see why the field you’re referring to seems required, since it animates in like it does. Maybe it’s default, non-selected state label should be Select (Optional) ? What do you think, or do you have other ideas?

I think your solution would be great (and would’ve prevented my issue). I think, too, that it was probably the “Related Field” animation that deceived me into thinking it was required.

Of course, the HTML5 attribute, required, could be added to the input tags for the Label and Name fields, though that wouldn’t have any effect from a visual perspective.

An indicator next to those labels would be a nice bonus. It would be easy enough by adding an extra class to the required field’s label or to one of the containing elements. Without that, an indicator cannot be added via CSS, but would require JS. All in all, I think what you suggested is acceptable, but it’d be nice to see the indicators.