Go to main content

Textpattern CMS support forum

You are not logged in. Register | Login | Help

#1 2018-11-13 09:02:41

Destry
Member
From: Haut-Rhin
Registered: 2004-08-04
Posts: 4,909
Website

Small glitch in article navigation markup somewhere?

I think I have a glitch in my navigation system somewhere but I’m not sure how to find it, if anyone can give it a think…

As you may recall, the site is a simple two-section structure: Home and Stories. Home (homepage) functions more like a pseudo-magazine showing current issue list of titles, and an all-articles archive at bottom. Stories is where full articles are displayed.

The only main navigation used is on the Stories page, to navigate published articles. The navigation is not tied to issues, it just rotates through articles according to date/time. (I do have a notation in the title=“” attributes of nav links to show title in context under link and what issue it belongs to.)

As a test, I have four articles published belonging to ‘Issue 1’. They output in anti-chronological order in the homepage’s ‘Current issue’ list (i.e. newest to oldest):

  • Article latest
  • Article next to latest
  • Article next to oldest
  • Article oldest

There should be (as I desire) three possible nav link arrangements depending on the context of a given article displayed, as follows:

  • latest [previous, latest, all]
  • next-to-latest [previous, next, latest, all]
  • next-to-oldest [previous, next, latest, all]
  • oldest [next, latest, all]

Basically any article that is not the very first or latest published will show all four possible links. The oldest article will not show ‘previous’, naturally. Likewise the latest article will not show ‘next’. When in latest article context, the ‘latest’ link will point to the same article, but that’s okay, it’s the only time it will happen and I see it as a positive orientation cue.

But, I’m seeing two problems, which I think may only be one problem causing the other, but I don’t know which direction. I.e. if I fix one the other might go away too. I don’t know, not sure. It’s odd.

Problem 1:

In all contexts where there should be both ‘previous’ and ‘next’ links, I’m only getting ‘previous’. This was working in the beginning, but somewhere along the line it stopped working and I didn’t realize until this morning.

Problem 2:

For the article that fills the ‘next-to-oldest’ slot in the list above, it’s not taken into account in the navigation behavior for the four Issue 1 articles. The nav links on the Stories section just behave as if it’s not there even though it’s published/live and appears in the Homepage current issue list. It’s odd.

The following form creates the navigation bar. I borrowed some of this from somewhere else, maybe Hive out of box, I forget, and I don’t quite grasp the logic of the variables. For example, I’ve no clue what the ‘more’ variable is for. So if you get what it’s supposed to do but can refine the tag markup, that would be nice too. ;)

<txp:variable name="more" value='<txp:link_to_prev /><txp:link_to_next />' />
<txp:variable name="prev" value='<txp:link_to_prev />' />
<txp:variable name="next" value='<txp:link_to_next />' />

<ul>
    <txp:if_variable name="more" value="">
       <txp:hide> do/output nothing </txp:hide>
    <txp:else />
       <txp:if_variable name="prev" value="">
          <txp:hide> do/output nothing </txp:hide>
       <txp:else />
         <li><a rel="prev" href="<txp:link_to_prev />" title="<txp:prev_title escape="tidy,textile,tags" /> (Issue <custom::field name="issue" />)">Previous</a></li>
       </txp:if_variable>
       <txp:if_variable name="next" value="">
          <txp:hide> do/output nothing </txp:hide>
       <txp:else />
         <li><a rel="next" href="<txp:link_to_next />" title="<txp:next_title escape="tidy,textile,tags" /> (Issue <custom::field name="issue" />)">Next</a></li>
       </txp:if_variable>  
    </txp:if_variable>
    <txp:article_custom form="link_latest_nav" limit="1" wraptag="li" />
    <li><a href="<txp:site_url />#toc" title="Go to all stories.">All</a></li>
</ul>

And here’s the form being called for the ‘Latest’ link (near the end). It seems like a vestigial appendix hanging their on its own, but I’m not sure there’s a better way to rope it into the above form.

<txp:permlink title='<txp:title escape="tidy,textile,tags" /> (Issue <custom::field name="issue" />)'>Latest</txp:permlink>

Anyone see what the first problem might be as a start?

Last edited by Destry (2018-11-13 09:11:39)

Offline

#2 2018-11-13 10:30:08

jakob
Admin
From: Germany
Registered: 2005-01-20
Posts: 4,578
Website

Re: Small glitch in article navigation markup somewhere?

How about using txp 4.7’s evaluate tag and dispensing with the whole variable dance :-)

<ul>
  <txp:evaluate test="link_to_prev" wraptag="li">
    <a rel="prev" href="<txp:link_to_prev />" title="<txp:prev_title escape="tidy,textile,tags" /> (Issue <custom::field name="issue" />)">Previous</a>
  </txp:evaluate>
  <txp:evaluate test="link_to_next" wraptag="li">
    <a rel="prev" href="<txp:link_to_next />" title="<txp:next_title escape="tidy,textile,tags" /> (Issue <custom::field name="issue" />)">Next</a>
  </txp:evaluate>
  <txp:article_custom limit="1" wraptag="li">
    <txp:permlink title='<txp:title escape="tidy,textile,tags" /> (Issue <custom::field name="issue" />)'>Latest</txp:permlink>
  </txp:article_custom>
  <li><a href="<txp:site_url />#toc" title="Go to all stories.">All</a></li>
</ul>

When there’s no previous or next article, that link should not appear.

If you didn’t need the special title attribute, you can achieve this more simply with just the link_to_prev and link_to_next tags by doing:

<txp:link_to_prev wraptag="li">
  <txp:prev_title />
</txp:link_to_prev>

And if hint, hint Oleg, link_to_prev and link_to_next were to have a title attribute at some point in future, you could put your custom title tag straight in there.

It seems like a vestigial appendix hanging their on its own, but I’m not sure there’s a better way to rope it into the above form.

Just use article_custom as a container tag and omit the form attribute. It’s good for one-only instances or simple mini-bits of output like here…

EDIT: Error in code example: no form attribute is necessary when using article_custom as a container tag.


TXP Builders – finely-crafted code, design and txp

Offline

#3 2018-11-13 12:47:05

Destry
Member
From: Haut-Rhin
Registered: 2004-08-04
Posts: 4,909
Website

Re: Small glitch in article navigation markup somewhere?

Thank you, Jakob. That certainly cleans up the markup a bit and replicates the exact behaviour as before, including the two problems. So they must be caused by something different than the navigation form.

Here are the nav links displayed in context of each of the four test articles:

  • Article latest : previous, latest, all
  • Article next-to-latest : previous, next, latest, all
  • Article next-to-oldest : previous, next, latest, all
  • Article oldest : next, latest, all

The code items show what should be appearing but do not. And even though I can get to the ‘next-to-oldest’ article from the homepage current-issue list, it does not reflect in the contextual behaviour of the nav bar links. The nav just acts like it’s not published. Very strange.

I’m guessing whatever is causing the problem with the article is screwing up the general function of the navigation too.

Offline

#4 2018-11-13 13:32:56

jakob
Admin
From: Germany
Registered: 2005-01-20
Posts: 4,578
Website

Re: Small glitch in article navigation markup somewhere?

Hmm, I’m unsure for the moment. I’ve forgotten what determines the choice of next and previous (I thought a combination of timestamp and section). Some things to check:

  • this appears in an individual_article context?
  • are the articles all in the same section? (IIRC: you’re using just /title as your url scheme)

TXP Builders – finely-crafted code, design and txp

Offline

#5 2018-11-13 14:07:58

Destry
Member
From: Haut-Rhin
Registered: 2004-08-04
Posts: 4,909
Website

Re: Small glitch in article navigation markup somewhere?

jakob wrote #315197:

  • this appears in an individual_article context?

After 15 years I still can’t remember what that means. But I think, yes. There’s a dedicated page for articles, aligned with an articles section, and it’s called in using an article form.

  • are the articles all in the same section? (IIRC: you’re using just /title as your url scheme)

Ahh… This did change recently when working on the Issue list from the other thread. That’s probably when the behavior changed and I didn’t catch it. They were all in the ‘articles’ section, but I’ve since parsed them to four different sections according to type of writing they are: narrative, descriptive, persuasive, expository. I did that thinking I might have to replicate the TXP Mag ‘columns’ structure idea and didn’t change it back.

But I’ve since been using it for the homepage archive region to create archive lists by the same writing types. They were setup as categories, but this way seems, on the surface, to buy me an extra level of structure. The reasoning goes: most stories are a particular main type of writing (thus section assignment), but can also be one or two other types in places. So you could have this:

  • Section = persuasive
    • Category1 = descriptive
    • Category2 = narrative

But in truth, I think it’s rare to never that I’ll have need for three designations like that; never more than two, so maybe I should switch it back to a single ‘articles’ section and use categories for types again.

Yep. Doing that to see what shakes out.

Offline

#6 2018-11-13 16:10:26

Destry
Member
From: Haut-Rhin
Registered: 2004-08-04
Posts: 4,909
Website

Re: Small glitch in article navigation markup somewhere?

Thank you once again, Jakob, for helping me iron it out. It seems you’re second point was indeed the problem. Working now that I’ve put the sections back as they were.

I’m guessing I can ignore this warning that shows up in debug mode? Nothing seems to be broken despite its appearance.

Tag error: <txp:smd_article_stats item="body,excerpt" break="+" /> ->  Textpattern Notice: smd_article_stats tag is not registered while parsing form stories on page articles

textpattern/lib/txplib_publish.php:562 trigger_error()
textpattern/lib/txplib_publish.php:471 processTags()
textpattern/lib/txplib_misc.php:2617 parse()
textpattern/lib/txplib_publish.php:540 splat()
textpattern/publish/taghandlers.php:5128 processTags()
txp_eval()
textpattern/vendors/Textpattern/Tag/Registry.php:116 call_user_func()
textpattern/lib/txplib_publish.php:547 Textpattern\Tag\Registry->process()
textpattern/lib/txplib_publish.php:471 processTags()
textpattern/lib/txplib_misc.php:4364 parse()

It might have been there all along, but I’ve been in Testing mode and didn’t see it, maybe.

Offline

#7 2018-11-13 16:27:38

jakob
Admin
From: Germany
Registered: 2005-01-20
Posts: 4,578
Website

Re: Small glitch in article navigation markup somewhere?

Destry wrote #315211:

Thank you once again, Jakob, for helping me iron it out. It seems you’re second point was indeed the problem. Working now that I’ve put the sections back as they were.

Glad you got it working. That was more thinking aloud than anything. I see in HISTORY.txt on Github that etc has added an attribute called context to those tags for the next version 4.7.2 but I don’t know how it works.

I’m guessing I can ignore this warning that shows up in debug mode? Nothing seems to be broken despite its appearance.

That’s just the unregistered tag warning as described here. Add this:

// TXP 4.6 tag registration
if (class_exists('\Textpattern\Tag\Registry')) {
	Txp::get('\Textpattern\Tag\Registry')->register('smd_article_stats');
}

to the top of the plugin code (or the public section of the code) to silence it (Admin › Plugins › Edit code). You need an addition ->register('tag_name_here') for every public tag.


TXP Builders – finely-crafted code, design and txp

Offline

#8 2018-11-14 16:49:33

etc
Developer
Registered: 2010-11-11
Posts: 5,028
Website GitHub

Re: Small glitch in article navigation markup somewhere?

jakob wrote #315187:

And if hint, hint Oleg, link_to_prev and link_to_next were to have a title attribute at some point in future, you could put your custom title tag straight in there.

I would rather make the most common unused HTML attributes global, even have a plugin for this:

# Name: etc_attribute v0.1 
# Type: Admin/Public plugin
# 
# Author: 
# URL: 
# Recommended load order: 5

# .....................................................................
# This is a plugin for Textpattern CMS - http://textpattern.com/
# To install: textpattern > admin > plugins
# Paste the following text into the 'Install plugin' box:
# .....................................................................

YToxMTp7czo0OiJuYW1lIjtzOjEzOiJldGNfYXR0cmlidXRlIjtzOjY6ImF1dGhvciI7czow
OiIiO3M6MTA6ImF1dGhvcl91cmkiO3M6MDoiIjtzOjc6InZlcnNpb24iO3M6MzoiMC4xIjtz
OjExOiJkZXNjcmlwdGlvbiI7czowOiIiO3M6NDoiY29kZSI7czoxMDkzOiJmdW5jdGlvbiBl
dGNfYXR0cigkYXR0cywgJHRoaW5nID0gJycsICRyZWdvbmx5ID0gZmFsc2UpDQp7DQogICAg
c3RhdGljICR0YWdzID0gYXJyYXkoJ3JlbCcgPT4gJ2F8YXJlYXxsaW5rJywgJ3N0eWxlJyA9
PiBudWxsLCAndGl0bGUnID0+IG51bGwpLA0KICAgICAgICAkYXR0ciA9IGFycmF5KCk7DQoN
CiAgICBpZiAoJHJlZ29ubHkpIHsNCiAgICAgICAgJGF0dHIgPSBhcnJheV9rZXlzKCR0YWdz
KTsNCiAgICAgICAgVHhwOjpnZXQoJ1xUZXh0cGF0dGVyblxUYWdcUmVnaXN0cnknKS0+cmVn
aXN0ZXJBdHRyKCdldGNfYXR0cicsIGltcGxvZGUoJywnLCAkYXR0cikpOw0KICAgICAgICAk
YXR0ciA9IGFycmF5X2ZpbGxfa2V5cygkYXR0ciwgZmFsc2UpOw0KICAgICAgICByZXR1cm47
DQogICAgfQ0KDQogICAgJGxhdHRzID0gbEF0dHMoJGF0dHIsICRhdHRzLCBmYWxzZSk7DQoN
CiAgICBmb3JlYWNoICgkbGF0dHMgYXMgJGF0ID0+ICR2YWwpIHsNCiAgICAgICAgaWYgKCR2
YWwgIT09IGZhbHNlKSB7DQogICAgICAgICAgICAkdGFnID0gZW1wdHkoJHRhZ3NbJGF0XSkg
PyAnXHcrJyA6ICR0YWdzWyRhdF07DQogICAgICAgICAgICAkcmVwbGFjZW1lbnQgPSAkdmFs
ID09PSAnJyA/ICcnIDogJyAnLiRhdC4oJHZhbCA9PT0gdHJ1ZSA/ICcnIDogJz0iJy50eHBz
cGVjaWFsY2hhcnMoJHZhbCkuJyInKTsNCiAgICAgICAgICAgICRhdCA9IHByZWdfcXVvdGUo
JGF0KTsNCg0KICAgICAgICAgICAgJHRoaW5nID0gcHJlZ19yZXBsYWNlKA0KICAgICAgICAg
ICAgICAgICdAPCgnLiR0YWcuJylcYigoPzooPyFccycuJGF0LidcPSkuKSopKCg/OlxzJy4k
YXQuJ1w9KD86IlteIl0qInxcJ1teXCddKlwnKSkqKShbXj5dKik+QGknLA0KICAgICAgICAg
ICAgICAgICc8JDEnLiRyZXBsYWNlbWVudC4nJDIkND4nLA0KICAgICAgICAgICAgICAgICR0
aGluZywgMQ0KICAgICAgICAgICAgKTsNCiAgICAgICAgfQ0KICAgIH0NCg0KICAgIHJldHVy
biAkdGhpbmc7DQp9DQoNCi8vIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KZXRjX2F0dHIobnVsbCwgbnVsbCwgdHJ1
ZSk7IjtzOjQ6InR5cGUiO3M6MToiMSI7czo1OiJvcmRlciI7czoxOiI1IjtzOjU6ImZsYWdz
IjtzOjE6IjAiO3M6NDoiaGVscCI7czowOiIiO3M6MzoibWQ1IjtzOjMyOiIwMTFiMGI3NDg0
YjhmZmExYTY4ZGI5N2E0OGM0OTg5MiI7fQ==

It enables rel, style and title HTML attributes in most tags that don’t use them natively. Rough around the edges, though.

Offline

#9 2018-11-14 16:58:08

jakob
Admin
From: Germany
Registered: 2005-01-20
Posts: 4,578
Website

Re: Small glitch in article navigation markup somewhere?

Nice! I’ve not looked at it but I guess that uses the same register_attr mechanism you once showed me for a possible lang attribute?

Makes me wonder whether a similar thing for aria-* would be possible?

And perhaps even data too, though maybe that one is a bit more complex because the attribute itself carries a varying name?


TXP Builders – finely-crafted code, design and txp

Offline

#10 2018-11-14 17:06:36

etc
Developer
Registered: 2010-11-11
Posts: 5,028
Website GitHub

Re: Small glitch in article navigation markup somewhere?

jakob wrote #315230:

Nice! I’ve not looked at it but I guess that uses the same register_attr mechanism you once showed me for a possible lang attribute?

Makes me wonder whether a similar thing for aria-* would be possible?

Yes, register_attr and quick-n-dirty replacements. Adding new attributes is just a matter of modifying

static $tags = array('rel' => 'a|area|link', 'style' => null, 'title' => null)

in the plugin code.

And perhaps even data too, though maybe that one is a bit more complex because the attribute itself carries a varying name?

Yes, this is more complex, we can not register global attributes by their regex.

Offline

Board footer

Powered by FluxBB