• Hello all,

    my site:

    https://4nf.org/

    …uses the newest version of WP and some plugins such as W3 Total Cache.

    My aim, just for testing purposes is to disable 404 error handling completely, i.e. to revert to “naked” 404 handling, which really throws a hard 404 error instead of handling it softly.

    I’ve tried deleting the 404.php file in the theme and also disabling the W3 Total Cache page cache in vain.

    I’ve also researched the web and the usual question seems to be the opposite, i.e. how to handle the 404 error “softly”.

    Any help is greatly appreciated!

    Thanks in advance!

Viewing 3 replies - 1 through 3 (of 3 total)
  • Thread Starter arvgta

    (@arvgta)

    EDIT: Sort of solved by adding a custom 404.php in the child theme.

    Now, a 404 error is thrown and the content of 404.php is shown ??

    It would still be interesting to know, why WP throws a 404 error, when a custom 404.php is specified and not in case of the parent theme’s 404.php?

    Moderator bcworkz

    (@bcworkz)

    I’m not sure I understand what you’re asking. Assuming permalinks are enabled, WP must always throw a soft 404 (as I define it at least) because all permalink requests go first to index.php, which always should exist, so the chance for a hard 404 is past because the redirected file was found. The server cannot go back and unfind a file, which would be the only way to get a hard 404 from WP.

    The theme’s 404.php file should always be used if it exists, I don’t know why your parent theme’s file was not used when your child theme was lacking a 404.php. Even with both files missing, WP generates a 404 page internally from core code. It’s not possible to go back to the server’s 404 page once index.php is found.

    Thread Starter arvgta

    (@arvgta)

    Thanks for your reply – much appreciated!

    Yes, permalinks are enabled.

    To be more precise, my first attempt was to rename the 404.php in the parent’s theme, assuming that it wouldn’t be fetched anymore.
    I have no idea, whether it was found nevertheless, or the 404 page was generated from the core code, as you illustrated.
    Either way, a 404 error wasn’t thrown.

    It might be worth mentioning, that I’m using a jQuery $.ajax() call, which I am now enhancing to handle errors.

    At first, the Ajax call was never running into the error branch.

    Finally, when I overrode the 404.php in the child theme, the Ajax call ran into the error branch, where I now can handle the error softly at a JS level.

    I have no idea, why specifiying the 404.php in the child theme did the trick. (It only holds a small <div> – no <body> or <head>)

    My use-case is solved. We can mark this thread as “resolved” unless you find it interesting for other users…

Viewing 3 replies - 1 through 3 (of 3 total)
  • The topic ‘Disabling 404 handling completely’ is closed to new replies.