[Resolved] Cred user form ‘first name’ entry field breaks page

[Author]

Posts

[Paul Bowman]

I have a front-end user form for general user info updating, so that site members can change their information without having to go to their user profiles in the WordPress admin area.

Currently the form is working fine for user updates to their display name and password. I would like for users to also be able to change the values for first and last names.

The curious issue I’m confronting is that in any version of this form that I create, the Cred user field for ‘first name’ entry breaks the page, regardless of how I add it to the form. The ‘last name’ entry field can be included in the form without problems. Only adding the field for first name entry to the form is resulting in some kind of failure.

I’ve done some very minimal checking for plugin conflicts, but so far I haven’t been able to identify any.

Here’s the essence of the form that I’d be implementing, including the problem ‘first name’ entry field:

[creduserform]

[cred_field field='form_messages' class='alert alert-warning']

<div>
	<div style="display: table;">
		<div style="display: table-cell;">email:</div>
		<div style="display: table-cell;">[wpv-user field="user_email"]</div>
	</div>
	<div style="display: table; width: 100%; margin-bottom: 0.25rem;">
		<div style="display: table-cell;">name:</div>
		<div style="display: table-cell;">[wpv-user field="user_firstname"] [wpv-user field="user_lastname"]</div>
	</div>
	<div style="display: table; width: 100%;">
		<div style="display: table-cell;">display as:</div>
		<div style="display: table-cell;">[wpv-user field="nickname"]</div>
	</div>
</div>

<div class="row">
	<div class="form-group col-md-12">
		<label for="%%FORM_ID%%_first_name">[cred_i18n name='first_name-label']First Name[/cred_i18n]</label>
		<!----- ADDING THE FOLLOWING SHORTCODE CAUSES PAGE LOAD TO BE DISRUPTED ----->
		[cred_field field="first_name" class="form-control" output="bootstrap"]
	</div>
</div>

<div class="row">
	<div class="form-group col-md-12">
		<label for="%%FORM_ID%%_last_name">[cred_i18n name='last_name-label']Last Name[/cred_i18n]</label>
		[cred_field field='last_name' class='form-control' output='bootstrap']
	</div>
</div>

<div class="row">
	<div class="form-group col-md-12">
		<label for="%%FORM_ID%%_nickname">[cred_i18n name='nickname-label']For display to other users, use:[/cred_i18n]</label>
		[cred_field field='nickname' class='form-control' output='bootstrap']
	</div>
</div>

<div class="row">
	<p>Password update:</p>
	<div class="form-group col-md-12">
		<label for="%%FORM_ID%%_user_pass">[cred_i18n name='user_pass-label']new password[/cred_i18n]</label>
		[cred_field field='user_pass' class='form-control' output='bootstrap']
		<label for="%%FORM_ID%%_user_pass2">
		[cred_i18n name='user_pass2-label']new password repeated[/cred_i18n]</label>[cred_field field='user_pass2' class='form-control' output='bootstrap']
	</div>
</div>

[cred_field field='form_submit' output='bootstrap' value='Submit update' class='btn btn-primary btn-sm']

[/creduserform]

[Paul Bowman]

Dev copy of the site is available if needed.

[Nigel]

By "breaks the page" I assume you mean something along the lines of the page failing to complete loading, rather than the layout being broken or some other visual glitch.

In which case it sounds like you should expect to see errors in the PHP logs that should indicate where the problem arises.

If you haven't already, turn on the debug log by editing your wp-config.php file and change the line with WP_DEBUG like so:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
define('WP_DISABLE_FATAL_ERROR_HANDLER',true);

That will create a debug.log file in your /wp-content/ directory which you can examine in any text editor. Try visiting the page with the form again and then inspect the log.

I tested this on my own site and didn't see any problems.

Let us know what you find.

[Paul Bowman]

Thank you Nigel.

Yes, the page fails to complete loading if that one Cred field is present, whether added to the form via the visual editor or in ‘expert mode.’ It’s weird.

For me, it seems, setting WP_DEBUG and WP_DEBUG_LOG to ‘true’ doesn’t result in a .log file being written in /wp-content with page loads. I don’t have a deep background here, but I expect that has to do with the hosting service I’m working with. I’m going to have to do a little work to get this figured out, it looks like. Will report back shortly.

[Shane]

Hi Paul,

Usually there is also a php log on the server itself that will automatically log all php errors.

Perhaps you can check this as well for any errors relating your site and toolset. Then provide us with what error is being thrown so we can have the best plan of action to move forward.

Thanks,
Shane

[Paul Bowman]

Okay, many thanks to you both. I didn’t know where to begin, and this will stand me in good stead in future troubleshooting situations, I’m confident.

WP_DEBUG still isn’t working for me, but I located the server’s PHP error log. Thanks for that additional pointer, Shane.

Here’s the relevant bit from the error log:

[31-Jan-2022 19:50:15 UTC] PHP Warning:  Illegal string offset 'validate' in /dev.###.net/htdocs/wp-content/themes/generatepress_child/functions.php on line 702
[31-Jan-2022 19:50:15 UTC] PHP Fatal error:  Uncaught Error: Cannot use string offset as an array in /dev.###.net/htdocs/wp-content/themes/generatepress_child/functions.php:702
Stack trace:
#0 /dev.###.net/htdocs/wp-includes/class-wp-hook.php(309): my_required_fields()
#1 /dev.###.net/htdocs/wp-includes/plugin.php(189): WP_Hook->apply_filters()
#2 /dev.###.net/htdocs/wp-content/plugins/cred-frontend-editor/application/controllers/form_rendering.php(146): apply_filters()
#3 /dev.###.net/htdocs/wp-content/plugins/cred-frontend-editor/application/controllers/translate_field_factory.php(225): CRED_Form_Rendering->add()
#4 /dev.###.net/htdocs/wp-content/plugins/cred-frontend-editor/application/models/field/command/custom_fields.php(67): CRED_Translate_Field_Factory->cred_translate_field()
#5 /dev.###. in /dev.###.net/htdocs/wp-content/themes/generatepress_child/functions.php on line 702

I haven’t tried to decipher all of that, but figured it would make sense to you.

What I did understand was that I should try disabling the filter at functions.php line 702, which was this:

/**
 * required form fields
 */
function my_required_fields( $field ){
    if(in_array($field['id'], array('first_name', 'email'))){
        $field['data']['validate']['required'] = array (
            'active' => 1,
            'message' => 'This field is required'
        );
    }
    return $field;
}
add_filter('cred_filter_field_before_add_to_form', 'my_required_fields', 10, 1);

I’d forgotten that I’d put this filter in place for a signup form, added to the site some time ago, also using the Cred ‘first_name’ field. That earlier form is working fine, but the filter seems to have been a problem for this more recent one.

I’ve now applied the recommendation for modifying this filter in the reply by Chanond here: https://toolset.com/forums/topic/cred_filter_field_before_add_to_form-not-working-in-php-7-1/?bbp_reply_to=1268509&_wpnonce=b25a341ff5#new-post

Making that change allows my new form (and the pages it’s in) to load.

My issue is resolved now. Thank you!