Forum Replies Created
-
AuthorPosts
-
Doug
ParticipantI figured it out. I had a plugin called Post Types Order installed. It was overriding order, even though I thought I had sorting disabled for this specific post type. I found a filter to use that ensures the plugin doesn't affect this post type. So order/orderby query args are working as expected now. Thanks!
ParticipantThanks, Long. I see the Tab field now. Perhaps this changed at some point a while ago, because we used to need to specify tabs with custom attributes in Builder. All of my older (1+ year) metaboxes set up tabs that way, and those are the ones that no longer work.
I’m a little surprised an update broke the old way of setting up tabs. There doesn't seem to be any reason to ignore those custom attributes if they already exist. Regardless, I’ll reconfigure them using the newer Builder UI now.
ParticipantI also just ran into this same warning after updating to 5.1.0 that my license key was expired. Deactivating Meta Box Updater solved the problem for me.
Anh - you can disregard the email I just sent in from your contact form about this same issue. I didn't see the instruction to remove Updater in your update email this morning. But I see it in the linked blog post.
ParticipantYes, if I disable 2FAS Light, Meta Box AIO can be activated without a problem. But as soon as I activate 2FAS Light, WP goes into its fatal error mode again. So there's definitely a conflict between the two in how they both use twig.
When researching this on my own, I found a thread about when plugins use two different versions of the twig library, this creates issues with deprecated code in the older version.
https://github.com/timber/timber/issues/1286
Meta Box AIO (Builder) uses 1.42.2 (from June 2019). 2FAS Light is running 1.33.2 (from April 2017). So I suspect 2FAS is referencing something within twig that has been deprecated. And AIO's inclusion of twig supersedes the version 2FAS Light references, thus creating the error. Manually updating the version of twig that 2FAS Light uses does not solve the issue.
I have requested the developers of 2FAS Light update their version of twig here. But I’m not sure how long it will take, or if they'll be able to do so.
ParticipantOk, one more update from me. I just updated MB Relationships on our production server too. Tested by updating one of our speakers, and then checking the event, and that speaker was bumped to the bottom of the list.
However, after dragging the speaker back to the correct position on the event page, updating, then updating the same speaker again, the order was preserved. And it's preserved every time now for that event.
I tested our other events, here's what I found (that mirrors what Clayton notes above)...
Any new relationships that get created with the updated plugin code should preserve order, because of the way index order is getting set now. But for any existing posts that had relationships defined before updating the plugin, you must go into each of those posts, and update each post once to establish an index order for its related posts. Then specified post order will be preserved from that point forward.
ParticipantUpdate: Actually, scratch my report above. I think it's working on our staging server now too.
Just went back to test one more time, and related post order is preserved on our staging server too. Not sure why I saw it move yesterday, since I haven’t changed any of the plugins. But this issue seems to be fixed from what I can see. Thank you!
@Clayton - I don't think there is a separate dev branch on GitHub. Since I don't see any dev branches either, I'm betting GitHub is dev for the MB team. I just grabbed master of MB Relationships and installed from that.
ParticipantThanks for the video, Anh.
I created a fresh install of WP just for this, installed Meta Box, MB Custom Post Type, MB Relationships, and the Twenty Seventeen theme, and duplicated the steps you took in your first video. And yes, it's working for me right now -- order is preserved after updating a speaker post.
But our staging and production servers are still bumping the last updated post to the bottom of the list. I'm going to slowly add back in pieces of our staging environment (plugins, theme files) to see if I can pinpoint what it is that causes the posts to reorder. If I find what it is, I’ll report back here.
ParticipantAhn - 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:
SPEAKER 1
SPEAKER 2
SPEAKER 3If 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:
SPEAKER 2
SPEAKER 3
SPEAKER 1Sure, 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.
ParticipantFinally 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
October 26, 2018 at 7:32 AM in reply to: ✅select advanced in Group showing: "Warning : Invalid argument supplied foreach" #11768ParticipantAnh - note that it's not just select_advanced that is buggy when added to a group. It's also the regular select field that shows the same behavior when placed into a group using Builder. Perhaps fixing one will fix the other. Just wanted to make sure you knew it was both field types that did this.
ParticipantJuanita/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.
ParticipantI think maybe I wasn't clear enough in what I was reporting about 'address' fields. Separate issue from not getting auto-complete to work...
In the bug report, I wasn't noting that certain fields wouldn’t auto-complete. But rather, that fields with 'address' in the name would not auto-populate.
For example, in your screenshot, apply an ID of 'address' to the field labeled 'Location name' (and intend on using that as the auto-complete field), then use ID of 'street_address' for the field labeled 'Address 1'. ('Address 2' in my screenshot is just an extra freeform field we sometimes need to us in the US for apartment #, floor, PO box #, etc.)
Now, you'll notice when you fill in a name or address in the Location name field, that 'street_address' does not get auto-completed with the specific street address.
My expectation is that 'address' will auto-complete with a full address, for example:
'660 3rd Street, San Francisco, CA, USA'.And with that address, 'street_address' should get auto-populated with '660 3rd Street', 'locality' with 'San Francisco', 'administrative_area_level_1_short' with 'CA', etc.
'street_address' is the one that will not auto-populate, because it is being interpreted as an auto-complete field, not an auto-populate field. According to the docs, only fields with an ID that starts with 'address' will be treated as auto-complete, right?
ParticipantI updated Geolocation. Auto-complete seems to work fine now, even if a map field is added to the meta box. Just need to make sure I added the API key again in the map field's settings, even though it's already applied to via the meta box.
Find Address still doesn't seem to do anything when clicked for me. Not sure why.
Did you see my buried bug report in the second followup message about a field that contains the word 'address' anywhere triggering auto-complete fields, even if not starting with 'address'? It prevents a field like 'street_address' from being auto-populated. Apologies for adding two issues in one thread.
ParticipantAh, ok. Makes sense, but that is strange.
Given this, I thought I might be able to explicitly specify the post_type alongside 'relationship' in the query and still keep those CPTs set to exclude_from_search. But that didn't work. Probably due to the way the plugin modifies the query. I’ll have to hide those custom post types from search another way. No worries.
ParticipantSo I think i figured out what the issue was, in addition to leaving in 'to' instead of 'from' as I was testing everything I could think of. I actually have several custom post types created in addition to 'event' and 'speaker', including 'location' and 'sponsor'. I was originally trying to query posts via the relationship of event_to_location. That was the one that wouldn’t return anything no matter what I did
I just switched the query back from speaker to location, and no posts returned again. But I went into the custom post types and compared the settings for each. My 'location' CPT had 'exclude from search' as true, but speaker was false. Sure enough, toggling the 'exclude from search' setting on breaks the display of MB Relationship posts. Is that expected behavior? I would expect turning off 'publicly queryable' would block the display. But not exclude from search?
-
AuthorPosts