You can reference here for a Site aware exception handling in Magnolia CMS which is updated for Magnolia CMS 5.7.+


The 404 Handler

In some projects you may want to have the possibility to define your own Error-Pages (as 404 etc.).
With magnolia it is either possible to define this pages internally in the website tree, or externally.

Since magnolia 3.5 (magnolia internal error page)

If you are using Tomcat/Jboss you can do so by simple edit the magnoliaPublic web.xml (inside webapps\magnoliaPublic\WEB-INF\web.xml)
and add the following section:

<error-page>
   <error-code>404</error-code>
   <location>/errorPages/404.html</location>
</error-page>

When using a single installation with multiple domains, host based virtual URI mapping might be useful:

<!--
    The error handler for HTTP 404 Not Found, and alike.

    The page "/my-virtual-uri-mapping/error-404" does not exist, but
    is used in some URL rewriting configured like below:

    - The rewriting uses "ends-with" mappings, so "magnolia-cms.de" also
      matches "www.magnolia-cms.de". And simply using ".de" matches both
      domains as well.

    - When there are multiple matches, the longest match is selected.

    - If there's no match, then the mapping in "toUri" is used.

    - Using "forward:" ensures that Tomcat preserves the actual HTTP
      error code, making browsers and search engines understand that the
      page is actually an error page, even though a normal Magnolia page
      is shown to the visitor.

    Configuration
      + modules
        :
        + adminInterface
          :
          + virtualURIMapping
            :
            + my-error-forbidden
              + hosts
                - 1      .de=forward:/de/some/magnolia/forbidden/page
                - 2      .com=forward:/en/some/other/forbidden/page
              - class    info.magnolia.cms.beans.config.HostBasedVirtualURIMapping
              - fromURI  /my-virtual-uri-mapping/error-403
              - toURI    forward:/en/some/default/magnolia/forbidden/page
            + my-error-notfound
              + hosts
                - 1      .de=forward:/de/some/magnolia/notfound/page
                - 2      .com=forward:/en/some/other/notfound/page
              - class    info.magnolia.cms.beans.config.HostBasedVirtualURIMapping
              - fromURI  /my-virtual-uri-mapping/error-404
              - toURI    forward:/en/some/default/magnolia/notfound/page
-->
<error-page>
    <error-code>403</error-code>
    <location>/my-virtual-uri-mapping/error-403</location>
</error-page>
<error-page>
    <error-code>404</error-code>
    <location>/my-virtual-uri-mapping/error-404</location>
</error-page>

A 500 Internal Server Error might best be served without relying on Magnolia. Hence:

<error-page>
   <error-code>500</error-code>
    <!--
        Magnolia's default "/docroot" is known in server, filters, cms, bypasses.
        When using another path, be sure to add a bypass for that path as well.
    -->
   <location>/docroot/error-500.html</location>
</error-page>

After your application server restarted, the error page will now come out of magnolia (with all it's benefits).

If you have an older version of magnolia or, for whatever reasons, want to have your error page outside of magnolia you can do this as well following the procedure below.

Before magnolia 3.5 (external/redirected error page)

For this example let's assume that your magnolia site is under /index/
and that you have created your own 404.html error page under that..ie

/index/404.html

Edit the magnoliaPublic web.xml (inside webapps\magnoliaPublic\WEB-INF\web.xml)
and add the following section:

<error-page>
     <error-code>404</error-code>
     <location>/admintemplates/404.jsp</location>
  </error-page>

Now, create a 404.jsp file inside your \webapps\magnoliaPublic\admintemplates directory
that contains the following jsp code

<%
response.setStatus(HttpServletResponse.SC_MOVED_PERMANENTLY);
String contextName = request.getContextPath();
String newLocn = contextName + "/index/404.html";
response.setHeader("Location",newLocn);
%>

What will happen is that if a user requests a page that doesn't exist inside
your magnoliaPublic context then Tomcat will redirect the user to the /admintemplates/404.jsp page which then redirects to your /index/404.html page.

Why must you do it this way?? Well, your web.xml has to point to a file that actually exists somewhere in your webapps directory, not to a 'virtual' file in your Magnolia repository. If you doubt this, try replacing /admintemplates/404.jsp with /magnoliaPublic/index/404.html and see what happens. We point the web.xml to a 'real' file and then have that real file perform a redirect to your magnolia generated 404.html file.

Please note here, that when you are redirecting the error page, the page header received by the request will no longer by 404 but 302 instead. This may lead to some issues with search engines, like with google for example.

When using this with Magnolia 3.5.x

Now to make this work with Magnolia v3.5.x you need to define a bypass for a custom jsp page created above.

Warning

When configuring bypass all the values are applied immediately. In other words, your filter will be applied before it is configured, resulting in a completely broken configuration. Hence you must configure this node elsewhere in the tree and only when fully configured move it to (server/filters/bypasses)

Read what you can do if your bypass configuration is broken.

Go to the configuration menu and create new contentNode anywhere but not at
server/filters/bypasses and call it 404 for this node create dataNode class and set it to info.magnolia.voting.voters.URIStartsWithVoter and dataNode pattern with value pointing to your 404.jsp (i.e. /admintemplates/404.jsp in the case of example above). Once configured, move your node to server/filters/bypasses.

In its previous incarnation on JspWiki, this page was last edited on Mar 31, 2007 10:07:56 PM by Magnolia
Other known authors include :

  • RamonBuckland
  • Jgibbens
  • BorisKraft

6 Comments

  1. I think the bypass filter contentNode needs to go into server/filters/cms/bypasses?

    1. depends what you need to do in your 404 page (wink)
      You can even (at least in 3.6) define the < location> to be a Magnolia page, in which case the bypass is to be avoided.

      Also check the <dispatchers> element of the main Magnolia filter. If it doesn't contains the ERROR dispatcher, no bypass needed. If you want to use a Magnolia page as your 404 on the other hand, you will need the ERROR dispatcher.

  2. You will also have to check the implications for search engines and return the correct error codes etc. I will ask Olivier and Sameer to give feedback on this; they did some work lately with m.i in that regard.

  3. I haven't been able to do much in this regard but in general when you return status code like HttpServletResponse.SC_MOVED_PERMANENTLY, you are basically communicating that the page exist but at a different location.
    You need to return an error code 404 instead of an status code for non existing pages.

    Like Boris mentioned, the implications of not returning "error" are many...
    This is not the right thread to discuss those but for an example:

    • Your 404 page might be indexed by the search engines because its a valid page for them, this could happen if your non-existing page(s) are linked from other websites/pages.

    IMO, it would be easier if magnolia can provide some kind of basis for this and projects can simply specify which page to use as 404 page content. Otherwise each project under different containers would have to handle it accordingly.

    1. IMO, it would be easier if magnolia can provide some kind of basis for this and projects can simply specify which page to use as 404 page content.

      See MAGNOLIA-1565@jira (smile)
      (only issue is our web.xml would become kilometric to cover all error codes)