Labels

[Rajiv]

Forum URL: giffas.proboards.com

I use labels extensively on my forum. For example, the label "GS(S)". A screenshot of page 1 of the board when the label is clicked:



However, when I click on page "2" or "Next", it goes to page 2 of the whole board, rather than page 2 for the label. A screenshot:



Can this be corrected?

Thanks.

[Chris]

Appears to be happening here on support for me as well, changing page destroys the filter. We'll wait for an admin to confirm if this is a bug or a temporary glitch.

[Rajiv]

Thanks.

It's been happening for a while now. I now find that re-freshing the page each time seems to rectify the listing.

[Chris]

The filter remains in the url so refreshing should reapply it, but it should not be losing that filter when using the pagination in the first place.
Thanks for pointing this out

[Michael]

Hi,

This is a long-term bug that has not been a priority to fix because of how infrequently the label system is used. I'll see if we can bump this up the list.

[Michael]

Hi,

This issue was resolved in v6 but appears to not have been resolved in v5. There is still a pending task to resolve this bug (in v5) but I don't have an exact ETA for when that fix will go into place and be pushed live. With any luck it will see attention in the next two weeks and will be pushed live sometime after that.

[Chris]

Rajiv ,

I believe I have a coding solution for you

<script>/* Patch Autosearch Query Filters (Global Header)*/
$.ajaxPrefilter(function( options ) {
 if ( "string" == typeof options.data ) {
   if( /filters%255B%255D/.test(options.data))
options.data = options.data.replace('filters%255B%255D',encodeURIComponent('filters[]'));
 }else if("object" == typeof option.data && options.data["filters%5B%5D"]){
 options.data["filters[]"] = options.data["filters%5B%5D"];
 }
});
</script>


The fault lies in the proboards.consolidateParams method since it uses decodeURIComponent on the query values but not on the query names themselves so when you end up with filters%5B%5D instead of filters[] in the url the autosearch has no idea what to do with that. The code  simply tries to target that specific case where filters are URI encoded in the url and change before consolidateParams grabs it.

Upon deeper inspection other filters do not URI encode the square brackets in the url (example: /board/44/support-board?filters[]=thread_replies%3Agt%3A45) so when the server rightly does this for labels it appears that URI encoded "filters%5B%5D" is also being  encoded over again before being sent via XHR so that the percent signs used for the first encoding are themselves encoded resulting in a double encoded string "filters%255B%255D" which would have to be double decoded on the server side to get back to "filters[]" (I'm going to guess that's not happening server side yet).


(Original code was causing problems assuming all filters behaved this way)

[Rajiv]

Thanks Chris.

For now, just doing this:

Jul 17, 2019 21:56:54 GMT -8 Rajiv said:

Thanks.

It's been happening for a while now. I now find that re-freshing the page each time seems to rectify the listing.

[Michael]

Hi,

This fix was pushed live a number of weeks ago so you shouldn't need any workarounds any longer.

[Rajiv]

Oct 1, 2019 9:52:07 GMT -8 Michael said:

Hi,

This fix was pushed live a number of weeks ago so you shouldn't need any workarounds any longer.

Thanks, I should have noticed that! Wasn't thinking!!