Massive bug found (?) with relationships between posts and users!!!! - Support Fourms

This topic has 8 replies, 3 voices, and was last updated 2 days, 15 hours ago by JC.

Creator

Topic
February 22, 2021 at 8:54 PM #24535
JC
Participant
This is my use-case:

A "student" (user) buys a "course" (custom post type) and upon purchase, a relationship is created between the user and the post. This is what grants the user access to the course content.

All has been working wonderfully. Until today.

A course was removed from ALL users who had a relationship with that course! This was NOT supposed to happen.

This happened immediately after I deleted a single user.

Upon further investigation I found that coincidentally the user who was deleted had the exact same ID as the course that went missing for all other users that had a relationship with it.

Upon deleting that particular user, it deleted all rows in the mb_relationships table which pointed to that post/course with the same ID.

To be clear, I deleted a user with the ID of 154 and then any reference in the mb_relationships table to a course with an ID of 154 was removed.

Here is the method in my plugin code which creates the relationship.
```
protected function register_relationship_for_user_tutorial_access() {

    \MB_Relationships_API::register([
        'id'   => 'the1914_user_to_tutorial',
        'from' => [
            'object_type' => 'user',
            'meta_box'    => [
                'title' => 'Tutorials',
            ]
        ],
        'to' => [
            'object_type' => 'post',
            'post_type'   => 'tutorial',
            'meta_box'    => [
                'title' => 'Students',
            ],
            'query_args' => [
                  'post_parent' => 0,   // Show ony parent tutorials
                  'number' => 100       // Maximum to show in the admin area
            ]
        ],
        'reciprocal' => true // Prevent metabox showing in the 'to' (tutorial) post type
    ]);

}
```
Is this an oversight from the developers of this plugin?

Or is this expected behaviour based on my code above?

I have since set 'reciprical' to FALSE in case that had something to do with it. That does not solve this issue.

Furthermore, when I access the profile of a user to add or remove courses, if the user ID matches a course ID, I get a LOT of dropdown menus appear like this:

Image

Here is a screenshot of the mb_relationships table:

Image

Thank you for your assistance and for an otherwise great set of plugins!
Creator

Topic

Viewing 8 replies - 1 through 8 (of 8 total)

Author

Replies
February 23, 2021 at 11:25 AM #24575
Long Nguyen
Moderator
Hi JC,
1. I've tried to reproduce the issue on my local site but not see an issue like that.
- Create a new user
- Create a new post
- Access the database and set the user ID match with the post ID
- Create a relationship between user and post (reciprocal = true)
- Delete the user
- The post still there
  So I suppose that the user has created that post and when you delete the user, the post is deleted too.
1. If a user and a post are the same ID and have a connection, the select field will show double connect. I will discuss it with the developer team to cover this case.
February 23, 2021 at 4:00 PM #24590
JC
Participant
Thank you very much for your swift response.

You have slightly misunderstood the issue.

The (related) post does not get deleted; that stays intact like you have found.

The issue is ALL other users that had a relationship with that post no longer have a releationship with it.

To replicate the issue:
- Create three new users
- Create one new post
- Make a relationship between the three new users and the new post
- Make one of the users have the same ID as the post
- Delete the user who has the same ID as the post
Once deleted, the remaining two users will no longer have a relationship with the post.

My short-term solution to the issue has been to change the auto-increment of the ID column in the users table to 1 million meaning any new user IDs will be 1M+1, 1M+2, 1M+3, etc, to ensure there will be no more ID collisions between users and posts (my post IDs are still relatively low, less than 200).

That will keep things working on my website for a long time. It's unlikely but if the post IDs in the future exceed 1M, the problem will come back because there will again be user IDs that match post IDs and the problem will persist.

I hope I have made things a little clearer. If you need to know anything else, let me know and I'll be happy to explain further.

Thank you
February 23, 2021 at 6:17 PM #24595

JC
Participant

UPDATE:

This is actually worse than I first thought.

I just deleted a standard page (standard pages have no MB relationships set up on my installation at all).

The page had an ID of 55.

When I then checked the user with an ID of 55, this user no longer has any of the relationships they had before I deleted the completely unrelated page!

This means if I delete ANY post type that happens to share an ID with a user, all of that user's relationships disappear!

This is a very big problem!

Thanks for reading.

March 25, 2021 at 7:06 PM #26690

JC
Participant

Hello, I am bumping this thread because this is a major bug!

Please see my previous post (this one) for instructions about how to replicate this issue.

This is actually worse than I first thought.

I just deleted a standard page (standard pages have no MB relationships set up on my installation at all).

The page had an ID of 55.

When I then checked the user with an ID of 55, this user no longer has any of the relationships they had before I deleted the completely unrelated page!

This means if I delete ANY post type that happens to share an ID with a user, all of that user’s relationships disappear!

This is a very big problem!

Thanks for reading.

May 7, 2021 at 9:52 PM #28006

hlikes
Participant

I am following this as I am about to set up multiple relationships between post types and terms on a membership site that is going live soon.

Worried about the possible effects of this problem as reported here by JC.

An update from the developers would be appreciated!?

May 7, 2021 at 11:19 PM #28012

JC
Participant

I think you'll be ok unless you are using MB Relationships with the MB User Meta plugin to make relationships between posts and users. If so, you will run into big problems if any of your user IDs share the same IDs with any other posts (of ANY post types).

I too would appreciate an update from the developers because this nearly crippled my website and I would love to see it patched for my own peace of mind and so other developers in the future do not experience what I had to.

I have implemented a hacky workaround as mentioned above BUT it will not last forever:

My short-term solution to the issue has been to change the auto-increment of the ID column in the users table to 1 million meaning any new user IDs will be 1M+1, 1M+2, 1M+3, etc, to ensure there will be no more ID collisions between users and posts (my post IDs are still relatively low, less than 200).

That will keep things working on my website for a long time. It's unlikely but if the post IDs in the future exceed 1M, the problem will come back because there will again be user IDs that match post IDs and the problem will persist.

May 8, 2021 at 10:05 PM #28024

hlikes
Participant

I meant to say relationships between terms and users, so will be keeping an eye on this thread.

May 8, 2021 at 10:38 PM #28025

JC
Participant

I suspect you will be okay in your scenario because terms utilise the terms database table whereas posts, pages and custom post types utilise the posts table.

Matching IDs from the users table and the posts table is where problems lies.

However, I do not know for sure about terms; you'll have to test this by assigning multiple users to the same term and then deleting any user that shares the ID of said term (or vice versa) to see if everything remains intact as it should.

But still, this is a very significant bug. Developers, please chime in. Here is how you can replicate the issue. Thank you.
Author

Replies

Viewing 8 replies - 1 through 8 (of 8 total)

You must be logged in to reply to this topic.