Mystery 404's on server environment

[vluijkx]

Bug description

After updating to Statamic 5, all our entries result into 404 pages on our staging server. Nothing goes wrong locally though. I find it pretty hard to write this issue as I can't tell you how to replicate this behaviour. I am not even able to replicate the issue locally myself.

This is what I figured out so far:

• The 404's seem to be rendered by Laravel/Statamic and not by NGINX.
• At first I thought it might have something todo with [5.x] 404 on every page after upgrade to beta 1 #9987. However, when I downgraded to v5.0.0-alpha.1, the issue persisted.
• I've removed all addons including the eloquent-driver. The issue still persisted.
• Clearing the cache doesn't help.

How to reproduce

So I know this issue is pretty vague 😅. I am not expecting anyone te be able to provide a solution based on these details. I do hope that someone could point me into a better direction so that I will be able to narrow things down and provide better info.

Logs

No response

Environment

## Staging environment (results into 404's)

Environment
Application Name: Cell0
Laravel Version: 11.7.0
PHP Version: 8.2.6
Composer Version: -
Environment: staging
Debug Mode: OFF
URL: staging.cell-0.com
Maintenance Mode: OFF

Cache
Config: NOT CACHED
Events: NOT CACHED
Routes: NOT CACHED
Views: CACHED

Drivers
Broadcasting: log
Cache: statamic
Database: mysql
Logs: stack / single
Mail: mailgun
Queue: sync
Session: file

Statamic
Addons: 0
Sites: 1
Stache Watcher: Disabled
Static Caching: Disabled
Version: 5.0.2 PRO


## Local environment (works fine)

Environment
Application Name: Laravel
Laravel Version: 11.7.0
PHP Version: 8.2.6
Composer Version: -
Environment: local
Debug Mode: OFF
URL: website.test
Maintenance Mode: OFF

Cache
Config: NOT CACHED
Events: NOT CACHED
Routes: NOT CACHED
Views: CACHED

Drivers
Broadcasting: log
Cache: statamic
Database: mysql
Logs: stack / single
Mail: smtp
Queue: sync
Session: file

Statamic
Addons: 0
Sites: 1
Stache Watcher: Disabled
Static Caching: Disabled
Version: 5.0.2 PRO

Installation

Existing Laravel app

Additional details

No response

[duncanmcclean]

Are you able to provide us access to the codebase? That might be the easiest way for us to try and reproduce it.

[vluijkx]

Okay, with loads of trial and error, I was able to figure out that this was caused by middleware registered in the bootstrap app.php. Laravel shift generated the following code:

<?php

use App\Providers\AppServiceProvider;
use Illuminate\Foundation\Application;
use Illuminate\Foundation\Configuration\Exceptions;
use Illuminate\Foundation\Configuration\Middleware;

return Application::configure(basePath: dirname(__DIR__))
 ->withProviders()
 ->withRouting(
 web: __DIR__.'/../routes/web.php',
 api: __DIR__.'/../routes/api.php',
 commands: __DIR__.'/../routes/console.php',
 channels: __DIR__.'/../routes/channels.php',
 health: '/up',
 )
 ->withMiddleware(function (Middleware $middleware) {
 $middleware->redirectGuestsTo(fn () => route('login'));
 $middleware->redirectUsersTo(AppServiceProvider::HOME);

 $middleware->api('throttle:api');

 $middleware->replace(\Illuminate\Foundation\Http\Middleware\PreventRequestsDuringMaintenance::class, \App\Http\Middleware\PreventRequestsDuringMaintenance::class);
 $middleware->replace(\Illuminate\Foundation\Http\Middleware\TrimStrings::class, \App\Http\Middleware\TrimStrings::class);
 $middleware->replace(\Illuminate\Http\Middleware\TrustHosts::class, \App\Http\Middleware\TrustHosts::class);
 $middleware->replace(\Illuminate\Http\Middleware\TrustProxies::class, \App\Http\Middleware\TrustProxies::class);

 $middleware->replaceInGroup('web', \Illuminate\Cookie\Middleware\EncryptCookies::class, \App\Http\Middleware\EncryptCookies::class);
 $middleware->replaceInGroup('web', \Illuminate\Foundation\Http\Middleware\ValidateCsrfToken::class, \App\Http\Middleware\VerifyCsrfToken::class);
 })
 ->withExceptions(function (Exceptions $exceptions) {
 //
 })->create();

Commenting out all the middleware solved the issue.

I have the feeling that the problem has something to do with an outdated TrustHosts or TrustProxies middleware which caused the entries not to work on a server. Don't understand why though.