jasonvarga
commented
1 month ago Would you be able to provide a repo where this behavior happens?
Open heidkaemper opened 1 month ago
jasonvarga
commented
1 month ago Would you be able to provide a repo where this behavior happens?
robdekort
commented
1 month ago I think ours are separate issues @heidkaemper. It looks like #10412 solves the issue I was running into. As this project I'm noticing it on features both structured collections and static caching (also locally because I was testing stuff).
heidkaemper
commented
1 month ago Yea that's right. We do use static caching (half) in production but certainly not in development.
@jasonvarga We have to prepare a repo without client data. But we can manage that, I'll get back to you on that!
JorisOrangeStudio
commented
1 month ago We are experiencing this same random behaviour (on v5). Also half page caching using the redis application cache driver.
After the requiresSlugs() error the sites throws a lot of Call to a member function routeData() on null errors and pages are no longer reachable. Redeploying fixes it most of the times.
heidkaemper
commented
1 month ago An update from me as well: The 404 pages in Production could have something to do with #10412 for us as well. Cuz we run cache:clear and static:warm one after the other in deployment pipelines. So that would at least explain some of it.
The other part of the issue is probably related to our development environment. Because I did:
artisan cache:clear followed by please stache:warmWhen I tried to open the page at first the requiresSlugs() on null error came up. And after reload a 404 page.
However, I then did exactly the same thing locally in a Laravel Herd environment. And lo and behold, no errors at all, everything worked just fine!
I dived in a little deeper and looked at the stache files. After a stache:warm, they appear to be identical in both of my development environments. Here for example the storage/framework/cache/data/stache/keys/entries file:
9999999999a:1:{s:4:"home";s:79:"/home/heidkaemper/code/local/vanilla-statamic/content/collections/pages/home.md";}After I opened that page in the browser the stache key in my Laravel Herd environment remained unchanged. The file in our regular development environment does not:
9999999999a:0:{}I have to say that the stache behavior goes a bit over my head. :-) But I'm glad that at least a fix for #10412 ist in sight.
schwemmer
commented
1 month ago We also have this same problem, locally (with no caching) and on production (with "half"-measure caching). The issue seems to appear a few hours after the last deployment but we couldn't reliably reproduce it.
SRWieZ
commented
1 month ago Just had this issue after the last release. Had to revert to v5.14.0
I'm using STATAMIC_STATIC_CACHING_STRATEGY="full" in my env
and php please static:clear && php please static:warm --queue in deployment.
Happy yo test things if needed!
heidkaemper
commented
3 weeks ago Okay, I think I found the problem for our setup. And it's quite clearly our own fault..
We use a docker setup for local development. And we often run console commands from outside the container. But things like the Stache Watcher obviously run inside the docker container. And although both work, there is one important difference: the base_path() is different!
For example, when I run stache:warm from outside the container, the Stache file looks something like this:
9999999999a:1:{s:5:"pages";s:76:"/home/heidkaemper/code/local/vanilla-statamic/content/collections/pages.yaml";}The same command from inside the container generates a Stache file like this:
9999999999a:1:{s:5:"pages";s:35:"/web/content/collections/pages.yaml";}I'm pretty sure this causes empty stache files. And it also explains why we could not reliably reproduce the error in production.
This could possibly be fixed by not saving absolute paths in the stache. However, in my opinion this is an edge case and probably not worth the time and effort. Or what do you think @jasonvarga?
As far as I'm concerned, we can close this issue. However, I am unsure whether the problems mentioned in the other comments are still valid. They sound more like issues with static caching?!
schwemmer
commented
3 weeks ago @heidkaemper We are seeing this issue locally (using docker) as well as on production (not using docker). So I don't think the issue is docker. It might be one of the ways to cause this but not the only one.
heidkaemper
commented
3 weeks ago Okay, it's still valid than. Do you get the same requiresSlugs() errors with the newest Statamic version? Or just 404 pages?
schwemmer
commented
3 weeks ago I think we were getting a Call to a member function routeData() on null. I will make sure to take a note of the detailed error message next time it occurs.
jasonvarga
commented
3 weeks ago I think this issue is still valid in general, but the path issue @heidkaemper outlined I wouldn't consider an issue. You should run the commands in the docker container. 👍
benlilley
commented
3 weeks ago Chiming in that we appear to be running into this on almost every deploy and it's not a good time!
I'd thought I resolved it by updating our pipeline to use the more aggressive cache clear of artisan optimize like so: php artisan optimize && php please static:warm but it is continuing to happen. We see 404's on all URL's and this is resolved by clearing the application cache via the Statamic CP.
PHP 8.3.9 Statamic 5.18.0
jbreuer95
commented
2 weeks ago I think its also related to this one, i have the same problem. https://github.com/statamic/cms/issues/10025
schwemmer
commented
2 weeks ago We separated the stache from the application cache so we won't have to clear the stache and warm it again on each deployment. After this change, our application did not have the 404 problems for about 2 weeks, over multiple deploys. Today, however, I had to run php please stache:clear and the problem immediately returned. Last time this happened, it was caused by php artisan optimize:clear and fixed by reloading PHP FPM Workers. This time, it was caused by stache:clear and not fixed by reloading FPM workers but by running artisan optimize:clear twice. Very strange! When the 404s happened, I noticed, that a segment was missing from the URL. The URL is something like domain/en/projects/project_name/about and it was missing the "projects" part. The entire sub-navigation was also gone and came back after running optimize:clear twice. We only see the 404s on pages that are nested 2 levels in the collection tree. My wild guess is, that clearing the stache messes up the URL structure somehow.
I hope this helps with debugging this mysterious issues. Would be great, if we didn't have to worry anymore about broken production sites.
benlilley
commented
2 weeks ago Another observation on this behaviour is that it appears to be time based in some way? I need to do more testing to confirm but we get 404's across entire sites on the first deploy in a certain period but subsequent deploys within an hour or two do not exhibit the same behaviour even though they go through the exact same pipeline commands.
I'll also note that we're seeing these site wide 404s on all of our Statamic V5 projects (didn't happen on V4) with manually clearing the Application Cache being the only resolution which is problematic when we have various people triggering deploys at times, including content editors.
Bug description
This is a strange one, sorry! :-)
After the update to 5.x, everything looked okay at first. After a few hours, however, 404 pages for published entries appeared in production. Clearing the cache helped at first, but after a while the 404 pages were back again.
I have since been able to reproduce the behavior with two projects in development as well. PHP version and collection settings do not seem to matter.
Rob also has this problem randonly with his projects, but cannot reproduce it reliably.
Any ideas? Unintentional behavior of the stache perhaps?!
How to reproduce
php please stache:warmCall to a member function requiresSlugs() on nullerror occursLogs
Environment
Installation
Other (please explain)
Additional details
Plain statamic/statamic site, update from 4.x to 5.x