Tag architecture challenge for complex conditional output

Destry · 2013-10-08 11:09:22

Nope. That wasn’t it. Still having the same output on landing page.

Oh, btw, this /foo section is not the homepage. In case that wasn’t clear.

etc · 2013-10-08 11:44:38

Destry wrote:

In the case of the first article, if I remove the limit="1", all articles in the /foo section are output to the /foo landing section.

That looks suspect. Are you using gbp_permanent_links in some clean permlink mode? I’ve heard it could give some strange results.

Destry · 2013-10-08 12:48:54

etc,

That’s what I thought too. I didn’t remember ever having to use limit="1" like that before on an article tag, but…

And come to think of it, the code I show here was creating a single title composed of all titles for every article in that section; i.e., one big long concatenated title. I had to put a limit="1" on that article tag too, and that really doesn’t seem right.

To your question, I do have gbp_perm_links installed, but there are only two custom URLs setup with it, and neither are associated with this section/pages code. Or did I misunderstand your question?

etc · 2013-10-08 13:00:36

Destry wrote:

the code I show here was creating a single title composed of all titles for every article in that section; i.e., one big long concatenated title.

and it shouldn’t, you agree?

I do have gbp_perm_links installed, but there are only two custom URLs setup with it, and neither are associated with this section/pages code.

Mind disabling it, just to check if it helps? I have never used it, so don’t cross your fingers, but who knows.

maniqui · 2013-10-08 13:33:21

Hi Destry.

This snippet of yours has a flaw (imo):

<txp:if_individual_article>
     <txp:article limit="1">
           {all the article pieces needed; smd_bio stuff, etc. }
     </txp:article>
<txp:else />
     <txp:article_custom status="sticky">
            <txp:body />
     </txp:article_custom>
</txp:if_individual_article>

The flaw is the <txp:article_custom status="sticky"> tag in the else branch.
Yes, it may be “working” right now, returning the article you expect it to return, but it’s doing so just by chance.

From the Wiki

Unlike the article tag, article_custom will always return an article list and is not context-sensitive. This means while the article tag can only see posts within the currently viewed section/category/author and so forth, article_custom can see all posts from all sections, categories and authors unless you restrict it via attributes (see below), thus context-sensitive navigation tags, such as older and newer, will not work.

So, back to the <txp:article_custom status="sticky"> in your code, there are some implicit attributes & values: limit="10", section="" (which means from all sections), sort="Posted desc" and a few others, on that tag. As said before, if it’s currently returning the sticky article you expected, it’s only by chance (I’d bet you have only one sticky article).

So, you should replace it with a <txp:article status="sticky">, making it context-sensitive: it will return only sticky articles from current section. Of course, implicit default attributes & values still come into play: you may probably want to add a limit="1", if you only want one sticky article in the output.

Destry · 2013-10-08 14:46:29

etc wrote:

and it shouldn’t, you agree?

Yes, I agree. It shouldn’t.

Mind disabling it, just to check if it helps? I have never used it, so don’t cross your fingers, but who knows.

When turning that off, I now get an error saying the article body tag is used out of context.

So here is the code, now, with a few more details between the lines…

<txp:if_individual_article>
     <txp:article>
          <header class="headline">
              <h1><txp:title /></h1>
              <txp:smd_bio_info fields="url_title, RealName">
                   {all the smd_bio stuff, which works fine}
              </txp:smd_bio_info>
          </header>
          <p class="excerpt"><txp:excerpt /></p>
          <txp:body />
          <txp:if_custom_field name="gplus_post_link">
               {the Gplus stuff that works fine}
          <txp:else />  
               <txp:hide>Nothing outputs</txp:hide>
          </txp:if_custom_field>
     </txp:article>
<txp:else />
     <txp:article status="sticky">
          <txp:body />
     </txp:article>
</txp:if_individual_article>

There are two body tags, and both seem to be in context of an article tag. No?

Destry · 2013-10-08 14:54:43

Hold up. I forgot to edit out the section="" attribute in the actual code.

I also changed the custom field name from “Gplus link” to “gplus_post_link”.

Making those changes and it’s now outputting as you’d expect it should.

Except, when I turn gbp_permanent_links back on, it breaks it again. So it appears to be something with that plugin.

Out of the fire and into the coals.

maniqui · 2013-10-08 18:38:06

Destry wrote:

Except, when I turn gbp_permanent_links back on, it breaks it again. So it appears to be something with that plugin.

How does it break? Is there any error?

There is a known bug in gbp_permanent_links that is triggered when a section has the same URL name than an article. In other words, when section name == article-url-title.
For example, if your section is “foo” and your sticky article’s URL title is “foo”, gbp_p_l will throw an error. Could that be your issue?

els · 2013-10-08 18:45:42

If it’s not what Julián said, try if wrapping your code in <txp:gbp_disable_permlinks> ... </txp:gbp_disable_permlinks> makes a difference.

And if that’s not it either, can you please post the tag trace?

Last edited by els (2013-10-08 18:48:11)

Bloke · 2013-10-08 22:00:23

maniqui wrote:

There is a known bug in gbp_permanent_links that is triggered when a section has the same URL name than an article.

Aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaarrrrrrrrrrrrrrrrrrgggggggggggggggggggggggggghhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh!!!!!!!!!

Why didn’t I read this sooner? Just spent an hour fumbling around trying to figure out why the damn plugin was tripping individual article context on landing pages. Renaming the article from ‘articles’ to ‘articles-sticky’ (or something) means the problem goes away. Thank you, maniqui. I was about to yank out the last remaining strands of hair.

Mind you, I did stumble upon a bizarre work-around using smd_if:

<txp:smd_if field="pretext:url_title" operator="defined">
   // On an individual article page
<txp:else />
   // On a sticky landing page with url_title the same as section title
</txp:smd_if>

So I suppose it wasn’t all in vain.

This sort of thing is precisely why we desperately need curated content pages for each plugin in a publicly editable wiki. This “known bug” could have been highlighted on that page instead of buried in a 100-page forum thread. *sigh* my own fault for not improving textpattern.org properly in a timely fashion.

maniqui · 2013-10-09 02:23:48

Bloke wrote:

Aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaarrrrrrrrrrrrrrrrrrgggggggggggggggggggggggggghhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh!!!!!!!!!
(…) This “known bug” (…)

I should have said “bug known by me” ;)
I think I’ve reported it in the plugin thread, but I just searched for it but couldn’t find it (yet).

Good to know you have found a workaround, Bloke!

Destry · 2013-10-09 07:48:11

Bloke wrote:

This sort of thing is precisely why we desperately need curated content pages for each plugin in a publicly editable wiki. This “known bug” could have been highlighted on that page instead of buried in a 100-page forum thread.

I think it was like 2006 the firs time I pleaded for that, and several times since then. But no, people loooooooove wasting time in the forum.

We could easily start the plugin pages in the wiki now, and you could just hook into them when .org is ready. I’ll get something setup with a couple sample plugins as demo. How about gbp-pl, smd_bio, smd_if? Two with some starter copy and one wide open.

Textpattern CMS

Textpattern CMS support forum

#13 2013-10-08 11:09:22

Re: Tag architecture challenge for complex conditional output

#14 2013-10-08 11:44:38

Re: Tag architecture challenge for complex conditional output

#15 2013-10-08 12:48:54

Re: Tag architecture challenge for complex conditional output

#16 2013-10-08 13:00:36

Re: Tag architecture challenge for complex conditional output

#17 2013-10-08 13:33:21

Re: Tag architecture challenge for complex conditional output

#18 2013-10-08 14:46:29

Re: Tag architecture challenge for complex conditional output

#19 2013-10-08 14:54:43

Re: Tag architecture challenge for complex conditional output

#20 2013-10-08 18:38:06

Re: Tag architecture challenge for complex conditional output

#21 2013-10-08 18:45:42

Re: Tag architecture challenge for complex conditional output

#22 2013-10-08 22:00:23

Re: Tag architecture challenge for complex conditional output

#23 2013-10-09 02:23:48

Re: Tag architecture challenge for complex conditional output

#24 2013-10-09 07:48:11

Re: Tag architecture challenge for complex conditional output

Board footer