Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Avoiding the need for "pgonly"
Some tags only work correctly when placed after an article tag, because they depend on context (namely the $thispage global) that isn’t created until the article tag has been processed. Hence we have the pgonly attribute for article.
Working on a plugin dealing with pagination, loosely based on the old rsx_page_number plugin, I borrowed a trick from the old plugin to allow correct function even when placed before the article tag: if $thispage isn’t set, the tag returns itself as a string. This works, usually, because textpattern() runs the Page through parse() twice in a row. (I’m not sure why it does this, other than to enable this very trick — is there another reason? What native Txp functions make use of the second parse() pass?)
I said “usually”, because it fails if there is no article tag at all. This came to my attention in the thread above when my plugin’s tag was used in the title element, leaving the raw tag plain to see. After digging around I discovered $pretext['secondpass'] and am now using that to prevent this bug. I made a support function to handle it:
function _soo_secondpass ( $func, $atts, $thing = '' ) {
// in case $func's associated tag requires context from a tag later in the page,
// this runs $func's tag again during textpattern()'s second parse() pass
global $pretext;
if ( $pretext['secondpass'] ) return; // you only live twice
$a = '';
foreach ( $atts as $k => $v )
$a .= " $k=\"$v\"";
return "<txp:$func$a" . ( $thing ? ">$thing</txp:$func>" : ' />' );
}An example of a tag calling it:
if ( ! is_array($thispage) ) return _soo_secondpass(__FUNCTION__, $atts, $thing);From a comment in the rsx_page_number code, I gather that some early version of Txp used the same trick for older and newer. Back before we had pgonly, I think.
I post this here because:
- might be of interest to plugin devs
- might be of interest to Txp devs
- someone might point out a better method, or native Txp function for doing the same thing
- I’m wondering what the second
parse()pass does
I’m already using it in two plugins, so wouldn’t mind seeing something like this in core.
Last edited by jsoo (2009-07-09 23:51:13)
Code is topiary
Offline
Re: Avoiding the need for "pgonly"
I’ve always found the “second pass” to be an ugly, inefficient solution. This is not a comment on your plugin, just an opinion on how this is handled in TXP.
Offline
Re: Avoiding the need for "pgonly"
Well, I had the same thought, but I haven’t figured out why it’s needed, or if it even is needed. What native code depends on the second parse() pass?
Code is topiary
Offline