[Resolved] Problems after post relationship migration

[Author]

Posts

[jimP]

I am trying to: In essence, I'm trying to do what I've done many times in past (though > 1 year ago and with changes since then in Toolset Types). I don't seem to be able to edit an existing CPT, which has a predefined many-to-many relationship with another existing CPT, and select that other existing CPT. What I have to do is go to the (hidden) intermediate CPT, add a new post and connect it with the other existing CPT, then go back to my initial CPT and select this new intermediate CPT post. This seems like a long workaround for what was once a quick operation.

Said another way: I've defined a many-to-many relationship that long works on my site (let's call it CPT A and B, with intermediate CPT AB, which has one-to-many relationship with both A and B). I am editing an existing CPT B and trying to add a relationship to an existing CPT A. The related relationship metabox shows up at the bottom of the edit screen, but when I press the "Connect existing..." button I cannot search for CPT A...it is only bringing up results for CPT AB. So, what I have to do is go to CPT AB (the hidden, intermediary CPT), create a new intermediate post and connect it to CPT A. Then I can go back to CPT B and select this new intermediate post via "Connect existing..." Once I've done all this it works...but this is a much longer process than it used to be.

It is possible that some complication was introduced when I migrated the site or upgraded Toolset plugins, but I see no other problems on the site. Again, my intent is to simply select many-to-many relationships between existing posts by editing one of the posts; this long worked in past.

Link to a page where the issue can be seen: One page I defined in past that works fine is here: hidden link. You'll see under "Related Axes" four from another CPT. These were existing Axis CPTs, and I simply selected them by editing the Climate post and navigating to the post relationships metabox. This is what I want to be able to do again.

I am not yet providing access to my site; I suspect you have a ready answer to my question, based on the experience of others who have gone through recent Toolset upgrades.

[jimP]

I now believe I have a clue as to the problem, which may've been introduced when I migrated my site...see attached image. What I'm seeing is that your migration assistant took my many-to-many relationship and created *two* relationships, both one-to-many, involving the intermediate CPT. There is no many-to-many relationship when I look at existing Relationships. This is why I see only the intermediate CPT when I do "Connect existing...."

Moving forward, I apparently can:

(1) Continue to do the long workaround for new many-to-many relationships as previously summarized (not ideal, but doable);

(2) Possibly edit the existing two one-to-many relationships to merge them into a many-to-many relationship between my two actual CPTs (though this may destroy existing relationships...there are fewer existing relationships than new ones I need to add, so this is a relatively minor concern); or

(3) Possibly create a brand new many-to-many relationship between the two CPTs, while not touching the existing two one-to-many relationships, and start adding new relationships via this new option.

I'd appreciate advice on which of the above is the best workaround at this point.

Jim P.

[Christian Cox]

Hi, I would try option 2 first on a clone of your site, in an effort to maintain those existing relationships. If you encounter problems with this approach, option 3 is your fallback. If you have not yet seen this document, I encourage you to read more about merging migrated m2m relationships: https://toolset.com/documentation/post-relationships/how-to-merge-existing-post-relationships/

Let me know if you have follow-up questions about this process.

[jimP]

Okay, thanks. I have now merged the two one-to-many into the previous many-to-many, and it appears to be correct and successful, in part. Here are my remaining issues:

(1) I apparently had to redo the Views template post-link id code from e.g.

[wpv-post-link id="$ecotypes-axis" output='raw']

to

[wpv-post-link item="@application-axis.child"]

though the former was working prior to merging the two relationships. Can you briefly explain? I used code such as the former many times in past to pull information on related parents in many-to-many relationships.

(2) This is the more serious issue. With the Views edits noted above, all existing (not new) many-to-many relationships are displaying correctly, e.g., see the four posts that display via

hidden link

But (serious issue) I do not seem to be able to add any new many-to-many relationships! There seem to be several issues here:

(2a) When I edit a post and choose "Connecting existing [other CPT]," it now correctly brings up the other parent CPT in the many to many relationship and saves it, and I see this correct relationship when I view intermediate CPTs, but I don't see this new post in the View loop alongside the others.

(2b) I am not sure how to edit the intermediate CPT field specifying the nature of the many to many relationship. In past I could display it alongside the parent CPT, but when I choose the "Select columns to be displayed" gear, it displays only fields for the other parent CPT, plus an *incorrect* related post type (see attached: EcoTypes Main Theme). It does not display the intermediate CPT and related fields.

(2c) What's more, if I edit an existing or new intermediate CPT directly via that CPT edit window, none of the changes I make to the intermediate CPT fields are saved, at all. I have verified this.

So, there may be a pattern in the issues I note above that you will recognize.

Thank you again for your quick and helpful earlier remarks, and I hope we can get through these similarly well.

Jim P.

[Christian Cox]

I apparently had to redo the Views template post-link id code
Yes, the syntax for referring to related posts has changed to support more robust relationship features like M2M, post reference fields, and repeatable field groups. The new syntax is necessary moving forward, so you must update shortcodes throughout your existing codebase. The migration and merge document I shared with you mentions updating shortcodes related to post relationships (#2): https://toolset.com/documentation/post-relationships/how-to-merge-existing-post-relationships/#considerations-before-merging-relationships

(2a)...but I don't see this new post in the View loop alongside the others.
This could be because the Post Relationship Query Filter needs to be updated. If you have not already reconfigured the Query Filter, I suggest you delete the old one and create a new one from scratch. If the new results still don't appear in the View, expand the Post Relationships Query Filter and take a screenshot. Include it in your next reply so I can see the configurations.

(2b)...I am not sure how to edit the intermediate CPT field specifying the nature of the many to many relationship.
Please go to Toolset > Relationships and edit the new merged M2M relationship. Scroll down to the Intermediary Post Type and Custom Fields panel, and take a screenshot. Include it in your next reply so I can see the configurations.

(2c) What's more, if I edit an existing or new intermediate CPT directly via that CPT edit window, none of the changes I make to the intermediate CPT fields are saved, at all. I have verified this.
I'm not sure I understand how you are editing the intermediate CPT directly. Can you take a screenshot showing where you click to edit the intermediary CPT, then a screenshot of the CPT edit window that you're describing? Share those in your next reply.

[jimP]

Again, thank you for your careful and quick response! Here (and see all attached screenshots) is my current status:

(1) I do understand the need for the new syntax. I was confused as the old shortcode syntax still works on my site, outside of this new many-to-many relationship and this one view; I'm assuming it has been grandfathered, and will upgrade it all in time.

(2) Now, on to the multifaceted issue of not being able to successfully add new many-to-many relationships with the now-merged relationship (and I'll keep my prev numbering system for clarity):

(2a) I have now deleted the old Query Filter and created a new one from scratch (see two screenshots), selecting Post filters > Post relationship for type, and settings as per https://toolset.com/documentation/post-relationships/how-to-display-related-posts-with-toolset/#displaying-information-from-intermediary-post-types. It did not affect behavior: the new added many-to-many relationship still shows up when I edit the parent CPT, but does not display in the view (the existing four relationships both show up and display).

(2b) This may be getting at some issue in the database: see attached Relationships screenshots. In brief, there are no custom fields currently attributed to the intermediate CPT, yet I don't want to add a new custom field as I have an existing custom field group previously connected to this intermediate CPT (and info from existing many-to-many relationships stored in this existing custom field group does show up correctly in my current view, as desired). But when I edit the existing custom field group to connect it to the new merged many to many intermediate post type, it does not show up! See the last image for this intermediate post type, created via the merge process you coached me thru.

(2c) To directly edit an intermediate CPT, I simply go to the intermediate CPT in my dashboard menu and edit an item (see attached IntermediateCPT screenshot). The one pictured is a new relationship I created when editing the parent CPT, and the relationship (i.e., the two parent posts) is correct as shown at upper right, but the intermediate post fields (Axis and Axis-App Connection) do not store text when I enter it here and save.

One final point of information: I notice I have both a custom field and a CPT with similar slug: axis-app-connection. (This wasn't intentional: it was introduced by accident when I named the merged intermediate CPT slug.) Not sure if this is a problem, but I can readily edit the custom field slug if needed.

Hopefully this helps! Again, thanks for your clear replies, and let me know what I can provide next.

Jim P.

[Christian Cox]

Okay is it possible for me to log into your wp-admin area and take a closer look? I will activate private reply fields here so you can share login credentials. If that's not possible we can discuss other options.

[Christian Cox]

Okay let's start with the View here: hidden link
I can see that the View is configured to use the Intermediate post type as the content selection, and the "Order by" criteria is set to use the "Axis" custom field. There is a quirk in WordPress query Ordering criteria. If you order by a custom field, but a post in the results does not have a value for that custom field, that post is filtered out of the results. This is why none of the new related posts were appearing - the intermediary posts did not have those fields set. So for now, I have switched this Ordering criteria to be Post Date. We can revisit this once the intermediary fields are implemented correctly.

Next, let's look at the custom field group here: hidden link
The idea is you want to apply these custom fields to the intermediary post type, correct? During the relationship migration process, custom fields applied to the original intermediary post type should have been migrated into the new M2M intermediary relationship seamlessly. It looks like that did not happen here for some reason. Did you keep a backup of the database from before the migration? I would like to see what could have caused this problem. I will activate private reply fields here so you can share a database dump file from the original site.

[Christian Cox]

Since that added relationship was simply for testing, I didn't necessarily want to display on this production site, so I went back to edit the View and (temporarily) set it back to what I had
I don't understand this approach, it seems like you would just remove the testing relationship rather than re-break the View. Regardless, if the intermediary post type is not appearing now in the Content Selection area, that indicates a problem. I'm going to have to do some deep investigation tomorrow on these database backups, and I'll update you when I can.

[jimP]

Yes, that would have been another option! But the axes were not ordered alphabetically in your temporary solution, and I also wanted to fix that globally.

Please do be in touch once you compare database tables, and thanks for your help.

Regards,

Jim P.

[Christian Cox]

Okay I believe I have tracked down the main issue. In the new system, in order to apply a custom field group to an intermediary post type, that field group cannot be associated with other post types or relationships. It must be exclusive to this relationship. In your old site, the "EcoTypes Axis-App Fields" field group was associated with all content types, the default setting (all-content.png). I think this is why the field group association and field values did not transfer correctly. As a test, I modified this field group to be associated with only the intermediary post type (intermediary-only.png). Then I performed the relationship merge process. Now when I edit one of the intermediary posts, I can see that the custom field values were maintained in the new intermediary post (after-merge.png). So I think this is one option for you, you can revert to the backup database and modify the field group settings, then merge the relationships like you did before.

Another option is to simply create new custom fields on the intermediary post type, in the current live site, by going to Toolset > Relationship and editing this relationship. There is a button at the bottom that allows you to create new fields associated with the intermediary post type. Create your custom fields here (they will have different slugs) and copy your content from the old custom fields into the new custom fields. You'll have to update the code used to display this information, and any custom field query filters, but this way you don't lose the content that was added since the pre-merge database backup. I can see that there were only 8 intermediary posts in the old database, so this might be the fastest way to resolve the problem with minimal redundancy.

[jimP]

Thank you for your diligence in sleuthing out the issue here. I am in a very busy time at work, and may not get to this until tomorrow aft US Pacific time, but will try your options then if not before.

Regards,

Jim P.

[Christian Cox]

That sounds good to me. I'm off Fridays and Saturdays, though, so I will not get back to you until Sunday as my day is closing here.

[jimP]

Okay, I've followed the second option, and have successfully transferred field content via earlier export. I've fixed all templates and etc. at this point. I'll keep this open just in case I discover problems, but for now we can consider it resolved.

[Christian Cox]

That sounds fine, I'll stand by for your updates.