Hey, I posted this on stackoverflow but was hoping to make this bug a little shallower by adding a few more eyeballs. I am running will_paginate 2.3.7.
Looks like a bug in very old version of the gem. Please update "will_paginate" and try again. Uninstall any old will_paginate plugins that you might have
On Fri, Mar 19, 2010 at 01:54, sleepycat <blessedbyvirtuos...@gmail.com>wrote:
> Hey, I posted this on stackoverflow but was hoping to make this bug a > little shallower by adding a few more eyeballs. I am running > will_paginate 2.3.7.
> -- > You received this message because you are subscribed to the Google Groups > "will_paginate" group. > To post to this group, send email to will_paginate@googlegroups.com. > To unsubscribe from this group, send email to > will_paginate+unsubscribe@googlegroups.com<will_paginate%2Bunsubscribe@goog legroups.com> > . > For more options, visit this group at > http://groups.google.com/group/will_paginate?hl=en.
Hi Mislav, I updated the plugin, but it wasn't until I switched to the gem that the issue was resolved. Not sure what the difference might be. Anyway, thanks for responding. I've marked the question as solved on stackoverflow as well.
On Mar 21, 8:56 am, Mislav Marohnić <mislav.maroh...@gmail.com> wrote:
> Looks like a bug in very old version of the gem. Please update > "will_paginate" and try again. > Uninstall any old will_paginate plugins that you might have
> On Fri, Mar 19, 2010 at 01:54, sleepycat <blessedbyvirtuos...@gmail.com>wrote:
> > Hey, I posted this on stackoverflow but was hoping to make this bug a > > little shallower by adding a few more eyeballs. I am running > > will_paginate 2.3.7.
> > -- > > You received this message because you are subscribed to the Google Groups > > "will_paginate" group. > > To post to this group, send email to will_paginate@googlegroups.com. > > To unsubscribe from this group, send email to > > will_paginate+unsubscribe@googlegroups.com<will_paginate%2Bunsubscribe@goog legroups.com> > > . > > For more options, visit this group at > >http://groups.google.com/group/will_paginate?hl=en.
> Hi Mislav. > I thought I would resurrect this somewhat old thread. I am running the > latest will_paginate gem and once again I seem to be getting stuck on > page two again. > I am looking through the code and wanted to ask about > ViewHelpers#url_for
> I can't quite follow all thats going on in there but .sub "\0" seems > to be a reference to one of the global regex vars which appears to be > nil. Since it's nil its not substituting the page number. Am I reading > this right? Any thoughts on what might be going on here?
> On Mar 21, 7:56 am, Mislav Marohnić <mislav.maroh...@gmail.com> wrote: > > Looks like a bug in very old version of the gem. Please update > > "will_paginate" and try again. > > Uninstall any old will_paginate plugins that you might have
> > On Fri, Mar 19, 2010 at 01:54, sleepycat <blessedbyvirtuos...@gmail.com > >wrote:
> > > Hey, I posted this on stackoverflow but was hoping to make this bug a > > > little shallower by adding a few more eyeballs. I am running > > > will_paginate 2.3.7.
> > > For some reason my will_paginate collection is stuck on page 2. I have > > > the usual links the view helper provides except every page after page > > > one links tohttp://localhost:3000/ceo/gr_messages?page=2I have tried > > > to add the :order option with no luck. I have also ensured that the > > > request is a get as mentioned on this page: > > >http://wiki.github.com/mislav/will_paginate/simple-search
> > > There is a little more detail and some controller code posted here:
> > > -- > > > You received this message because you are subscribed to the Google > Groups > > > "will_paginate" group. > > > To post to this group, send email to will_paginate@googlegroups.com. > > > To unsubscribe from this group, send email to > > > will_paginate+unsubscribe@googlegroups.com<will_paginate%2Bunsubscribe@goog legroups.com> > <will_paginate%2Bunsubscribe@googlegroups.com<will_paginate%252Bunsubscribe @googlegroups.com>
> That is odd. Which version of Ruby? Are you doing anything unusual with
> routing?
> (Note I brought this discussion back to the mailing list)
> On Thu, Jul 22, 2010 at 06:54, sleepycat <blessedbyvirtuos...@gmail.com>wrote:
> > Hi Mislav.
> > I thought I would resurrect this somewhat old thread. I am running the
> > latest will_paginate gem and once again I seem to be getting stuck on
> > page two again.
> > I am looking through the code and wanted to ask about
> > ViewHelpers#url_for
> > I can't quite follow all thats going on in there but .sub "\0" seems
> > to be a reference to one of the global regex vars which appears to be
> > nil. Since it's nil its not substituting the page number. Am I reading
> > this right? Any thoughts on what might be going on here?
> > On Mar 21, 7:56 am, Mislav Marohnić <mislav.maroh...@gmail.com> wrote:
> > > Looks like a bug in very old version of the gem. Please update
> > > "will_paginate" and try again.
> > > Uninstall any old will_paginate plugins that you might have
> > > On Fri, Mar 19, 2010 at 01:54, sleepycat <blessedbyvirtuos...@gmail.com
> > >wrote:
> > > > Hey, I posted this on stackoverflow but was hoping to make this bug a
> > > > little shallower by adding a few more eyeballs. I am running
> > > > will_paginate 2.3.7.
> > > > For some reason my will_paginate collection is stuck on page 2. I have
> > > > the usual links the view helper provides except every page after page
> > > > one links tohttp://localhost:3000/ceo/gr_messages?page=2Ihave tried
> > > > to add the :order option with no luck. I have also ensured that the
> > > > request is a get as mentioned on this page:
> > > >http://wiki.github.com/mislav/will_paginate/simple-search
> > > > There is a little more detail and some controller code posted here:
> > > > --
> > > > You received this message because you are subscribed to the Google
> > Groups
> > > > "will_paginate" group.
> > > > To post to this group, send email to will_paginate@googlegroups.com.
> > > > To unsubscribe from this group, send email to
> > > > will_paginate+unsubscribe@googlegroups.com<will_paginate%2Bunsubscribe@goog legroups.com>
> > <will_paginate%2Bunsubscribe@googlegroups.com<will_paginate%252Bunsubscribe @googlegroups.com>
At the line you were currently at, this is not a bug. Will Paginate does a little optimization here in that it generates and caches a URL for page 2 regardless of the page number you're currently at (page 3 in your case). So what you debugged up to this point is all correct. It's only *a few lines after *that the number "2" in the cached URL string should be replaced with the page number for the pagination link currently being output: "4", "5", "6", and so on. Pagination link for the current page ("3" in your case) is never genererated because that's the current page, and there's no sense in linking to the current page.
I see you are proficient enough with the ruby debugger. Can you resume from that line and see what happens in next few lines? Your case is very strange; and I don't know what to make of it.
Hi Mislav. Here is some new stuff to chew on. I requested "http://
localhost:3000/ceo/gc_claimed_rewards?page=7" and ran it till
view_helpers.rb:346.
This is what is going on at that point. Hopefully you can see
something helpful in the output.
> At the line you were currently at, this is not a bug. Will Paginate does a
> little optimization here in that it generates and caches a URL for page 2
> regardless of the page number you're currently at (page 3 in your case). So
> what you debugged up to this point is all correct. It's only *a few lines
> after *that the number "2" in the cached URL string should be replaced with
> the page number for the pagination link currently being output: "4", "5",
> "6", and so on. Pagination link for the current page ("3" in your case) is
> never genererated because that's the current page, and there's no sense in
> linking to the current page.
> I see you are proficient enough with the ruby debugger. Can you resume from
> that line and see what happens in next few lines? Your case is very strange;
> and I don't know what to make of it.
I also stepped through the loop at line 346.
Nothing matched both conditions (char == '3' and url[i, 1] == '2') and
the $~ and $& values were never set.
> Hi Mislav. Here is some new stuff to chew on. I requested "http://
> localhost:3000/ceo/gc_claimed_rewards?page=7" and ran it till
> view_helpers.rb:346.
> This is what is going on at that point. Hopefully you can see
> something helpful in the output.
> > At the line you were currently at, this is not a bug. Will Paginate does a
> > little optimization here in that it generates and caches a URL for page 2
> > regardless of the page number you're currently at (page 3 in your case). So
> > what you debugged up to this point is all correct. It's only *a few lines
> > after *that the number "2" in the cached URL string should be replaced with
> > the page number for the pagination link currently being output: "4", "5",
> > "6", and so on. Pagination link for the current page ("3" in your case) is
> > never genererated because that's the current page, and there's no sense in
> > linking to the current page.
> > I see you are proficient enough with the ruby debugger. Can you resume from
> > that line and see what happens in next few lines? Your case is very strange;
> > and I don't know what to make of it.
Well, there's the problem. See the "page" parameter occurring twice? There should never be symbols present in this hash; will_paginate only works with strings at this point. The `stringified_merge` method takes care of that.
Because you have symbols here, something is wrong either with that method or with your app. Are you sure no plugins hook into and change will_paginate? No custom link renderers? Can you use the debugger to inspect how are the @url_params constructed? Thanks.
Ok, here goes.
I made another direct request for "http://localhost:3000/ceo/ gc_claimed_rewards?page=7" and I stepped through again in a painful
level of detail.
@url_params gets constructed in a pretty uneventful way. The
highlights are below.
Here is the line where my request for page 7 becomes a request for
page 2:
Then at 337 I took an exceedingly long tour through the Rails routing
system which thoughtfully turns your newly stringified keys and turns
them back into symbols.
So that is where the :page => 2 comes from.
As you can see above going into the call to url_for we had 6:
@url_params.inspect = {"action"=>"gc_claimed_rewards", "page"=>2,
"controller"=>"ceo"}
and coming out the other end: @url_params.inspect =
{:controller=>"ceo", :action=>"gc_claimed_rewards", :page=>2}
From there its pretty boring until we get to line 345 which adds back
in the stringified "page" with a value of 3.:
6: @url_params.inspect =
{:controller=>"ceo", :action=>"gc_claimed_rewards", :page=>2}
8: options.inspect =
[340, 349] in /usr/lib/ruby/gems/1.8/gems/will_paginate-2.3.14/lib/
will_paginate/view_helpers.rb
340 if complex
341 @url_string = url.sub(%r!((?:\?|&)#{CGI.escape
param_name}=)#{page}!, "\\1\0")
342 return url
343 else
344 @url_string = url
=> 345 @url_params[param_name] = 3
346
@template.url_for(@url_params).split(//).each_with_index do |char, i|
347 if char == '3' and url[i, 1] == '2'
348 @url_string[i] = "\0"
349 break
/usr/lib/ruby/gems/1.8/gems/will_paginate-2.3.14/lib/will_paginate/
view_helpers.rb:345
@url_params[param_name] = 3
(rdb:36) s+
6: @url_params.inspect =
{:controller=>"ceo", :action=>"gc_claimed_rewards", :page=>2}
8: options.inspect =
[372, 381] in /usr/lib/ruby/gems/1.8/gems/will_paginate-2.3.14/lib/
will_paginate/view_helpers.rb
372 def total_pages
373 @total_pages ||=
WillPaginate::ViewHelpers.total_pages_for_collection(@collection)
374 end
375
376 def param_name
=> 377 @param_name ||= @options[:param_name].to_s
378 end
379
380 # Recursively merge into target hash by using stringified
keys from the other one
381 def stringified_merge(target, other)
/usr/lib/ruby/gems/1.8/gems/will_paginate-2.3.14/lib/will_paginate/
view_helpers.rb:377
@param_name ||= @options[:param_name].to_s
(rdb:36) s+
6: @url_params.inspect =
{:controller=>"ceo", :action=>"gc_claimed_rewards",
"page"=>3, :page=>2}
8: options.inspect =
[341, 350] in /usr/lib/ruby/gems/1.8/gems/will_paginate-2.3.14/lib/
will_paginate/view_helpers.rb
341 @url_string = url.sub(%r!((?:\?|&)#{CGI.escape
param_name}=)#{page}!, "\\1\0")
342 return url
343 else
344 @url_string = url
345 @url_params[param_name] = 3
=> 346
@template.url_for(@url_params).split(//).each_with_index do |char, i|
347 if char == '3' and url[i, 1] == '2'
348 @url_string[i] = "\0"
349 break
350 end
/usr/lib/ruby/gems/1.8/gems/will_paginate-2.3.14/lib/will_paginate/
view_helpers.rb:346
@template.url_for(@url_params).split(//).each_with_index do |char, i|
The only funky thing that is happening to will_paginate is we are
calling it with a few params that were calculated (like "remaining =
collection.total_entries - displayed").
The call looks like this:
<%= will_paginate collection, {:page_links => false, :next_label =>
"Show next #{to_show} records (#{displayed + 1} to #{displayed +
to_show} of #{collection.total_entries})"} %>
I did see some heavy involvement in the routing by subdomain-fu and I
know its an old version. I'm going to update it and see what happens.
Mike
On Jul 26, 9:28 pm, Mislav Marohnić <mislav.maroh...@gmail.com> wrote:
> Well, there's the problem. See the "page" parameter occurring twice? There
> should never be symbols present in this hash; will_paginate only works with
> strings at this point. The `stringified_merge` method takes care of that.
> Because you have symbols here, something is wrong either with that method or
> with your app. Are you sure no plugins hook into and change will_paginate?
> No custom link renderers? Can you use the debugger to inspect how are
> the @url_params constructed? Thanks.
On Tue, Jul 27, 2010 at 06:44, sleepycat <blessedbyvirtuos...@gmail.com>wrote:
> Then at 337 I took an exceedingly long tour through the Rails > routing system which thoughtfully turns your newly stringified keys and > turns them back into symbols. So that is where the :page => 2 comes from.
You don't have to take those long tours, you know. You could have just stepped out of the function when you entered `url_for()`.
> As you can see above going into the call to url_for we had 6: > @url_params.inspect = {"action"=>"gc_claimed_rewards", > "page"=>2, "controller"=>"ceo"} > and coming out the other end: @url_params.inspect = > {:controller=>"ceo", :action=>"gc_claimed_rewards", :page=>2}
So there's our problem. The `url_for` method changes our input parameters in a way that it symbolizes the hash when in fact it shouldn't touch it. I think it's one of your plugins that does that — subdomain-fu perhaps.
Yeah, I know. I was hoping I might get a sense of some of the
interactions in there, which I did.
That said it didn't seem to help. I upgraded and then removed
Subdomain-fu completely and neither seemed to help.
I also removed the auto-admin plugin (Because it has a paginate method
of its own using the Sequel class.) to see if that might be involved
but it didn't improve the situation either.
Any other thoughts on what I might do?
Mike
On Jul 27, 7:03 pm, Mislav Marohnić <mislav.maroh...@gmail.com> wrote:
> On Tue, Jul 27, 2010 at 06:44, sleepycat <blessedbyvirtuos...@gmail.com>wrote:
> > Then at 337 I took an exceedingly long tour through the Rails
> > routing system which thoughtfully turns your newly stringified keys and
> > turns them back into symbols. So that is where the :page => 2 comes from.
> You don't have to take those long tours, you know. You could have just
> stepped out of the function when you entered `url_for()`.
> > As you can see above going into the call to url_for we had 6:
> > @url_params.inspect = {"action"=>"gc_claimed_rewards",
> > "page"=>2, "controller"=>"ceo"}
> > and coming out the other end: @url_params.inspect =
> > {:controller=>"ceo", :action=>"gc_claimed_rewards", :page=>2}
> So there's our problem. The `url_for` method changes our input parameters in
> a way that it symbolizes the hash when in fact it shouldn't touch it. I
> think it's one of your plugins that does that — subdomain-fu perhaps.
Well, here is an interesting thing. I changed the Rails version back
to 2.1.0 and it works. Rails 2.3.4 and 2.3.5, 2.3.6 all work. As soon
as I switch to 2.3.7 it breaks. I am not sure yet what to do about
that other than use 2.3.6 for a while, but its a start.
On Jul 27, 8:55 pm, sleepycat <blessedbyvirtuos...@gmail.com> wrote:
> Yeah, I know. I was hoping I might get a sense of some of the
> interactions in there, which I did.
> That said it didn't seem to help. I upgraded and then removed
> Subdomain-fu completely and neither seemed to help.
> I also removed the auto-admin plugin (Because it has a paginate method
> of its own using the Sequel class.) to see if that might be involved
> but it didn't improve the situation either.
> Any other thoughts on what I might do?
> Mike
> On Jul 27, 7:03 pm, Mislav Marohnić <mislav.maroh...@gmail.com> wrote:
> > On Tue, Jul 27, 2010 at 06:44, sleepycat <blessedbyvirtuos...@gmail.com>wrote:
> > > Then at 337 I took an exceedingly long tour through the Rails
> > > routing system which thoughtfully turns your newly stringified keys and
> > > turns them back into symbols. So that is where the :page => 2 comes from.
> > You don't have to take those long tours, you know. You could have just
> > stepped out of the function when you entered `url_for()`.
> > > As you can see above going into the call to url_for we had 6:
> > > @url_params.inspect = {"action"=>"gc_claimed_rewards",
> > > "page"=>2, "controller"=>"ceo"}
> > > and coming out the other end: @url_params.inspect =
> > > {:controller=>"ceo", :action=>"gc_claimed_rewards", :page=>2}
> > So there's our problem. The `url_for` method changes our input parameters in
> > a way that it symbolizes the hash when in fact it shouldn't touch it. I
> > think it's one of your plugins that does that — subdomain-fu perhaps.
> Well, here is an interesting thing. I changed the Rails version back > to 2.1.0 and it works. Rails 2.3.4 and 2.3.5, 2.3.6 all work. As soon > as I switch to 2.3.7 it breaks. I am not sure yet what to do about > that other than use 2.3.6 for a while, but its a start.
> On Wed, Jul 28, 2010 at 09:25, sleepycat <blessedbyvirtuos...@gmail.com>wrote:
> > Well, here is an interesting thing. I changed the Rails version back
> > to 2.1.0 and it works. Rails 2.3.4 and 2.3.5, 2.3.6 all work. As soon
> > as I switch to 2.3.7 it breaks. I am not sure yet what to do about
> > that other than use 2.3.6 for a while, but its a start.
