Character encoding issue in class.arm_members_directory.php (Line 1130+)

๐Ÿ‘ Gathering votes

Hi ARMember Team,

I hope you're doing well.

After updating the plugin (version 6.9.10), we've encountered a character encoding issue specifically with Persian (UTF-8) characters. In the current version of ARMember, the following block of code starting around line 1130 in

class.arm_members_directory.php

seems to be the source of the problem:

$arm_template_html = $template_data['arm_template_html'];

$arm_template_html = htmlentities($arm_template_html);

$arm_template_html = apply_filters('arm_user_profile_template_html_modified_externally', $arm_template_html);

$arm_template_html = html_entity_decode($arm_template_html);

This code causes UTF-8 strings (such as Persian text) to be rendered incorrectly on the frontend. For example, the persian word is shown as:
"รšยฉร˜ยฏ ร˜ยฏร˜ยงร™ห†ร˜ยทร™โ€žร˜ยจร›ล’"

It seems the

htmlentities()

function is escaping the string using a default charset (likely ISO-8859-1) instead of UTF-8. While

html_entity_decode()

is used afterwards, it doesn't restore the original text properly due to the incorrect charset used during encoding.

Suggested fix:

We recommend reverting to the logic from the previous version, which worked correctly:

$arm_template_html = stripslashes_deep($template_data['arm_template_html']);
$arm_template_html = apply_filters('arm_user_profile_template_html_modified_externally', $arm_template_html);

Additional Note:

In addition to the character encoding issue, Iโ€™d like to point out another problem we encountered in the Profiles & Directories โ†’ Profile Templates section.

When creating a custom profile template, we can select user profile fields and assign custom labels to them โ€” which is a great feature, since it allows us to display user data with different labels in the frontend, without changing the original field label globally.

However, after the recent update, these custom labels are no longer being used. Instead, the system displays the original field labels in the frontend, ignoring the custom labels set in the template.

This seems to be happening in the same frontend output where the character encoding issue occurs. I just wanted to flag this in case it's related to recent changes in how templates are processed or rendered.

We would appreciate it if you could review this section and provide an update or workaround to properly support non-Latin character sets like Persian.

Thanks for your continued support and a great plugin!

Best regards,

S Izadbakhsh

5 days ago

One vote
Categories
๐Ÿชฒ Bug