Any Laravel experts here?

[Walter]

Any Laravel experts around here? I'm currently experimenting with Laravel and currently I'm banging my head against a wall (probably a simple problem for a seasoned Laravel programmer)....

 

[Jerry]

I've used it a lot. What is the issue ?

 

[Sim]

Yeah, I do a lot of Laravel development - what's up?

 

[Walter]

I have a given user table (not Xenforo, not changeable) which differs from the Laravel default.

What works: different table name and different primary key (changed in User.php)
What doesn't work: different name for email field.

I even managed to register at the new site, everything in database looks ok but when I try to login it fails because Laravel still tries to query with a 'WHERE email=xxx@xxx.com'.

TBH, I'm astonished that such simple things make so much troubles?

 

[Sim]

Yes, the default authentication controllers assume that you are also using the supplied migration to create your database with the correct column names (or your existing database already uses the required column names).

If your database uses different column names than "name", "email" and "password" (and "remember_token" etc), you will need to re-write the default controllers and traits.

App\User - you need to adjust the fillable and hidden protected variables

You'll also need to remove the "use Authenticatable, CanResetPassword;" line because neither of these traits (which are part of the Illuminate namespace and are thus uneditable) are compatible with changing the column names.

You'll then need to provide your own implementations of the two contracts used by the User model:
Illuminate\Contracts\Auth\Authenticatable and Illuminate\Contracts\Auth\CanResetPassword

App\Http\Controllers\Auth\AuthController uses the Illuminate\Foundation\Auth\AuthenticatesAndRegistersUsers trait, which is incompatible with different email and password column names (check the validation fields in the postLogin method).

App\Http\Controllers\Auth\PasswordController uses the Illuminate\Foundation\Auth\ResetsPasswords trait, which is also incompatible with different column names.

The authentication controllers are only provided as a convenience for simple applications and as an example of how to implement these mechanisms.

If you are doing anything different to the default database configuration, you'll need to write your own controllers to suit and not use the supplied Illuminate traits which make certain assumptions.

Hope this helps.

 

[Walter]

Thank you very much for your detailled answer! Will give it a try.

But....
I can't help but thinking that Laravel has a loooong way to go. If such simple things force me to rewrite so many parts Laravel probably still isn't ready....

Quite absurd that I was able to register a user but couldnt login

 

[Sim]

But....
I can't help but thinking that Laravel has a loooong way to go. If such simple things force me to rewrite so many parts Laravel probably still isn't ready....

Ready for what?

Laravel is a framework. It lets you build applications from scratch. It's a set of tools which help you build applications - it's not an off-the-shelf application ready to go.

If your application is a simple one, you can use the supplied controllers to quickly get an authentication mechanism in place based on the assumptions they make.

Otherwise, you build it all yourself using their examples as a template.

Earlier versions did not provide any authentication controllers at all - you had to code it all by hand. At least you now have a working example to base your code on. That's all it really is - an example, any serious application would never use this base-code unmodified, because it really does make too many assumptions.

There are plenty of large scale applications that were written using Laravel in production around the world today. It is very ready and has been for quite some time now.

Have you used any other PHP frameworks?

 

[Walter]

Sorry, I really didn't want to attack Laravel and get in an argument with you. I'm evaluating it.

But my approach to this issue would be: either I don't provide an authentication mechanism or I provide a good one. Nothing in between. Why can I change the name of the table name and the user but can't change the email field?

 

[Sim]

Sorry, I really didn't want to attack Laravel and get in an argument with you. I'm evaluating it.

No argument - just trying to understand what your expectations are and make sure you understand what Laravel is capable of.

But my approach to this issue would be: either I don't provide an authentication mechanism or I provide a good one. Nothing in between. Why can I change the name of the table name and the user but can't change the email field?

The problem is with the way Eloquent models work - the column names are implicitly linked to the property names of the model, so $model->email expects to find the data in the email column.

However, there is an alternative - Eloquent models allow you to provide accessors and mutators for the various fields (user, email, password, remember_token, etc) such that when you request the "email" from the model, it actually retrieves the value from the column names you define.

For example ...

class User extends Model {

    public function getEmailAttribute()
    {
        return $this->email_address;
    }

    public function setEmailAttribute($value)
    {
        $this->attributes['email_address'] = $value;
    }

}

Then $model->email will actually be returning the value of the column 'email_address' rather than 'email'.

There is some magic behind the Eloquent model class which makes this possible - have a close look at the Model class to understand more about how it works under the covers - it really is quite powerful.

Personally I don't like this approach though and would rather write my own clean user model code to start with to make it much more obvious what is happening (less magic).

Also, don't forget that Eloquent isn't the only way to do this. Personally, I prefer using Doctrine for my ORM which doesn't have these problems because you can configure the table and column names directly in the model annotations.