Hi,@KreisonReis,

What distribution or container are you using?

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

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.

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!

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.

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.

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 theonly 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.

@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.

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 instorage/framework/views theX.php cache file contains blade syntax, rather than the transformed output that would be expected.

Performing aview: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.

@tom-skilltech isopcache.enable_cli set totrue in your environment?

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

@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.

@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:

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

@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:

sudo apt-get purge'php*'

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

php artisan optimize:clearphp 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.

@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 🤔

Please check:#52382 (comment) for further discussion

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.

@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

@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.

@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.

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.

@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 aview:clear and that caused every new cache attempt to result in a failed compilation, requiring an Apache restart then deleting the files individually.

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.

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.

@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 problemshouldn'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.)

@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.

@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.

@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/.

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.

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.

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.

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).

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.

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/

@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 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.

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 runningsystemctl 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

<?phpdump(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/shafter_upgrade() {    systemctl daemon-reloadif [-f /var/run/php83rc-fpm.pid ];thenkill -USR2`cat /var/run/php83rc-fpm.pid`fi}after_install() {    systemctl daemon-reloadif [-f /var/run/php83rc-fpm.pid ];thenkill -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)

Hey@mattkomarnicki :)

Yeah that was the response. I followed their suggestion of upgrading to 8.4 from 8.3 in case it really is a 8.3 issue.

I am still sticking to the OPCache theory I posted above rather than it being an 8.3 bug.

I believe it fixes it because when you switch to 8.4, it's essentially restarting (well, starting) PHP, so OPCache is clear. And then you run all of your Laravel cache/view/config clear commands which then uses freshly compiled code.

I have had the same success sticking to 8.3, restarting PHP & running the same commands, which is why I think it's a OPCache issue. I also don't have this issue on any of my staging sites, only live sites despite the same setup, only traffic difference so another reason why I think it's OPCache.

RunCloud have told me they're changing the PHP upgrade script to add a PHP restart command as well the existing reload command, so hopefully that does the trick. It will be released with their next agent release.