Go to main content

Textpattern CMS support forum

You are not logged in. Register | Login | Help

  1. Index
  2. » Core development
  3. » Dev news

#121 2020-02-04 14:33:37

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

Re: Dev news

gaekwad wrote #321507:

Seriously, we’re gonna need at least a year to document all the hidden gems in Textpattern.

The opposite direction would be an electoral program.

Offline

#122 2020-02-04 17:00:37

gaekwad
Server grease monkey
From: People's Republic of Cornwall
Registered: 2005-11-19
Posts: 4,296
GitHub

Re: Dev news

Every so often, I wonder how useful it would be to have a scheduled Textpattern tag focus, say one tag per week, and the collective knowledge / experience of people here work on documenting the things that might not be commonly known. Examples, explanations, that sort of thing.

Offline

#123 2020-02-04 18:05:22

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 11,475
Website GitHub

Re: Dev news

Very useful, I expect. Stuff gets buried in the forum so if we transferred those examples to tag docs or Txp Tips, it increases visibility and usefulness.

Tangentially, we need to fix up the tag builder with the new attributes. Although not vital, it’d be nice to add them, if they apply. I can probably do that in the next day or so unless someone gets to it first.


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

#124 2020-02-04 18:16:02

colak
Admin
From: Cyprus
Registered: 2004-11-20
Posts: 9,096
Website GitHub Mastodon Twitter

Re: Dev news

Bloke wrote #321510:

Very useful, I expect. Stuff gets buried in the forum so if we transferred those examples to tag docs or Txp Tips, it increases visibility and usefulness.

If others agree I would include in the docs either Julian’s (his edit at the end of the post) or Oleg’s responces to a question which I feel that it will be asked again at some point in the future.


Yiannis
——————————
NeMe | hblack.art | EMAP | A Sea change | Toolkit of Care
I do my best editing after I click on the submit button.

Offline

#125 2020-02-04 22:27:00

phiw13
Plugin Author
From: Japan
Registered: 2004-02-27
Posts: 3,243
Website

Re: Dev news

gaekwad wrote #321509:

Every so often, I wonder how useful it would be to have a scheduled Textpattern tag focus, say one tag per week, and the collective knowledge / experience of people here work on documenting the things that might not be commonly known. Examples, explanations, that sort of thing.

Useful, I am sure. Sometimes people find interesting ways to do things with the standard tags, and sometimes mentioned in the forums, deep down a forum thread, or maybe document it in an obscure blog post.


Where is that emoji for a solar powered submarine when you need it ?
Sand space – admin theme for Textpattern

Offline

#126 2020-02-05 07:11:53

philwareham
Core designer
From: Haslemere, Surrey, UK
Registered: 2009-06-11
Posts: 3,564
Website GitHub Mastodon

Re: Dev news

Yeah I’d like to see the new pagination methods in a blog post – would be good to know.

Offline

#127 2020-02-05 10:50:30

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

Re: Dev news

You can test this code (in any place) to get the main ideas:

<txp:pages pg="page" total="100" evaluate="2,6,4">
    <nav>
        <txp:newer showalways>&laquo;</txp:newer>
        <txp:newer shift><txp:yield item="page" /></txp:newer>
        <txp:newer shift="-2" link="">...</txp:newer>
        <txp:pages total shift="2" break=" "><txp:yield item="page" /></txp:pages>
        <txp:older shift="-2" link="">...</txp:older>
        <txp:older shift><txp:yield item="page" /></txp:older>
        <txp:older showalways>&raquo;</txp:older>
    </nav>
</txp:pages>

It will generate nav bar for 100 links numbered by page URL parameter: ?page=1 etc.

< 1 ... 5 6 7 8 9 ... 100 >

Explanations:

  • <txp:pages pg="page" total="100">...</txp:pages> sets the number of pages and page URL parameter (needed only for custom pagination).
  • <txp:newer shift /> points to the first page, <txp:older shift /> to the last one.
  • <txp:newer shift="-2"/ > points to the 2nd page from the end of ‘newer’ direction, i.e. the second page. Similarly, <txp:older shift="-2" /> points to the last - 1 page.
  • <txp:pages total shift="2" /> outputs n-2, n-1, n, n+1, n+2 links, adjusting the output if n is close to start/end.
  • <txp:yield item="page" /> outputs processed page numbers.
  • link and showalways attributes are self-explanatory.

Now, why evaluate is needed? Suppose that there are only three pages and we are on the third one. Tag by tag, this block would output < 1 ... 1 2 3 3 > which is obviously not desired. To fix it, these tags (with few exceptions) are instructed not to output already shown pages. Since txp processes tags downwards, we thus get < 1 ... 3 > which is better but not ideal yet, because we expect 2 in place of .... The problem is that <txp:newer shift="-2" /> is processed before <txp:pages total shift="2" /> and ‘shows’ the second page. The solution is to alter the processing order via evaluate="2,6,4" attribute, which will first process the 2nd tag (<txp:newer shift />), then the 6th one (<txp:older shift />), followed by the 4th (<txp:pages total shift="2" />) and finally all the others.

Offline

#128 2020-02-05 11:09:56

philwareham
Core designer
From: Haslemere, Surrey, UK
Registered: 2009-06-11
Posts: 3,564
Website GitHub Mastodon

Re: Dev news

I’ve sprinkled some accessibility attributes into Oleg’s example above (you can change "Blog navigation" to whatever description you prefer):

<txp:pages pg="page" total="100" evaluate="2,6,4">
    <nav aria-label="Blog navigation">
        <txp:newer showalways><span aria-label="Go to previous page">&laquo;</span></txp:newer>
        <txp:newer shift><span aria-label="Go to first page"><txp:yield item="page" /></span></txp:newer>
        <txp:newer shift="-2" link=""><span role="separator" aria-label="More pages">…</span></txp:newer>
        <txp:pages total shift="2" break=" "><span aria-label="Go to page <txp:yield item="page" />"><txp:yield item="page" /></span></txp:pages>
        <txp:older shift="-2" link=""><span role="separator" aria-label="More pages">…</span></txp:older>
        <txp:older shift><span aria-label="Go to last page"><txp:yield item="page" /></span></txp:older>
        <txp:older showalways><span aria-label="Go to next page">&raquo;</span></txp:older>
    </nav>
</txp:pages>

Offline

#129 2020-02-05 13:19:07

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 11,475
Website GitHub

Re: Dev news

I love this!

I’m still gonna have to play with this newer/older stuff to get my head round it, and also to try it alongside regular use of newer/older to compare. Feels like it’s almost ready for prime time.

One thing I was interested in exploring with the above example, was to make the ellipses do something. A common issue with these types of navigation construct is that you’re somewhere in the list and want to move along slightly more quickly, but you’re limited to jumping to either end, or to two either side of the page you’re on, maximum. This makes iterating pages slower than it could be.

So I wondered if the ellipses could jump an entire set so if you’re showing:

< 1 ... 5 6 7 8 9 ... 100 >

then clicking the rightmost ellipses would reveal:

< 1 ... 10 11 12 13 14 ... 100 >

Through judicial use of the shift attribute to offset from “the current page” of <txp:pages> rather from “either end of the list”, we get this:

<txp:pages total="100" evaluate="2,6,4">
    <nav>
        <txp:newer showalways>&laquo;</txp:newer>
        <txp:newer shift><txp:yield item="page" /></txp:newer>
        <txp:pages shift="-5">...</txp:pages>
        <txp:pages total shift="2" break=" "><txp:yield item="page" /></txp:pages>
        <txp:pages shift="5">...</txp:pages>
        <txp:older shift><txp:yield item="page" /></txp:older>
        <txp:older showalways>&raquo;</txp:older>
    </nav>
</txp:pages>

Notice I’ve dropped the pg attribute because I was paginating a regular article list on my site so wanted the standard ?pg=. Works a treat!

I am, however, intrigued by the total attribute. I have 28 pages of articles on my test site, built up over time. The pagination works nicely to jump around the pages fairly quickly. If I set total="100" in the outer <txp:pages> tag, when I’m on (say) page 21, I get:

 « 1 ... 19 20 21 22 23 ... 28 »

No matter what value I set for total I get the same output – even if I use total="1", presumably because Txp knows I have 28 pages and ignores the attribute. I thought it might be some maximum or something. However, if I omit the total, I get this:

« ... 19 20 21 22 23 ... 28 »

Notice the link to page ‘1’ is missing. Bug? Or by design? Is total required to set things up, even if it’s ignored?

So I went a bit further. I was curious why you needed to set the valueless total attribute in the central <txp:pages> tag. Turns out it’s vital. But why? It doesn’t seem to set up the ‘current’ page because if I omit the total from the central <txp:pages> tag, I get this when I’m on page 21:

 « 1 ... 23 ... 28 » 

i.e. it’s added ‘2’ to the current page and made a link to it. Why does total do this? Is it required for the yield attribute to function properly?

If I also omit the total from the outer tag, the ‘1’ link disappears again, as it did before.

I presume there’s a functional reason why the total is needed, I just can’t figure out from a logical end-user perspective why it needs to be present for the tag to work, when the surrounding older and newer tags – and indeed the <txp:pages> tags for the ellipses – don’t.

EDIT: also, with <txp:yield item="page">, it would be handy to know what other items we could output here when we document this. There appears to be a link between the URL attribute ‘page’ and the yield item in this example, when there isn’t. The yield name MUST be page regardless of what is used in the URL pagination, so maybe we should choose a different URL var just to make it clear.

EDIT 2: Interestingly, changing my central <txp:pages> tag thus: Ignore this and see forum.textpattern.com/viewtopic.php?pid=321523#p321523

<txp:pages total shift="3" break=" "><txp:yield item="page" /></txp:pages>

Results in a curious output when I near the extremities of the pagination.

On page 22: « 1 ... 19 20 21 22 23 24 25 ... 28 » OK
On page 23: « 1 ... 20 21 22 23 24 25 26 28 » Missing page 27 or ellipses
On page 24: « 1 ... 21 22 23 24 25 26 27 28 » OK
On page 25: « 1 ... 22 23 24 25 26 27 28 » OK
On page 26: « 1 ... 22 23 24 25 26 27 28 » OK, but why is the lower limit not 21?
On page 27: « 1 22 23 24 25 26 27 28 » Urk? No lower ellipses, and still 22 lower limit?

Last edited by Bloke (2020-02-05 13:46:10)


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

#130 2020-02-05 14:08:08

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

Re: Dev news

Without pg attribute <txp:pages /> uses the current one, which is the default pg and then total defaults to $thispage['nimPages'] too. Try <txp:pages pg="pg" total="100" /> instead.

Offline

#131 2020-02-05 14:26:46

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 11,475
Website GitHub

Re: Dev news

etc wrote #321522:

Try <txp:pages pg="pg" total="100" /> instead.

Okay, that makes sense and is important info to go in the docs, thanks. Doing that makes the page extremity whatever I set, even if it’s beyond the number of pages I have, and fixes the missing ‘1’ thing. That’s cool.

So for people that are using this to paginate regular Txp articles, they should always use the pg="pg" attribute, and either:

a) omit the outer total attribute to let Txp calculate the maximum.
b) use the outer total attribute if they want a fixed maximum number of pages.

That clears one thing up. Just the thing about the total in the central <txp:pages> tag to go.

Edit: The ‘Edit 2’ in my post above was me being stupid. Altering the step in the central <txp:pages> tag requires an adjustment in the ellipses tags either side of it to balance it. so they needed to be:

        <txp:pages shift="-7">...</txp:pages>
        <txp:pages total shift="3" break=" "><txp:yield item="page" /></txp:pages>
        <txp:pages shift="7">...</txp:pages>

Sorry for the false info.

Last edited by Bloke (2020-02-05 14:54:59)


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

#132 2020-02-05 16:52:43

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

Re: Dev news

Bloke wrote #321523:

So for people that are using this to paginate regular Txp articles, they should always use the pg="pg" attribute, and either:

a) omit the outer total attribute to let Txp calculate the maximum.
b) use the outer total attribute if they want a fixed maximum number of pages.

Not exactly, sorry. Explicitly setting pg="pg" does not reset total, it acts like any other pg value, leaving you the freedom to abuse it (and create meaningless txp links). To reset to defaults, use valueless pg (then total will be ignored): <txp:pages pg />.

That clears one thing up. Just the thing about the total in the central <txp:pages> tag to go.

You’ll probably need to adjust the ellipses shift, to avoid it prematurely disappear when close to the extremities: shift = min (7, current - 2) or something like that. The total number of remaining pages is given by <txp:newer/older total />.

Offline

  1. Index
  2. » Core development
  3. » Dev news

Board footer

Powered by FluxBB