404 Fallback

Table of Contents

  1. Dynamic Files
  2. Static Content

In MageStack, the 404 fallback mechanism revolves around the bootstrap of Magento (index.php).

Dynamic Files

When working in the context of dynamic files, there is no such thing as a server generated 404 page - as we need every non-existent URI to hit Magento itself (after looking for a file or directory with the same name).

Eg. https://www.example.com/my-non-existent-url.html

If there is no file named my-non-existent-url.html and no directory named my-non-existent-url.html, then we don't simply want the web server to stop processing the request and issue a 404, instead, we'll redirect the request to Magento to see if the application is aware of the URL. At this point, Magento will either find the matching page, or return its own styled 404 page.

So if you were to use the return 404 method when working with a bootstrapped application, you'll find that it won't just halt and return a server error, but rather hand off the request to the application (Magento) to make a decision.

Fallback Order

  1. Filename matching URI (eg. /my-non-existent-url.html)
  2. Directory matching URI (eg. /my-non-existent-url.html/)
  3. Magento bootstrap (eg. /index.php)

Static Content

We make exclusions to this rule when it comes to static content (see what files are defined as static content) - as we can safely presume this type of URL doesn't need to actually hit Magento if it doesn't exist on disk (read more).

Fallback Order

  1. Filename matching URI (eg. /my-non-existent-image.jpg)
  2. Directory matching URI (eg. /my-non-existent-image.jpg/)
  3. Magento lightweight 404 PHP error file (eg. /errors/404.php)
  4. Hardcoded lightweight 404 HTML error file (eg. /errors/404.html)
  5. Magento bootstrap (eg. /index.php)

We recommend that all users create the following file, so that 404 for static content produces an efficient/lightweight error page, rather than hitting the Magento bootstrap,