404 redirect issues in templates.
Development and Programming
I am for sure spinning my wheels on this one.
What would make EE stop redirecting to the 404 page set in the Settings -> Template Settings on a Closed entry?
I’ve cut the entries tag down to the most very basic - channel, dynamic=yes, limit=1. Just the “if no_results -> redirect 404” conditional, and otherwise, the title.
Entry is set to Open, I get the title. Entry is set to Closed, it loads an empty page (with the layout header/footer), but doesn’t redirect! The path for the 404 page is correct, the 404 template/page works fine on its own – it also works outside of this particular channel. If I change the redirect to a different template, the redirect works!!
I tested this on a different site and it works in those same conditions (in a channel specifically). The key difference between the two sites – the one where this is broken, is on ee 7.5.19; the working one is 7.5.21. Also, the broken one is an old site (upgrades from previous EE versions), the working one is a brand new one.
Was there something between 7.5.19 and 7.5.21 that would have fixed redirects but wasn’t noted on the changelogs? I planned on doing the update for this site anyway, but wanted to know in case it was definitely a bug in it at some point and was sorted out on the latest version.
do you have require_entry="yes"?
No, but that’s what puzzles me. On the new site it still observes the 404 even without that? Is that the bug then? 😂
Idk. I have observed weird behavior where some entries work without it and some require it… not sure why.
It’s strange…
This site has Hop Reporter installed on it, too. Hop Reporter is registering these closed entries as 404s… But without redirecting it. But, if I uninstall that add-on, and clear the caches (I had reset the template back to its full setup, which includes several other statuses, but not closed, and has template caching), that same page does not register as a 404 in the network tab of the browser inspector.
Meanwhile the test site with minimal configuration does register that closed entry as a 404 in the network tab.
So, for some reason it is broken on this site for this channel, and I don’t know why. And worse, it’s their primary channel. 😞
The issue is present on both the live site and the copy on my local, which is where I uninstalled Hop Reporter.
While I don’t understand why it wasn’t working with a basic set of attributes in the tag… I finally got it to work by including ALL of the statuses in the status attribute. If I leave out ‘closed’ when I add the others in there, it continues to not register it as a 404. It doesn’t work if no statuses are noted, when it should. 🤷♀️ Also, adding required_entry introduces other weirdness, so I’m leaving that one out.
But once I included the ‘closed’ status, and added it as a status to watch for in the conditional (because now it’s no different than an open entry), it hits the redirect->404 and the page is reflected as a 404 in the network tab.
It’s hacky, but I get the 404 in the network tab, which is what I want for these pages. Others are redirected to the main category pages, or the homepage, depending on the level of category (that’s a whole other ordeal I still need to hash out).
If you have status=closed in an entries loop, then it should not give you a no_results anymore on a valid closed url_title. That’s so bizarre. And Hop 404 Reporter should not fire if the 404 page doesn’t load. I think you’re getting an error on the 404 page parsing so the page loads blank. You would not actually BE redirecting. Try a minimal 404 template and build from there. If it is caused by the Hop addon tag please email [email protected]
I tested some more today.
Ultimately, it was because I was trying to put the no_results conditional with a status, e.g. {if no_results OR status="Draft"}.
…because I wanted both things to redirect to a 404. Apparently, what I didn’t know was that no_results is a loner and won’t work in combination with anything else it seems. So, I’ve put it by itself, then another conditional following it for the Draft status. Both redirect to a 404 now, which is what I want.
And maybe a little bit of template caching being super sticky, because initially when I reset everything to a basic template with no statuses specified to compare against the other site, I had cleared the EE cache, but it still seemed to not be observing the redirect in no_results - which I had put by itself in that test (no other status conditions bc I didn’t specify any in the entries tag).
I’m not sure what made today different but I basically repeated the same test - stripping out the attributes from the entries tag, cleared the cache, set the no_results conditional to it’s regular state, and the 404 redirect worked… 🤷♀️ If it had gone that way the first time I probably would’ve pinpointed the reason the 404 redirects weren’t working for that template much sooner.
And to what Jared said last week about setting up most sites with Structure – that I would here, normally, but it was built with the Pages module, which I have yet to dissect and remove/replace with Structure. Someday…
