Add a way of seeing the referrer for each 404

Thanks @DamienMcKenna I totally agree.

Surely this would have to be tracked in another table and as additional information, but knowing the referrer is extremely helpful to find out and fix the 404's. That way we can wee, where the wrong link is coming from.

It's a 1:n relation, so it definitely needs another table. I guess the current 404's list can be kept and a link to details should be added, when clicking an entry. That one should then list the referrers.

Clearing the 404's should also clear that additional table.

Might be a nice feature to implement for Novice's?

After applying the MR we need to use the drush updb command once.
The referrers will be stored in the 404_referrers table.
Too see the referrers from UI itself
1. Visit /admin/structure/views/add
2. Under View Settings select 404 Referrers
3. Add necessary fields to view the referrer

Hi @sandipta,

I installed and enabled the Redirect module against 8.x-1.x-dev on my D10 site including the Redirect 404, and confirmed the 404 Referrers view is now available and working after applying MR!101.

Please see the attached files for reference.

I'm moving this now to ‘RTBC’.

Thank you!

* There is no cleanup process for thew new table, which is a big challenge because we don't delete them one by one, so this table could get very, very large. Might need it's own handling
* Table name is not using module prefix
* Update hook shouldn't call hook_schema() because that might change in the future
* Should probably use a merge query like the main table to avoid many duplicate rows and instead use a counter.
* Should have an answer for displaying this information by default in a useful way if we bother to store it.

This is very much not a novice issue. I'm also not sure that this is necessary. It adds a quite a bit of complexity, doubles storage requirements and suppressing of 404 logs in dblog is optional. If we want to see referers in our projects, we typically disable the suppression at least temporarily.

Thanks for the feedback @Berdir!

Like @DamienMcKenna I think this would be a really useful feature, giving huge benefit to the 404 logging. But you're right, it adds some complexity and isn't essential to the module.
So I'd say it's a great candidate for a submodule? Would you be fine with that?

Who needs it, can enable it. I added your points from #9 to the issue summary.

Maybe, but a separate submodule has its own complexity. We'd still need to make the main module extensible and flexible enough so that the submodule could hook into it, and if it's in the same project, it's still complexity that needs to be maintained.