There seems to be a problem when you remove the next link by setting the next_link parameter to nil on the will_paginate method.

It seems to result in the link for the last page being repeated.

For example:
« Previous 1 2 2

Reported by Ron Valente with mislav-will_paginate v2.3.11

466992 rows in set (0.97 sec)

>> h = Host.paginate :per_page => 15, :page => 1

SystemStackError: stack level too deep

Ruby Versions - Same Error On Both
1. ruby 1.8.7 (2009-06-12 patchlevel 174) [i686-darwin10]
2. ruby 1.9.1p129 (2009-05-12 revision 23412) [i386-darwin9]

Hi,

Here is the requests generated and showing the issue :

Author Load (1.3ms) SELECT users., COUNT(1) AS count FROM users INNER JOIN posts ON posts.author_id = users.id WHERE ( (users.type = 'Author' ) ) GROUP BY posts.author_id LIMIT 2, 2 SQL (0.2ms) SELECT count() AS count_all FROM users INNER JOIN posts ON posts.author_id = users.id WHERE ( (users.type = 'Author' ) )

In this case the GROUP BY as been removed but should have been kept to return the right number of results.

Hi,

Here we go with the second issue regarding the counting request :

SELECT count(users.*, addresses.full_address) AS count_users_all_addresses_full_address FROM ...

This case actually breaks.
Looks like the select option could have been replaced to produce the following request and work as expected :

SELECT COUNT(1) AS count_all FROM ...

Right now I work around this issue using the :count option of paginate but doesn't feel natural.
Let me know if you need further details.

P.S. : a BIG thanks for this wonderful gem.

Hello mislav,

Is fully I18n support in todo list of will_paginate?

I'm using will_paginate with in some sites which needs to be internationalized.

Thanks

Hi,
The paginate method defaults to 1 the parameter :page if this one is false or nil. This parameter can also be an empty string. It could be good to defaults :page to 1 also in this case. We encountered this problem when our site is crawled by google bots.

Here is my patch to this bug
http://gist.github.com/218537

first of all thanks for sharing this great stuff. I am using this, amongst others, to skip through a stock of input forms of the same type. That means I am showing only 1 item per page and the user is able to jump or skip through the whole stock. To improve the visualisation I had to change your code of "page_entries_info" like that:

  if collection.length == 1
    %{Displaying #{entry_name} <b>%d</b> of <b>%d</b> in total} % [
      collection.offset + 1,
      collection.total_entries
    ]
  else
    %{Displaying #{entry_name.pluralize} <b>%d&nbsp;-&nbsp;%d</b> of <b>%d</b> in total} % [
      collection.offset + 1,
      collection.offset + collection.length,
      collection.total_entries
    ]
  end

Maybe you like to change this as well for others.

The default entry_name logic works better if you change the sub() call to gsub(). Then it handles classes with multiple underscores gracefully.

entry_name = options[:entry_name] ||
  (collection.empty?? 'entry' : collection.first.class.name.underscore.gsub('_', ' '))

Since will_paginate's method_missing takes control over any method that starts with the word "paginate", any custom methods that start with that word will not be found with respond_to?

A work around for now is to rename the method to not use the word "paginate" in the front.

http://github.com/enriquez/will_paginate/commit/26e5cf73f37338a8b7c78abddaccc22910d839ff