Member Login and Inline Errors

You can pass your own validation class, which is what I did for the login. There is a parameter for this called “form_class=”

Strangely, it does not work for other EE forms, but it does for the login form. That way, you can build your own inline validation on pages. I actually prefer this method, EE passing its own classes creates all sort of mess on templates. An example of this is the channel forms, on the latest version they to inject their own classes and I had to remove that code because it was messing my page design.

Yeah, that’s sorta my suggestion to the client; I can create a custom Ajax endpoint they can use to verify the credential pair before submitting the form. But, that’s hardly “good” IMO and completely bypasses the template tag.

I don’t know; I was really hoping there was a way to do inline error messages on the login form in 2022. FWIW, it’s not that the client wants to display “required” per field but that they want to avoid the default EE error template and keep the user on the login form. For example, displaying ‘user not found’ inline with the username field.

That’s not possible? Am I implementing this weird and there’s an “official” way to do this?

Correct, in my case I just made some custom validators that do check for content as well, not just missing, example, if something is an email, or numbers, or max characters, etc.

You can do all that with your own validations. Granted, it bypasses the EE field validation, but that would still be triggered on the server side validation if for example someone submits the form or disables your validation on purpose (like disabling JavaScript).

I found out it’s a good compromise, the validation is on the user side for a better GUI experience, but EE will still make its own server validation (which is the real security one). Most users will never see the EE one unless they are messing up with something in the source code. Ideally you could use the EE validation and just pass the results to your template with CSS or Ajax, but in my experience this does not work very nicely with your own design either as everyone might use a different style or framework. Might work for basic designs or simple sites.

This also did not play right when you have multiple languages, as you get a generic text. In my experience, I was just better off not using the EE validation for the user front end, since it is not flexible enough at this point for my needs.

The member parameters are mostly new and still missing features, while the login one comes from older versions, reason why it probably had that inline methods you mentioned, other member forms for example don’t even support the class parameter to name one. I wrap them in another form or div to apply my style class to those forms, as discovered recently. I suspect this stuff will be improved in further releases, and maybe inline EE validation can be used again for most forms or consumed to a template in a better way.

For the login, validation should be quite simple as you are just checking mainly one field (username). You should not validate the password since it’s very complex, and you have no idea what characters someone might use. Passwords are usually not validated on the user front. It’s mainly the username only, and if it’s an email, there is HTML 5 build in email field for that, most validators will have at least email, numbers, etc. If it’s something else, like a number, again very simple to validate.

I see. Bummer. Still, thank you SO very much for the detailed explanation. For real. You could have come in with “No, you can’t do that” and called it a day. The follow through made this make a ton of sense and really understand why it is that way. For real; I appreciate the effort.

So, for now, anyone who comes by this in the future, the answer’s:

No, you can’t do that as of 6.2.7.

I’ve put a little Action method together for this particular client; thought I’d share for anyone else who could use:

public function member_login_ajax_validate()
{
    ee()->load->library('Auth');
    $verify = ee()->auth->verify();
    $reasons = [];
    if(!$verify) {
        $reasons = ee()->auth->errors;
    }

    $email = '';
    echo json_encode([
        'result' => ($verify ? 'success' : 'fail'),
        'reason' => $reasons,
        'username' => ee()->input->get('username'),
    ]);
}

Is the “little action method” workable for someone like me? I can understand and work with the basics of EE, but not with things like ajax, or php. If not, I’ll just leave out the validation bit out. It’s not such a big deal.

Here’s a comprehensive response addressing the inline error handling issue in ExpressionEngine 6 for login forms:

Understanding the Issue:

• The error_handling="inline" parameter for {exp:member:login_form} is not functional in EE6.
• It’s unclear if this change was intentional or a bug.

Available Solutions:

1. JavaScript-based Error Handling:

   • Use JavaScript to validate fields and display inline errors.
   • Provides flexibility for custom styling and error messaging.
   • Example using jQuery:

   $('#login-form').submit(function(e) {
      // Validate fields here
      if (/* invalid fields */) {
          e.preventDefault(); // Prevent form submission
          // Display inline errors using jQuery
      }
   });
   

2. Third-Party Add-Ons:

   • Explore add-ons that offer inline error handling for forms:
     • FreeMember:
     • Solspace User:
     • EE Hive Login:

3. Template Modifications:

   • Manually create inline error elements within your template.
   • Check for error variables (e.g., error:username) and display errors accordingly.
   • Less flexible but avoids additional code or add-ons.

4. Custom Solutions:

   • If necessary, create custom form handling actions or modules for more control over error display.
   • Requires development expertise.

Additional Considerations:

• Stay updated with any future EE releases that might address this issue.
• Consider the project’s specific needs and available resources when choosing a solution.

I hope this comprehensive response addresses the infinite craft issue and provides helpful options!

Complete and utter success! Among the various papers on the issue, this one is possibly the most compelling. Very impressive information! Given my significant experience in this industry, I fully understand the level of effort you are putting in. I sincerely appreciate the outstanding service you have offered. papa’s freezeria

The username is the main focus, and if it’s an email, there is a built-in email field in HTML 5 for that. Most validators will include email, numbers, and other types of validation. If it’s a different type head soccer of input, such as a number, it’s also very simple to validate.

The issue you’re experiencing with the {exp:member:login_form} tag likely stems from changes in how sprunki mods ExpressionEngine (EE) handles form error handling and inline error display in version 6.x compared to earlier EE2 days.

From what you describe, you’re right — in ExpressionEngine 6.2.7, error_handling=”inline” for the {exp:member:login_form} has some known issues and doesn’t behave exactly like it did in EE2. Even though there was a fix attempt (like in issue #705), it seems the login form still defaults to using show_error() if something goes wrong, instead of displaying inline errors properly.

If inline error handling is crucial for your client, you might need to custom-handle validation messages by:

Using a custom extension or hook to intercept login errors, dummynation

Or manually parsing errors in a separate template (for now).

It’s not that you’re missing anything — it’s more that full support for error_handling=”inline” on login forms hasn’t fully returned. You might want to check if upgrading to EE7 helps, though, because some member module behaviors were improved there.