I am trying to: Save a post without filling in all of the available custom fields
Link to a page where the issue can be seen: Happening inside of admin
I expected to see: The post being saved with only those custom fields that had been filled in in the post editor
Instead, I got: The post was saved with every possible custom field with an empty value for those that were not filled in
Notes:
We have just updated from 3.4.10 to 3.4.14 when this issue began.
We are on WordPress latest.
We use the classic editor.
Small update to note that this only seems to impact text inputs, not checkboxes or radio buttons.
Hello,
It is expected result, see the change logs of Toolset Types plugin:
https://toolset.com/download/toolset-types/#changelog
3.4.11
Fixed an issue that made it impossible to save an empty value to a field with a defined default value. Until now, even if the user deliberately clears the field and saves it, it was being reset to the default value. From now on, the default value will be applied only for a new element (post, term, user).
So if you setup the text field as empty value, it will save empty value into database.
Hi there -
Thank you for the reply.
By way of background, we have certain post types with a dozen or more optional single-line custom fields that have NO default value, they are empty by default and not required.
If I'm understanding it correctly, following this change, the expected behavior upon saving a new post is to write an empty value row to the postmeta table for each of these single-line custom fields that default to empty?
If so, this is a fairly major change and it's causing our post-meta table to fill with a dozen plus EMPTY values every time we add a post that uses these field groups, which is really not desirable at all. Beyond the bloat to our already very large postmeta table, we have presentation logic that (for better or worse) simply checks for the existence of these fields on a post and not if they are empty.
Is there any way to prevent / filter / hook this behavior so that NO postmeta row is written to the database when saving a new field with an empty value?
Thank you,
TL
Q1) If I'm understanding it correctly, following this change, the expected behavior upon saving a new post is to write an empty value row to the postmeta table for each of these single-line custom fields that default to empty?
Yes, you are right, it will write an empty value row to the postmeta table for each of these single-line custom fields that default to empty
Q2) Is there any way to prevent / filter / hook this behavior so that NO postmeta row is written to the database when saving a new field with an empty value?
There isn't such kind of built-in feature, you might consider custom codes, for example:
1) After user save the post, use action hook save_post to trigger a PHP function:
https://developer.wordpress.org/reference/hooks/save_post/
2) In this PHP function, get the those custom fields values:
https://developer.wordpress.org/reference/functions/get_post_meta/
If it is empty, then remove it:
https://developer.wordpress.org/reference/functions/delete_post_meta/
Thank you Luo.
We've already created some custom functions on insert_post hook (which runs just after save_post and is a bit more reliable for ensuring meta is already set) that work to delete these unnecessarily created empty meta values after save.
The catch is, we've got years and years of code that relies on these empty fields not being saved, and this (major) change in functionality has left us with a variety of potential blind-spots to things that can happen but shouldn't (e.g. hitting a 3rd party API with an empty ID) and we're forced to try and find and patch them all which is no small task.
My question was really if there is some way to filter / hook the Types functionality itself to PREVENT the saving of these empty fields in the first place, without have to do the unnecessary task of deleting them immediately after the fact.
Or better yet, it seems like such a major change should come with some sort of setting / toggle, either at the overall plugin level, field group level, or even field level.
Is there any possibility of such a setting being introduced? Or perhaps a filter?
Also, can you please link me to a repository where I can compare code differences between 3.4.10 and 3.4.11? Or if not, help me figure out where in the plugin code the changes were made that impact this behavior?
Unfortunately, there isn't such kind of filter / hook or option to disable this feature, you can add a feature request for it, our developers will evaluate it:
https://toolset.com/home/contact-us/suggest-a-new-feature-for-toolset/
And we don't have public repository
