Closed (fixed)
Project:
Fast 404
Version:
8.x-3.5
Component:
Code
Priority:
Critical
Category:
Support request
Assigned:
Unassigned
Reporter:
Created:
21 Oct 2025 at 09:47 UTC
Updated:
28 Jan 2026 at 21:34 UTC
Jump to comment: Most recent
Comments
Comment #2
leo pitt commentedThis is the fasts 404 config we have:
Comment #3
pobster commentedPlease install devel_php (or whatever you'd use for debug), and type:
For reference, I see this:
Where "1" is that this path is found in my router table.
edit: for me, it's very likely finding:
Comment #4
andmor commentedOK here is the output:
No "1" in the end and
Status messageisfalseIt looks like the problem might be that in your case, your file path is:
For us this is more like:
If I run the above code setting
$path = /sites/default/files/styles/thumbnail/test.jpg, I do get the "1" on the output but the file actually does not exist on that pathComment #5
andmor commentedOther settings that might be relevant:
- Under
admin/config/media/file-systemwhat do you select for "Default download method"? We have "Public local files served by the webserver."- On our settings.php we set:
Comment #6
pobster commentedThe thing is ...
Should have still matched on:
It's in your output, so that's strange.
Can you use
drush sqlc(or whatever you use to connect to your database). And run:See, the query in fast404 does a "more than or equals" on
number_partsso as long as this exists at all in your router table - then it should match.Comment #7
andmor commentedStrange indeed. It seems I get the same output as you:
BTW, as expected the images work when using the new v8.x-3.6
Comment #8
andmor commentedon your code posted above to run on php_devel, if I remove the number of parts from the SQL query, I do get a match:
This gives me
status=1Comment #9
andmor commentedSame if I subtract "1" or any greater number
Also gives me
status=1Comment #10
pobster commentedThat's more than just bizarre; logically, that's impossible!
See, the comparison is:
[number_parts] >= :count_partsSo, more than or equals ... it makes no sense at all that subtracting one from your
$partswould then cause a match? Because:1. If it were 6 and not working - it'd be 5 and so below the
number_partsvalue - but it should have matched on 6 anyway2. If it were 7 and not working - it'd be 6 and so equal to the
number_partsvalue - but it would have been greater anyway3. Anything above this isn't relevant, as it's always higher than the
number_partsvalue4. Anything below 6 isn't relevant, as it's always lower than the
number_partsvalue - and shouldn't matchSubtracting shouldn't work; only adding one should have made any difference.
BTW, the issue with removing that clause completely is that then you'll match on:
Which is way too loose, and kind of defeats the purpose of having fast404 anyway...
I'm wondering what you get if you use:
If that does work, maybe MariaDB is imposing a limit on the number of values in your IN statement?
Incidentally, version 3.6 works, as this change has been reverted. Obviously not ideal, as it still performs the full table scan we were trying to avoid... Also, Drupal core uses this as-is! So it's very strange that it's not working as expected.
Comment #11
andmor commentedFor our example path
/sites/default/files/styles/this-is-a-style/public/something.png:count($parts)returns 7.The router table entry in our database for
/sites/default/files/styles/%/%hasnumber_parts: 6So the condition
would compare as
So no match on
/sites/default/files/styles/%/%Comment #12
pobster commentedApologies, been away this week for my birthday. Okay, thank you - this explains everything, I'll have a think about what the best thing to do is... It is a bit strange that this must affect Drupal core as well, but I'll work out what the best approach is—no worries.
Comment #13
andmor commentedNo problem. Thank you for your efforts on this. Let me know when you need further testing.
Comment #14
joseph.olstad@pobster, if you find a solution for this it would be great and we'll try again for version 3.7!
Comment #15
oligerd commentedI have the same issue after update Drupal core to 11.3.2 version.
Fast 404 version is 3.6.
With $settings['fast404_path_check'] = TRUE;
all /admin/* pages have 404
and image styles are not being generated.
Comment #16
joseph.olstad@oligerd, this was reverted for 3.6. No guarantees it goes back in.
If you're still seeing this with 3.6 it's due to an incorrect upgrade or that you're storing contrib module code in your git project rather than using composer and you performed a botched update (not recommended).
Comment #17
jhiver commentedHello,
I had the exact same issue and the patch proposed in this new issue resolved the problem.
Comment #18
joseph.olstadThanks @jhiver for getting my attention.
https://www.drupal.org/project/fast_404/releases/8.x-3.7
Comment #19
joseph.olstadMarking this as a support request.
Calling it fixed.
Creditting all above.