404 Support

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?

Mary · 2005-10-29 07:48:56

bump Anyone?

Edit: Okay, so I looked through gbp_faux_static to see what Graeme did. So I create my own replacement for textpattern(), which ends in a die() and make that a callback for the textpattern event. Is that correct?

Last edited by Mary (2005-10-29 07:58:50)

Sencer · 2005-10-29 11:11:20

No, you don’t make replacements.

There are two callbacks you can use:

textpattern-event which is called after pretext() is done and would require you do set a couple of variables in $pretext (status, section [‘s’], page …). The other callback
pretext-event which is called before pretext() (or actually at the start of pretext), where you can “simply” set a section as it would be set by messy urls. And then pretext() handles the rest.

Basically I would adivse you to read pretext() and then textpattern() to see what is happening under which conditions and then you’ll see how you can injeect the right stuff with your plugin.

Here is an untested example from the top of my head:

register_callback(‘abc_myinitstuff’,‘textpattern’);
function abc_myinitstuff()
{
global $pretext;
if (url has whatever I want)
{
$pretext[‘status’] = ‘200’;
$pretext[‘s’] = ‘default’; // Name of the section you want to use
$pretext[‘page’] = safe_field(…) //get page template
}
}

And the alternative way:

register_callback(‘abc_alternativeinitstuff’,‘pretext’);
function abc_alternativeinitstuff()
{
if (url has whatever I want) $_POST[‘s’] = ‘default’; //trick pretext() into loading default page.
}

Mary · 2005-10-29 12:56:48

Okay. I had read them, but wasn’t really sure. I’ll take what you’ve given me here and re-read it. Hopefully it click this time ‘round. Thanks much. :)

Andrew · 2005-10-29 16:15:27

Hm… I’m running into problems. Using the pretext event method (the only one I’ve got “working” so far), if I set $_POST['s'], then /textpattern/css.php starts throwing 404s rather than serving up the css.

I’ve yet to get the textpattern event callback method to give me anything other than an ‘Unknown Section’ response. I’ll keep trying…

Last edited by Andrew (2005-10-29 18:01:55)

Andrew · 2005-10-29 18:17:48

Ok, it was the plugin interfering (not sure yet how) – so it’s confirmed the pretext callback works for me. I’ll continue playing with it.

graeme · 2005-10-29 18:23:58

mary wrote:
Edit: Okay, so I looked through gbp_faux_static to see what Graeme did. So I create my own replacement for textpattern(), which ends in a die() and make that a callback for the textpattern event. Is that correct?

So my plugin_callback filtering, textpattern() and die() calls have been discovered. Yeah it’s a very nasty hack, sorry. I’m not sure how textpattern will like this when two different plugins try the same trick. I’m looking for a better way to do this.

@Sencer,
Your code won’t always work because in textpattern() $pretext gets extracted before the plugin callbacks, so changes to $pretext[‘page’] have no effect as $page is used after the callbacks. Bug? This is why I used the textpattern() replacement as describe above to always force textpattern() to use new values. Why can’t I use the pretext callback? I hear you asking. If I did, in some cases, pretext() would replace some of the variables my plugin also tries to set.

Cheers.

Last edited by graeme (2005-10-29 18:56:39)

Andrew · 2005-10-29 18:26:48

graeme, I’m seeing it work properly while using the pretext callback – does what you just said apply to that method as well?

graeme · 2005-10-29 18:31:25

Andrew wrote:
graeme, I’m seeing it work properly while using the pretext callback – does what you just said apply to that method as well?

The pretext callback looks fine, although I’ve not tested.

Mary · 2005-10-30 06:09:55

Okay, I am still confused.

The pretext callback only runs at the beginning of the function, so anything you set just gets overwritten.
Setting anything like $pretext['status'] in a textpattern callback is useless, since the $pretext array has already been extracted.

???

Textpattern CMS

Textpattern CMS support forum

#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

#37 2005-10-29 07:48:56

Re: 404 Support

#38 2005-10-29 11:11:20

Re: 404 Support

#39 2005-10-29 12:56:48

Re: 404 Support

#40 2005-10-29 16:15:27

Re: 404 Support

#41 2005-10-29 18:17:48

Re: 404 Support

#42 2005-10-29 18:23:58

Re: 404 Support

#43 2005-10-29 18:26:48

Re: 404 Support

#44 2005-10-29 18:31:25

Re: 404 Support

#45 2005-10-30 06:09:55

Re: 404 Support

Board footer