Answered How to emulate a MODX 404?

Is it possible to emulate the way that MODX handles 404 pages on my site? As in, keep the current URL (no redirects), but serve a 404 response code and show the 404 page set in the system settings.

To cut a long story short, the reason I need to do this is because I've got an international website where each page is available in some regions, but not others. Each page has just 1 resource, but could be available in any number of regions. I then use a checkbox TV to choose which regions that resource should be available in.

For example, this page should display as normal:
/en/products/product-1/

But this page should 404:
/nz/products/product-1/

I've already got the site set up to redirect the incorrect pages to the 404 page with a MODX plugin that I made. However, this isn't good enough for SEO as the first page will show a 302 response code, not a 404.

So, ideally I want to do exactly what MODX does for a 404 - keep the URL the same, but show the 404 page set in the system settings and send the 404 response code.

Any ideas?

It should be possible to do by actually disabling the modx error page and have it serve the error page as defined in your host settings. You'll just need to style it up the same as the one you made.

Quote from: lkfranklin at Oct 06, 2017, 08:00 AM

It should be possible to do by actually disabling the modx error page and have it serve the error page as defined in your host settings. You'll just need to style it up the same as the one you made.

Hmm, I'm not sure I like that solution, I'd rather have the 404 page managed within MODX. I'd also prefer not to break what MODX already does!

Surely there's a way to serve the 404 resource instead of the current one?

That's fair enough. Though it's not breaking modx but rather just disabling a feature and letting cpanel or plesk serve your custom error page. But of course you are limited to not being able to use modx calls.

This might do it in your plugin:



It may not work, but it's worth a try. Redirecting this way in a plugin often doesn't work. It will definitely work in a snippet (usually called from the page template), if there's a way for you to use a snippet instead of a plugin.

Something like this might work if each region is a different context:



I'm not recommending using multiple contexts if you're not already. They tend to introduce other issues.

Another way to go would be the MODX permission system, since users who don't have right view a page are automatically redirected to the error page with a 404. This would only work if all the users are logged in, though, and it would probably be a royal pain to set up.

I'm glad go got it worked out, though I still don't understand your situation. If the URL doesn't point to a valid resource, MODX should automatically forward the user to the error_page with a 404, unless your plugin is preventing that.

It's all part of the internationalisation system that I've built. I didn't want to use different contexts as that can be messy, so I decided to use different TVs, which contain all of my language data.

With that in mind, I've got multiple languages all pointing to the same resource. So, with the below URL:

/en/products/product-1/

I use htaccess to strip out the /en/ and set that as my Culture Key, then I send the rest of the URL to the ?q= GET variable for MODX to deal with. So, as far as MODX is concerned, I'm just asking it to load a resource as normal. I then use various plugins and snippets that I've developed to serve the correct content on the page, including languages.

Where this thread came in was that I don't want some resources showing in certain regions. So, I set up a 'disallowedLocations' TV and used my plugin to redirect people to the 404 page if they're asking for a location/resource combo that I won't allow. I just wanted to do this better than a simple redirect, I wanted to handle a 404 the same way that MODX does.

All of this is further complicated because I use a modified version of xFPC, which allows full page caching based on the URL, but doesn't support response codes! So I had to figure out a way to programmatically disallow the cache for anything other than a 200 code, which I've done.

Hopefully that explains what I wanted to use the $modx->sendForward for and hopefully this thread can help people utlise it in the future!

Thanks Bob, that solution works too and is a little tidier!