Add option to exclude all non whitelisted file paths (Performance)

This needs to be rebased with the changes from 🐛 File extensions added in "search404_ignore_query" are being ignored. Fixed and 📌 The "Extensions to ignore" setting should have a higher priority than "Extensions to abort search" Fixed , but can be reviewed for now.

Great work once again @Grevil! Commented, please add tests for this afterwards to ensure:

1. Regular and whitelisted queries are not blocked
2. All file queries are blocked
3. Existing behavior works as before (checkbox disabled)

Since there are no functional tests implemented for this module yet, I'd suggest we refer to the test issue, and create the tests there, after these fixes are committed to dev (preferably to a new SemVer Version), WITHOUT creating a new release until the tests are implemented there.

Referring to 📌 Create tests to test this modules functionality Active .

I am reviewing the issue and find one problem. After enabling the Abort search on all paths containing file extensions checkbox, the file extension 404 showing Invalid keywords used..

OK, for some reason, I didn't properly finish this MR. Thanks for the adjustments based on the comments by @Anybody @mitthukumawat!

I did a rebase, added the missing update hook, and adjusted the logic, so if the search result ends with an ignored extension, the query will still execute (as stated in the "search404_ignore_file_queries" description: "[...] All extensions listed in "Extensions to ignore" will still be searched for [...]".

After enabling the Abort search on all paths containing file extensions checkbox, the file extension 404 showing Invalid keywords used..

Yes, this is correct, as it is the default message if the query gets aborted. So the logic works as expected, but the message doesn't make sense here, I agree! I'll adjust it accordingly!

Alright, I adjusted the error message, but I think the original error message 'The page you requested does not exist. Invalid keywords used.' might actually better... @Anybody should decide here.
This is the error message now:

We should also think about what priority "Extensions to ignore" (search404_ignore_extensions) should have. Currently, if "Abort search on all paths containing file extensions" (search404_ignore_file_queries) is enabled, the search will NOT abort if the query ends with an extension defined in "Extensions to ignore" (search404_ignore_extensions).
This is part of the requirement of "Abort search on all paths containing file extensions", see its description:

[...] All extensions listed in "Extensions to ignore" will still be searched for. [...]

BUT if we disable "Abort search on all paths containing file extensions", we can manually define file extensions to abort search on, through the "Extensions to abort search" (search404_ignore_query) setting. This setting currently has a higher priority, then "Extensions to ignore", which could be a bit confusing, but it was programmed like this before.

@Anybody, should we eventually program "Extensions to abort search" to be in line with "Abort search on all paths containing file extensions", so that the query never gets aborted, if the file extension is listed in "Extensions to ignore"?

Otherwise everything is in line now, please review!

This is super confusing and we should first decide on the expected End-User-Experience (UX).
Are we skipping file extensions in the background, or do we tell the user they did something forbidden?

From reading the code it currently seems to be mixed-up and confusing what's the goal.

I'd say renaming the config names shouldn't be part of this issue. Your main issue probably came with the badly named error message. I adjusted it accordingly. A maintainer should review this and decide.

I think it is good now to have new message. Further we can get feedback and can improve once other related issues get merged with it.

@mitthukumawat thanks, I'd be fine with that also.

Alright, great!

Let's merge this, then! 👍

Alright, the rebase for this issue took quite a bit of work, but should be correct now! Furthermore, I renamed a config variable so everything is less confusing. Please review once again!

Alright, everything is finalized now!!

I tested it throughout and everything works as expected! :)

Final review pls!

Thanks all!

Automatically closed - issue fixed for 2 weeks with no activity.