Meta Box

Any chance ajax loading of frontend-submission forms is possible yet, or on the roadmap? For better performance I would love to load the forms only if they are needed.

I thought "exists" and "not exists" were not very different. But sure, I'll make another topic.

Using advanced taxonomy is possible but misses out on the advantages of Relationships, like performance and being able to view the connection from both sides.

I'm also experiencing this. I worked around the white text issue with some custom CSS on admin side.

Still have the issue switching between text/visual.

Notably, and at least for me, the first WYSIWYG I expand (within a double nested, collapsed group) works fine. Any subsequent editors have the switching issue.

Are there any ways to filter out the "add new" option? I'm using it in a shortcode with multiple custom field groups.

So, it seems you can target the relationship meta box as a normal field group using the same ID as in the form shortcode:

<?php
add_action( "rwmb_before_REL_ID_relationships_to", function( $meta_box ) {
    echo '<div id="customID">';
} );
add_action( "rwmb_after_REL_ID_relationships_to", function( $meta_box ) {
    echo '</div>';
} );

Maybe you can do something similar with validate hooks to change the "add new" option?
Or as a last resort, give the container ID above and target it with CSS #customID .addnew-class { display: none; }

Note this hook is after/within the .rwmb-meta-box container -- which doesn't help my case, since that's the div I was trying to hook into.

I have a really nice, orderly frontend form with tabs. Then at the end ... some select (relationship) fields which I can't control the labels or width of 🙃

Suggestion
Ideally a relationship field would work with any MB post/term/user field.

Then just like the "Set as parent" option, there could be a "Set relationship" option. It would also need to input/select a relationship ID. On save, the current editing object would have the applicable relationships updated.

I nearly set up several tax_advanced/user/post fields for my case. Then on-save I would need to check that relationship every time, check/delete all existing relationships (looping through them since there's no function to delete all), and set the new relationships according to field input.

I think it can work....but for now I'm just using the somewhat-random fields at the end of my form.

Hopefully the devs consider this 🙏 because it would be awesome to manage relationships anywhere within a form/field group, plus control metabox attributes, CSS ID, columns etc.

You can try to follow this tutorial to increase the PHP setting max_input_vars to fix the issue
https://metabox.io/wordpress-custom-fields-not-saving-increase-max-input-vars/

Wowow, thank you.

This was the issue for me on a couple sites. Makes sense because I couldn't track it to any other variable, despite many hours trying.

Maybe it's obvious, but I want to add:

If using Builder, make sure to re-save your Field Group "Settings" such as the post type.

Because when attempting to save (with insufficient max_input_vars) something is corrupted, resulting in invalid EXPORT code also.

Devs: is it possible to make the save FAIL or give a warning, instead of doing what appears to be a partial save (thus corrupting the Field Group settings + export (php & json))?

This is such a devastating issue to run into, because it only affects sites with many fields– although I wouldn't consider the fields I'm using to be incredibly complex. On my latest site, I'm not even using groups.

Like others I tried many workarounds which were not reliably successful.
If you haven't already it probably deserves a big fat WARNING on the Builder docs page...

Are there other ways to mitigate this issue moving forward? Maybe deleting unused fields before submission? I don't know, it's a bit over my head.

I'm relieved that I know the cause now. Thank you again.

I tested a bit more. My temporary work-around was to delete an unneeded field. Then for some reason it saved the fieldgroup "settings" fine. This worked by deleting either a text or heading field.

But it would not let me first save a new field, to then delete. Not sure why. So something about the stored value of the fields, causing the settings not to save?

If it helps, this is a site which I have not used builder for a long time, probably since before the UI change.