oiler

Hey there,

Thanks for all the info and for your patience.

Looking at the debug log, WP Rocket is still running during the test, which makes sense – deactivating it from the WordPress admin doesn’t fully remove it because it writes rules directly into your server’s .htaccess file, and those stick around regardless. So the conflict test wasn’t quite clean, but honestly I don’t think WP Rocket is the real culprit here anyway.

The bigger clue is that swapping the destination to another domain works fine. That tells us ThirstyAffiliates and the link itself are healthy – the issue is specifically with systeme.io as a destination. Your server seems to run LiteSpeed, which has its own built-in firewall and security layer that operates completely independently from WordPress and its plugins. Systeme.io does end up on some server-level block lists because it’s widely used in spam and phishing setups, so it’s not uncommon for hosts to filter it.

At this point I’d recommend reaching out to your hosting provider and asking them to check whether outbound redirects to systeme.io are being blocked at the server or firewall level. You can use something like this:

“Hi, I’m having an issue where a redirect on my site (blogwinst.nl) to https://systeme.io is not working – the server returns a 302 response but without a Location header, so visitors end up on a blank page. Redirects to other domains work fine. I’ve ruled out WordPress plugins and themes as the cause. Could you check whether systeme.io is being blocked or filtered at the server/firewall/WAF level, and whitelist it if so? Thank you.”

Once they confirm or clear that, please let us know what they say.

Thanks,
Euler.

Hi there,

I checked your link and can confirm what you’re seeing. When someone opens https://blogwinst.nl/go/systeme/, the server sends a redirect response but without a destination URL, so the browser ends up on a blank page instead of systeme.io. Your other links on the same site seem to redirect normally, so this looks tied to the systeme link itself rather than a general plugin or site issue.

The most common cause is something off in the destination URL on that one link – often a missing https://, a bad copy-paste with hidden characters, or a broken override if you’re using geolocation or link scheduling in Pro. For systeme.io, the destination should look like https://systeme.io/?sa=YOUR_AFFILIATE_ID.

Could you please open that link in ThirstyAffiliates, delete the destination URL, type it in again by hand, save, clear any site cache you’re using, and test /go/systeme/ in a private window? If it still misbehaves, a screenshot of the destination URL field (you can redact part of the affiliate ID) would help, along with whether geolocation or scheduling is enabled on that link.

Thanks,
Euler.

Hey @jalorod,

Thanks for your contact!

You’re right – by default, Pretty Links only validates standard URLs (with http://, https://, etc.) and mailto: links, so tel: URIs get rejected by the validation. It’s not a bug per se, but it’s definitely a gap we’re aware of.

That said, you can get this working with a small code snippet. If you install the free WPCode plugin, go to WPCode -> Snippets, create a new PHP snippet and paste this:

/**
 * Add tel: URI Support to Pretty Links
 */
function prli_support_tel_uris($is_valid) {
    $url = '';
    if (isset($_POST['url'])) {
        $url = sanitize_text_field($_POST['url']);
    } elseif (isset($_REQUEST['target_url'])) {
        $url = sanitize_text_field($_REQUEST['target_url']);
    }

    if (empty($url) || $is_valid) {
        return $is_valid;
    }

    if (preg_match('/^tel:(?:\+)?[\(]?[0-9][0-9\-\.\s\(\)]*[0-9]$/', $url)) {
        return true;
    }

    return $is_valid;
}
add_filter('prli_is_valid_url', 'prli_support_tel_uris', 10);

Once activated, you’ll be able to use phone numbers like tel:+12026952128 or tel:123-456-7890 as your target URL. So creating a Pretty Link like https://website.com/call that redirects to tel:123456789 will work, and clicks will be tracked as usual.

One thing to keep in mind – make sure parameter forwarding is set to “Off” on your tel: links (it’s off by default, so unless you changed this option, it you should be fine). Otherwise Pretty Links would append query strings to the phone number, which would break the dialer.

Feel free to let me know if you run into any issues with it. Thanks!

All the best,
Euler.

Hey there,

Thanks for reaching out!

What you’re seeing doesn’t match how PrettyLinks normally behaves: redirects are meant to run on your own domain, so if clicks are ending up on ushort.com instead of your site, something outside the plugin is likely rewriting or intercepting the URL. That can sometimes be a compromised site, but it can also come from email link tracking, a security filter, or something else in the path between the click and your server.

The detail that pasting the URL into the address bar works while a click from email does not is especially useful, because it suggests the problem might not be only on the WordPress side. To narrow it down, could you send one specific Pretty Link that does this, plus where you’re clicking it from? It would help to know whether it only happens from email or also when the same link is clicked from a normal webpage.

In the meantime, running a deeper scan with something like Wordfence or Sucuri is still a reasonable step, and it’s worth checking common places where unwanted redirects get injected, such as .htaccess, wp-config.php, and the database, for anything that references that third-party domain. Once we have a concrete example and a bit more context on how the link is being opened, we can point you in a clearer direction.

Looking forward to your reply. Thanks!

All the best,

Hey there,

Thanks for your contact and welcome to our support!

As a quick test, could you please try to remove the Pretty Links plugin and reinstall it? If the problem persists, we might be facing an interaction issue with a third-party functionality, in this case:

• Make sure to have a complete backup before proceeding, and if possible test it in a staging version, not in the live production website
• Deactivate all the plugins that are not related to
• Switch for a moment to a WordPress default theme like Twenty Twenty-one
• If the issue is gone, activate one by one to see with which one there is an interaction issue

Could you please tell me the results of this investigation? Moreover, can you please enable the debug mode? Just add the following code in your wp-config.php file:

// Enable WP_DEBUG mode
define( 'WP_DEBUG', true );

// Enable Debug logging to the /wp-content/debug.log file
define( 'WP_DEBUG_LOG', true );

// Disable display of errors and warnings
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

// Use dev versions of core JS and CSS files (only needed if you are modifying these core files)
define( 'SCRIPT_DEBUG', true );

Please check the following links to read more about debugging with WordPress.

• https://developer.ww.wp.xz.cn/advanced-administration/debug/debug-wordpress/
• https://developer.ww.wp.xz.cn/advanced-administration/debug/debug-wordpress/#example-wp-config-php-for-debugging

After adding the code above, try to reproduce the issue again and check if you’ll find a debug.log file inside the wp-content folder. If you locate it there, kindly send us the last lines here in the ticket.

I’m looking forward to your reply. Thank you!

Best regards,

Hi there,

Glad you figured it out, and thanks for sharing the solution – that’s a great find!

Just as a heads-up that wp cache flush can also flush the object cache directly (including Redis), which might be a simpler alternative to redis-cli in your deployment scripts if you ever want to streamline things down the line.

Regardless, hope everything keeps running smoothly!

Best regards,

Hi @rik0399,

Thank you for taking the time to lay out your feature request. Many of the offerings we have now came from people like you who took the time to tell us what they want.

I’ve added this to a feature request ticket for our developers to review. While we can’t say if or when it will be implemented, you can stay tuned to our changelog for updates on future versions: https://ww.wp.xz.cn/plugins/thirstyaffiliates/#developers and https://thirstyaffiliates.com/thirstyaffiliates-pro-changelog.

Thanks for helping us improve ThirstyAffiliates!

All the best,

Hey Greg,

Glad that it is fine now!

In this case, I hope we are good to close here, but please feel free to contact us anytime if you need assistance with our products.

Kind regards,