[Resuelto] Toolset Membership Site deleting Relational CPTs with recent updates

[Autor]

Mensajes

[Ronald E]

Hello,

I was working with you on this question https://toolset.com/forums/topic/toolset-forms-update-to-2-2-1-1-broked-some-of-my-associations/ . It got cancelled due to my delay so I am starting a new question thread. Also, to save time, I created a video so you can what has been happening.

Here's the video:

 <em><u>enlace oculto</u></em> 

From the previous question I provided you all the login and FTP info.

Please let me know what our next steps should be.

Thanks,
Ron

[Nigel]

Hi Ron

I see on your site that the relationships are migrated relationships from Types 2.x, and that the form "Edit AAIMCo Article" is using the old format of linking child posts to parents (with a '_wpcf_belongs_parent-slug_id' custom field).

Types 3 included a backwards compatibility layer, which was designed to ensure such things continued working smoothly, but it is not infallible and it looks to have failed in this case.

And so the solution would be to update your site to that it corresponds to how this would be set up if you were creating it now, with Types 3 relationships etc.

I don't think that should be too onerous.

If I'm understanding correctly, you have a View which generates a list of articles written by the current user on their membership page (I looked at your list of Views but wasn't sure which one it was), with a link to an edit form to be able to edit the article. There is also a button to go to a form to add new articles for that user.

I don't think you need any custom code or special fields here.

Take a backup before making any changes.

I don't have a membership account for testing and I'm making some guesses here about how you have this set up.

The first thing to discuss is the button to add new articles. How does the form this links to know which writer should be linked to the article?

Here's how I would do it.

The context for that button should be the writer post you want the article associated with. If you were on a single writer post page that would be taken care of, but looking at your video I think you are on a generic "my account" page.

So maybe you could create a View whose sole purpose it to create the required writer context and to output the button that links to the form.

So make a View to query writer posts and add a query filter so that the required writer post is returned (I'm guessing each writer post has a user as a post author, and we can use the current user as the post author for the query filter).

Then in the output section of that View you output the link to create a new article. Use the Toolset Forms button and choose Create Child Post Link, which will insert a cred_child_link_form shortcode that links to the form to publish a child article.

You'll need to specify the page that has the child post form, and choose "Set the parent according to the currently displayed content" so that the correct parent writer is pre-selected.

Be sure to regenerate automatically the form to add new articles itself, which will add the fields in the required format. You will probably want to hide the parent writer selector so that users cannot change it.

(These steps are described here: https://toolset.com/documentation/post-relationships/selecting-parent-posts-using-forms-create-child-items/#creating-forms-when-a-parent-post-is-preselected)

Do some testing and confirm that from the my-profile page the users are able to publish an article, and it gets automatically associated with their writer profile post.

Then go ahead and regenerate automatically the edit article page. This time I think you can simply exclude the parent writer selector, because it will have been set when creating the article, and there is no reason to change it when editing the article.

Now update your View which lists the articles belonging to a user and which includes an edit link, and re-insert the edit post link to ensure that it is in the correct format etc. Note that if your current forms are very old you may not be using the current required workflow for edit forms, which is to create the edit form, then insert the form into a content template which does not get assigned to any post type and acts simply as a container for the form, and then select that template when you come to insert the edit link, again with the Toolset Forms button and choosing the Edit post link. (See https://toolset.com/documentation/getting-started-with-toolset/publish-content-from-the-front-end/forms-for-editing/)

Let me know I have misunderstood anything or you run into problems.

[Ronald E]

Thank you Nigel for this great response. I will take your instructions and do my best to implement. I'll be in touch with progress and needs of your expertise so I'll keep this thread open.

[Nigel]

Sure no problem, I'll just mark this as awaiting your feedback.

[Ronald E]

Hi Nigel,

I followed your directions and we are making headway but there are still obstacles. I feel it is my fault for not providing a very good explanation so I will endeavor to do a better job this time.

Some history to the existing functionality. Minesh helped out a lot to be able to get all this to work with Types 2.X. Here is the links to that which provide all the explanations, code and setup to date that is now failing with Types 3 relationship changes.

This was to get it to work with an Edit Cred Form in Types 2.
https://toolset.com/forums/topic/using-user-account-to-connect-member-profiles-with-articles-via-intermediary-cpt/

This was to get it to work with an New Cred Form in Types 2.
https://toolset.com/forums/topic/connecting-two-cpts-with-intermediary-cpt-via-cred-new-form/

For Types 3 I followed your directions on creating a View (named it “Assign Writer To Form”). I automatically regenerated the Add New Article Form. I attached some images to show how it worked.

The image titled" toolset-article-output.png" – This image shows you the output. “…rapid fire test 2” is the correct layout for displaying the member who wrote the article. Test post 6 and test post 5 was done after following the directions you so kindly provided. They only show the name of the Intermedialry post.

The image titled "toolset-article-intermediary-cpt-correct.png" shows the Writers (intermediary custom post type) when it’s working correctly.

The image titled "toolset-article-intermediary-cpt-incorrect.png" shows the Writers (intermediary custom post type) with the new view you had me set up.

The "toolset-article-output.png" image is under Pages called “Article Library”. I had it laid out with Beaver Builder but I turned that off to make things easier so excuse the bad layout. The View to display the articles is called “Article Finder”. I attached an image of the setup (called "toolset-article-finder.png").

The content template that I used for the Article Finder views is called “Loop item in Article Finder”. That is setup in Beaver Builder so I included a screenshot so you can see how that is setup. (see image "toolset-Loop-item-Article-Finder.png")

In your response you said if would be helpful to have a member account to login with. Here it is.

Go to enlace oculto
UN: webvisuals
PW: 1234

Once logged in you’ll see “My AAIMCo Articles” on the button nav on the right to see the articles I’ve show in the above examples. ONly the "Add A New Article" has the new way you had me setup. The Edit button is still the old (MInesh) way.

Please let me know if you need anything else from me. The client is super anxious to get this working again since his membership depends on it.

Regards,
Ronald E

[Nigel]

Sorry Ron,

If the site was broken by some update, I would revert to a backup prior to the update if possible while you work on any changes required.

I may have misunderstood something about your site, reflecting that it has migrated relationships.

What is the end goal of the relationships?

To be able to connect Member Profiles to AAIMCo Articles in a many-to-many relationship? So that members can write multiple articles, and articles can have multiple authors?

And in your set up, that was facilitated with Types 2 by creating an intermediate post type, "writers".

The purpose of writers is simply to connect profiles to articles?

If that is the case then before going any further you might want to consider completing the migration to create a true M2M relationship, we can then update the forms as required, and if you are using the existing relationships using a View, for example, then this would need updating, too.

As of now, your were emulating many-to-many relationships with Types 2 using two one-to-many relationships and a common intermediate post type, and you are effectively doing the same now with Types 3, they are not genuine many-to-many relationships.

We can continue with your current set up and work on something which is effectively a hybrid Types-2/Types-3 approach, or we can complete the migration to actual M2M relationships and deal with any hang-overs where you have something else (such as a View) which is dependent on the current approach.

Given that we have to make some changes anyway I am inclined to say let's complete the migration and do it right, but I'll wait for your input.

And just to clarify one thing. In the earlier posts you talk about a user logging in and using a form to connect an article to a member profile. The member profile and the user are the same, right? That is, you member profile posts are linked to user accounts by the post_author of the profile post.

[Ronald E]

Hi Nigel,

The site we are working on is a backup. The live site is currently on life support and we have an article freeze so the members don't break things further until we get this sorted out.

So a few month's ago working with Toolset tech support I did do the Relationship migration (see screenshot toolset-relationships.png) and at that time everything seemed to work. I tested a member account, added an article and things appeared to work fine. It's when a member adds more then 1 article things get messed up.

Yes, the Member Profiles are linked to the Author (see screenshot toolset-post-author.png)

Yes, lets build for the future and break what we need to so it works right and can grow with all the latest stuff that Toolset has to offer.

[Nigel]

There is one piece of the jigsaw you are missing.

The initial migration from Types 2 to Types 3 relationships wasn't complete. If you emulated M2M relationships with Types 2 using two one-to-many relationships and a common intermediate post type, when you migrated the site the same structure was effectively reproduced, i.e. you still had two one-to-many relationships (albeit new relationships) and not a real many-to-many relationship. (This was purposeful inasmuch as it allowed your forms and Views to work as before, or at least, that was the intention.)

Subsequently, a further step was added (because clients requested it), namely to convert the two one-to-many relationships into a genuine many-to-many relationship.

This is done from the Toolset > Relationships page, where you check the two relationships and then use merge, which you find in bulk actions.

I'm going to take a copy of your site and install it locally so that I can test that myself on your site, and then I'll report back with some further directions.

[Nigel]

Ron, there is one thing I don't understand about your current workflow.

The member profiles are linked to the WP users through the post_author field.

So a user has a profile post, and the profile post is their profile post because they are the author of the profile post.

What I don't understand then is why in the forms to publish articles the user is shown a list of members from which they should select themselves as the author of the article.

Why ask them who the author is? It can be assigned automatically. They are logged in (so we know which is their profile, or at least we can retrieve it), so if they create an article, we link to their profile. If they edit one of their articles, no need to even update the connection, the article is already linked to their profile.

Am I over-simplifying things? Something I'm missing which means the members really should choose the member profile to link to the article they are publishing or editing?

[Ronald E]

Hi Nigel,

You’ll see how all this came about in this post.
https://toolset.com/forums/topic/using-user-account-to-connect-member-profiles-with-articles-via-intermediary-cpt/

This was the first site I built using Cred form and Access with Types 2 and I was not sure to do relational CPT’s with them. So I asked this questions…

“What I want to be able to do is allow the user, via a Cred Form, Assign a Member Profile to the article they write. I can do it in the WordPress Admin. How can I set it up so the user, who is logged into the front-end created by Access, be able to do it with a Cred Form while they are creating their article?”

Minesh suggested the best way was to set that up was…

“ …display all the member profile as select box with article CRED edit form and allow user to select the specific member profile and set the selected member profile as parent of currently editing article…”

He then created a view that lists member profiles and output as JSON format, put in some code in the Functions.php files add some more code in the Cred form to create the Members drop down list.

Doing that allowed the following:
> The articles will show the Members profile information on the article page.
> The member profiles show underneath their respective articles on article list pages
> The member pages outside the login will show all the articles they have written
> Membership pages when logged in show all the articles created by that member

Simply put I did not know there could be another way and Minesh’s method worked.

If by over-simplifying and everything works like it did then I’m all for it. Does that answer your question?

[Nigel]

Hi Ron

Yes, I think so.

The Articles need to be connected to the Member Profiles, just like they were before.

But unlike before, there is no need for a user that creates an Article to select their own Member Profile as the publisher of the article, we can do that automatically.

Which means the form to publish the article in the first place will automatically relate the profile to the article.

The form to edit an article doesn't need to make such a field available at all, because the profile is already assigned and does not need to be changed.

OK, so I will work with that. Sorry, but today ran away from me, I will complete that on my local copy of your site in the morning.

[Nigel]

OK...

You first need to complete the migration by merging the migrated one-to-many relationships into a genuine many-to-many relationship. From the page Toolset > Relationships check both the one-2-many relationships and use the Bulk Action section to perform the merge.

When I did this on the local copy of your site it worked fine, there were reports of a couple of posts with missing relationship data that were skipped.

So if you edit a member profile in the backend for a member that already has published articles, you should at the bottom of that edit screen see the relationships metabox that shows the connected articles.

We now want to update the forms so that when a user publishes an article it is automatically linked to their profile.

You first need to remove any existing customisations to achieve the same, i.e. remove member profile selectors from the form, and remove the custom code that uses the cred_save_data hook from your child theme.

Now we will add some updated custom code to automatically make the connection, without the user having to select their profile.

Here is the code for that:

/**
 * Assign member profile when article submitted
 */
add_action('cred_save_data', 'tssupp_assign_profile', 10, 2);
function tssupp_assign_profile($post_id, $form_data) {

	if (in_array($form_data['id'], array(3633))) {

		// get member profile of current user
		$current_user_id = get_current_user_id();

		$profiles = get_posts(array(
			'post_type' => 'member',
			'post_status' => 'publish',
			'author' => $current_user_id,
			'fields' => 'ids',
		));

		if (!empty($profiles)) {
			// connect member profile and article
			toolset_connect_posts('article-member', $post_id, $profiles[0]);
		}
	}
}

You can add that to your child theme. I used the new(ish) Types feature for adding custom snippets at Toolset > Settings > Custom Code.

When the form is submitted, if a profile exists for the user submitting the form, it will be automatically assigned. There is no need for anything similar with the edit form.

Now, that should take care of setting up the data correctly.

But, you still need to revise the parts of your site that depend on this relationship, because the old method which depended upon the relationship being stored with the _wpcf_belongs_parent-slug_id custom field is no longer valid (the relationships are stored in custom database tables).

From your last reply, that means updating these things:

> The articles will show the Members profile information on the article page.
> The member profiles show underneath their respective articles on article list pages
> The member pages outside the login will show all the articles they have written
> Membership pages when logged in show all the articles created by that member

I looked at the first one and when I view an article on the front end it seems that below the title "Library of Articles" a link to a writer post is included, but it wasn't clear to me where this comes from.

So I think we'll need to work together to resolve these.

Going forward there will be no 'writer' post type (the intermediate post type used to emulate many-to-many relationships in Types 2).

You can display related posts by creating a View and adding a Query Filter to specify the relationship, so when displaying an article you can use a View to display the related member profile in that why, and conversely when displaying a member profile you can create a View with a relationship Query Filter to display articles linked to that profile.

As you know better how the site is built, can I leave you to perform the first steps so that the forms work, then begin making any other changes to the templates or Views, and you can ask me about anything specific that you get stuck on?

[Ronald E]

Hi NIgel,

I'm still working through this (and dealing with snow storms and power outages here in Seattle) so I would like to keep this thread open.

thank you,
Ron

[Nigel]

No problem. I'll again mark it as feedback required, which should give you another week before the bot nags you to respond.

[Ronald E]

Hi NIgel,

I was able to execute your directions to the point of changing out the old code and using Toolsets "Newish" way of adding code snippets. I'm now going through the list of "Updating Things" and I'm stuck on the first one.

> The articles will show the Members profile information on the article page.

Here's a reminder of what we are trying for with the members profile underneath the article they are associated with.
enlace oculto

Currently it is showing the text "writer for article 4546 ". (see screenshot toolset-current-writer-display.jpg)

This was done with the View called Add Writer (see screenshot toolset-add-writer.jpg of setup).

It maybe a simple change in Views, or an id name update, to get the members layout showing under the articles once again? Hope so. What do you recommend?

Thank you,
Ron