Textpattern CMS support forum

You are not logged in. Register | Login | Help

#11 2019-01-09 13:30:17

jakob
Moderator
From: Germany
Registered: 2005-01-20
Posts: 3,344
Website

Re: Act on article status in any context

Brilliant. Would love to see (something like) this too:

<txp:variable name="browser_title" txp-process="2" />

That’s much less confusing-looking than txp:hide (but not always), but might it be possible to use another attribute name?

Putting on my “regular-user” hat, most users will have little to no idea of the inner workings of the parser. Unless there’s a good reason for explicitly using process (maybe there are other use cases I haven’t thought of), perhaps the attribute could have a more generally understandable name, like post_populate="1", fill="postpone" or populate="deferred" … maybe someone else has a better suggestion…


TXP Builders – finely-crafted code, design and txp

Offline

#12 2019-01-09 14:07:59

etc
Developer
Registered: 2010-11-11
Posts: 3,106
Website

Re: Act on article status in any context

I hope we’ll find a better name, but I would also like to improve the postponed processing itself. For example, in

<txp:some_tag txp-process="2" attr='<txp:another_tag />' />

<txp:another_tag /> would currently be parsed on both first and second passes, though it’s used only on the second one. Hiding avoids this problem:

<txp:hide process="2">
    <txp:some_tag attr='<txp:another_tag />' />
</txp:hide>

etc_[ query | search | pagination | date | tree | cache ]

Offline

#13 2019-01-09 14:47:07

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 8,611
Website

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

#14 2019-01-09 16:12:39

etc
Developer
Registered: 2010-11-11
Posts: 3,106
Website

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.


etc_[ query | search | pagination | date | tree | cache ]

Offline

#15 2019-01-09 16:59:48

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 8,611
Website

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

#16 2019-01-09 18:22:07

etc
Developer
Registered: 2010-11-11
Posts: 3,106
Website

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.


etc_[ query | search | pagination | date | tree | cache ]

Offline

#17 2019-01-10 10:40:35

jakob
Moderator
From: Germany
Registered: 2005-01-20
Posts: 3,344
Website

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

#18 2019-01-10 12:02:26

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 8,611
Website

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

#19 2019-01-10 13:20:34

etc
Developer
Registered: 2010-11-11
Posts: 3,106
Website

Re: Act on article status in any context

It looks like the second pass has always been there.


etc_[ query | search | pagination | date | tree | cache ]

Offline

#20 2019-01-10 13:28:39

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 8,611
Website

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

Board footer

Powered by FluxBB