Activation Kit fails on PHP 8.2/8.4 hosting — FILTER_SANITIZE_STRING deprecated/removed

Hello @gdgsupport,


I am running the XLS Padlock Activation Kit Version 2025.0 on my web hosting (Websupport.sk, shared Linux). My compiled .exe performs online validation against https://ferovezakazky.sk/activation/dovalidation and key generation against /activation/getactivation.


The problem:


After my hosting provider upgraded PHP to 8.4, all activation/validation endpoints started returning HTTP 500 Internal Server Error. The PHP error log shows:




<span><span>PHP Fatal error: Constant FILTER_SANITIZE_STRING is deprecated</span></span>

This constant was deprecated in PHP 8.1 and completely removed in PHP 8.4. The Activation Kit code (specifically MainController.php) still uses it, which triggers a fatal error.


What I tried (none worked):

1. Asked hosting to downgrade PHP back to 8.2. The error persists, because Websupport's PHP-FPM configuration converts E_DEPRECATED warnings into fatal errors before index.php even loads.
2. error_reporting(E_ALL &amp; ~E_DEPRECATED &amp; ~E_STRICT); at the top of index.php — ignored, deprecation is raised earlier in the request lifecycle.
3. Polyfill if (!defined('FILTER_SANITIZE_STRING')) define('FILTER_SANITIZE_STRING', 513); — does not help on 8.2 (constant still exists but emits deprecation), and on 8.4 the call to filter_var($x, FILTER_SANITIZE_STRING) itself fails.
4. .htaccess with php_value directives — blocked by Websupport.
5. .user.ini with auto_prepend_file and a custom prepend script — the prepend loads, but the deprecation warning is still emitted by the PHP-FPM layer before user code runs.
6. Custom set_error_handler() — overridden by F3 framework's own handler.
7. ob_start() / ob_clean() — output buffer is flushed with the 500 status before user code can intervene.

The cleanest output I managed (with .user.ini + prepend) was a 124-byte response — but the server sent it with Transfer-Encoding: chunked, which the XLS Padlock client (Pascal) apparently cannot parse. It needs Content-Length.


My questions:

1. Is there an updated Activation Kit (2026 release?) that no longer uses FILTER_SANITIZE_STRING? If yes, where can I download it?
2. If not, which file(s) should I patch to replace FILTER_SANITIZE_STRING with a PHP 8.4-compatible equivalent (e.g. htmlspecialchars() + strip_tags())? I want to make sure I do not break the encryption/decryption flow with defuse/php-encryption.
3. Does the XLS Padlock client (Pascal binary inside the .exe) support Transfer-Encoding: chunked responses, or must the server always send Content-Length? This affects how I work around hosting-level interference.
4. My maintenance subscription expired on 25.02.2026. I am ready to renew it immediately if it gives me access to an updated Activation Kit. What is the renewal procedure?

Setup details:

• XLS Padlock Activation Kit Version 2025.0
• Hosting: Websupport.sk (Simple plan, shared Linux, PHP 8.2 / 8.4 only — no opt-in for older versions)
• Framework: Fat-Free Framework (F3) v3.x as bundled with the kit
• WordPress on the same domain (the /activation/ folder is a separate F3 application)
• .htaccess rewrites /activation/(.*) → /activation/index.php correctly (verified)
• Endpoint URL: https://ferovezakazky.sk/activation/dovalidation and /activation/getactivation

Any guidance would be greatly appreciated — my product launch is blocked until validation works again.


Thank you,Branislav

**Update / Resolution:**

After two days of investigation I located the actual root cause and
fixed it on my end. Posting here for the next person who hits the same
symptoms.

**The diagnosis was misleading.** The visible error message says:
"Constant FILTER_SANITIZE_STRING is deprecated"

I assumed this was caused by the Activation Kit's MainController.php
or the bundled F3 framework. **Both are clean.** The kit code does not
use FILTER_SANITIZE_STRING anywhere, and neither does fatfree-core
(verified across versions 3.7.0 - 3.9.2 on GitHub).

**The real cause:** F3's `set_error_handler` callback in `base.php`
converts EVERY PHP warning/notice/deprecation that passes the active
error_reporting() mask into an `ErrorException` and renders it as a
500 page. So whenever ANY component loaded after `wp-load.php` (in my
case: an outdated plugin called SmartEmailing combined with WordPress
6.7+ stricter `_doing_it_wrong` checks) emits a deprecation or notice,
the entire `/activation/*` request fails with 500.

In short: it doesn't matter where the deprecation comes from — F3 will
turn it into a fatal HTTP error. With WordPress 6.7+ tightening up its
"doing it wrong" emissions, this is increasingly likely to bite anyone
running the Activation Kit alongside an active WP/WooCommerce install.

**My fix:** patched `vendor/bcosca/fatfree-core/base.php` line ~2466,
the `set_error_handler` callback:

Before:
if ($level & error_reporting()) { trace=trace=trace=this->trace(null, false); array_unshift(trace,[′file′=>trace,['file'=>trace,[′file′=>file,'line'=>$line]); this−>error(500,this->error(500,this−>error(500,text,trace,trace,trace,level);}

After:
if ((level & error_reporting()) && !in_array(level, [E_DEPRECATED, E_USER_DEPRECATED, E_STRICT, E_NOTICE, E_USER_NOTICE])) { trace=trace=trace=this->trace(null, false); array_unshift(trace,[′file′=>trace,['file'=>trace,[′file′=>file,'line'=>$line]); this−>error(500,this->error(500,this−>error(500,text,trace,trace,trace,level);}


This keeps F3 strict about real errors (E_ERROR, E_WARNING, etc.) but
ignores the noisy non-fatal levels that PHP/WordPress are increasingly
emitting in 8.x.

**Question for @gdgsupport:** would you consider adding this hardening
to the Activation Kit by default, or at least documenting it? With the
PHP 8.4 ecosystem, every kit user running on a current shared hosting
will likely hit this sooner or later. The two-day debugging journey to
realize the root cause was a misleading error message is not a great UX.

Also — my XLS Padlock maintenance expired on 25.02.2026. I'm ready to
renew if there's a 2026 release of the Activation Kit that addresses
this proactively. Could you confirm whether such an update exists or
is planned?

Thank you,
Branislav

Thanks for the great feedback!

On the diagnosis itself

You are right, and the misleading error message is what makes this nasty. The FILTER_SANITIZE_STRING is deprecated message is emitted by some other component in the same PHP request lifecycle (typically WordPress itself in 6.7+, or one of its plugins running on the same domain), and Fat-Free's default set_error_handler in base.php then promotes that deprecation to a fatal HTTP 500. The Activation Kit code is clean, F3 is clean, but together with WordPress on the same hosting they create a tripwire.

Your patch to the F3 set_error_handler callback (filtering E_DEPRECATED, E_USER_DEPRECATED, E_STRICT, E_NOTICE, E_USER_NOTICE from the 500-conversion path) is the right fix.

Question 1: future Activation Kit release

Good news on this front: an Activation Kit 2026 is planned alongside XLS Padlock 2026, which will be released shortly. The 2026 kit will be compatible with the latest PHP versions out of the box, so the type of scenario you ran into will be addressed proactively in that release.

If anyone reading this needs the immediate fix on a current kit version, your patch (the !in_array($level, [E_DEPRECATED, E_USER_DEPRECATED, E_STRICT, E_NOTICE, E_USER_NOTICE]) guard around the error() call in vendor/bcosca/fatfree-core/base.php) is the way to go. It is a one-line surgical change with no impact on the kit's encryption flow or the defuse/php-encryption dependency.

Question 2: maintenance renewal and access to updates

Your XLS Padlock maintenance expired on 25.02.2026. Renewing reactivates your access to all subsequent kit updates (Activation Kit, Woo Integration Kit, FastSpring Subscription Kit) along with the desktop application updates. The renewal procedure is the standard one:

• Log in to your account at https://www.xlspadlock.com/account
  Click Renew Your Maintenance next to your XLS Padlock license. The Paddle checkout page will display the renewal price with the loyalty discount already applied.
• After payment, the updated maintenance status is reflected on your account page within minutes, and you can re-download the latest kits from the Downloads section.

If you renew now, you will automatically be entitled to XLS Padlock 2026 and the Activation Kit 2026 the moment they are published. To get notified at release, you can either watch the Paquet Builder / XLS Padlock announcements forums on this site (we post release threads there for every major and minor update) or subscribe to our newsletter from https://www.xlspadlock.com/newsletter, both channels announce new releases as soon as they are live.

On chunked vs Content-Length, while we are here

The XLS Padlock client (the HTTP layer inside the compiled EXE) does parse Transfer-Encoding: chunked responses correctly in current versions, so that part of your investigation should not have been a blocker on its own. However, when the response is a 124-byte intercepted error page sent before any kit logic runs, the issue is upstream of the transport encoding (the kit never got to produce a proper signed response), so even if the chunking had been parsed, the client would still have rejected the payload as invalid. Fixing the F3 handler is the right place to break the chain.