-
Notifications
You must be signed in to change notification settings - Fork 409
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Duplicate Rails fragment caching and link to first page without param[:page] #72
Comments
hi @technodrome, I received the same request (without all that detailed explanation) on the gitter chat, and I turn it down because - at that time - I didn't see any benefit while I saw a slight performance loss. |
Thank you @ddnexus, much appreciated! |
OK... here is what you can do. Just override the def pagy_url_for(page, pagy)
p_vars = pagy.vars; params = request.GET
params = params.merge(p_vars[:page_param] => page) unless page == 1
params.merge!(p_vars[:params])
"#{request.path}?#{Rack::Utils.build_nested_query(pagy_get_params(params))}#{p_vars[:anchor]}"
end That will remove the |
Another easier option would be using the def pagy_get_params(params)
params.delete(:page) if params[:page] == 1
params
end Probably better than the previous suggestion. |
After I put the second snipped to application_helper.rb, it removed page param from all pagination links. Now they look like: |
It was missing the |
Hmmm... sorry, I just remembered that the super fast proc that Pagy uses to render the links calls that methods only once and without the real page number, hence the methods that I suggested cannot work. D'oh :) |
Thanks, I look forward to a solution. |
After a lot of thinking, it looks like the simplest and more efficient way to strip the <%== pagy_nav(@pagy).gsub(/((?:[?&])page=1(?=")|\bpage=1&)/, '') %> That is fast and safe and consistent with the fact that Pagy deals mostly with strings. I tried changing the code in an extra to skip it at generation time, but it was ugly and it needs to remove part of the code that makes Pagy ~29x faster than Kaminari. The regexp is the best way IMO. A possible API improvement could be an extra that encapsulates the regex as a Pagy instance method so it could be used more easily (regardless the <%== pagy_nav(@pagy).gsub(@pagy.page_param_1_regexp, '') %> However it doesn't work with the compact helpers because the url is built in a javascript function... I am looking to integrate the same solution with all the nav extras. |
Excellent support, @ddnexus, as usual 👍 Thank you for fast reply and working solution! I will test it with Rails caching and report back in case I discover some irregularity. I am quite curious what you will come up with in the future. Thank you again. |
@technodrome |
@ddnexus amazing support again 👍 I will try the new version out as soon as possible. |
OK, that's only when the current page is the first page. I will take a look. Thanks. |
Fixed in |
I have pagination active on my homepage for a gallery. It shows different images for different user groups (logged in, admin, editor, ...).
When I click homepage logo, the URL is:
localhost:3000/
However, pagination link for the first paginated page shows
localhost:3000/?page=1
This raises two problems:
Current result for the first paginated page:
localhost:3000/?page=1
Expected result for the first paginated page only:
localhost:3000/
Basically, pagination should start inserting
?page=
into URL from number 2 upwards. This can be seen on many websites with video galleries on the homepage.localhost:3000
but there is one forlocalhost:3000/?page=1
. Again, two pages, same content = two different cache fragments are generated for the same content. I got bitten by this problem where cache was expired for one of these fragments, but not for another one - users see different images.I got around this by implementing a helper. Downside: hardcoded @pagy instance which is a problem when someone has several paginations active on a single page.
It checks whether
@pagy
is defined on that page and whether it hasparams[:page]
in the URL. If@pagy
is defined, but noparams[:page]
is in the URL, it assumes a homepage and inserts default page number 1 into cache_key fragment name.Helper
View
This works and inserts correct keys when visiting homepage without any
page
param in the URL:Write fragment views/images/member/1/ebb46c39e960e982acb853421cf145e4 (0.1ms)
Subsequent visits to either canonical homepage url without
page
param or withpage=1
param read correct cache fragment:Read fragment views/images/member/1/ebb46c39e960e982acb853421cf145e4 (0.1ms)
However, I don't like such solutions as they assume too much about something which may change.
Is there any way to get links without page=1 for the first page of the pagination sitewide?
will_paginate had something similar here: mislav/will_paginate#459
The text was updated successfully, but these errors were encountered: