Affiliate-Toolkit 3.8.6: Why We Changed the Template Rendering

With version 3.8.6 of affiliate-toolkit, we introduced a security-related change to the template rendering. Since this change can affect existing installations and was not communicated prominently enough in the changelog, this post summarizes the background, the impact, and the steps required.

What changed

Starting with version 3.8.6, raw PHP code – anything inside <?php … ?> blocks – is automatically removed from templates before Blade rendering and is no longer executed. Only Blade template syntax is allowed.

Why we did this

The affiliate-toolkit plugin was temporarily removed from the WordPress.org Plugin Directory by the Plugin Review Team due to a security vulnerability. The ability to execute arbitrary PHP code through templates was part of the problem.

The sanitization in 3.8.6 is the fix that brought the plugin back into the directory. This change was not optional – without it, the plugin would not currently be available through the official directory.

Who is affected

If you use only the default templates and default outputs, you generally don't need to do anything. The change affects installations with custom templates or snippets that contain PHP code – for example, custom product boxes, offer lists, or AJAX outputs. In those cases, outputs may be incomplete or empty until the templates have been migrated.

Typical symptoms:

• Product boxes appear empty
• More-offers or detail-offers no longer render
• AJAX-based product displays load no data
• Custom snippets break without a visible error

Migrating to Blade syntax

The most common constructs can be replaced one-to-one:

<?php echo $var; ?>                   →  {{ $var }}
<?php if (...): ?> … <?php endif; ?>  →  @if(...) … @endif
<?php foreach (...): ?> … endforeach  →  @foreach(...) … @endforeach
<?php echo esc_html($x); ?>           →  {{ $x }}        (escaping is the default)
<?php echo $raw; ?>                   →  {!! $raw !!}    (unescaped, only for trusted sources)

For cases where Blade is not sufficient – custom helper functions, more complex calculations, or external API calls – the intended path is a custom filter or hook in a child plugin or the theme, not PHP directly in the template.

Why the circulating hotfix is not a solution

A hotfix is being shared in the support forum that disables the sanitization by commenting out a single line (self::sanitize_template_content()). We strongly advise against applying it.

Doing so fully reopens the original security vulnerability on your installation. It once again allows arbitrary PHP code to be executed via template content – including indirectly, through imported or shared templates. This is not a theoretical risk; it is precisely the reason the plugin was suspended.

Anyone applying the hotfix assumes full responsibility for the resulting security risks on their site.

What we are doing better

A change with this kind of impact on existing templates should have been featured prominently in the changelog, not just as a note in the template editor. That was a communication failure, and we apologize to everyone affected. We are restructuring our release communication accordingly for future security-related releases.