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 🤔

[JFBauer-ZeroPlex]

My investigation on this

So I have experienced this issue a couple of times now, and again today. Without us actively doing anything on the server, but possibly automatic minor patches are performed, i'm not certain. I've debugged the issue quite a bit, and figured somethings out.

I've focused my attention mainly on laravel/framework/src/Illuminate/View/Compilers/BladeCompiler.php, all code fragments below are from this file.

1. When clearing cached view and going to the page again, it would create a new cached view, but this cached view would simply contain blade syntax which it shouldn't at this point.

2. Adding dumps in the compile function, made it clear that the original content and compiled contents were the same

   /**
        * Compile the view at the given path.
        *
        * @param  string|null  $path
        * @return void
        */
       public function compile($path = null)
       {
           if ($path) {
               $this->setPath($path);
           }
   
           dump('compile being called');
           dump($this->getPath());
   
           if (! is_null($this->cachePath)) {
   
                   dump('Original contents');
                   dump($this->files->get($this->getPath()));
   
               $contents = $this->compileString($this->files->get($this->getPath()));
   
               if (! empty($this->getPath())) {
                   $contents = $this->appendFilePath($contents);
               }
   
                   dump('Compiled contents');
                   dump($this->files->get($this->getPath()));
   
               $this->ensureCompiledDirectoryExists(
                   $compiledPath = $this->getCompiledPath($this->getPath())
               );
   
                   dump($compiledPath);
   
               $this->files->put($compiledPath, $contents);
           }
       }

3. In the compileString function I noticed that my dump on token_get_all($value), would just return a single element in it somehow, where as on healthy projects it would return a whole list.

   /**
    * Compile the given Blade template contents.
    *
    * @param  string  $value
    * @return string
    */
   public function compileString($value)
   {
       [$this->footer, $result] = [[], ''];
   
       // First we will compile the Blade component tags. This is a precompile style
       // step which compiles the component Blade tags into @component directives
       // that may be used by Blade. Then we should call any other precompilers.
       $value = $this->compileComponentTags(
           $this->compileComments($this->storeUncompiledBlocks($value))
       );
   
       foreach ($this->precompilers as $precompiler) {
           $value = $precompiler($value);
       }
   
       dump(token_get_all($value));
   
       // Here we will loop through all of the tokens returned by the Zend lexer and
       // parse each one into the corresponding valid PHP. We will then have this
       // template as the correctly rendered PHP that can be rendered natively.
       foreach (token_get_all($value) as $token) {
           $result .= is_array($token) ? $this->parseToken($token) : $token;
       }
   
       if (! empty($this->rawBlocks)) {
           $result = $this->restoreRawContent($result);
       }
   
       // If there are any footer lines that need to get added to a template we will
       // add them here at the end of the template. This gets used mainly for the
       // template inheritance via the extends keyword that should be appended.
       if (count($this->footer) > 0) {
           $result = $this->addFooters($result);
       }
   
       if (! empty($this->echoHandlers)) {
           $result = $this->addBladeCompilerVariable($result);
       }
   
       return str_replace(
           ['##BEGIN-COMPONENT-CLASS##', '##END-COMPONENT-CLASS##'],
           '',
           $result);
   }

4. Finally following into $this->parseToken, i did 2 more dumps:

   /**
    * Parse the tokens from the template.
    *
    * @param  array  $token
    * @return string
    */
   protected function parseToken($token)
   {
       [$id, $content] = $token;
       
       dump($id);
       dump(T_INLINE_HTML);
   
       if ($id == T_INLINE_HTML) {
           foreach ($this->compilers as $type) {
               $content = $this->{"compile{$type}"}($content);
           }
       }
   
       return $content;
   }

5. And now comes the possibly interesting part, the dump(T_INLINE_HTML) returns the value: 267. But based on everything i can find about it, it should be 318...

   /**
    * Parse the tokens from the template.
    *
    * @param  array  $token
    * @return string
    */
   protected function parseToken($token)
   {
       [$id, $content] = $token;
   
       dump($id);
       dump(T_INLINE_HTML);
   
       if ($id == T_INLINE_HTML) {
           foreach ($this->compilers as $type) {
               $content = $this->{"compile{$type}"}($content);
           }
       }
   
       return $content;
   }

6. Dumping this on a healthy project always returns 318. So somehow the constant got a different value for those requests. Even on my unhealthy project it would f.e. work if i use php artisan tinker and just echo T_INLINE_HTML. It returns 318.

Summary / Short-term solution?

We've figured out that simply restarting the php-fpm service resolves this issue, and it doesn't seem to come back quickly, we've had it come back maybe once or twice a year on just the one project. This also explains why some of you can't reproduce the issue after having fiddled a bit with your php service, likely you've restarted it at somepoint, fixing the incorrect constant values.

Sadly because the issue is on a used application I couldn't continue my investigation for too long and had to opt to resolve it by the above method with no means to further reproduce the issue.

If anybody finds the actual root cause behind this constant suddenly working incorrectly i'd love to hear it!

[JFBauer-ZeroPlex]

Please check: #52382 (comment) for further discussion

[macropay-solutions]

V8 vs V11
from your mentioned functions only the compileString differs:

but prepareStringsForCompilationUsing function is never called from the framework so this is a dead end.

There are a few other changes between these 2 versions and taking into account that the issue appears only in v11 might be a good starting place.

[christianoerick]

Question... The processor is amd or intel? We had this problem in the past and we switched to Intel and... Somehow the problem was gone.

[JFBauer-ZeroPlex]

@macropay-solutions, @tom-skilltech
Got word back from support from Runcloud, they did indeed update to 8.3.17 yesterday evening, so that does align with 8.3.16 to 8.3.17 which both seem to use a different number for T_INLINE_HTML (and likely other T_ constants as well). I'll follow up to ask for their exact update procedure

[macropay-solutions]

[JFBauer-ZeroPlex]

@christianoerick actually, both. I've had 2 servers affected today, one happens to use AMD and the other Intel. I'm pretty sure it's not related to that. Both servers received the same update yesterday of PHP 8.3.16 to 8.3.17.

[tom-skilltech]

@JFBauer-ZeroPlex Hmm interesting. I'm not aware currently if when we experienced it there was an update, and we just haven't had an update since. I've pinged my colleague to see if they're aware. As not experiencing it since may be due to there not being a patch update.

Appreciate the investigations @JFBauer-ZeroPlex @macropay-solutions , we hit a bit of a deadend this side, and it seemed like opcache itself was the problem. It's difficult to reliably reproduce on our system too, and when it does it needs resolving ASAP to reduce disruption.

[macropay-solutions]

Update from our devops team:

I still don't know if it's PHP version bound, but the documentation from PHP does make it seem so.
Also not sure what if there's something concrete from your last comment, or more the fact that it changed again in a patch version?

I'll make a note that if it ever happens again i'll quickly inject a phpinfo to get the versions, see if something possibly changed. Typing that. Could it be that if you have let's say php8.3.8-fpm running and you update to 8.3.9 somehow without restarting the fpm service, that 8.3.8 instantiates php processes that run on 8.3.9? and that we get a mismatch there somehow? That feels like it could be something.

For non Docker environment, if the PHP-FPM service isn’t restarted after an update, lingering old processes (from 8.3.8) could still be running, even though the new binary (8.3.9) is installed. This could explain unexpected behavior, especially if certain values or behaviors change between minor versions.

[JFBauer-ZeroPlex]

Well, i have the same issue now happening on production server, this morning it was staging. So far it hasn't afffected critical blade files yet (guessing the cached views are still good) so i have a little bit of time to investigate and do some testing there. If you have any suggestions let me know.

I'm eagerly awaiting response from the hosting party on whether they did an update, and to follow it up with what their procedure is regarding restarting or reloading PHP-FPM, I also figured out that reload likely isn't enough to update the PHP constant values, so that might play into that.

[tom-skilltech]

@JFBauer-ZeroPlex We run a slightly different setup, Apache2 with the usual PHP module rather than PHP FPM. For us, deleting the cached view will cause Laravel to rebuild correctly. However, since it's a new process every time, that may be why. We have one time performed a view:clear and that caused every new cache attempt to result in a failed compilation, requiring an Apache restart then deleting the files individually.

[macropay-solutions]

Another idea.
If cached views are not affected by this, and they rely also on this constant to be parsed by php, then the culprit might lie in the way laravel caches the views and that part could read the constant from different sources leading to the issue.

[JFBauer-ZeroPlex]

Views are cached after the blade is compiled into PHP, so the cached views might initially hide the problem (problem is active but the cached views were created before the problem is present). Or once you resolve the issue (restart PHP-FPM) the cached views might make it seem like the issue is still there (Problem no longer active but you have cached views which were (not) compiled before the issue was resolved)

This is very likely to happen for any one Laravel user that encounters this, thus prolonging the process and making it unclear what the issue is. They likely start with clearing the views, that doesn't resolve it. then the try other stuff, and maybe that resolved it but by this point some views got cached again incorrectly, and they have to clear the view cache again, and they might not try because they did it before and it didn't help. So i can see how a lot of people get taken on a journey with no idea what to blame at the end.

[macropay-solutions]

Issue created php/php-src#18067 on php.

[tom-skilltech]

Update from our side. Our servers have encountered the issue this morning. They had an automatic update from 8.3.18 to 8.3.19 on Friday morning, based on the findings here I suspected we may have a problem this week, since we have to wait for high traffic (we don't have much over the weekend) and for the existing cache files to expire or new uncommonly accessed areas to be requested.

Our usual fix, did not resolve it. Doing a full apache restart with apachectl and then removing impacting cache files resolved the issue.

Unattended upgrades / the post install scripts appear to call apache to restart during the process, however, there does appear to be checks around if it thinks it should restart or not, and even if it does it may not be a full restart, since our apache service status had an uptime of almost 4 weeks, which was when we last encountered this, but apache logs indicate a restart every day.

This finding does seem like a solid lead and makes opcache a red herring, it also explains why normal PHP files appear unaffected, only the blade compilation step, based on the constants it uses.

[JFBauer-ZeroPlex]

@tom-skilltech You're mentioning apache here, which is unlikely to be relevant in this (although maybe some caching can happen on that level as well).

Just to clarify you saw blade directives being returned after the update from 8.3.18 to 8.3.19 (You can verify both versions?)

I just checked on the version 8.3.18 and 8.3.19, both seem to return 267 as value for T_INLINE_HTML, I don't know if that constant being the same means all others constants are too, but if we assume that to be the case as we have thus far, we would argue that this problem shouldn't occur for that upgrade as that value hasn't changed.

And did php-fpm get restarted or reloaded? Because you mention restarting apache, but that wouldn't do much to resolve the problem.
And the caching I was referring to earlier is not from the webserver (which might also have caching) but from Laravel itself, which caches compiled views in the storage folder.

Restarting or reloading php-fpm seems to resolve it, and then you might have to follow up with clearing any cached views which were incorrectly compiled and stored in the storage folder. (And in your case maybe clear cached static pages on your webserver if relevant.)

[tom-skilltech]

@JFBauer-ZeroPlex We are using apache with the php module, rather than php fpm directly. So for us, restarting apache is also restarting php, I know the issue is around the Laravel views cache and not webserver cache, and the steps to resolve it as you mention. In your case restarting php-fpm then clearing Laravel compiled views that are impacted is the same as us restarting apache then clearing Laravel compiled views.

To clarify, I forgot to mention we also had a 5.3.17 -> 5.3.18 update on Wednesday last week, which did have the constant value change 318 to 267. This is the likely cause, not the 5.3.19 update which as you say was unchanged. A few days for the issue to become noticed is not uncommon for us, given it is typically first noticed on areas / blade templates not commonly accessed.

[JFBauer-ZeroPlex]

@tom-skilltech, aah. Sorry, that definitely clarifies things. Alright, then yeah that matches up pretty well. Might be interesting to hear from you what caused Apache not to actually fully restart once if you're willing to dive a bit deeper into that logic. I'm not too familiar with the update process with the PHP module for Apache, and whether the post install script are ones that you've manually prepared or are from apache itself?

For newer projects we're working with Docker, those are always stopped and started again so issues like these are not present. We only notice these issues on some older projects where we still have things managed through some 3rd party software. I'm still waiting to receive a follow up response to hear what their update procedure looks like.

If i can find some time i might try to simulate the issue in some clear steps to get some better insight and be able to provide a concrete set of steps to reproduce so we could make an issue out of this (likely with the PHP team). Maybe a docker image setup with 8.3.16 and then couple of steps to follow to get to a state where it's messed up. If somebody wants the honors, feel free to do so. I'm not sure when i can find the time.

[tom-skilltech]

@JFBauer-ZeroPlex The post install scripts are part of the libapache2-mod-php package. I'm not the most familiar with Bash, but I did dive into the script and it loads in Apache's own helper maintenance script and calls a restart method. However, the method does a check to see if Apache requires restarting, if it doesn't, it ignores the call and returns. I think this is what is happening.

I've had trouble finding much information on this script (even a git repo with the source), however, I did find a question post for PHP8.1 relating to similar symptoms with the post install script - https://answers.launchpad.net/ubuntu/+question/708148 - I suspect it is bug with the script and is still in place even now. Meaning Apache is not being restarted, as it should be, following an update to the PHP module.

Our datacentre who manages our servers are going to look into hooking into the update to force an Apache restart when that module is upgraded. Once in place, we'll then just need to keep an eye on new PHP releases and make notes when that constant changes and see if we get the issue show up.

Not sure if php-fpm ships with a similar post install script, maybe it is also not triggering an automatic restart when it should be? For reference, the post install script for the Apache module is in /var/lib/dpkg/info/.

[nekromoff]

Getting this error on PHP 8.3.20, Laravel 11, using Apache PHP, not PHP-FPM. I am not even using Blade for this request!

Undefined variable $component (View: /var/www/html/xxxxxx/vendor/laravel/framework/src/Illuminate/Foundation/resources/exceptions/renderer/show.blade.php)
Illuminate\View\ ViewException
Show exception properties

in[ /var/www/html/xxxxxxx/storage/framework/views/3a3f75ca235e15d15aa39cba9b4fc3cd.php ](file:///var/www/html/xxxxxxx/storage/framework/views/3a3f75ca235e15d15aa39cba9b4fc3cd.php#L5)(line 5)

    @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; ?>

<?php
echo T_INLINE_HTML;
// outputs: 318

Nothing seems to fix this issue.

Edit:
Running:

composer dump-autoload
php artisan optimize:clear

didn't change anything for the first time.

Running it again helped to clear the error/bug.