Forum Replies Created
-
AuthorPosts
-
November 12, 2025 at 4:57 AM in reply to: ✅MB User Profile adds some clutter to the wp-admin/profile.php page #49318
A.
ParticipantYour recent update, Meta Box AIO version 3.3.1, has resolved this issue for me now. Thank you.
A.
ParticipantHello Peter,
Thank you and the MB team so much for updating the UI in version 3.3.1 and also the documentation. It is much clearer now and extremely helpful with the caution/warning notices! ⭐⭐⭐⭐⭐
I had not noticed the explanation in the earlier documentation (before the update) so the update makes it easy now to see the notice and customize the field labels.
Thanks again for explaining and resolving this issue.
November 12, 2025 at 4:40 AM in reply to: Unable to save due to email field is set to required #49316A.
ParticipantHello Peter,
Thank you and the Meta Box team for the last update. It resolved several other issues I was concerned about, and I appreciate those changes. However, version 3.3.1 still did not fix this particular issue for me.
I tested it with a **new** custom field group containing required text fields and also with my **existing** custom field group that already had this problem. The same fields continue to show the message "Please fill out this field" when trying to save changes. I also tried exporting and reimporting the field group using the JSON file, but that made no difference.
If you’d like details about what I did to troubleshoot this, here is more information. These tests were done *after* updating the plugin to version 3.3.1.
Experiment 1:
I tried editing and saving my affected custom field group.Results:
The issue remained. It would not save and still asked me to fill in the fields. I had to enter random values only in the first and last required fields (which are bothtextfield types). Then I could save, but the fake values were not stored in the database. So, while not serious, it is still odd.Experiment 2:
I imported the custom fields from a previous JSON export and tried editing/saving again.Results:
It behaved the same as in Experiment 1.Experiment 3:
Returning to my original custom field group (not the reimported one), I duplicated the firsttextfield (id:first_name), gave it a new id (first_name_), kept both required, and tried saving.Results: Same as before.
Experiment 4:
I removed the "required" setting from the originaltextfieldfirst_name, kept it infirst_name_, and saved again (after refreshing the page to remove any cached or pre-filled data).Results: It then asked me to fill in the
first_name_field, which is the second field in the group but the first required one. It also still asked me to fill in the last requiredtextfield.Experiment 5:
I added an extra, non-requiredtextfield at the end of my field group to see if that would change anything.Results: No difference. It always asks to fill in the required
textfields, no matter their position in the field group.Experiment 6:
I created a new custom field group from scratch with several fields. I saved it successfully, refreshed the page, and then tried to edit and save changes.Results: The first save worked fine with no warnings, but following saves showed the "Please fill out this field" prompts again. This problem only affects required
textfield types.Other required field types in my custom field groups, such as
number,select advanced, andtextarea, are not affected.In summary, required
textfield types still show the "Please fill out this field" message when changes are made in the admin area. This can be bypassed by entering any value (I just type 0), but it remains inconvenient.I tried other small tests out of curiosity, but the same behavior occurred every time: required
textfield types always trigger that message and accept any input before allowing the "Save Changes" action.I hope this information helps you troubleshoot and solve the problem.
Thank you in advance for your help and follow-up.
A.
ParticipantThank you, I understand it now. But this was quite confusing to work with at first, and for a long time I thought it was a bug rather than the intended behavior.
It might help to make this clearer in the UI to avoid confusion for beginners using MB Relationships. Maybe add a short note or tooltip in the “Field” tab mentioning that these settings apply to the opposite post/object type, not the one currently being edited.
Alternatively, labeling it “Field settings for related items” could make it more intuitive. A quick clarification like this could save users from thinking it’s a bug.
Also, before posting my initial question, I had checked the documentation but couldn’t find anything clear about this behavior. If the explanation is already there but easy to miss, perhaps consider updating or highlighting it to make it easier to find.
Thank you again for your time and assistance.
November 1, 2025 at 1:38 AM in reply to: Can't Save Field Groups that have Fields marked Required #49264A.
ParticipantThis is actually a recent bug several Meta Box AIO users have noticed and reported here, after the update to 3.2.0, and we were told it would be fixed in the upcoming update, God willing.
But in the meantime, what worked for me was just entering any value when requested to fill out a field. Afterwards, I am allowed to click "Save". The actual value entered is not saved anywhere that I can see, but it fulfills the "requirement" and lets me save the changes I made in the admin area.
So you can try this too if you like, until the next update comes: Just enter any value, and save. It will see the required field as filled, and should then let you save, and you should not find the value you entered saved in the database (I did not).
A.
ParticipantThere is a lot of interest in this feature, as discussed in another thread linking to this one. I hope the Meta Box team will take it into consideration soon as it will be a time-saver and offer a better workflow. Thank you.
A.
ParticipantI am also interested in this and would like to know if you plan on including it any time soon, please?
A.
ParticipantAfter a lot of trial and error, and consulting of AI, I finally got a working solution that will allow changing the default error message for incorrect password when using a Meta Box login form.
Quick recap:
1. The default WP form would display a specific and security concerning type message such asError: The password you entered for the username <user> is incorrect. Lost your password?which clearly indicates that username or email entered is correct, only the password is not.
2. The Falcon plugin will override that message if you turn on the security setting to "Disable detailed login errors".
3. But if you use the Meta Box user profile login form it won't be covered with Falcon's security setting.The usual filters for changing default WP login errors would not catch those outputted by the Meta Box login form. I tried many methods, it seems intercepting the translation string works - so it will replace “The password you entered for the username %s is incorrect.” with “Invalid username or email.” or similar text with the generic message.
However, I feel like this is not the right way to do it and it feels fragile, but
wp_authenticate_userandlogin_errorsfilters did not work with the Meta Box form when I tried it, and I needed a quick solution for this so opted for this temporary translation string fix.Can Meta Box be updated to allow for custom login related error messages or at least to adhere to the Falcon security setting? A long time has passed since the original post in this thread, perhaps the core code now has safer more robust methods that can be used for this essential security concern.
October 21, 2025 at 4:47 AM in reply to: ✅MB User Profile adds some clutter to the wp-admin/profile.php page #49182A.
ParticipantThanks for that tip. I forgot about excluding the field group from admin related roles and now it only shows up as intended: on my registration form and for Subscribers editing their form. Only that clutter that I originally posted about remains. Looking forward to the update that will have them removed.
October 21, 2025 at 4:45 AM in reply to: Unable to save due to email field is set to required #49181A.
ParticipantAlso, thank you Peter and the Meta Box team for working on resolving this soon.
October 21, 2025 at 4:43 AM in reply to: Unable to save due to email field is set to required #49180A.
Participant@Konstantinos: That is a thoughtful contribution and temporary solution, thank you. But in my case I can just enter anything in the fields it nags me about, such as
0, and then it lets me save. The0or whatever value I enter would not be saved in the database or anywhere I have seen so far, therefore that is how I am dealing with it until the next update: just enter anything and click save and move on until I have to edit it again.A.
ParticipantI have an issue directly related to this older post, so it feels right to post it here as a follow up in case anyone searching like I was comes across this topic.
I created some custom registration fields and kept the default username option available (meaning: no email as username), however, I noticed the username field does not have validation even though it is a core WordPress field. For example: if someone typed in random non-English/Latin characters in the username like
السلام123, the registration form would actually be submitted successfully, a confirmation displayed, but the user creation failed without visible errors at all.I quickly set up a separate plain WordPress installation without Meta Box AIO and my custom form to see what the default WP behavior would be if that happened, and it turns out WordPress' default registration form only validates after you attempt to submit - so it would not check the username OR email fields until you clicked submit. After that, it would give an error:
Error: This username is invalid because it uses illegal characters. Please enter a valid username.My issue with the Meta Box user registration form only happened with the username field. The email was validated correctly before even submitting (even better than the default WordPress form).
It would be fine if the username field at least behaved like the default WordPress behavior and warned me after submitting instead of silently accepting the incorrect username characters. But ideally, it would be better if it had proper validation like the email field.
Is this username field validation something that can be fixed or addressed or did you intentionally leave it out intending the WordPress behavior to be a catch-all or fallback? Or is it actually there but something in my setup made it not work? (If so, how do I debug this to check?)
At the moment, I created a temporary mu-plugin to add validation for the username field so now it behaves as expected when I am using a Meta Box customized registration form. It enforces strict username validation (Latin letters, numbers, dots, underscores, hyphens only) with client-side and server-side validation. I did not make it to work with the default WP form as my only interest now is to ensure the username field made by the Meta Box user registration shortcode had proper validation for the username field, since I want to continue using the custom form I have. But, I would appreciate if such a fix could me made in the Meta Box plugin (if it needs fixing) or appreciate any other guidance you can offer on this so I don't have to use my temporary plugin solution. I made it with the help of AI to resolve this real quickly but prefer a human logically coded solution for the long term.
October 16, 2025 at 9:11 PM in reply to: Unable to save due to email field is set to required #49165A.
ParticipantIn my case (described above) I do not have conditional logic for this particular set up.
A.
ParticipantGood to know, thank you. But does any approach (UI or PHP code) have any distinct performance (or other) advantages beyond the deep customization the PHP approach offers?
October 14, 2025 at 2:52 AM in reply to: ✅MB User Profile adds some clutter to the wp-admin/profile.php page #49144A.
ParticipantThank you. And on a related note, is it normal for the custom user registration fields I created to also show up in profile.php for every user role? I just want them to show up for a specific user role (Subscriber) but they are showing up for the admins and other users - just above those things in the screenshot I showed. So if the admin makes any changes to their user profile (like changing the color scheme) they have to enter the info in the required fields of the custom registration form that show below. Is this normal behavior or also a bug?
-
AuthorPosts