0

I am trying to find out what impact setting a custom stucture prefix in permalinks has on 404's

I have a custom structure of:

/news-opinion/%postname%/

This is working as expected if you tried to go to a page: domain.com/news-opinion/non-existing-url I will get a 404 as expected.

However if I use: domain.com/non-existing-url this will redirect a user back to the homepage and not 404.

Am I missing somthing here I should have accounted for?

This is a Bedrock / Composer based install and this is the list of plugins in use if any of these are known to cause this issue:

"wpackagist-plugin/cache-enabler": "^1.3.4",
"wpackagist-plugin/classic-editor": "1.5",
"wpackagist-plugin/relevanssi": "4.2.0",
"wpackagist-plugin/safe-svg": "1.9.4",
"wpackagist-plugin/wp-mail-smtp": "^1.8",
"wpackagist-plugin/instant-images": "4.2.0",
"wpackagist-plugin/shortpixel-image-optimiser": "4.16.1",
"deliciousbrains-plugin/wp-migrate-db-pro": "^1.9",
"humanmade/s3-uploads": "^2.1",
"custom-repo/advanced-custom-fields-pro": "^5.7.0",
"custom-repo/gravityforms": "^2.4.0",
"wpackagist-plugin/duplicate-post": "3.2.4",
"wpackagist-plugin/filebird": "2.7.1",
"wpackagist-plugin/crop-thumbnails": "1.2.6",
"wpackagist-plugin/redirection": "4.7.1",
"wpackagist-plugin/advanced-cron-manager": "2.3.10",
"wpackagist-plugin/wp-seopress": "3.8.4",
"wpackagist-plugin/cookie-bar": "1.8.7",
"custom-repo/vcaching": "^1.8.0", 
"wpackagist-plugin/wordpress-importer": "0.7",
"wpackagist-plugin/export-media-with-selected-content": "2.0",
"wpackagist-plugin/user-roles-and-capabilities":"^1.2.3",
"wpackagist-plugin/wp-all-export": "1.2.5"

If I can provide any more information that may be pertanent to this please let me know.

Any help with this would be apperciated.

Improve this question

3 Answers 3

Reset to default
0

So to confirm, on a fresh Wordpress install with that setup /non-existing-url definitely returns 404, so it's not specifically the custom permalink that's the cause.

It may be worth posting your .htaccess in case it's been modified.

However I'd suspect that one of the plugins you have is helpfully adding this feature, and I'd suggest temporarily disabling Redirection and SEOPress to see if it's them. Once you figure out which one it is you can see if there's a way to disable this specific behaviour in that plugin

If you want to, it would be easy to manually add an .htaccess rule to make /anything 404, but that puts a fix on top of a problem and will quite possibly break other things, so I agree with the point of your post which would be figure out what's doing it if possible.

EDIT: Query Monitor shows you which URL rules the current page matched against, however I don't know if it'll be useful here where there's a redirect. Worth knowing about if you don't already as it's a great tool for debugging URL rewrite issues.

Improve this answer
3
  • 1
    Yeah disabling both those plugins and flushing permalinks didn't resolve anything. I will go request the .htaccess, I can only see staging / development enviroments so I will have to request the production one and look into that. I am aware of query monitor I will see if I can get that on the production server. I am of the assumption or rather leaning towards this being a hosting related issue on production only, dev, qa and staging all problem free using the same plugins etc. Thanks for your input I will come back to this in regards to the bounty after looking into .htaccess
    – Someone
    Commented Jul 23, 2020 at 10:07
  • 1
    Every so often, Caching will be the cause of this. Not just in a plugin (I see you have one) or on the hosting side (some live hosting has quite elaborate proxy/cache setups) but also in Browsers themselves. Time and again I have had issues with Chrome being absolutely sure nothing has changed on a site, when it very definitely has. So... to rule out something really silly and simple, disable your Cache plugin, make the changes you want, and test in all available browsers with fresh tabs and forced cache clearance. Definitely disable that cache plugin when testing! Worth a try...
    – t2pe
    Commented Jul 23, 2020 at 16:03
  • @Sam Interested to hear if/how you solved this. You can update your question or add an answer with anything that might be useful to other people who find this question.
    – mozboz
    Commented Jul 28, 2020 at 12:44
0

It is normal behavior of WordPress to redirect users to 404 page when a post is not found.

Both should have got redirected to 404 page ideally:

  • domain.com/news-opinion/non-existing-url
  • domain.com/non-existing-url

It is strange that you are facing this issue. Would you mind trying the below steps (check the issue after each step):

  1. Change Permalinks to the "Plain" from the Permalinks Settings Page.
  2. If it doesn't work then please check that your .htaccess file contains the default WordPress Rules. If not then please add them.
  3. Deactivate all the plugins.
  4. Switch to default theme like Twenty-Twenty.

If you find that after trying the above steps the issue is fixed then please activate your theme and plugins back one-by-one and also reverting to your custom permalinks settings.

Hope you can get to the problem which is causing this issue.

Improve this answer
2
  • Changing the URL structure to "Plain" doesn't resolve this issue, Changing it to "Post Name" does work, this doesn't solve the issue because I need it to have the custom permalink structure. This is happens on 2 websites now not just one I first reported this issue for, Both still 404 when visit an invalid URL after the custom forward bit of the permalink. This doesn't happen locally on either site, I think its hosting related and .htaccess is not used because these are hosted under Nginix both locally where its fine and online. Switching theme to a default doesn't help.
    – Someone
    Commented Feb 10, 2021 at 10:36
  • @sam I didn't suggest to keep permalinks settings as "plain". It was just to check or debug the issue. In the end, in my comment itself I have written that you would also need to revert your custom permalinks settings. And, yes on Nginx .htacess files don't work. Did you get a chance to check settings on your server itself? You can also try below code to tell WordPres whether a URL is 404 or not if you like. But, it is not a proper way I think. $wp_query->is_404 = false; See this post
    – SagarG
    Commented Feb 11, 2021 at 16:47
0

OK so after much working out what was causing this, this was caused by me not setting:

fastcgi_param PATH_INFO

Which was being set as part of the hosting setup the company I work for sets.

We found this out by tracing back the cause to the class_wp.php file in particular we found that:

if ( empty( $requested_path ) || $requested_file == $self || strpos( $_SERVER['PHP_SELF'], 'wp-admin/' ) !== false ) {

$self and $_SERVER['PHP_SELF'] were coming up as index.php for my local copy but on the hosting environment these values were matching the $requested_path.

So nothing to do with plugins etc.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.