[Resolved] Query strings being added to archive page URLs

[Author]

Posts

[matthewL-7]

Hi,

For some reason pagination links have strange query strings on the end of them.

For example see this page: hidden link

The link to page 2 is: hidden link

When really it should just be: hidden link

How can I solve this?

Thanks.

[Luo Yang]

Hi,

I assume we are talking about WordPress archive page for taxonomy "genre", and you are using Shortcodes to display "Next" and "Previous" links:
- [wpv-pager-archive-prev-page]
- [wpv-pager-archive-next-page]

The problem occurs only when you put the pagination shortcodes outside section "Loop Editor"

Please edit the WordPress archive(ID: 22502) , move the pagination shortcodes into section "Loop Editor", within shortcodes:
[wpv-items-found] ... [/wpv-items-found]

And test again

[matthewL-7]

Hi Luo,

Hmm they were outside this but I have now moved them inside this and still having the same issue.

Here is the code inside the loop editor, maybe this will help you identify what I am doing wrong?

[wpv-layout-start]
	[wpv-items-found]
	<!-- wpv-loop-start -->
	<wpv-loop>
		[wpv-post-body view_template="Loop item in Genre Archive Template"]
	</wpv-loop>

[lgc_column grid="50" tablet_grid="50" mobile_grid="50" last="false"][wpv-pager-archive-prev-page][wpml-string context="wpv-views"]<button class="button previous">Previous</button>[/wpml-string][/wpv-pager-archive-prev-page][/lgc_column]

[lgc_column grid="50" tablet_grid="50" mobile_grid="50" last="true"][wpv-pager-archive-next-page][wpml-string context="wpv-views"]<button class="button next">Next</button>[/wpml-string][/wpv-pager-archive-next-page][/lgc_column]

	<!-- wpv-loop-end -->
	[/wpv-items-found]
	[wpv-no-items-found]
		<strong>[wpml-string context="wpv-views"]No items found[/wpml-string]</strong>
	[/wpv-no-items-found]
[wpv-layout-end]

Cheers.

[Luo Yang]

Thanks for the details, you are right, the URL parameter "wpv_view_count" still persists even put those shortcodes insider [wpv-items-found] ... [/wpv-items-found], and the URL parameter "wpv_view_count" is required when you are using AJAX pagination or custom search form, if you insist on remove it, you can try the filter hook "wpv_filter_wpv_get_object_unique_hash", for example:

add_filter('wpv_filter_wpv_get_object_unique_hash', function($res, $view_settings){
	if($view_settings['view_id'] == 22502){
		$res = '';
	}
	return $res;
}, 10, 2);

And test again

[matthewL-7]

Hmm its strange because on our old theme this didn't happen. I guess the them handled the next previous links.

I tried adding the code you sent over but it came back with an error:

"The code snippet you are trying to save produced a fatal error on line 3:
syntax error, unexpected '$res' (T_VARIABLE)"

I am not using AJAX pagination but I am using custom filters, is this the same as using a custom search form, I am guessing it is?

I understand the query string needs to be on the end when the custom search is used, but I don't see why it needs to be in the static next/previous links.

[Luo Yang]

If you are using custom search form, then the URL parameter "wpv_filter_wpv_get_object_unique_hash" is required.

For example:
when you search in the custom search form, you might also get some result with pagination, this URL parameter is required when you click the pagination links, and View will be able to display the correct search result.

[matthewL-7]

Hi Luo,

Sure I understand but when the custom search form isn't being used why do the links need to have the query string on the end?

The query string surely only needs to be on the end when a custom search/filter has been done?

Thanks.

[Luo Yang]

Yes, I agree with you, and have escalated this thread to our 2nd tier supporters, will update here if there is anything news.

[Luo Yang]

Here is the feedback from our 2nd tier supporter,
This happens with Views 2.5.2 . So, it seems that wpv_view_count is added to the URL for an important reason.

In order to change it, you can add a feature request for it:
https://toolset.com/home/contact-us/suggest-a-new-feature-for-toolset/

[matthewL-7]

So there is no way to avoid this then?

I don't really see why this should be a feature request?

It is really messy and looks suspect on Google for end users when they see URLs like this.

This is should be a top priority to sort this and this 100% isn't needed when no search filter is implemented.

[Luo Yang]

Thanks for the comment, I have to forward it to our 2nd tier supporters, will update here if there is anything news.

[Luo Yang]

Here are feedback from our 2nd tier supporters.

This issue is filed in our to-do list as a feature request, waiting for our developers evaluation, but we cannot promise anything, and currently as for now there is no solution for it.

[matthewL-7]

Any update on this issue being fixed?

[Luo Yang]

It is still in our to-do list, waiting for evaluation status, as I mentioned above, there isn't any ETA for it.

[matthewL-7]

Hi Luo,

Just wanted to check in on this to see if there is any progress?

Cheers