Skip Navigation

[Resolved] Blocks' pagination changes the > and < for u003e and u003c

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.

This topic contains 13 replies, has 2 voices.

Last updated by Christian Cox 1 year, 3 months ago.

Assigned support staff: Christian Cox.


I've started trying to use Toolset's Blocks (usually use Views) and I show some posts with pagination.

On the front-end, all the > and < signs (ex: Next >) are replace by the unicode value (ex: Next u003e).

My page uses the Unicode (UTF-8) encoding, so it should work. I also tried replacing it with the HTML entity (ex: Next >), but it simply shows the entity itself.

What can I do to prevent that from happening?

I tried using jQuery:
jQuery('.wpv-filter-next-link').text('Next >');
jQuery('.wpv-filter-last-link').text('Last >>');
jQuery('.wpv-filter-previous-link').text('< Previous');
jQuery('.wpv-filter-first-link').text('<< First');

and though it does work when the page loads, since I use Ajax it is replace by the Unicode character as soon as I click a page or one of the other links.



Hi, that's unusual. Have you tried troubleshooting by activating a default theme like Twenty Twenty One and deactivating all plugins except Types and Blocks? Is the pagination block set up to use a custom font, or the default theme font? Where can I see the problem on the front-end of the site?


I have tried to activate the default 2021 theme and deactivate all the plugins except Toolset, Elementor and WP Staging Pro and it does the same thing...

I can't show you where it does that, since the site being public I simply removed these signs... But I could give you access to the staging site for you to check if you want.


Sure, that would be helpful. I will activate private reply fields here. You mentioned that the page uses UTF-8 encoding. Can you tell me the DB_CHARSET and DB_COLLATE settings from your wp-config.php file?
Standard settings are:

/** Database Charset to use in creating database tables. */
define('DB_CHARSET', 'utf8mb4');

/** The Database Collate type. Don't change this if in doubt. */
define('DB_COLLATE', '');

Are yours different?


Where can I see the problem after I log in to the staging environment? It's not obvious on the homepage, and I don't know where else to look.


Sorry for that... Yeah, there's a lot of pages and posts, and the link is not even in the main menu yet...

It's the Conferences & Events CPT and the page that shows them is hidden link

Of course, since it's on the staging site, if you find the issue please tell me how to reproduce the steps on the live site.

Thank you,

Screen Shot 2021-02-01 at 10.42.37 AM.png

Okay, thanks for the extra information. After some additional investigation I didn't see anything obviously wrong or any obvious conflicts. So I set up a similar test on my own local test site, and it turns out I'm able to replicate the problem there as well. It seems that there is an issue with these specific text characters in Blocks pagination, because they are being replaced with unicode equivalents on the front-end. I'm escalating this to my 2nd tier support team for additional investigation.

Until we get an update, I was able to replace the basic "less-than" and "greater-than" text characters with some similar-looking characters that are not converted to unicode unnecessarily:

‹ Previous
Next ›
« First
Last »

It seems to be working now in staging. You can confirm, then copy + paste the text from the pagination block configurations in the staging site into the pagination block configurations in the live site, if you'd like to replicate the solution.

I'll let you know what I find out from 2nd tier support when I have an update.


Ok, great! Thank you.

I does work and I implemented it on the live site... but of course, I hope you'll find the solution (or, if not possible, change the default characters that are added when we enable that feature, since it's the greater than and less than signs that are there by default).



Okay great to know that solution worked. And yes, we definitely need to get the issue with the basic text characters addressed. I'll keep you updated here as I receive more information from the team.


This issue has been confirmed by 2nd tier support and escalated to the developers. I'll keep you posted here as I receive more information.


Hi, our developers are including the fix for this issue in the upcoming Views 3.5.2 / Blocks 1.5.2 release. I'll update the ticket here when that update is ready to go.


I apologize, I made a mistake in my previous comment. Those versions (3.5.2 / 1.5.2) are already available and do not include the fix. The fix will be included in the upcoming releases, versions 3.5.3 / 1.5.3.


Thank you.


Blocks 1.5.3 / Views 3.5.3 are now available. You should receive the fix when you update to the latest versions of our software.