Support › MB Relationships › Drag and drop order reset without consentResolved
I used the drag and drop functionality to arrange the relationships in the exact order I needed them to show on the front-end. Now they have reverted back to where when they were added to the database. Where is the order stored in the db? Why would it revert back? Frontend and backend match up so I know that there is not a sort order on the frontend.
Did you save the post after reordering the relationships? The plugin relationship values in the exact order they're set in the backend. In the frontend, they're sorted by the
ID columns from
mb_relationships table. This is the query looks like in the plugin's code:
Did some testing and found that when I arrange the relationships on a bi-directional relationship, you cannot have a specific sort order on both sides of the relationship.
In my use case, I have an attorney related to a practice area. I want a specific order on the practice area page and then another order of relationships when viewing the attorney biography.
It might be good to add to_order and from_order database column so that you can arrange relationships independently of each other. You could keep the default order to be ID unless filtered to use the from_order or to_order column.
You're right about the order for bi-directional relationships. I'll add a task on that.
The other thing I noticed is that if you change the post title, then resave, that post gets pushed to the bottom of the related pages list.
Juanita/Anh - I just noticed this unwanted behavior as well. You don't even need to change the post title. Just go to one of the posts in the admin, click update without making any changes, and it will get pushed to the end of the related posts list (both in WP admin, and in the rendered post set).
Bummer, because I constantly need to go back to the post where I've specified the relationship, and drag them back to the original order.
Anh, any update on either of these two issues?
FYI, Clayton is my real name. Juanita is the office manager that bought/signed up this account when we purchased the bundle.
Also, if you give me a little hint about where to look for #2, I can trouble shoot on my end to speed it along.
Hey Clayton and Doug,
We've just a fix for this problem on Github. Can you please test it?
We follow your instruction by adding 2 columns
order_to to track the order of each side. So far so good for now. Please take a look.
Went to test this and I cannot save a relationship value.
I installed a clean version of 4.9.8 and also 5.0 to test on with the same results. The database structure was created properly and happy to see the extra columns. Here are the steps I took to test.
On save, the relationship fields get cleared out. Reset back to a single empty value.
Am I missing something on my setup? Have you tested on a fresh install?
I have the same problem with the "reset" of the field.
I also get this error when enabling debug mode:
WordPress database error: [You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'WHERE
type='post2conf' ORDER BY order_to' at line 1]
from FROM WHERE
type='post2conf' ORDER BY order_to
Finally had a chance to test master from github (as well as v1.4.1 downloaded directly from metabox.io, which seems to be identical to what's on github). This version won't load or save any existing relationship data.
For anyone having major issues with 1.4.1, rolling back to version 1.4.0 at least works again for me, though still with the re-ordering issue this thread originally reported.
I have debugging turned on, and with v1.4.1 installed, I see this at the top at the top of every wp-admin page, which seems to prevent loading or saving any relationship data (username and server name obscured from my paste):
Notice: Undefined property: RWMB_Relationships_Table_Storage::$db in /home/username/servername.com/wp-content/plugins/mb-relationships-master/inc/database/class-mb-relationships-storage-handler.php on line 61
Notice: Trying to get property of non-object in /home/username/servername.com/wp-content/plugins/mb-relationships-master/inc/database/class-mb-relationships-storage-handler.php on line 61
Warning: Cannot modify header information - headers already sent by (output started at /home/username/servername.com/wp-content/plugins/mb-relationships-master/inc/database/class-mb-relationships-storage-handler.php:61) in /home/username/servername.com/wp-admin/includes/misc.php on line 1126
Nice one Doug. I am seeing the same thing.
Looks like the storage interface doesn't have the db param.
I think Anh removed the parameter in favor of the direct reference of `global wpdb'.
The storage handler should do the same global reference probably.
Thanks a lot for testing! I've fixed the bug that Doug pointed out. This bug prevents the data from saving. Can you please try the latest version on Github?
It's the dev version and not the same as 1.4.1 version on .org. I will release version 1.5.0 if this works 🙂
Ahn - I just installed the dev version from GitHub. I can load, view, and save relationships again. But the original issue Clayton pointed out at the beginning of this thread is still happening.
For example, and to be clear what's happening... I have an EVENT post type and a relationship specified with a SPEAKER post type. Each EVENT typically has multiple SPEAKERs associated with it, and I have arranged those SPEAKERS in a specific order in the Relationship metabox on the relevant EVENT post admin page, and I want that order maintained.
Assume those speakers are arranged like this:
If I open up the SPEAKER 1 post and Update it, then go back to the relevant Event admin page, the new order in the Speaker metabox will now be:
Sure, I can drag them back to the correct order. But I have to remember to do this. Seems like a specified order of posts should be maintained, regardless of whether any of them have been modified since the original relationships were created and order was specified.
Sorry, long-winded. But hopefully clear what we see happening that is unexpected.
I've just made the video to check the problem. So far it works for me: http://recordit.co/mRNyr8h4f2. Can you try again?
I also recorded another video to demonstrate more complex actions: http://recordit.co/MrHGxyfzAM
It seems to work well on my side.