Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: soo_page_numbers: page counting and navigation widgets
jsoo wrote:
That is a very slick site!
I’m not familiar with chh_keywords, but did notice this note about its issues with clean URLs. Have you tried experimenting with any of those suggestions?
It is a little while that I brought up this issue (thanks for the kudos!), but I haven’t yet been able to fix it. On a new site that I am building I am using <txp:article />
with customfieldname="value"
. It gives me the same problem:
When a list of articles is created using keywords stored in custom fields, soo_page_numbers gives links to more pages than there actually are for that particular keyword. So you end up with pagination linking to pages that contain no articles.
Is this my set-up in some way, or an issue with the plugin?
• Old Photos of Japan – Japan in the 1850s~1960s (100% txp)
• MeijiShowa – Stock photos of Japan in the 1850s~1960s (100% txp)
• JapaneseStreets.com – Japanese street fashion (mostly txp)
Offline
Re: soo_page_numbers: page counting and navigation widgets
I didn’t realize it when I posted my previous comment, but my issue appears to be the same as the one that John Stephens describes in the post above mine, albeit for authors instead of custom fields.
So this appears to be a problem in the code?
• Old Photos of Japan – Japan in the 1850s~1960s (100% txp)
• MeijiShowa – Stock photos of Japan in the 1850s~1960s (100% txp)
• JapaneseStreets.com – Japanese street fashion (mostly txp)
Offline
Re: soo_page_numbers: page counting and navigation widgets
John, Kjeld: apologies for the delay; I’ve been traveling. In some very quick testing on author searches I am unable to duplicate this error. I haven’t tried the custom field setup yet.
All of the calculations this plugin does are based on the $thispage
global, particularly $thispage['numPages']
. Txp sets this in the doArticles()
function, the main function called by the article
tag.
Are there any other article tags, or other plugin tags, that could be changing the value of this variable?
You can check the value of $thispage['numPages']
by adding this to your page template, just above the soo_page_links
tag:
<txp:php>global $thispage;dmp($thispage);</txp:php>
(You can enclose this in HTML comment delimiters if you don’t want it to pollute live pages.)
Code is topiary
Offline
Re: soo_page_numbers: page counting and navigation widgets
Thanks for your reply, Jeff!
Here’s the output for the unfiltered articles list:
array (
'pg' => 1,
'numPages' => 1,
's' => 'articles',
'c' => '',
'grand_total' => '10',
'total' => 10,
)
At this point, the site has only ten articles— and the “limit” variable is set to 30, so it is not paginating.
Here’s the output of the same dump on a page of articles in the same section filtered by an author URL-variable:
array (
'pg' => 1,
'numPages' => 2,
's' => 'articles',
'c' => '',
'grand_total' => '2',
'total' => 2,
)
soo_page_links displays links to a second page of results, but there is only one article associated with the current author, so I don’t know why Textpattern thinks there should be multiple pages of results.
I hope this helps!
Offline
Re: soo_page_numbers: page counting and navigation widgets
Hi Jeff, thanks.
I discovered that on both sites the problem resulted from having an article tag containing a pgonly="1"
attribute on the page. Like this:
<txp:article limit="1" pgonly="1" searchall="0" />
The problem vanished after removing this tag. The drawback is that I can’t give a count of the number of articles found…
Your piece of code aided me in finally figuring this out. Thanks.
Maybe the help file of the soo_page_numbers plugin should warn people that the plugin can’t count the correct number of pages for articles filtered by custom field (and author, perhaps, John?) if there’s an article tag with a pgonly
attribute on the page.
Once again, great plugin, Jeff!
• Old Photos of Japan – Japan in the 1850s~1960s (100% txp)
• MeijiShowa – Stock photos of Japan in the 1850s~1960s (100% txp)
• JapaneseStreets.com – Japanese street fashion (mostly txp)
Offline
Re: soo_page_numbers: page counting and navigation widgets
I’m glad you found the independent variable in your case, Kjeld!
To clarify, I do not have a single instance of a pgonly
attribute on this entire site.
Offline
Re: soo_page_numbers: page counting and navigation widgets
johnstephens wrote:
To clarify, I do not have a single instance of a
pgonly
attribute on this entire site.
It looks like you have a sticky article on your page, John, or a custom article tag, or am I mistaken? Anyway, it appears like you have two article tags on your page. Maybe that’s where the clash happens on your page?
• Old Photos of Japan – Japan in the 1850s~1960s (100% txp)
• MeijiShowa – Stock photos of Japan in the 1850s~1960s (100% txp)
• JapaneseStreets.com – Japanese street fashion (mostly txp)
Offline
Re: soo_page_numbers: page counting and navigation widgets
Perhaps in my case the problem lay not in pgonly
attribute, but in the fact there were two article tags on the page…
• Old Photos of Japan – Japan in the 1850s~1960s (100% txp)
• MeijiShowa – Stock photos of Japan in the 1850s~1960s (100% txp)
• JapaneseStreets.com – Japanese street fashion (mostly txp)
Offline
Re: soo_page_numbers: page counting and navigation widgets
It’s true that I use multiple article tags on each page, and if soo_pn doesn’t work with that I need another pagination method.
Offline
Re: soo_page_numbers: page counting and navigation widgets
OK, here’s a little more explanation that might help. As Txp goes through the page template, when it hits a soo_page_links
tag, soo_page_links
checks to see whether or not the $thispage
global has been set. If it has, soo_page_links
produces its output based on the current values in $thispage
at that point.
If, however, $thispage
hasn’t been set yet, i.e. soo_page_links
is above all article
tags in the page template, then soo_page_links
makes use of Txp’s second parse()
pass. This is so you can have the page links appear before the article output, without the need for an empty article
tag with pgonly
set.
But if there are multiple Edit: looking more closely I see this isn’t true — article
tags on the page, and soo_page_links
is above all of them, then soo_page_links
will always end up with $thispage
values from the last article
tag. This is true no matter how the pgonly
attribute is set in any of those article
tags.$thispage
does not get overridden by subsequent article
tags.
So when using multiple Edit: Hence, it’s crucial that the first non-custom, non-sticky article
tags, it is essential to place the soo_page_links
tag after the one you want to paginate and before any others.article
tag on the page is the one you want to paginate.
I hope that makes sense, and I will see about adding a similar explanation to the plugin help.
Last edited by jsoo (2010-05-26 17:55:12)
Code is topiary
Offline
Re: soo_page_numbers: page counting and navigation widgets
Thanks, Jeff. So the clash was indeed in the multiple article tags as I suspected. Glad that’s clear now. Good luck, John! I hope you can make it work.
• Old Photos of Japan – Japan in the 1850s~1960s (100% txp)
• MeijiShowa – Stock photos of Japan in the 1850s~1960s (100% txp)
• JapaneseStreets.com – Japanese street fashion (mostly txp)
Offline
Re: soo_page_numbers: page counting and navigation widgets
I don’t think that applies to what I’m seeing— I have soo_page_links nested in the article tag I want to paginate— like this:
<txp:article limit="30">
... Article title and other info ...
<txp:if_last_article>
<txp:soo_page_links
active_class="active"
break="li"
html_id="pagination-menu"
wraptag="ul"/><txp:else/><hr/>
</txp:if_last_article>
</txp:article>
Does that make sense? From what you’ve said, it seem’s like soo_page_links should be getting $thispage
from the context of the relevant article list, right?
The other article lists on this page come after soo_page_links.
Offline