Blade is not rendering the views, which are displayed as raw php.

[JesusRodriguezAcosta]

Laravel Version

11.x

PHP Version

8.3.9

Database Driver & Version

No response

Description

A few days ago, we updated Laravel and PHP to the latest available versions. Everything went great until this morning when the views stopped working in our last build. Since then, we were not able to put it working again.

Apparently, Blade is not "processing" the views, which are displayed in as raw php.

So, what you see in the HTML is like:

@extends('system.library._layout')

@section('sub-breadcrumbs')
    <li class="breadcrumb-item">
        <a href="[{{ _route_system_library_topics() }}](http://whatever.com/s/library/%7B%7B%20_route_system_library_topics()%20%7D%7D)">Temas</a>
    </li>
    
@endsection
...

I have no idea why it was working yesterday and not today. I expent several but nothing worked. I also found out that if I compile the views, some of them are displayed, but the error pages produce another error. It’s really strange.

Upon inspecting the cached views at runtime within "storage," it is clear that Blade directives are indeed not being processed. However, if I run php artisan view:cache, they are processed correctly.

I also downgrade to 10, but still the same issue with blade.

EDITED; I tried with a clean installation of Laravel 11 and still getting the same problem, so it looks something related with the container (alpine 3.20 with some extensions).

The error shown:
Undefined variable $component (View: /var/www/app/vendor/laravel/framework/src/Illuminate/Foundation/resources/exceptions/renderer/show.blade.php)

@component('Illuminate\View\AnonymousComponent', 'laravel-exceptions-renderer::layout', ['view' => 'laravel-exceptions-renderer::components.layout','data' => ['exception' => $exception]])<?php if (isset($attributes) && $attributes instanceof Illuminate\View\ComponentAttributeBag): ?><?php $attributes = $attributes->except(\Illuminate\View\AnonymousComponent::ignoredParameterNames()); ?><?php endif; ?><?php $component->withAttributes(['exception' => \Illuminate\View\Compilers\BladeCompiler::sanitizeComponentAttribute($exception)]); ?> <div class="renderer container mx-auto lg:px-8">@component('Illuminate\View\AnonymousComponent', 'laravel-exceptions-renderer::navigation', ['view' => 'laravel-exceptions-renderer::components.navigation','data' => ['exception' => $exception]])<?php if (isset($attributes) && $attributes instanceof Illuminate\View\ComponentAttributeBag): ?><?php $attributes = $attributes->except(\Illuminate\View\AnonymousComponent::ignoredParameterNames()); ?><?php endif; ?>

I've tried with Alpine Edge and PHP 8.3.10 and the same error occurs. Does anyone have any idea what might be happening?

Steps To Reproduce

No idea.

[JesusRodriguezAcosta]

After many hours of testing and after seeing that a fresh installation of Laravel 11 also failed, I modified the container, based on Alpine 3.20 and PHP 8.3, to use version 8.2, and it started working again. Something changed this morning in Alpine's PHP 8.3 libraries, particularly FPM, which completely broke the application and seems to be causing these issues.

Since it does not seem to be related to the framework, I kindly ask you to CLOSE THE ISSUE and accept my apologies.

As soon as things here return to normal, I will try to gather more information (if possible) in case it is of interest. Even so, if anyone is curious and requests more information, I will try to provide it.

Thank you all,
Jesús

[rodrigopedra]

If this happens again, upon updating PHP's version, try running these commands:

composer dump-autoload
php artisan optimize:clear

[JesusRodriguezAcosta]

Hi @rodrigopedra,

Thanks for the reply. I tried everything, also clearing all caches but it finally seems to be a problem in the alpine FPM package for PHP 8.3, at least with the configuration I use. I am preparing a docker image to reproduce the error and pass the issue to the package maintainer.

Thanks again.

[JesusRodriguezAcosta]

Wow, I created a couple of images (PHP 8.2 and 8.3) this weekend to try to reproduce the error with an empty Larevel 11 project, but I couldn't reproduced it.

I will try PHP 8.3 with our application again to see if the issue with the package, I believe it's FPM, has disappeared as suddenly as it appeared.

[KreisonReis]

I have the same problem, but my config are: php 8.3.8, npm 10.2.4, node 20.11.1 and composer 2.7.1

[JesusRodriguezAcosta]

Hi, @KreisonReis,

What distribution or container are you using?

[KreisonReis]

Linux version 5.15.0-107-generic (buildd@lcy02-amd64-012) (gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0, GNU ld (GNU Binutils for Ubuntu) 2.38)

• Laravel 11
• ReactJS 18.2
• InertiaJS 1.0
• PHP 8.3.8
• Vite 5
• Tailwindcss 3.2.1

[JesusRodriguezAcosta]

Thanks, @KreisonReis,

I'll check with another container based on this distribution (Ubuntu 11.4.0) to see if I can reproduce the error. That's what we need to shed some light on the issue.

[KreisonReis]

Thanks, @KreisonReis,

I'll check with another container based on this distribution (Ubuntu 11.4.0) to see if I can reproduce the error. That's what we need to shed some light on the issue.

I had a problem with file permissions, after that I moved to another branch and ran the php artisan optimize command, it works, but if it doesn't run it gives an error!

[luizboaretto]

Maybe the problem is with the OpCache. We have the same problem and disabling opcache seems to be working

[JesusRodriguezAcosta]

I think so. As soon as I find a gap I will repeat the test modifying the default configuration. I am almost sure that the problem is there.

[jonathan-bird]

@JesusRodriguezAcosta @luizboaretto Did you ever get to this bottom of this? I have the same issue which is intermittent on 6 different codebases. Not using Docker, or Alpine, just standard PHP 8.3 FPM. I've tried clearing OPCache and changing PHP Versions to 8.2 (as well as clearing everything in php artisan and composer) with no luck.

Only thing that's worked for me was adding a random space to a view and redeploying. This makes me think it's still OPCache maybe.

[JesusRodriguezAcosta]

No, I haven't had the problem again and I haven't been able to reproduce it, although I certainly did very little testing.
Reading the comments, it seems that the problem is still there and that it is not directly related to Laravel, rather it seems like a malfunction or bug in OpCache that should be reported to its developers.

[chibyk101]

I'm getting the same issue right now on a freshly installed Laravel 11.x, I believe it's an 11.x issue because 10.x works fine

Blade directives such as @include, and @content are printed plain on the pages, and views are not processed.

[henzeb]

My advice is to have a base image with all dependencies installed so all you have to do is add your code to it when you build the final image.thst way you have always the same versions. See it as a form of package.lock/composer.lock.

[SimonErich]

Just had the exact same issue and searched for hours.
Solution (for now) was for us to disable opcache and clear laravel caches. Then everythign worked fine again.

[chris-skilltech]

I've increased our memory and files within our opcache settings but still hitting the issue.

I'm not convinced this is a pure opcache issue as we did not have this problem in Laravel 10 and it is only affecting Blade files not normal PHP files (controllers, models, etc). If it were a pure opcache issue I would expect to see far more talk about this online however this thread is the only discussion I have found.

I'm also seeing this issue on servers that host 1 site and those that host 20+ sites.

I upgraded to 8.3 and Laravel 11 and then started hitting the issue.
Some of the view cache files in storage/framework/views contain blade not PHP and haven't been compiled properly. I'm not sure why this would be?

Unfortunately the solution is still the same:

1. Restart apache
2. Touch the affected blade template file(s)
   A very manual process and not scalable.

[macropay-solutions]

@chris-skilltech

As a resume of OPcache Changes in PHP 8.3
The opcache.inherited_hack directive is no longer present in PHP 8.3.0.
The opcache.consistency_checks directive was disabled as of PHP 8.1.18 and 8.2.5, and it was removed entirely in PHP 8.3.0.
The opcache.fast_shutdown directive is also not present in PHP 8.3.0.
The maximum permissible value for opcache.max_wasted_percentage is now "50", which is enforced if a larger value is set.

Maybe these are the culprits.

[tom-skilltech]

Update from our side. We have since increased our opcache memory settings to 2GB, as the previous value was still causing the issue fairly often.

We've had a handful of instances reported by users since this change, however, the actual "broken" view was generated before we made the opcache changes, so far 🤞we haven't seen an instance of this since making our change to 2GB, all reports so far have been from before the change but not noticed until recently.

Similar to OP, we have narrowed down that the Blade code is being returned to the screen as for whatever reason the Blade compilation step does not happen, but we still get the view cache file created. So in storage/framework/views the X.php cache file contains blade syntax, rather than the transformed output that would be expected.

Performing a view:clear in our experience, seems to exaggerate the problem, causing most views to fail and making it quite a task to get an environment fixed again, sometimes even needing a restart of Apache. A reliable process we have found is to identify the impacted cache view file, and deleting it. This will then cause a recompile and will not produce a broken output. We then use grep to check for any other instances by searching on on common Blade syntax.

[crynobone]

@tom-skilltech is opcache.enable_cli set to true in your environment?

[tom-skilltech]

@crynobone It is not, it is set to 0 both in the CLI environment and when running through Apache.

[eugen-bondarev]

I'm also having this issue with php8.3 in a fresh Laravel project.
PHP 8.3.16, Laravel 11.31, created with Laravel Installer 5.10.0

[tom-skilltech]

@eugen-bondarev Interesting you're experiencing it with a fresh project.

Would you be able to provide the steps for getting that setup, what you used, and what you did to trigger it? As if this is something that can be much more easily reproduced with a blank Laravel project, we can maybe promote this discussion to a Laravel bug and/or a PHP bug to get more of a technical investigation going under the hook of the framework and/or PHP itself.

Currently, as my colleague @chris-skilltech mentioned above, this thread is all we've been able to find on this issue, and we're experiencing the problem almost daily on our environments. If it was more of a wider non-Laravel specific issue then I would expect it to be easier to find and already reported on the PHP bug tracker.

[eugen-bondarev]

@tom-skilltech thanks for your quick reply :)

Would you be able to provide the steps for getting that setup, what you used, and what you did to trigger it?

Sure.

laravel new foo

1. No starter kit
2. Pest
3. SQLite
4. "yes" (run migrations)

cd foo

php artisan serve

Result:

[tom-skilltech]

@eugen-bondarev That's perfect thanks, screenshot is super helpful too!

I'm going to see if I can reproduce on my machine using your steps, which is Windows 11, what OS were you using in the screenshot?

I also assume default PHP 8.3.x configuration?

[eugen-bondarev]

@tom-skilltech

Yes, default configuration.

Update:
I was able to fix the problem on my machine and I guess I know what caused it.

After encountering this issue with a fresh project I went back to another project that I work on daily and there I faced another set of weird issues: Laravel components stopped rendering, I had lots of "component not found" errors.

And then I realized - when setting up that fresh project I must have messed up my PHP installation, because I accidentally ran this PHP installation script from the Laravel documentation, even though I already had PHP installed:

Long story short, here's what I did to fix my local setup:

Caution

This removes PHP

sudo apt-get purge 'php*'

/bin/bash -c "$(curl -fsSL https://php.new/install/linux/8.3)"

php artisan optimize:clear
php artisan cache:clear

rm -rf vendor

composer install

php artisan serve

Now both projects work as expected and Blade templates render properly.

I think due to the fact that I had PHP8.3, installing PHP8.4 messed up some other components.

[tom-skilltech]

@eugen-bondarev Hmm unfortunately I've not been able to reproduce on Windows 11, or with a fresh Debian 12 Linux docker where I installed 8.3. Even 8.2 -> 8.3 upgrade didn't trigger it.

Interesting you experienced it following an upgrade, I wouldn't have assumed it'd cause an issue as (unless the Laravel command in their docs does something different) PHP installs are scoped to different folders. It is a variable we have changed on projects experiencing it vs ones that do not seem to be, though 🤔