404 Support

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.

???

Sencer · 2005-10-30 09:55:54

mary
re 1: You don’t set values in $pretext, but in PHP’s superglobals like _POST or _GET from where pretext() decides what to do. If you set _GET[‘s’] to a section-name, then pretext() will assume messy urls and not parse the request-uri, instead it will prepare to show that section.

re 2: $pretext[‘status’] of course works, since we are not using the extracted value, but referencing the global directly. But as graeme said:

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?

is correct. I think I’ll remove the extract() and reference $pretext as a global in that function. Then you should be able to set $pretext[‘page’], section etc. etc.
edit: Done.

Last edited by Sencer (2005-10-30 10:34:24)

graeme · 2005-10-30 12:41:24

Sencer wrote:
I think I’ll remove the extract() and reference $pretext as a global in that function. Then you should be able to set $pretext[‘page’], section etc. etc.

Cool, 1073

Thank you Sencer

Andrew · 2005-10-30 16:17:15

Good thread :-)

Textpattern CMS

Textpattern CMS support forum

#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

#46 2005-10-30 09:55:54

Re: 404 Support

#47 2005-10-30 12:41:24

Re: 404 Support

#48 2005-10-30 16:17:15

Re: 404 Support

Board footer