Replace deprecated seems_utf8() and removed utf8_encode()

[GaryJones]

Problem

BuddyBoss Platform uses two functions that are deprecated or removed in modern PHP/WordPress:

1. seems_utf8() — deprecated in WordPress 6.9 in favour of wp_is_valid_utf8(). Used in BP_Attachment::sanitize_utf8_filename().

2. utf8_encode() — removed in PHP 8.2 (previously deprecated in 8.1). Used in bbp_get_reply_author_display_name() and bbp_get_topic_author_display_name().

Sites running WordPress 6.9+ see deprecation notices from seems_utf8(), and sites on PHP 8.2+ get fatal errors from utf8_encode().

Fix

For seems_utf8(): Use wp_is_valid_utf8() when available (WordPress 6.9+), falling back to seems_utf8() on older versions.

For utf8_encode(): Use mb_convert_encoding($str, 'UTF-8', 'ISO-8859-1') which is the recommended replacement. Falls back to utf8_encode() only on PHP versions where mb_convert_encoding is unavailable (effectively PHP < 7.2, which is well past end of life).

All replacements include backward-compatible fallbacks so the code works across WordPress and PHP versions.

Files changed

• src/bp-core/classes/class-bp-attachment.php — seems_utf8() → wp_is_valid_utf8()
• src/bp-forums/replies/template.php — utf8_encode() → mb_convert_encoding()
• src/bp-forums/topics/template.php — utf8_encode() → mb_convert_encoding()

Test plan

• Upload an avatar with a non-ASCII filename on WordPress 6.9+ — no deprecation notices
• View a forum topic/reply by an author with a non-ASCII display name on PHP 8.2+ — no fatal error
• Verify the display name is correctly encoded in both cases

[chetansatasiya]

@GaryJones Thanks for the PR and it will be added in our upcoming release.

[chetansatasiya]

@claude Review the PR

[claude]

Claude finished @chetansatasiya's task in 1m 48s —— View job

---

PR Review: Replace deprecated seems_utf8() and removed utf8_encode()

• Gather context from PR description and changed files list
• Read src/bp-core/classes/class-bp-attachment.php
• Read src/bp-forums/replies/template.php
• Read src/bp-forums/topics/template.php
• Analyze changes against WordPress/PHP coding standards
• Post detailed review

---

Overview

This PR correctly addresses two real compatibility issues — the WordPress 6.9 deprecation of seems_utf8() and the PHP 8.2 removal of utf8_encode(). The approach (primary wp_is_valid_utf8() + mb_convert_encoding(), with backward-compatible fallbacks) is sound. One linting inconsistency needs fixing before merge.

---

Issues Found

1. Missing phpcs:ignore comment on seems_utf8() in forum templates — needs fix

class-bp-attachment.php correctly suppresses the deprecation warning on its fallback seems_utf8() calls:

: seems_utf8( $retval ); // phpcs:ignore WordPress.WP.DeprecatedFunctions.seems_utf8Found

But the same seems_utf8() calls in the forum templates do not have this comment:

• src/bp-forums/replies/template.php, line 1207
• src/bp-forums/topics/template.php, line 1528

} elseif ( seems_utf8( $author_name ) === false ) {
// ↑ missing: // phpcs:ignore WordPress.WP.DeprecatedFunctions.seems_utf8Found

These two lines will trigger WordPress.WP.DeprecatedFunctions.seems_utf8Found on any environment running composer lint-php with WordPress 6.9+ WPCS rules. Fix this →

---

2. Duplicate function_exists('wp_is_valid_utf8') check in class-bp-attachment.php — minor

The availability of wp_is_valid_utf8 is checked twice: once for $is_utf8 (line 290) and once for $is_utf8_fallback (line 306). Since the function won't change availability mid-execution, a small optimization would be to cache this once:

$has_wp_is_valid_utf8 = function_exists( 'wp_is_valid_utf8' );
$is_utf8 = $has_wp_is_valid_utf8 ? wp_is_valid_utf8( $retval ) : seems_utf8( $retval );
// ...later...
$is_utf8_fallback = $has_wp_is_valid_utf8 ? wp_is_valid_utf8( $retval ) : seems_utf8( $retval );

Note that $is_utf8_fallback is correctly re-evaluating $retval after remove_accents() modifies it — so the two variables are not redundant, they're checking the string at different points. The only redundancy is the two function_exists() calls. This is a minor style concern and not a blocker.

---

3. utf8_encode() fallback on PHP 8.2 without mbstring — acknowledged edge case

The fallback path in both forum templates:

: utf8_encode( $author_name ); // phpcs:ignore PHPCompatibility.FunctionUse.RemovedFunctions.utf8_encodeDeprecated

...would only be reached on PHP 8.2+ if mbstring is not loaded. On PHP 8.2, utf8_encode() is removed, so this would still fatal. That said, mbstring is enabled in virtually all modern hosting environments and is a WordPress installation requirement in practice, making this an unreachable path on PHP 8.2. The phpcs:ignore comment is appropriate. Not a blocker, but worth noting in a code comment.

---

What's Good

• Correct semantic equivalence: wp_is_valid_utf8() is the proper successor to seems_utf8(). Both check whether a string is valid UTF-8; wp_is_valid_utf8() uses a stricter regex-based approach.
• Correct encoding replacement: mb_convert_encoding($str, 'UTF-8', 'ISO-8859-1') is the documented PHP replacement for utf8_encode(), preserving the same Latin-1 → UTF-8 conversion assumption.
• Backward compatibility: All three files degrade gracefully on older WordPress/PHP versions.
• phpcs:ignore comments in class-bp-attachment.php are correctly placed on the fallback seems_utf8() lines.

---

Summary

One concrete issue to fix before merge: add // phpcs:ignore WordPress.WP.DeprecatedFunctions.seems_utf8Found to the seems_utf8() fallback lines in replies/template.php:1207 and topics/template.php:1528, matching the pattern already used in class-bp-attachment.php:292,308. Everything else is correct.