Store your users in a database.
If you have a large amount of users, or you need to scale horizontally, it may make sense to store them in a database.
.env file, add the following variables and customize as necessary:
DB_HOST=localhost DB_DATABASE=database-name DB_USERNAME=username DB_PASSWORD=password
Generate the migration file into
site/database/migrations by running the following command:
php please make:user-migration
Modify the migration file as necessary:
- You may optionally separate the
- If you don’t plan to use OAuth, you can remove the references in the
site/settings/fieldsets/user.yaml fieldset as necessary:
- Ensure you have the correct name
last_name) field(s) to match your migration.
- Remove the
contentbiography field, unless you’ve specified a matching column in your migration.
- Add validation to require non-nullable fields in your migration.
Make sure the database you specified in your
.env file exists and run the migration:
php please migrate
Finally, enable the driver in your
If you chose to separate the
name column into
last_name, you should be aware that the default OAuth implementation will try to save a
name value to the user and result in an exception.
You will need to customize the user data creation to handle the two columns.
The Redis user driver assumes you are using Redis as the cache driver.
Ensure you are using Redis as the cache driver:
Enable the driver in your
By default, user files will still be saved to disk. This will allow you to track them in source control. Additionally, when your Redis cache is empty, any user files will be read from disk.
If you don’t have a need to track user files, you may disable them being written to disk inside
A typical example where you may not care about keeping user files is if you are using OAuth. The users will be re-created on the fly whenever they re-authenticate with the provider.