Custom fields not storing data
Erik Liljencrantz Staff asked 4 years ago
Using the ea_bootstrap booking form.
Have ID as default_value for first custom field, but instead of ID from wp_users table (the logged in user id), the appointment ID is stored. The process_fields method in EAUserFieldMapper appear to do "the right thing", but then the user id is replaced with the appointment id "later on"...
Instead tried user_nicename to have the login name of the user, this works if field is visible (and editable) but with visible=0 again process_fields seem to do the right thing, but the record stored in wp_ea_fields have empty value (even tried two custom fields for user_nicename with only difference visible=0 and 1 and the visible was saved, the invisible not).
Also tried switching to ea_standard form, but then the custom fields showed up empty so that was... worse?
In short it appears that:
+ custom field ID receive appointment ID instead of logged in users ID
+ custom fields with visible=0 are NOT saved as empty values in wp_ea_fields
Current work around is to have a visible user_nicename field instead of the hidden user ID - which is not really what I want... :-O
Erik Liljencrantz Staff answered 4 years ago
+ in ea_bootstrap_tpl.php the line
if (item.visible == "0") { return; }
looks... problematic. Non visible fields with a default value would be better of as type="hidden" input field so the value is still saved when appointment is made, right?
+ each input field have "id=slug" so a javascript workaround that make visible fields with the value from wp_users table still visible but read only should be possible as a work around. Using jQuery I ended up with this:
jQuery(document).ready(function($) {
$('#cf_display_name').css({'background-color':'#cccccc', 'color':'black'});
$('#cf_display_name').prop('readonly', true);
$('#cf_user_nicename').css({'background-color':'#cccccc', 'color':'black'});
$('#cf_user_nicename').prop('readonly', true);
});
that make my custom field cf_display_name (with display_name from wp_users) and cf_user_nicename (with user_nicename from wp_users) appear as readonly fields with gray background and black text.
(also kept the ID field with visible=0, become empty in db but present for future fix of plugin)
Erik LiljencrantzExtended workaround to make ID “work” and actually get stored in db using jQuery generated in my PHP plugin code:
+ field ID have visible=1 but using jQuery to hide it’s grand-parent – entire form-group is hidden
+ setting ID value to logged in users id from PHP
+ making the display_name read only with gray bg/black text
My PHP-code with $content inserted just after ea_bootstrap:
$content=”
jQuery(document).ready(function($) {
$(‘#cf_id’).parent().parent().css({‘display’:’none’});
$(‘#cf_id’).val(‘”.$current_user->ID.”‘);
$(‘#cf_display_name’).prop(‘readonly’, true);
$(‘#cf_display_name’).css({‘background-color’:’#cccccc’, ‘color’:’black’});
});
“;
(and the script tags turned into two empty lines – please add “script type=text/javascript” and finishing /script tags to above content)
Nikola Loncar Staff answered 4 years ago
Yes, having a custom field with a default value taken from a logged in user field require a hidden field (…or similar…) to actually store the value in the database. Or perhaps that the save logic identifies the non visible fields and re-get the default value from user data.
Erik Liljencrantz Staff answered 4 years ago
exy Staff answered 4 years ago
There is a workaround above by keeping it visible (in Easy-Appointment) then using jQuery set display:none; on the fields grandparent (hide entire row). It works, but of course it would be much better with a fix in easy-appointment that output “input type hidden with value” for non visible fields instead of just skipping them entirely.
Please login or Register to submit your answer