Core Features

Instead, we want to look into a way to save all the messages in the content.xml files of each plugin and use those messages instead of directly writing messages in the code. That way all those can easily be translated (at least technically it should not be much of a problem.)

This requires us to define a few things such as a way to write messages with variables which are to be replaced at runtime (i.e. if you say something such as "we do not know email address foo@blah.com" then the email address probably need to be defined as "$email" instead of "foo@blah.com".)

So in the end it would be a part of the Message Box feature [core] plugin.

I had another feature definition, Automatic Pages [core], which sounds like it is a similar idea to this one.

IMPORTANT NOTE

Thinking about displaying processing errors to end users? This is done with the Message Box feature [core]

NOTE

In regard to implementation, all errors use the die() function at this point. This displays a detailed error, but not a regular page. This feature is about presenting a regular page to the end users so it doesn't look like a low level system error of death type of a thing.

We want to support error pages:

1) 403 when the user is not authorized to access a page (Access Denied), we want to display a log in prompt instead;

2) 404 when the user is going to a page that doesn't exist then we want to display a Page Not Found error message on a page that generally looks like the normal website without all the bells and whistles, but still most of the menus, etc.

Assuming we have a Search capability, we can have a 404 error page that gives the end user a choice to move forward (i.e. show the search feature result for the given URL.)

3) 401 when a user could not login via Basic Auth; this is handled by the basic auth plugin and is not specific to this talk. In general it ends up with a default login or error page explaining that the website is private (or at least that specific section.)

4) 531 when the user does not have enough permission to access a page and log in as administrator will still not be enough;

5) Others? -- The other type of errors we can emit are rare except for a 302 which could offer multiple choices in which case sending a Location: would be "complicated". Thus showing a page for a 302 and the offered choices could be a good solution.

In all cases, when we send a page with a valid header, we want to include a meta tag telling robots to not index that page and maybe (user selection) whether the search engines are allowed to follow the links; also we can do the same with robots used to archive data. (Note that Administrative pages should already be hidden with the robots.txt file though.)

<meta name="robots" content="noindex, nofollow, noarchive" />

Note that the 404 is a very simplified error if the domain doesn't even match properly (because otherwise we waste a lot of resources for nothing.) Similarly, if the domain is correct, but no website matches the URL, then we also generate a fairly simplified error, but in this case we can offer the user to go to the home page of the given domain. Here simplified means as raw as Apache's 404 page (i.e. an <h1> and one <p> with links if available.)

The 403 can be an issue (i.e. tells hackers that there is a page there, but that they need authentication to access it...). So we want to be able to protect such pages with a set of IP addresses. If the user IP address doesn't match any of the valid IPs, then he/she is given a 404 instead. This way they cannot learn of all the administration pages. (Instead of just the IP, the log in expired session could also be used to determine whether the user is a known administrator... since the log in is expired but not the cookie.)

The 403 should probably be a Redirect to the Log In screen so that way we don't reinvent the wheel. Then once logged in, the user can be redirected back to the page he/she was trying to access first. The redirection will be done using the session created at the time the user arrived on the website.

Note that a redirect allows us to avoid the remote possibility of showing private information from the top secret page!