Add Page Number token

It is something I'd like to ad - however... What if you have a page with TWO pagers on it?

Eg, a panel page and the panel has 2 paged views.

The 'issue' is easy to solve if any given page only has 1 pager on it... But what if you have a page with two separate pages on it. In my example, say you defined a panel which has 2 views in it. Each view has its own pager. What if we set View 1 to be Page 2 and View 2 to be page 5.... What should the title be? How would we get a simple and effective interface to configure the title for something like this.

I agree that the "two pagers per page" problem is a hard problem to solve, but it's not very common. Why not just focus initially on the simple cases like the node/ pager, forum pagers, blog pager, tracker pager. ?

How about this attempt? patch sets a token value for the pager-page if set.

Ahh adding it as a Token isn't a bad idea! However, for security, Instead of...

  $values['pager-page'] = $_REQUEST['page'] ? t('Page') .' '. $_REQUEST['page'] : '' ;

I'd recommend something like:

  $values['pager-page'] = $_REQUEST['page'] ? t('Page @page', array('@page' => $_REQUEST['page']) : '' ;

This does two things:

1. It allows easy translation of the title
2. It also protects the code from malicious gits. The code you provided simply printed whatever was in the $_REQUEST into (in this case) the in the of the page. This could quite easily allow XSS. I believe this meethod should stop it as any 'variables' starting with an '@' get run through check_plain.

Does else anyone have any thoughts on this?

works for me...i suppose you could even force a check for is_numeric to be
even more complete.

Do you know what would be REALLY nice...

Another module which took potential arguments from the URL (eg, 'page') and provided them as tokens :-)

I encoutered this problem on my site I have hundreds of duplicate pages on google because of it... So a big +1 for this from me.

A nice feature would be to be ale to build custom titles by inserting tokens related to the pager you are using : for examle for taxonomy pagers, I would include the taxonomy terms, forum could include the forum name, etc...

Looking forward to a new patch to help and test this.

Patchak

There is already a token for the term name ([cat] I believe)... The problem is getting Page Title to be able to identify a taxonomy_term or forum page... PT2-dev has code in it for working with non-node page titles.

My theory for the page title is to write a tiny contrib module which provides a [page_numer] token... This would allow you to define a default page title as [title][page_number]. The [page_number] token could provide a response which has a space at the beginning (or a colon... or anything really?) to separate it from the rest of the content...

@nicholasThompson - this seems general enough that it belongs in token core as a global token. If you agree please move this issue there.

The other problem with this patch is that it puts "Page " into the output. In general tokens should be the most simple thing possible - e.g. the number. If someone wants to have the output like "Page #number" then they could use the pattern "Page [page-number]"

If you agree please move this issue there

I'd be happy for this to be in Token Core. Two things:
1) I dont have permission to shift issues to different queue's...
2) Do you need a hand with this?

In the “Edit issue settings”, just select a different project from the pull-down menu when Posting a new comment.

This will need to back-ported to 5.x as well.

@nicholasThompson
1) yeah, what JohnAlbin said
2) always!

Ooops - I just realised about the Project drop down in the comment posting :-) (I cant see an Edit Issue Settings section)...

I'll try to get a patch for Token done :-)

Hi guys,
this path seems not not work on 5.x version of Drupal.

Any issue for the problem for this version?

Thanks,
Bencio

Is there any update on this? Is the page number token in yet?

Is it possible to use it with views?

Thanks,
Patchak

Yes, what are news about this?

(Just for info, It lacks a parenthesis in your example.)

New patch with your suggestion.

I user luron patch for page_title, and it works like a charm with page_title v2 per d6.

I personally - as stated above - think that this patch should head into Token rather than Page Title. The concept of tokens is bigger than just Page Title (far bigger) so making Page Title a prerequisite for having the Page token is a little unfair on users... imho.

I have attached a 2 line modification patch which adds a page-number token to the global array.

This is particularly useful when Page Title needs to handle unique page titles for listing pages such as Views.

Any chance this could get committed? I'm running it on www.thingy-ma-jig.co.uk with the latest DRUPAL-6--2 release of Page Title. If you go to the frontpage you get the normal frontpage title but if you got to page 2, you get an appended string pattern which uses the [page-number] token provided by this patch.

Updating status... Previous post failed to do so for some reason.

For some strange reason - my patch seems to break token.module. It's not a syntax problem - but when I re-apply that patch to the same version of token on another site on the same server that generated the patch... I get:

# warning: include_once(./sites/mysite.co.uk/modules/token/token.module) [function.include-once]: failed to open stream: Permission denied in /var/www/html/mysite.co.uk/drupal/includes/bootstrap.inc on line 611.
#  warning: include_once() [function.include]: Failed opening './sites/mysite.co.uk/modules/token/token.module' for inclusion (include_path='.:/usr/share/pear:/usr/share/php') in /var/www/html/mysite.co.uk/drupal/includes/bootstrap.inc on line 611.

Very odd!

EDIT: I Cannot explain that error - there must be a bug with my patch binary.. it works fine if I manually apply it!

To manually apply it..
... add the following to the end of the array in the function token_token_list (after the site-date-d entry):

$values['page-number']     = check_plain(1 + (int)$_REQUEST['page']);

... and add the following to the end of the array in the function token_token_values (again, after the site-date-d entry):

$tokens['global']['page-number']     = t('The current page number for paged lists');

I've just tested this patch on my development virtual machine and it worked perfectly. My patch binary on my webserver must be broken...

The same patch worked on DRUPAL-5 too... It outputted this message:

Hunk #1 succeeded at 91 (offset -8 lines).

But when I checked the file, the two lines were in the correct place.

Greggles - could this please get committed as it's a requirement for a new feature in Page Title. I did consider putting it in Page Title itself, however I feel that such a general token could be useful for other modules to have access to without Page Title being a prerequisite...

Nowhere else in core do we use $_REQUEST['page'] - why not $_GET['page'] ?

check_plaining something that's been cast to (int) is unnecessary. We can just cast as an int and call it good.

I'm going to make a new release soon...if you can test dev to make sure it's good that will make me more likely to commit this. Bumping priority, not as much :p

Those changes look sensible - I'll run a test now on DRUPAL-6--1 and DRUPAL-5....

I've been looking through the pager_query function and it looks like $_GET['page'] could be a comma separated numbers as a string if there is more than 1 page...

Thoughts... Imagine we have a page with multiple pagers on it (in this example, assume 3 or more). Imagine we have selected Page 2, 3 and 7 for these pagers. In this case, do you think [page-number] should contain:
a) the string "2,3,7"
b) the string "2, 3 and 7" (or "2, 3 & 7").
c) just the first page listed (in this case "2").

Any thoughts?

I say 2. That's how we handle multiple terms/vocabs on a node.

If someone wants a token for each they should create a custom module.

Attached is a patch which does option C (from post #30).

If there is a comma present in $_GET['page'], a substr() will be applied to grab the first digit, otherwise the $_GET['page'] will be used. I also added a short comment to explain what is happening in the line.

Cheers,
Nick

This seems slightly difficult to read, but since I'm the dumbest guy who works on this module it shouldn't be a problem ;)

Committed to 5.x http://drupal.org/cvs?commit=217380 and 6.x http://drupal.org/cvs?commit=217378

Thanks for providing both versions.

On the first page is $_GET['page'] NULL therefore its better to check this. see patch.

Thanks, Razorraser, http://drupal.org/cvs?commit=219284 6.x and http://drupal.org/cvs?commit=219284 5.x fixed!

Re-opening to ensure this gets added to the D7 version.

Patch up for review that adds a 'current page' token type and the [current-page:page-number] token for basic functionality, although it does need testing for it.

Revised patch that also adds current page alias and URL.

I fixed the one test failed by the testbot and I also tested locally, so committing to CVS!
http://drupal.org/cvs?commit=395840

FYI
For Drupal 6 support
http://drupal.org/project/ptoken

@podarok: You do know that Token for D6 provides a [current-page-number] token right?

Is it global token?
I can`t find it in page_title global context
Possibly I have to use developpment version ?

See: http://drupalcode.org/project/token.git/blob/a10367bc7e6e1f4b6031ba753d4...

Unfortunately filter_input() doesn't have a fallback to work either with query string or clean urls, i.e

/node/1?page=10 vs /node/page/10/0

I am adding a new patch that implements it using the Drupal 7 way, using pager_find_page() found in /includes/pager.inc

Changing the status, would be nice if someone can test and approve it.

Haven't tested it - but logically it looks fine.

It looks like a variant of my patch for D6 ((#224262-32]) which used $_GET) was committed and Dave Reid's patch for D7 (#224262-38]) used filter_input - what is the advantage of this function? We still cast to (int) later anyway... And D7 core uses $_GET...

Unfortunately filter_input() doesn't have a fallback to work either with query string or clean urls, i.e

/node/1?page=10 vs /node/page/10/0

filter_input takes it's variables directly from $_GET in this case. Not sure what you're talking about there. And paths like node/page/10/0 aren't actually valid pager paths in core, so I assume this is coming from a module or rewrite rule?

We have views creating URL that do not contains the page in the query string i.e. /list/page/10/0
I tried to use the token [current-page] to appear in the title, but it comes always as page 1 no matter which page I am.
As I mentioned earlier, it looks like filter_input() can only get the value of the page is the argument is in the query string.
With the fix that I proposed, using the D7 function pager_find_page() it works well.

@marcelovani - well it would, pagenation in Core is handled by "page=N" in the query string (as opposed to entirely new URLs).

Arguably, a new URL (by appending /N to the View) is incorrect. The 2nd page is not a new resource, is the same resource, just advancing through a list.

pager_find_page() gets its value from the query string as well. How would this function suddenly work differently?

Yes, we have custom modules that does the pagination that way.

We use similar logic as Smart Paging
http://drupalcode.org/project/smart_paging.git/blob/ba09bed:/smart_pagin...

The page number is still passed via GET in the query string, but NOT in the URL.

marcelovani, I've really worked with your patch in #48 in combination with Meta Tags dev (Add a customizable pager token to extend the normal Token pager), and something is not successful for me. I can get the [current-page:page-number] token to work on plain nodes, but when it comes to Views pages, the token is not activated. We are working on a [metatag:pager] token that would replace it at the link above, so I do not need a fix. I just wanted to report this. Thanks for your work.

@Dave Reid
[current-page-number] sucks,
$values['current-page-number'] = (int) $page + 1;
Using it you can't add stuff like "page 32" - when page number is missing you will get "page " string. So for D6 http://drupal.org/project/ptoken is the way to go.

What is the status on getting this patch for Token committed? I would like to use it with the Smart Paging module.

This may be crude but in token.tokens.inc line 677 I changed the case statement to this to get it to work.

        case 'page-number':
         
		if ($_GET['page']){
			$dapage = intval($_GET['page']) + 1;
		 	$replacements[$original] = '| Page '.$dapage;
		 }else{
			 $replacements[$original] = '';
		 }
          break;
     

This works great with the newest MetaTag 7.x-1.0-beta1

I can confirm that patch #48 by @marcelovani causes page numbers to be displayed correctly in our Views page title when using the Token, Metatag, Metatag Views, and Smart Paging modules. Without the patch, there is no value rendered for the [current-page:page-number] token. Module versions in our setup are as follows:

Drupal 7.34
Token 7.x-1.5
Metatag 7.x-1.4
Smart Paging 7.x-2.1
Views 7.x-3.8

#48 worked for me to get [current-page:page-number] work properly in Metatag module.

#48 worked for me! Thanks!

I can confirm that patch #48 by @marcelovani causes page numbers to be displayed correctly...

#48 worked for me to get [current-page:page-number] work properly in Metatag module

#48 worked for me!

Does this feature request need any additional work before changing to RTBC?

Not as far as I know... we've been using it for 4 years without issue.

Have moved it to RTBC, and if someone wants to change it back they can.

This patch still applies cleanly to the latest 7.x-1.8 release.