Tell us what you are trying to do?
Part of my current project includes a simple contact database using a single CPT. Some of these contacts have numerous aliases and I need a separate record for each alias. How can I create a field that associates an alias Contact L with the post_ID or post_title of her true identity, Contact B?
Is there any documentation that you are following?
No. I've found similar questions in the support forum, but none were helpful.
Is there a similar example that we can see?
Not that I know of.
What is the link to your site?
It is a subsite of hidden link, but is private while under development.
How can I create a field that associates an alias Contact L with the post_ID or post_title of her true identity, Contact B?
Hello, Toolset's post relationships feature is designed to manage associations between two posts in different post types, so unfortunately the post relationship feature is not helpful in this case. You could definitely create a custom field that holds a numeric value, and store the post ID of the true identity in the alias post's custom field.
That method is pretty straightforward, and can be useful, but it is not very user-friendly when it comes to data entry. When creating or editing this value in wp-admin or front-end Forms, you must use the numeric ID of the other "related" post. It may not be immediately obvious how to find the ID of that related post if you do not have wp-admin access. Even if you do have access, you'll have to search for it in the post list and copy + paste that or something into the field. In other words, there is no intuitive input field type that will help you find the post by title, but store the post ID, like in true post relationships. It's just dealing with raw numeric values.
Also, the relationship is not automatically reciprocal, meaning that there is no indication in the true identity post that there are known alias posts. You may need to establish the "relationship" in both the true identity post and all the alias posts for reciprocal associations.
One other option you might consider is a taxonomy-based approach instead of a custom field approach. You could create a custom taxonomy specifically for managing post relationships between Contacts. You could create a new term for each true identity Contact post, and add that term to each alias Contact. Terms are easier to understand than numeric IDs, and they offer autocomplete inputs in wp-admin.
Another option you might consider is a Repeatable Field Group (RFG) inside the Contact post type, where each Alias exists as a separate row in the RFG. Depending on what you need to accomplish, you might have to include the true identity as one of these rows, or you might need to break it out so that those fields exist separately from the RFG. Hard to say based on the information I have available. Keep in mind that in a View of RFG, it is not possible to filter by the fields that exist separate from the RFG in the parent post type, and vice versa. In a View of the parent post type, it is not possible to filter by the fields in an RFG on that parent post type.
Thanks again, Christian! I hadn't considered the custom taxonomy approach. I will think about how that might work.
I had originally tried the second option, but ran up against the problems you stated at the end of the paragraph. Folks will need to see all the names - including the aliases - sorted "lastname, firstname" in a single list. I couldn't figure out how to do that using the RFG approach. I'm pretty much a newbie, so if there's a not-too-onerous way to do that, please let me know.
Folks will need to see all the names - including the aliases - sorted "lastname, firstname" in a single list. I couldn't figure out how to do that using the RFG approach. I'm pretty much a newbie, so if there's a not-too-onerous way to do that, please let me know.
I don't see a problem with displaying the names sorted as such in a single list if you're flexible about how the data is stored and displayed. The simplest solution is a single View of all RFGs (no post relationship filter in this case) that sorts all the names alphabetically by post title, without grouping by identity. In other words, the true identity and its aliases may not be listed together if alphabetical ordering places other results between them. Technically speaking, each RFG row is a post and the internal title field is stored as the post title. See the screenshot attached showing a parent post with 3 RFG rows - one true identity and two aliases. You could store the full name in the format Last Name, First Name in the RFG's "internal title" field. All the names would appear in the View results list, including aliases and true identities, sorted alphabetically. That's the simplest solution and it's fairly straightforward to implement.
The results list can include any information from the RFG like other custom fields, as well as information from other custom fields and taxonomy terms applied to the parent post or other ancestors/related posts. Keep in mind that whatever information you add in the loop will be repeated with each result. The setup becomes more complicated as you add in custom search filters, sorting controls, pagination, and other customizations.
If you need the First Name and Last Name stored as separate fields in the RFG entry for other reasons (filtering, reporting, display elsewhere), this means you'll have some duplication of information. Unfortunately that may be necessary here, unless you are capable of implementing a custom code solution to facilitate sorting using two combined custom field values. A View's results list can be easily sorted by a single custom field as the primary sort key, but cannot be easily sorted using a second custom field as the secondary sort key. This is a known limitation of Views. So it is best to have the first and last names combined in one field for sorting the results. That one field could be the post title or a separate custom field, but my example utilizes the existing post title without the need for a separate custom field or custom code.
This looks like it will work if I can learn how to accomplish it. Thank you for being a patient teacher. Questions:
1. I had been planning to auto generate the parent post title (First Name Last Name order) using directions found in the support forum "add auto generate post title from fields." If the First Name and Last Name fields for the True Identity are located in the RFG along with the alias identities, is this still possible?
2. For the RFG posts, would the user manually enter the "internal title" or can it be automatically generated from the entry in the First Name and Last Name fields?
3. I am planning to use front-end spreadsheets (WP Sheet Editor Pro) for sorting, filtering and editing. Do you suppose that will alleviate some of the Views limitations that you mention? (I just subscribed to it, so I know less about it than I do about Toolset, if that's possible.)
4. The True Identity checkbox is a taxonomy field or custom field or does it matter?
5. If a user deletes the parent post, are the related RFG posts also automatically deleted? That is the behavior I want and it would be a big benefit to using your method vs. the one I was proposing.
1. I had been planning to auto generate the parent post title (First Name Last Name order) using directions found in the support forum "add auto generate post title from fields." If the First Name and Last Name fields for the True Identity are located in the RFG along with the alias identities, is this still possible?
I assume you mean this ticket: https://toolset.com/forums/topic/add-auto-generate-post-title-from-fields/
In theory yes it's still possible, but the code must be adjusted to find the custom name field values in an RFG related to the parent post. That means you will probably need to use the Post Relationships API toolset_get_related_posts to query RFGs related to the post being updated, and filter those results by the True Identity custom field value to get the correct RFG row. Then get the name field values from that post and use them to build the new post title string. Depending on whether or not you choose to display the post title in wp-admin when editing the parent post type, and whether or not you use the Block Editor to edit the parent post, this process may lead to data sync problems where the value in the database and the value in the editor are not the same. The post title that was updated programmatically will not be updated in the editor unless the page is reloaded.
2. For the RFG posts, would the user manually enter the "internal title" or can it be automatically generated from the entry in the First Name and Last Name fields?
The internal title field can be automatically generated from its own custom fields, but the same data sync issues apply here. Refreshing the page after updating any of the RFG values would be one workaround. Using the classic editor instead of the Block editor might be another workaround, since the page always reloads.
3. I am planning to use front-end spreadsheets (WP Sheet Editor Pro) for sorting, filtering and editing. Do you suppose that will alleviate some of the Views limitations that you mention? (I just subscribed to it, so I know less about it than I do about Toolset, if that's possible.)
I really have no clue, I've never used that 3rd-party plugin, so I don't have any input on its functionality or available features. I seriously doubt you will be able to just drop a 3rd-party sorting and filtering system into a View and have it work out-of-the-box. My guess is you'll need a significant amount of custom code to integrate 3rd-party filters in a View. If the system accepts a JSON data model, you might be able to use Views loop to generate such a formatted data set. This is really a huge topic to discuss, so I suggest you create a separate thread for more details.
4. The True Identity checkbox is a taxonomy field or custom field or does it matter?
Either is possible and could work, but I'd make it a custom field because it will only have one or two possible values. Doesn't really make sense to create a whole taxonomy for one or two options. A radio field or select field with two options like "True identity" and "Alias" would work well and be easy to use in a filter. A checkbox might be more difficult to filter on or use in conditionals, for technical reasons involving custom fields that don't store a value. It's better to have a value of (A or B) stored as opposed to a value of (A or empty).
5. If a user deletes the parent post, are the related RFG posts also automatically deleted? That is the behavior I want and it would be a big benefit to using your method vs. the one I was proposing.
The related RFGs are not deleted automatically, they will remain in the database without a parent post association. A custom code snippet would be required to either trash or permanently delete those RFGs from the database automatically.
This ticket is now closed. If you're a WPML client and need related help, please open a new support ticket.
