404 Support

zem · 2005-08-19 12:07:04

I would not dare to present that meager sentence “You have reached the end of the internet as far as I know of…” to a visitor/client on my website

Trouble is, we’re not dealing with vistors on a web site. We’re dealing with visitors on thousands of web sites, each of which is running in a different environment, some with only subtle differences, others entirely different platforms. And everyone has a different idea of what should be on that error page.

Baby steps. The previous behaviour – serving up the front page of your web site when someone requested /robots.txt or /favicon.ico or /some/nonexistent/path – was a big problem, and it’s fixed now.

Andrew · 2005-08-19 15:10:00

Edit: thanks zem… ‘sheesh’ is right. When will that Andrew guy shut the hell up? ;-)

Last edited by Andrew (2005-08-19 16:26:48)

wet · 2005-08-19 16:10:08

zem wrote:

Trouble is, we’re not dealing with vistors on a web site. We’re dealing with visitors on thousands of web sites, each of which is running in a different environment, some with only subtle differences, others entirely different platforms. And everyone has a different idea of what should be on that error page.

I wrote:

…reinstantiated the semantics of ErrorDocument existing in Apache when we had file based websites by applying its own method of assigning repository items (forms, pages, sections, search results, a user-provided hook/plugin, whatever design may evolve as useful)…

So from my point of view we both agree: Textpattern should provide a means for a user selectable — let me call it — ErrorDocument for a number of well defined error conditions (403, 404 at least), and maybe provide a sample implementation along the lines of todays sample page templates: Its there after an initial seup, it works, and everybody’s free to “bend it, shake it anyway she wants it…” People know their sites, their visitors. I do not expect that textpattern gave me the perfectly layouted page for 404s, but txp should give me the tools. The rest should be a matter of creativity just like today all of txp’s users are creative with their page templates, forms and — if they are coders — with their plug-ins.

Assuming that the database is still ok (which I hope it is when encountering a 403 or 404 condition) textpattern could lay all responsibility into the hands of the site owners if it only defined the rules / API /conventions or whatever you’d like to call it. This rules could be as dumb as “every 404 condition is handled by rendering article with $id=911” or as complicated as “we will call a function you could name on the admin side, passing in the following parameters: … and expect it to return the ROT13-encoded URL of …” You know what I mean…

And I am glad I would not have to code this ;)

//w&

Last edited by wet (2005-08-19 19:04:01)

Sencer · 2005-08-19 17:19:41

> wet wrote:
> I may sound a little blatant, but I beg to differ:

Not really (at least not in what you wrote). colak was asking about 410 for deleted articles. And that would be in line what you call a feature request as well (your’s being more elaborate and certainly something to look for down the line).

A 404 and a 200 are important differences to clients, especially search engines. It’s the difference between a page appearing in search results and not appearing there, with respect to duplicate pages, certainly something that’s relevant.

The difference between a 404 and 410 is mostly semantic, and I while, too, like the idea, in the real world I don’t know of any client that will behave differently for a 410 than it would for a 404.

Oh, and when looking for Feature requests, I am sure this thread is not going to be the place where we would think of looking, so they really are better off in a different place. ;)

wet · 2005-08-19 19:02:03

> Sencer wrote:

Not really (at least not in what you wrote). colak was asking about 410 for deleted articles. And that would be in line what you call a feature request as well…

Agree, I’ve mixed a few things up as I was responding with respect to colak writing this:

2. I would love for the error to have a link on the root of the site so instead of the “not_found” message we could get something like “not_found please view the site <txp:link_to_home>Here</txp:link_to_home>”

which was what I thought you’d call a feature request, especially when obeying this thread’s topic. I personally wouldn’t need any 410 handling in the near future, as I do not expect to have much use for it… And I wouldn’t like neither Txp nor myself to care for all the bookkeeping overhead with respect to articles, images, files, anchor segments and even comments. ymmv.

//w&

zem · 2005-08-19 23:50:58

‘sheesh’ is right. When will that Andrew guy shut the hell up? ;-)

The ‘sheesh’ was aimed at me. It only took me, what, like eight thousand checkins to get a simple 404 message right? :)

Nothing is as simple as it sounds, even things that really are simple. Which is precisely why:

Textpattern should provide a means for a user selectable—let me call it—ErrorDocument for a number of well defined error conditions (403, 404 at least) [..etc..]

..will come later. I’ve written and re-written Textpattern errordoc handling enough times to know there are many things that can go wrong, and many different interpretations of what should happen and what should be possible. Error handling is a critical function: what happens if an error happens while you’re trying to handle an error? How do we localize it? The first step is a basic failsafe error message display, which is what we have now.

Other things will come later, and they’ll come one step at a time. Textpattern has been a continual source of education to all of us on the dev team. Any developer deals with Murphy’s Law every day. But it’s not until you sit in the hot seat that you realise just how ruthlessly efficient a large distributed user base is at proving it. Every mistake or assumption we make is multiplied several thousand-fold, over all of the sites running Textpattern, on a range of different and sometimes incompatible platforms and environments, and many times over again, for every visitor to every one of those sites.

So I’ll hope you’ll forgive us for stepping slowly and carefully in the stable branch.

colak · 2005-08-20 07:02:56

I am writting this wondering whether this is the right thread or category but I think that responses to my previous post in this thread allows me to answer for my self.

>wet wrote
<blockquote>Agree, I’ve mixed a few things up as I was responding with respect to colak writing this:

<blockquote> 2. I would love for the error to have a link on the root of the site so instead of the “not_found” message we could get something like “not_found please view the site <code><txp:link_to_home>Here</txp:link_to_home></code>”</blockquote>

which was what I thought you’d call a feature request, especially when obeying this thread’s topic. I personally wouldn’t need any 410 handling in the near future, as I do not expect to have much use for it… And I wouldn’t like neither Txp nor myself to care for all the bookkeeping overhead with respect to articles, images, files, anchor segments and even comments.</blockquote>

Point taken and understood.
<blockquote> Sencer wrote:

> @colak: That’s a feature request, where I really don’t see the necessity to cram it into the 4.0.x line.</blockquote>

The link to home, although semantically should have been posted as a “feature request”, I felt that there was no reason of opening a new thread when this one was already open. Semantically again, I am not sure what kind of posts should fall under “Revison Discussion”.

Revision Discussion for me would be a discussion about existing features in the latest svn, how they work and how they could be improved. (it is possible that I am wrong with this assumption)

Sencer · 2005-08-20 08:24:56

It’s ok to mention it. Though it’s most likely that when we look for what it was people requested we are not going to look into old threads in Revision Discussion, so your suggestions simply might get lost.

Andrew · 2005-08-20 19:45:09

Just a thought about the current state of the 404; it’s sort of a bug, but not really. Here’s the scenario:

I was authoring a plugin for del.icio.us links that sort of creates a nice past archive of links based on the del.icio.us API. The end result is similar to what Simon Willison does with his Blogmarks in that it creates /clean/ url archives and caches the API request results returned. The way I was using it was by creating a /section that had the plugin call on its page template, and that enabled /section/2005 and /section/2005/08 etc.

Now however, this doesn’t work because the URLs aren’t technically acceptible by the prefs-defined url schema. So my question is this: is there a flag that can be used for plugin developers that will allow for bypassing or overriding the error page behavior, so that additional custom url schema extensions may be added to a site?

zem · 2005-08-21 00:48:11

Andrew,

A plugin can bypass the URL parsing in preText() by setting $_GET[‘s’] and/or $_GET[‘id’], whichever is more appropriate, when it loads. That tricks preText() into thinking the URL is messy, publish.ph line 208:

// if messy vars exist, bypass url parsing
if (!$out['id'] && !$out['s']) {

zem_rewrite works this way.

Andrew · 2005-08-21 07:21:39

> zem wrote:

A plugin can bypass the URL parsing in preText() by setting $_GET[‘s’] and/or $_GET[‘id’], whichever is more appropriate, when it loads. That tricks preText() into thinking the URL is messy, publish.ph line 208:

That’s a hidden gem of a trick. I had a feeling something like that existed – thanks for the tip!

Mary · 2005-10-25 22:02:58

Could someone please fully explain the proper sequence to go through for providing support for custom url schemes in 4.0.1/4.0.2?

Textpattern CMS

Textpattern CMS support forum

#25 2005-08-19 12:07:04

Re: 404 Support

#26 2005-08-19 15:10:00

Re: 404 Support

#27 2005-08-19 16:10:08

Re: 404 Support

#28 2005-08-19 17:19:41

Re: 404 Support

#29 2005-08-19 19:02:03

Re: 404 Support

#30 2005-08-19 23:50:58

Re: 404 Support

#31 2005-08-20 07:02:56

Re: 404 Support

#32 2005-08-20 08:24:56

Re: 404 Support

#33 2005-08-20 19:45:09

Re: 404 Support

#34 2005-08-21 00:48:11

Re: 404 Support

#35 2005-08-21 07:21:39

Re: 404 Support

#36 2005-10-25 22:02:58

Re: 404 Support

Board footer