Problem with Font Awesome

Hello,

Thank you for your kind words and for using wpDataTables for so long.

We tested this on our side with the same setup (Excel-based table and the same HTML for the icon), and we were unable to reproduce any change in behavior related to the plugin update.

Here’s what we found during testing:

When the Excel file contains: <i class="fas fa-external-link-square-alt"></i> the cells appear empty in the WP-Admin preview.

View post on imgur.com

On the front-end, the icon will only render if Font Awesome is loaded on the page.

In our test, once we added Font Awesome manually in the page header:

<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/6.5.0/css/all.min.css">

the icons displayed correctly on the front-end.

(Screenshots attached for reference.)

View post on imgur.com

View post on imgur.com

It looks like Font Awesome might no longer be loading on your front-end pages. This can happen if:

• Your theme previously included Font Awesome and stopped loading it after an update
• A plugin that was loading Font Awesome was disabled or changed behavior
• Caching/minification removed or deferred the stylesheet

From our testing, we didn’t observe any changes in the latest version related to how HTML is rendered in table cells. The behavior you’re seeing is consistent with Font Awesome not being loaded on the page.

Let us know if you can confirm that Font Awesome is properly loading on the front-end page, but the table still doesn’t render the icon.

You can also try switching to a different theme temporarily and disabling other plugins, to check if there might be a conflict preventing Font Awesome from loading correctly.

Hope this helps.

Kind regards,
Milos

• This reply was modified 1 month, 1 week ago by Milos Jovanovic.
• This reply was modified 1 month, 1 week ago by Milos Jovanovic.

Hey Stick,

You’re right — thanks for the clarification and for sticking with this.

I took another pass at testing, and you’re correct: when rolling back further to 6.5.0.4, the icon does render even in a URL Link column. In newer versions, it gets escaped and shown as HTML instead.

So there seems to be a change in behavior between 6.5.0.4 and the newer versions.

From what we can see, the URL Link column now strictly treats values as URLs and escapes any embedded HTML (like your <i> tag). That’s why it ends up rendered like this:

<a href="http://i%20class=fas%20fa-external-link-square-alt/i" target="_blank">  &lt;i class="fas fa-external-link-square-alt"&gt;&lt;/i&gt;</a>

It is possible that this was tightened intentionally (for consistency or security reasons), but I’ve escalated this to our developers to confirm whether this change was planned or not. I’ll follow up with you as soon as I have more info from them.

In the meantime, the recommended workaround would be:

• Switch the column type to String
• Output the full HTML manually, including the <a> tag and icon

Example:

<a href="https://lelaurier.net/user/your-slug" target="_blank">  <i class="fas fa-external-link-square-alt"></i></a>

The URL Link column is intended for plain URLs (with optional || formatting), as described here:
https://wpdatatables.com/documentation/column-features/url-link-columns/

Also, just to mention — we do have the Transform Value feature, which makes it easier to build dynamic custom links, but that’s available only in the Premium version:
https://wpdatatables.com/documentation/table-features/transform-value/

If you prefer to keep your current setup for now, you can download older versions (including 6.5.0.4) from here:
https://wordpress.org/plugins/wpdatatables/advanced/
→ “Previous versions”

Otherwise, updating to the latest version and switching to a String column should resolve it cleanly.

Thanks again for flagging this — I’ll get back to you as soon as I hear from the dev team.

Kind regards,
Milos

• This reply was modified 1 month, 1 week ago by Milos Jovanovic.

Hello,

This has not been fixed yet.

At the moment, our developers are still investigating what exactly caused this change in behavior in the newer plugin versions.

That said, as mentioned previously, the URL Link column type was never originally intended to be used with custom HTML content inside the value itself.

The intended format for URL Link columns is:

• a plain URL
• or the standard URL||Label format

For example:

https://example.com||Visit profile

Because of that, the fact that embedded HTML (such as Font Awesome <i> tags) previously rendered correctly inside a URL Link column was not actually intended behavior, even though it worked in older versions.

In newer versions, the URL Link column appears to apply stricter escaping/validation rules, which causes the HTML to be displayed as text instead of being rendered.

For custom HTML rendering, the recommended approach is to use a String column type and output the full HTML manually, for example:

<a href="https://lelaurier.net/user/your-slug" target="_blank">
    <i class="fas fa-external-link-square-alt"></i>
</a>

This is also aligned with our documentation for String columns:
String columns documentation

And for URL Link columns:
URL Link columns documentation

At this time, I can’t provide an ETA or guarantee whether the previous behavior will be restored, since that depends on the outcome of the investigation and internal review. However, the team will continue looking into it.

Kind regards,
Milos

Hello,

That makes sense, and thanks for sharing the workaround.

As you pointed out, using &#xf360 avoids passing HTML through the URL Link column, so it also avoids the escaping behavior introduced in newer versions. In your case, that’s a perfectly valid solution.

I’m glad you found an approach that works on your setup. Since this resolves the issue on your side, we can consider this thread resolved for the time being.

If you notice anything else related to URL Link column behavior in future versions, feel free to open a new thread, and we’ll take another look.

Kind regards,
Milos

• This reply was modified 1 week, 6 days ago by Milos Jovanovic.