Plugin Support
oiler
(@eulerarthur)
Hi there,
Thank you for this report!
To help us fully understand and reproduce this issue, could you share what steps you followed when you encountered this warning? For example:
– what were you doing when the log was generated? (e.g., creating/editing a post, saving a draft, using auto-save, etc.)
– what post type were you working with?
– do you have keyword replacement enabled, and if so, for which post types?
– what permalink structure does your site use?
Regardless, we’ll be reviewing the code in pro/app/models/PlpKeyword.php to investigate the issue and see what can be done to prevent this deprecation warning in PHP 8.2+. This thread will be updated once we have more information.
Thank you,
The error seems to be triggered if
- any visitor in frontend visits
- a taxonomy archive (both
post_tag and category) page
- and if the first shown entry
- has a
Target URL pointing to external site
- without any further path
Target URL like this: https://www.example.com
Post type: post
Keyword Replacements is enabled, for post, page and a custom post type
Permalink structure: /%category%/%postname%/
Additional observation, error also triggered on
- date archive page, like
/2025/04/
- and in general also on paged archive pages like
/tag/abc/page/4/ or /2025/04/page/3/ etc.
Plugin Support
oiler
(@eulerarthur)
Hi there,
Thanks for the details!
I’ll be better checking this matter in the next hours. You can expect a response by the end of the day.
Appreciate your patience in the meantime.
Best regards,
Plugin Support
oiler
(@eulerarthur)
Hello there,
Thanks again for the additional details. We are still reviewing this issue but haven’t reached a conclusion yet. I’ll need a bit more time to properly investigate and test the scenarios you’ve described. I’ll follow up with more information tomorrow.
Thanks for your patience.
Best regards,
Plugin Support
oiler
(@eulerarthur)
Hey @ov3rfly,
Thanks for your patience!
I’ve been testing the scenarios you described but haven’t been able to reproduce the deprecation warning in a clean environment, which suggests it’s related to something specific in your site’s configuration. However, we’ve created a fix that adds a null check before the value is passed to $wpdb->esc_like(), which should prevent the deprecation warning you’re seeing.
Could you test this fix on your site and let us know if it resolves the issue? Please make sure to have a website backup before testing it. Then, in pro/app/models/PlpKeyword.php, replace lines 281-283:
$post_url_path = parse_url(get_permalink($post_id), PHP_URL_PATH);
$post_url_path = '%' . $wpdb->esc_like($post_url_path);
$and_str = $wpdb->prepare("AND li.url NOT LIKE %s", $post_url_path);
$post_url_path = parse_url(get_permalink($post_id), PHP_URL_PATH);$post_url_path = '%' . $wpdb->esc_like($post_url_path);$and_str = $wpdb->prepare("AND li.url NOT LIKE %s", $post_url_path);
with:
$post_url_path = parse_url(get_permalink($post_id), PHP_URL_PATH);
if($post_url_path !== null) {
$post_url_path = '%' . $wpdb->esc_like($post_url_path);
$and_str = $wpdb->prepare("AND li.url NOT LIKE %s", $post_url_path);
} else {
$and_str = '';
}
$post_url_path = parse_url(get_permalink($post_id), PHP_URL_PATH);if($post_url_path !== null) { $post_url_path = '%' . $wpdb->esc_like($post_url_path); $and_str = $wpdb->prepare("AND li.url NOT LIKE %s", $post_url_path);} else { $and_str = '';}
This should be included in the next plugin update. Also ensure to have a backup copy of this file before testing it, and kindly let us know if this resolves the warnings on your site.
Thanks,
Thanks for the feedback. Your code seems a bit messed up with that extra last line but I got the idea and added a $post_url_path !== null check and it now seems to catch the above cases and does not call empty $wpdb->esc_like() any more.
As a sidenote, I do not really understand the whole function yet as e.g. a Target URL like this https://www.example.com/ (note the training slash) creates a '%' . $wpdb->esc_like('/') for the $and_str and compares li.url to be not like that, not sure if that case makes sense.
Plugin Support
oiler
(@eulerarthur)
Hi @ov3rfly,
Regarding your sidenote about the trailing slash case – you’re right to point out the logic, but in practice it works correctly. We’ve tested this on clean installs with various permalink structures (including plain permalinks where post paths are just /), and keyword replacement functions properly on archives, single posts, and homepages.
The code is designed to prevent self-referencing links by excluding Pretty Links whose target URLs match the current post’s path. While the logic with NOT LIKE '%/' might seem too broad when the path is /, WordPress’s permalink handling and the way the function is called ensures keywords still get replaced correctly.
And sorry about that extra duplicated line at the end of my code snippet – the WordPress.org forums sometimes mangle code block formatting!
Thanks again for the detailed report and for testing the fix!
Best regards,
Appears to be fixed with PrettyLinks 3.6.18, thanks for quick response.
Plugin Support
oiler
(@eulerarthur)
Hey there,
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,
