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?
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…
