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]

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.

[soipo]

On Runcloud, as it was an emergency but i could upgrade to 8.4 and the problem seemed to be gone after i run

composer dump-autoload php artisan optimize:clear

With 8.3 I couldn't solve the issue

[jonathan-bird]

I was able to solve the issue when I disabled OPcache with 8.3 FYI. But 8.4 looks to be the better solution, at least until someone conclusively finds the root cause.

[fabiocgd]

Hello,

Today this problem happened to me.

I use the RunCloud service here.

I noticed that if I downgraded to PHP 8.2, the application started working again.

Then I found out that yesterday (2025-05-26) the RunCloud platform released an update for PHP (PHP 8.3.21), but when I ran the command on the cli: php -v ... Linux continues to display version 8.3.20

I contacted the RunCloud team and they sent me a link to manually update their client (https://runcloud.io/docs/how-to-update-runcloud-agent-manually)

After running this agent update, when I returned to Linux, the php -v command returned version 8.3.21

So I ran a php artisan view:clear and the problem was solved!

@soipo please check my answer.

[JFBauer-ZeroPlex]

The issue is simply that Runcloud seems to not properly restart the PHP-FPM service after the update. And then there's a secondary problem because of laravel's view caching, so even if you restart PHP-FPM service (or switch back and forth between versions which will also do the trick) you have to do view clear.

I think a lot of people get confused because they might run view:clear while still on the old PHP-FPM and then restart it at some point, but never try to view:clear again afterwards.

[fabiocgd]

Hello JFBauer-ZeroPlex,

Please check this image:

For an unknown reason, the php83rc package was not updated by the RunCloud agent.

I had tried to restart the PHP-FPM service, but I was only successful after manually updating the RunCloud agent, which resulted in php83rc being updated to version 8.3.21.

[JFBauer-ZeroPlex]

But if your php didn't update you wouldn't have experienced any issues. The problem is that it's sort of half updated, making new requests have different value for the PHP tokenizer constant but not actually being fully updated (or vice versa, i don't remember). I must say that i honestly gave up. I tried with support to get them to delve deeper into it, but they weren't really willing to.

Did you restart the service and then view:clear afterwards? because as i mention you might have done php-fpm service restart, but had cached a view which was showing all the blade unprocessed and it was cached.

I'm already moving to a full docker setup so not spending much more time on this as it's seemingly an issue with Runcloud's update workflow (and possible some people's personal workflow).

[jonathan-bird]

We are also using RunCloud service. We had 2 Laravel sites have this issue yesterday/today.

I was able to fix by:

• Upgrading from PHP 8.3 to 8.4
• Redeploying app (which runs all of the clear cache, optimize:clear commands and re-caches views etc.)

Another fix I've noticed is:

• Disable OPcache
• Redeploy app to run all the Laravel cache/view clears

It's difficult to say exactly what causes it but the timing seems to coincide with the RunCloud's PHP minor upgrades run by the RunCloud agent. With that said, it completes these regularly and doesn't cause issues most of the time, and it doesn't cause this issue on all Laravel sites I manage using RunCloud either.

Very strange. I can now fix the error by disabling OPcache and upgrading to PHP 8.4 (doesn't fix alone, need to clear all Laravel caches - most likely the cached views but haven't tried one by one specifically).

I have reported to RunCloud and they are investigating their side so it'll be interesting to hear their report.

Hope this helps someone. If anyone works out the root cause of this, please post in this thread.

[JFBauer-ZeroPlex]

Oh sorry, I've never really dived into opcache as a thing. Just reading up about. We do have it active as well. But I definitely didn't touch it specifically in any way when this occured to me.

Funnily enough i haven't noticed any issues yet on any of our application, I'll keep an eye open.

[jonathan-bird]

I have a feeling it's the root cause knock on effect of all of this. Eg. php binary upgrade > agent reloads (instead of restart) > opcache has mismatched T value > Laravel views cached with old code causes issues with new PHP version.

RunCloud has OPcache enabled by default, you can disable it in your corresponding conf file in /etc/php-extra/

[jonathan-bird]

@daika7ana I think that's more correlation than causation. If you try just restarting PHP FPM (also clears OPcache), and clearing Laravel view cache, your app should work again.

[daika7ana]

@daika7ana I think that's more correlation than causation. If you try just restarting PHP FPM (also clears OPcache), and clearing Laravel view cache, your app should work again.

It usually worked like that, but this time it didn't. Even restarted the whole server, yet the problem still remained. Stopped the webserver. Killed all running fpm processes and threads. Created a script to manually clear OPCache. Nothing solved it untill the above-mentioned solution.

[JFBauer-ZeroPlex]

Just to correct one part: "Laravel views cached with old code causes issues with new PHP version"

The cached views are simply that, cached views. They don't use the tokenizer of PHP anymore. It is the view but with all the blade converted to PHP. So it doesn't require the T_INLINE_HTML constant when showing those views.
Technically if you do restart immediately then all is good, but because you only notice it once old views are being dropped and the new broken views are getting cached you need to cache clear as well.

Regarding the remark of just reloading the service, for me that did seem to already work. I'm dumping my final back and forth with runcloud on this matter earlier this year (Credits to ChatGPT for markdown reformat):

JFBauer
2 months ago - 03 April 2025 (11:04:47 AM)

I'm saying performing the command below, and only running this...
systemctl reload php83rc-fpm
...resolved the issue for me, so my point is that either your update script is not actually doing the reload, or it is doing it too soon in the update process.
Otherwise me running systemctl reload php83rc-fpm would not have made any difference as you would've already done the reload, but that's not the case.

I've had this issue pop-up occasionally (2-3 times a year). But every time it would impact a production environment with 0 warning.

I would love for some to actually take the time and try to reproduce the behaviour, i already specified how you likely could:

Just to give you some way of possibly reproducing it. Have a web application (on one of your servers, preferably still with version 8.3.16). and when you do a request dump the following constant + the phpversion

<?php dump(T_INLINE_HTML); phpinfo(); ?>

this would give back 276 and 8.3.16
Then perform the update to 8.3.17 as you did now to all servers. and do the request again. For 8.3.17 the constant should apparently have 318 as value, I would see as result still 276 as value for the constant. But php version 8.3.17 so the version was updated but the constant wasn't. If i then do systemctl reload or restart than everything is good again. We also started a brief issue with PHP (T_INLINE_HTML changes between minor versions from 267 to 318 and back causing laravel blades to fail · Issue #18067 · php/php-src), but they also mention it shouldn't really be possible to get something like that. So please enlighten us so we might be able to resolve this mystery :) It could also be because i think you build your own PHP to some degree? hope someone can explain it to us, but i'm guessing you would need some core developer of your team that works with those PHP binaries to be involved.

---

RunCloud Logo
Fadli Khalid
2 months ago - 04 April 2025 (06:39:58 AM)

Hi JFBauer,

Thank you for your patience while we investigated this matter. After a thorough review with our engineering team, we can confirm:

1. Our system properly handles service reloads through the post-installation script (/var/lib/dpkg/info/php83rc.postinst), which executes the relevant portion of the script that shows the reload mechanism:

   #!/bin/sh
   
   after_upgrade() {
       systemctl daemon-reload
       if [ -f /var/run/php83rc-fpm.pid ]; then
           kill -USR2 `cat /var/run/php83rc-fpm.pid`
       fi
   }
   
   after_install() {
       systemctl daemon-reload
       if [ -f /var/run/php83rc-fpm.pid ]; then
           kill -USR2 `cat /var/run/php83rc-fpm.pid`
       fi
   }

2. The behavior you're observing falls outside our service management scope and is more likely related to either:

   • PHP's internal processes
   • Laravel framework behavior

This concludes our investigation, and we consider the matter resolved from our perspective. However, if you’d like us to look into any specific aspects further, please don’t hesitate to let us know. We appreciate you bringing this to our attention.

Best regards,
Fadli Khalid
Service Delivery Engineer
RunCloud | [runcloud.io](https://runcloud.io)