Tyler

Hi @dwaynebmwtokyo,

Thank you for reaching out. Would it be possible to provide me with the URL to your pretty link that’s redirecting correctly, and the URL to one of your pretty links that aren’t redirecting?

I look forward to hearing from you!

Kind regards,

Hi @londonnut,

Thank you for getting back to me and providing that detailed information. Since you’ve opened a support ticket via our website, I’ll go ahead and close out this support thread as I believe the behavior you’re experiencing with the <meta> tag may be related to one of our Pro features.

Kind regards,

Hi @outrospective,

Thank you for reaching out. The Pretty Links Settings is registered as a meta box in WordPress, so it might’ve been accidentally dragged over to the right-hand side of the page when the link was being edited.

Could you please hover over the dark bar at the top that shows the “Pretty Links Settings” text with your mouse then drag it back to the center of the screen (underneath the title) and see if that fixes the issue?

I hope this helps!

Kind regards,

Hi @peacepilgrim,

It looks like one of our support members has reached out to you via our ticketing system so I’ll go ahead and mark this thread as resolved.

Since you’re a premium member, please open a support ticket via the link they provided in their email and we’ll be happy to help get this sorted out for you.

Kind regards,

Hi @peacepilgrim,

Thank you for reaching out and taking an interest in our PrettyPay Links feature. To answer your questions:

a) I do believe that creating a PrettyPay link will greatly improve your sales and conversions. For one thing, you’ll be able to use your site’s domain name which adds credibility to any links you send out to users. Users who purchase products using one of these links can also be redirected to their own Thank You page set up within the Pretty Links plugin, and they’ll also be able to view invoices and manage subscriptions within their own unique customer portal.

b) There’s not currently a way to convert an existing pretty link into a PrettyPay link as there’s some specific information needed for the PrettyPay link to work such as the product you’re selling, the checkout message to show on the Stripe checkout page, etc.

However, once you’ve created your PrettyPay link, you could change the slug of your existing pretty link to something else and then use that same slug for your PrettyPay link on the PrettyPay Links page (Wp-Admin -> PrettyPay Links) and anytime that the link is accessed users will be redirected to your checkout page for that product.

I hope this helps!

Kind regards,

Hi @londonnut,

It’s nice to chat with you again, and I’m sorry to hear you’re still experiencing this behavior.

Would it be possible to provide me with the URLs to one of your pretty links that’s having the slow response time so I may see what might be causing the problem?

I look forward to hearing from you!

Kind regards,

Hi @londonnut,

Thank you for getting back to me, and I’m glad to hear the speeds are loading faster now! I’m thinking it might’ve been an intermittent issue with Litespeed or Cloudflare’s CDN as when the link is cached, our code shouldn’t be running at all.

Regarding the notice you’re receiving in the log file – this can sometimes occur if a cron event was scheduled but never got executed due to the schedule associated with it being removed.

Does Pretty Links get deactivated from time to time on your site? If it does, then you might’ve deactivated it while one of our cron events was scheduled, but since deactivating the plugin also removes our cron schedules (prli_cleanup_visitor_locks_interval in this case), WordPress will log that notice.

These are just notices though so they shouldn’t impact anything on your site or within the Pretty Links plugin.

I hope this helps!

Kind regards,

Hi @monetenfuchs,

Thank you for getting back to me. It doesn’t look like I mentioned this in my last response, but once you’ve reloaded the admin dashboard with that code I provided added you can remove it from your functions.php file as the “link_redirect_action” option will be deleted from the database.

Those two other deprecation notices you’re receiving appear to be a PHP 8 compatibility issue on our end. Our developers are working on making the plugin fully compatible with PHP 8 and those changes will fix these sorts of notices, but in the meantime, you can safely ignore them in your log file and Pretty Links will still function correctly.

The original notice you were receiving seems to have been caused by an old option we might’ve been storing in the plugin but removed support for in a later release, so I wanted to ensure we got that option removed for you.

I hope this helps!

Kind regards,

Hi @londonnut,

Thank you for reaching out. As long as your pretty links are cached then the time it takes for the redirect to occur will depend on how fast the client’s connection is with the particular caching solution you’re using.

Would it be possible to provide me with the URL for one of your pretty links where the redirect seems to be taking a while? I’ll try checking whether or not it’s currently being cached.

I look forward to hearing from you!

Kind regards,

Hi @benfrankie,

Thank you for reaching out. We don’t track the user’s geographical location when a link is clicked, but we do offer geographic redirects in the Pro version of the plugin so you could set up a pretty link specific for a particular region (like the US, UK, etc) and if a click is recorded for that link then you’ll know what region they’re from.

To filter clicks by a specific date range, you’ll want to navigate to the Clicks page (Wp-Admin -> Pretty Links -> Clicks) and then click the “Customize Report” button. This will display a popup where you can filter clicks by a particular start and end date.

To share those statistics with someone else, you can click the “Download CSV (All Links)” button at the bottom of the Clicks page and this will download a CSV file with that click data.

We don’t currently offer a way to redirect users to another URL after x amount of clicks but our Pro version offers a “Rotation” redirect type which can be used to send users to different URLs with one pretty link. The target URL they’ll be redirected to will occur randomly, but you can define weights on each rotation so if you set the target URL for Site A to 50% and the target URL for Site B to 50% then the user will be redirected to Site A half of the time and Site B for another half.

I hope this helps!

Kind regards,

Hi @andrew55,

Thank you for reaching out. There is a Public Link Creation tool we offer in the Pro version of Pretty Links that’ll allow users on the front end of your site to create pretty links from your site’s domain.

I hope this helps!

Kind regards,

Hi @peacepilgrim,

Thank you for reaching out. If your pretty links are associated with categories, then this could explain why they’re showing up in search results as most SEO plugins generate sitemaps that include those taxonomies.

Are you using any sort of SEO plugin? Some of these plugins such as Yoast allow you to alter the settings so that certain taxonomies and/or custom post types are excluded from the sitemap so you might try excluding these two taxonomies and see if that prevents further clicks going forward:

pretty-link-category
pretty-link-tag

I hope this helps!

Kind regards,

Hi @monetenfuchs,

Thank you for getting back to me. Do you have any additional plugins active on the site that integrate with Pretty Links? The “link_redirect_action” option isn’t something that we store in the database, so I’m wondering if it’s coming from somewhere else.

If you have any plugins that integrate with us, please try temporarily deactivating them and seeing if that helps to remove the deprecation notice you’re receiving.

If that still doesn’t help, please add this code snippet either to your theme’s functions.php or using a plugin such as WP Code and reload the admin dashboard once it’s added. This will remove the “link_redirect_action” option stored in the database so you should no longer receive that deprecation notice going forward:

add_action( 'admin_init', function() {
    $options = get_option( 'prli_options' );

    if ( $options && is_array( $options ) ) {
        unset( $options['link_redirect_action'] );

        $prli_options = new PrliOptions( $options );
        $prli_options->store();
    }
} );

I hope this helps!

Kind regards,

Hi there,

Thank you for reaching out. If you’re using a 301 redirect for your pretty links then the redirects should be cached by default in the user’s browser, but if you’re using a caching solution such as Cloudflare then other redirects such as 302 or 307 should be cached as well which will prevent requests to your web server.

However, please note that if a caching solution is in place then click tracking won’t work correctly since Pretty Link’s code won’t run to record that information so if you’re needing that data then I’d recommend excluding your pretty links from caching.

I hope this helps!

Kind regards,

Hi @monetenfuchs,

Thank you for reaching out. Our developers have tried searching the code base for the latest version of Pretty Links (3.6.0 at the time of writing this), but there doesn’t appear to be a “link_redirect_action” property we’re using.

Are you on an older version of Pretty Links? If so, please try upgrading to the latest version and see if that removes the deprecation notice from your site’s debug.log file going forward.

I hope this helps!

Kind regards,