On my current project I have a strict requirement to have clean URLs. Parameters in the URL are only accepted for the WordPress search result page.
How can I get the manual pagination (not AJAX) to not include parameters in the URL? It has to be clean and simple as /page/2 or similar. It also has to be compatible with WPML.
I'm not using too much of Toolset's extraordinary stuff, it's only a regular blog with a featured article on top (separate View). The only "special" thing is that I include posts from a specific category in all category archives and that I exclude the one featured article (using it's post ID). By reading in your forum I figured out how to do this using the filter wpv_filter_query. So far so good if it wasn't for the pagination URLs.
I've even tried to get clean URLs by using the WordPress Archive instead of a View for the category archives. I encountered two issues using this approach:
1. I couldn't figure out how to get the action/filter pre_get_posts to do what I did with the wpv_filter_query filter.
2. In the pagination links, there was still a wpv_view_count parameter that I don't know how to get rid of. In fact, the parameter doesn't seem to affect the page output in any way when I removed it by hand and reloaded the paginated page.
Please help me out.
Thanks!
There are no similar filters for the archives, as you were looking for.
As for the URL's, this is only possible in certain settings constellations.
A clean URL as you want it is only achievable by using the AJAX features.
You can as first, either use the URL's globally or hide them globally in Toolset > Settings > Front End Content.
I suggest to use them globally so you can turn them off in single Views.
Now, head to the View in question and for the Pagination, choose at least "Pagination enabled with manual transition and AJAX" and in it, uncheck "Update the URL of the page when paginating the View".
This will remove all URL parameters.
For the Custom Search, you need to choose "Do not adjust URLs after loading search results" in "How do you want to update the results?"
These settings can as said also be controlled globally - but they will have the desired effect only with AJAX interactions.
It is not possible to achieve this otherwise.
Hi Beda,
I've already presented the AJAX solution to my client but they want to use the traditional WP pagination (or something very similar), i.e. have separate URLs for the archive sub pages. I really need to exhaust all possibilities to get this sorted out as I was the one proposing to use Toolset for this project.
Here are a few questions:
1. The WP-PageNavi plugin. Can it be used in order to get cleaner pagination URLs?
2. Can the pre_get_posts action/filter be used to add posts from one category into other categories and exclude a certain post ID? I've done this with the wpv_filter_query filter, but I guess pre_get_posts should work as well? If this works, I can use a WordPress Archive instead of a View and hence move a bit closer to the URL structure I'm looking for.
3. Is it possible to somewhat bypass Toolset for the blog and category archive pages and use old-school templating in order to use the default WP pagination?
4. Other possibilities? For example URL rewriting of the Toolset parameters. Maybe dynamically (based on URL) load a page with post listings using an offset.
As you can imagine, I'm really desperate to find a solution. I wouldn't wanna ditch Toolset at this stage in the project :S
Many thanks!
It is not possible to change that URL structure.
The only possibility is the use the AJAX methods.
Or, you might create a Custom Code, that grabs the View's output and creates a New URL and produces them there.
You would still save yourself the hassle of writing the Query Itself and the Loop Output, but would need to create your own URL and print the View there.
You can of course use the Theme's rendering methods in Archives, you may just unassign existing archives, and create (if missing) your Custom Templates in the Theme to render the Archives.
We also have some Documents abut that:
https://toolset.com/documentation/customizing-sites-using-php/
You would not have to ditch Toolset. It would still save you a lot of time related to Design of the Loops and the Query.
With PHP you would then need to customize the URL and hide it (remember that the Views rely on those URL parameters, hence you need to pass them to the View, even if not visible in the browser bar)
I apologize that any further customization in this case falls under Custom Coding.
Thanks for the information.
Let's disregard the path of creating templates outside of Toolset for a while and explore what could be done to improve Toolset's URL behavior, especially when it comes to pagination of relative simple pages.
For one, WordPress own Rewrite API, could it be used to convert the Toolset parameters into paths?
What can be done to get rid of the worst parameter, i.e. the long hash value that the parameter wpv_view_count uses? One should be able to set another unique (and sightly) value to be used as identifier instead of the horrific hash, right?
Best regards.
As I mentioned, Toolset Views relies to the URL parameters it produces, and it is to be hidden with AJAX only, if you use the Toolset features.
wpv_view_count is exactly needed to as example avoid interference in-between views.
Imagine you have more than one View with searches.
You need to identify this.
Unfortunately it is not possible without custom coding, and then eventual fix-conding for eventual followup issues.
Thanks for the explanation.
However, for e.g. a "simple" magazine type site, the wpv_view_count parameter with its long and unsightly hash seems to be unnecessary and also results in poor UX.
The UX impact of an URL is of course something the product owner should take into account. The sightlyness of URLs should be improved in order to keep up with the emerging competition.
How can I submit an improvement request to the product owner?
I have filed this request.
I will also re-discuss this with the Developers.
In past we have rejected such requests, that is why I explained the reasons to this above.
I will update you here in case this is decided differently this time.
Thank you for adding your voice to the request!
