Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

daveb2's avatar

spatie/laravel-permission ignoring database contents

Hi all,

I am running the following code in a blade template:

@can('manage-users')
<p>HELLO WORLD</p>
@endcan

...and the text <p>HELLO WORLD</p> is not seen, when I expect that it will be.

I am trying to use role-based permissions, where a permission that I am testing for (called 'manage-users' in this case) is assigned to a role, and a user is assigned to that role. I then use a @can to test whether the currently logged-in user has that permission.

I am logged in (authorised) in a web session of the application as the User with the id 1 (it is the only user in the users table). This user had all of the relevant permissions setup in tinker, eg.

$user = User::first();
$role = Role::create(['name' => 'admin']);
$permission = Permission::create(['name' => 'manage-users']);
$role->givePermissionTo($permission);
$user->assignRole('admin');

In my permissions table I have a record:

id: 1
name: manage-users
guard_name: sanctum
created_at: 2023-02-14 03:08:51
updated_at: 2023-02-14 03:08:51

and in my roles table I have a record:

id: 1
name: admin
guard_name: sanctum
created_at: 2023-02-14 03:05:07
updated_at: 2023-02-14 03:05:07

and in my role_has_permissions table I have a record:

permission_id: 1
role_id: 1

My model_has_permissions table is empty, but in my model_has_roles table I have:

role_id: 1
model_type: App\Models\User
model_id: 1

I have use Spatie\Permission\Traits\HasRoles; at the top of my User.php model class file, and use HasRoles; at the head of the class definition.

I have added Spatie\Permission\PermissionServiceProvider::class, to the 'providers' => [] section of config/app.php

I've tried clearing the caches (there are soooo many in Laravel, I don't think I know them all) including:

$user->forgetCachedPermissions();// to clear the spatie permissions cache for the user

php artisan config:clear

php artisan optimize

rm ./bootstrap/cache/*.php

sudo php artisan cache:clear # always have to use sudo with this one for some reason

php artisan route:clear

php artisan view:clear

...and that's all the caches I know of I think. If anyone knows any others I can try clearing please let me know.

But yes I'm stumped - I have two projects using the same version of spatie-permissions (5.9.1) and one works and one doesn't, using the same code (as far as I can tell). I have copied the code from the old project, where it works, into the new project, where it doesn't.

I have LOG_LEVEL=debug in /.env but I am not seeing anything in the log, and the page is rendering with status code 200.

Does anybody know what might be going on here?

EDIT: Sorry I forgot to say, I have tried editing the database and changing all the guard_name fields to web instead of sanctum, but it doesn't make any difference.

0 likes
7 replies
daveb2's avatar

OMG. After going over this for at least the 50th time today it seems to be working?!?!

Here is the summary note I have made for the future on how to clear the laravel caches - one of these must be the key.

php artisan config:clear
php artisan optimize
rm ./bootstrap/cache/*.php -f
php artisan route:clear
php artisan view:clear
sudo php artisan cache:clear

...also, in tinker:

$user->forgetCachedPermissions();// to clear the spatie permissions cache for the user

But now it's working. It's as frustrating as much as it is a relief. Holy cow there are so many caches, and spatie/laravel just flatly ignores the database contents unless you can find the right cache, no matter how many times you recreate the permissions records!

Anyway, hopefully this is of some use to someone (probably just future me).

Sinnbeck's avatar

@daveb2 spaties package only uses it's own cache $user->forgetCachedPermissions().

But instead run the global one, not on a user

app()->make(\Spatie\Permission\PermissionRegistrar::class)->forgetCachedPermissions() 

So if it happens again only focus on this one. Run it multiple times if needed.

Also don't run the other cache commands in dev

1 like
daveb2's avatar

Thanks @Sinnbeck I will add that to my list.

Would you mind elaborating on why not to run some of those commands in dev? Everybody has a different story when it comes to cache.

Sinnbeck's avatar

@daveb2 ok let's run through it quickly

php artisan config:clear //clearing config cache. Yay 
php artisan optimize //adding config, route and view cache 
rm ./bootstrap/cache/*.php -f //remove config again. Yay 
php artisan route:clear // clear route cache. Yay 
php artisan view:clear // clear view cache. Yay 
sudo php artisan cache:clear // clear config cache as super user (shouldn't be needed) 

So you set and clear your caches multiple times. So the end result is good. But not setting it in the first place is better. Be aware that all of these caches are just a bunch of php files. Not using the Cache in laravel

Now why is it bad to set it in dev (you can set it to make sure it does not break your app, but clear it at once after). Let's say that you run the optimize command to speed up your app while developing. Sounds like a good idea. Let me give you examples of possible issues.

  • you add or change a route. It doesn't work. So you change the order of your routes. Delete them. Create them again. Nothing works. This is because it's cached so it ignores all changes. This can waste hours of your time (i have seen this happen many times)
  • you change your config. Maybe add a new package, or edit an env value. It does not work. Config is cached and does not pick up any changes
  • this is the worst one and I have seen many people get real angry. You have spend month setting up the data in your dev database. Now it's time for testing so you set up everything correctly. It works! Now you optimize your app with the command. Now when running tests, laravel completely ignores your test credentials and uses the database credentials from cache.. Your real database. Now it just deleted everything in your dev database.. Time to start over
1 like
daveb2's avatar

Lol thanks for that - that totally makes sense. I never want to cache anything in dev if possible (I didn't realise optimize was building the cache).

It might take me a while to understand point #3 but I think I get the general idea.

BTW I find that I always need to run cache:clear with sudo, which I don't like. This is even from a clean composer install. One day I'll look into this some more too.

Sinnbeck's avatar

@daveb2 Sounds like a permission issue. If ever your files get messed up permissions, make sure they are changed to be owned by the correct user instead :)

1 like
daveb2's avatar

@Sinnbeck absolutely. But I find I get these issues even when I've created the project as a non-root user, and I have to keep going in as root and repairing the ownership. Must be something to do with my apache config.

Please or to participate in this conversation.