Plesk bare metal server installation of Laravel ignoring @if statements… huh?!

I recently got a bare metal server (running plesk) set up for hosting multiple Wordpress/Laravel sites and while setting things up I've come across something really weird.

I've been able to set the server up as per my old VPS and have created several domains, each with an installation of my 'base' Laravel application.

Everything appeared to be working but I found that a lot of the Laravel admin area which shows buttons based on a users permission (Spatie) aren't rendering.

Looking into it a little deeper I've noticed that some other areas which are based on @can(for permissions) aren't working - when rendering the page these areas are being skipped.

It looks like this on the Plesk server…

Shouldn't look like this

…instead of this which is on the WHM VPS…

Should look like this

I've installed Laravel on several VPS which use WHM and cPanel without any issues but on this bare metal server only Plesk is available so I'm not sure if there's a setting on it which is causing this or not.

The two Laravel installations I'm testing are exactly the same as those running on the VPS, so there's no change to the actual coding so it must be server related.

The server spec is:

Ryzen 7 Pro
AMD Ryzen 7 Pro 3700
8 cores x 3.6GHz
64GB RAM
DDR4 ECC
960GB NVMe
(2x 960GB)
AlmaLinux 8
Plesk Obsidian

I have the Laravel Toolkit extension installed and have updated composer to the latest version etc.

Has anyone else come across this or have any idea what could be causing this?

I'm stumped!

click

3 years ago

Level 35

I really doubt it is related to hardware. I guess it is something related to some cache?

Did you already debug what exactly is failing? Is it with all @if even @if(true) or only in combination with a permission check?
What happens if you clear the (view) cache and refresh the page?

idcreatv

3 years ago

Level 3

@click I’ve checked my logs in storage and there’s nothing recorded for either domain. I’ve checked the server logs and there’s nothing flagged there either.

I clear caches whenever I do an install so I know it’s not that.

Perhaps it’s the spatie permission package which is having the problem. Will test it tomorrow and report back with results.

(What’s weird is that I’ve installed another test domain with the same Laravel installation and that displays fine. I’ve updated composer on it, cleared caches etc and it’s still fine. Weird…)

Cheers. 👍

idcreatv

3 years ago

Level 3

@click I’ve been looking into this and realised I said @if aren’t working when I meant @can (sorry!). I’ve updated my original question accordingly.

I’ve cleared caches and checked these two installations against another new install (which works) and they’re running the same php version, same spatie package etc.

idcreatv

3 years ago

Best Answer

Level 3

Okay, I went through everything and narrowed it down to composer.json and package.json (plus the lock files) had been changed by (I think) Laravel Toolkit. Why, I don't know, but when I did a diff check they were different from what I uploaded.

I went through a lot of tests, clearing caches and re-uploading files etc and eventually solved it, so if anyone else has a similar problem the method below fixed everything:

I re-uploaded composer.json and package.json (plus the lock files) from my master files and (using SSH) ran the commands to clear all caches, re-installed node_modules, cleared all caches, ran npm run prod and cleared caches again.

Then I refreshed the site and everything was working perfectly.

So, I'll stay away from the Laravel Toolkit, I much prefer using SSH terminal and running my commands as that way I know what is happening.

click

3 years ago

Level 35

@idcreatv great you were able to figure it out. It looks like you / the script ran composer update instead of composer install during one of the deployments.

Please or to participate in this conversation.