[Resuelto] Ajax pagination taxonomy view with nested post view doesn't work
This support ticket is created hace 5 años, 3 meses. There's a good chance that you are reading advice that it now obsolete.
This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.
Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.
Hoy no hay técnicos de soporte disponibles en el foro Juego de herramientas. Siéntase libre de enviar sus tiques y les daremos trámite tan pronto como estemos disponibles en línea. Gracias por su comprensión.
I am trying to:
Making ajax pagination work in a taxonomy view. Perhaps this is a bug.
I set up a demo site on discower-wp. Please look at this
Link to a page where the issue can be seen: enlace oculto
I expected to see:
working pagination
Instead, I got:
No items found on page 2.
Perhaps the problem appears because the id of the current page is replaced by the views id when paginating completed. I found this when I tried to display the id of the current page in the taxonomy view.
As indicated in that document, for the moment the workaround is to not use a template for the loop output but add the markup for the output directly between the wpv-loop tags of the Loop Editor.
Thanks. I saw the issue and was able to reproduce it on my own test site. I tried various tests to see if I could pin down or work around the problem but could not (aside from paginating via page reload), and so I'm passing a copy of my test site to my second tier colleagues to investigate further, and I'll get back to when I have news from them.
I can see from the internal tickets that my colleague in second tier is working on this at this very moment, so I should be able to provide some news soon (whatever that is).
Thanks for the quick response.
Unfortunately, I need to continue to display the results of the previous page, so pagination with a reload is not suitable. In this case, I use pagination only to break the view in order to optimize page loading speed.
Is there any hope that this will be fixed someday?
Perhaps after the release of Views 3.0, when there will be time to fix old problems.
You are right that Views 3.0 is consuming a lot of developer resources at the moment, and I am hopeful that we will be able to do a sweep of outstanding issues when that milestone is reached.
I'm not in a position to say when it might be fixed, it shouldn't be a big issue according to the debugging, but hopefully it will receive some attention after the Views update.