oiler

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.wordpress.org/advanced-administration/debug/debug-wordpress/
• https://developer.wordpress.org/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://wordpress.org/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,

Hi Michael,

Thanks for your kind words! Could you please also post them in our special ‘Reviews’ section: https://wordpress.org/support/plugin/pretty-link/reviews/? This channel here is focused on the support side, while the ‘reviews’ seems more appropriate for the purpose of your message.

I hope it helps to clarify, but please feel free to reach out again if you need further assistance. Thank you!

All the best,

Hi there,

You could also try to clear both update transients before running the command:

wp transient delete prli_update_info
wp transient delete update_plugins
wp plugin update pretty-link

It should force WordPress to fetch fresh update information and recognize the Pro version properly. If that still doesn’t work consistently across your pods, though, the manual “Install Pro” click might be the most reliable approach for your setup.

Hope this helps. Thanks!

Best regards,
Euler.