pagy_bootstrap_compact_nav working fine, pagy_bootstrap_responsive_nav is blank #140
Comments
|
I hope you found out the problem by yourself. Missing the Javascript initialization? |
|
The event listener I think, still not working in production as it does in development, assumed it was the initializer needing reloading, but rebooted server and still the same
… On 9 Mar 2019, at 23:37, Domizio Demichelis ***@***.***> wrote:
I hope you found out the problem by yourself. Missing the Javascript initialization?
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
Which event listener are you using? |
|
window.addEventListener("turbolinks:load", Pagy.init);
My Capistrano job runs precompile on every deploy.
It is actually adding items if you drag browser width to maximum, it’s almost like it’s ignoring that the first breakpoint exists, so at mobile size the pagination is wider than the viewport
Dev on left, production on right
…On 10 Mar 2019, at 01:13, Domizio Demichelis ***@***.*** ***@***.***>> wrote:
Which event listener are you using?
Production not working with Javascript makes me think to asset:precompile. Did you re-compile?
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub <#140 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA8PGn6-IuEHCp3N0aGxlTnoiN4y9sFmks5vVFw_gaJpZM4bm6SK>.
|
|
OK, so let's recap (correct me if I am wrong):
|
|
in dev mode it works
Yes
in prod mode it doesn't
Partially
when it doesn't work:
the nav is initially empty
No
after a resize the nav gets populated
Always populated
after the first correct rendering... does it works or not?
Partially, it will add items as the window gets wider, but when made smaller, or first rendered at minimum browser width it doesn’t remove enough items to fit the view
… On 10 Mar 2019, at 09:37, Domizio Demichelis ***@***.***> wrote:
OK, so let's recap (correct me if I am wrong):
in dev mode it works
in prod mode it doesn't
when it doesn't work:
the nav is initially empty
after a resize the nav gets populated
after the first correct rendering... does it works or not?
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
Another question that I added later: is there any difference in different browsers and different initial sizes? BTW if I understand correctly, in production the only differences are:
|
|
Another question that I added later: is there any difference in different browsers and different initial sizes?
Initial size makes no difference, issue not appearing in Safari, but does in Chrome and Firefox (worse in Firefox as browser window goes smaller)
BTW if I understand correctly, in production the only differences are:
the breakpoints behave differently than in dev
Yes
the problem appear to be related to the small size (first breakpoint?)
Yes
do bigger size work well?
Yes
… —
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
That's interesting. |
|
That's interesting.
Can we check if there is no difference in the bootstrap breakpoints settings between the dev and prod?
Definitely the same
Could you share a minimal app with that settings in order to reproduce the issue?
Could give you access to whole app if you like(ssh details, bitbucket repository), it’s a complete rewrite of an existing site, so the production server is not being used by anyone but me at the moment
… —
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
That would work... let's start with adding my email-address to the bitbucket repo, so I could clone it and try it locally. Thanks. |
|
Maybe also the web address/access to the deployed app, so if I am lucky I don't even have to run the app locally, but use the deployed one. |
|
One thing that I notice: the pagy breakpoints in the initializer are probably a problem (although doesn't explain the difference dev/prod). Did you try to change that? |
|
I tried them at the defaults, but it seemed to make no difference
… On 10 Mar 2019, at 12:06, Domizio Demichelis ***@***.***> wrote:
One thing that I notice: the pagy breakpoints in the initializer are probably a problem (although doesn't explain the difference dev/prod). Did you try to change that?
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub <#140 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA8PGnclMImtwARhREuXYfvd7UiYRq1Nks5vVPUwgaJpZM4bm6SK>.
|
|
Have mailed you details
… On 10 Mar 2019, at 11:56, Domizio Demichelis ***@***.***> wrote:
Maybe also the web address/access to the deployed app, so if I am lucky I don't even have to run the app locally, but use the deployed one.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
That are not a default! they are just a bad example. Sorry. I should change that, because the width values are crazy small! You should sync them with the standard width of the bootstrap breakpoints. Please, can you try that? |
|
Thank you, that has fixed it
… On 10 Mar 2019, at 12:09, Domizio Demichelis ***@***.***> wrote:
That are not a default! they are just a bad example. Sorry. I should change that, because the width values are crazy small! You should sync them with the standard width of the bootstrap breakpoints. Please, can you try that?
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub <#140 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA8PGpMkEG6J1zIL2IfpRyJ9umfB6M97ks5vVPX8gaJpZM4bm6SK>.
|
|
Great! Could you post the breakpoints? Are they synced with the bootstrap breakpoints that you use? |
|
too soon, it works on initial load, but as you go through the pages it gets wider and wider than the viewport
this is what I tried
… Pagy::VARS[:breakpoints] = { 0 => [1,2,2,1], 576 => [2,3,3,2], 720 => [3,4,4,3] }
On 10 Mar 2019, at 12:16, Nick Hayday ***@***.***> wrote:
Thank you, that has fixed it
> On 10 Mar 2019, at 12:09, Domizio Demichelis ***@***.***> wrote:
>
> That are not a default! they are just a bad example. Sorry. I should change that, because the width values are crazy small! You should sync them with the standard width of the bootstrap breakpoints. Please, can you try that?
>
> —
> You are receiving this because you modified the open/close state.
> Reply to this email directly, view it on GitHub, or mute the thread.
>
|
|
Not sure to understand "wider and wider than the viewport". Do you mean that the pagy |
|
Please, take a look at this page https://bootstrapcreative.com/bootstrap-4-media-queries/ and use the container widths as the reference. The pagy nav applied breakpoint depends on the container width, so please ensure that the container would snap at different widths correctly even without the pagy nav in it. |
|
Will do, should have some time later this evening
… On 10 Mar 2019, at 12:29, Domizio Demichelis ***@***.***> wrote:
Please, take a look at this page https://bootstrapcreative.com/bootstrap-4-media-queries/ and use the container widths as the reference. The pagy nav applied breakpoint depends on the container width, so please ensure that the container would snap at different widths correctly even without the pagy nav in it.
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub, or mute the thread.
|
I have setup Page fine, adding the extras. If i use the compact extra it displays fine, trying the responsive extra and it's empty, inspect the html it creates the nav-id but there is no btn-group created.
I was of the understanding that require 'pagy/extras/bootstrap' in my page.rb should load compact and responsive, am a bit lost.
The text was updated successfully, but these errors were encountered: