Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: Act on article status in any context
Haha, post_populate sounds like some kind of 80s music movement you’d see referred in the Grauniad.
I agree that process isn’t broadly grokkable so if there is anything better, let’s consider it, but I seem to recall we brainstormed when the idea was first floated and couldn’t come up with anything back then either. Thinking caps on.
While I like the txp-process concept for brevity – if it can be implemented in a useful and logical (no surprises) way – I think the notion of using <txp:hide> remains a good one because you are essentially hiding the content from the parser, just until a certain processing stage. Hey, I wonder if this syntax works:
<txp:hide until="2"> ...
// content only "seen" in second pass
</txp:hide>It does still rely on people knowing there are multiple passes, though. And is "until=1" essentially redundant because it’s the same as not having the hide tag there at all? Or does its use mean it will only be processed in stage 1, and skipped in 2 onwards (if indeed there’s anything left to parse)?
EDIT: Also, if we rename the process attribute, does that impact the txp-process too? txp-until doesn’t seem quite as attractive.
When we nail this, should we expose “Number of parser passes” in our new (well, recently re-introduced) Advanced Prefs area?
Last edited by Bloke (2019-01-09 14:52:47)
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: Act on article status in any context
IIRC, until was considered at some stage, but process has another special meaning: <txp:hide process /> (without any value) will parse the content, but not output the result:
<txp:hide process>
<!-- some comment for dev only eyes -->
<txp:variable name="param1" value="1" />
<!-- another comment for dev only eyes -->
<txp:variable name="param2" value="2" />
</txp:hide>No, there would not be txp-until :-) And yes, until="1" is useless as is, but makes sense in until='<txp:possibly_one />'.
Not sure about the number of parser passes pref. Currently it’s 2, but we could set it to, say, 15 without much risk, because parsing stops anyway as soon as there is no more <txp:tags /> left.
Offline
Re: Act on article status in any context
Makes sense we’d considered (and rejected) until already. I’ve slept since then.
Presumably then, without any process attribute, the contents of hide tags are truly invisible. ISTR in previous versions scratching my head because the page issued an error or warning due to a malformed tag construct inside a <txp:hide> block. I’d have to check now but I also think I saw such hidden tags at least mentioned in the tag trace. Might be wrong.
I honestly can’t think of anything better than process. Stumped.
And if it makes sense to ditch the hidden pref and increase the default number of passes without ill effect to the parsing speed, then go for it. Convention over configuration, FTW.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: Act on article status in any context
These warnings are normal. Though the content of hide is not processed, it is still syntactically analysed. That’s why I always wanted to make the debug output invisible to the outer world, but this would make errors less easily detectable.
If we stumble upon a case where two passes do not suffice, increasing their number is straightforward.
Offline
Re: Act on article status in any context
Can one of you remind me/us why there are several processing passes (or point me to somewhere where it’s described). I’ll gladly write a tip on textpattern.tips but the briefest of background would help…
TXP Builders – finely-crafted code, design and txp
Offline
Re: Act on article status in any context
I originally thought two passes were required to support things like pagination tags that can’t necessarily be evaluated in a single pass if things are used “out of order” (e.g. if pagination comes before an article tag, for instance). However, this notion might be misguided because, until 4.7.0, you couldn’t do it anyway and had to rely on pgonly.
According to the commit in which it was introduced by Sencer the message was the rather cryptic:
Adding if_preview and some (potentially experimental) stuff to customize previews. More details to follow…
No details seemed to follow.
Upshot: your guess is as good as mine!
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: Act on article status in any context
It looks like the second pass has always been there.
Offline
Re: Act on article status in any context
Ah yes, indeed you are right. I was just hunting for mention of secondpass explicitly, which surfaced in 4.0.2.
So the reason for its inclusion is definitely lost in the mists of time amid Dean’s initial vision.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: Act on article status in any context
So that means it does 2(+) passes but we don’t know quite why ;-)
But now we have found a reason.
TXP Builders – finely-crafted code, design and txp
Offline
Offline
Re: Act on article status in any context
The function so nice, he ran it twice.
Very funny.
But the second pass is so widely (ab)used in various tips that we can not get rid of it.
Can you give me some examples? Aside from what you showed us here, I was trying to understand what it’s good for.
TXP Builders – finely-crafted code, design and txp
Offline
Offline