Performance improvement for resolve_image_id()

saw your reply in a similar thread. We noticed this because the queries were melting our database servers (7x mariadb galera).

it is mostly for older, imported posts from another CMS, which don’t include a post ID in their markup. I did notice it for a few hand placed img tags too, here and there in our templates, like this:

<img src="https://www.washingtonian.com/wp-content/themes/washingtonian/assets/img/wash_logo_blue.svg" class="img-responsive" alt="Washingtonian.com">

In chasing this down further I found that the expensive query isn’t really needed. There is a core WP function that does the same thing faster. Here is the updated version of this function that works for us. Sorry about the indentation, this forum software seems to mess with it.

function resolve_image_id( $url ) {

	$pattern = '/[_-]\d+x\d+(?=\.[a-z]{3,4}$)/';
	$url = preg_replace( $pattern, '', $url );
	$url = $this->get_pathinfo_from_image_src( $url );

        $cacheKey = "gallery-custom-links-id-" . $url;
        $cacheGroup = "gallery-custom-links";
        $cached = wp_cache_get($cacheKey, $cacheGroup);

        if ($cached != null) {
            return $cached;
        }

	$result = attachment_url_to_postid($url);
	wp_cache_set($cacheKey, $result, $cacheGroup, 7*24*60*60);
	return $result;
}

P.S., we tried to enable the plugin only on pages that use it, but ran into some problems. I think it’s because it checks the filter at “init” hook (start() function), which is too early to have access to any information that would let us make a dynamic decision about whether the post actually needs it.

is it possible that the performance issues are caused by this line being commented out in the released plugin?

		//$classes = apply_filters( 'gallery_custom_links_classes', array( '.entry-content', '.gallery', '.wp-block-gallery' ) );

*crickets*

we switched back to wp-gallery-custom-links by johnogg and our database cluster calmed down immediately.

Hi @chriscombsdc,

I am reading all this, no worries ?? To be honest, I think the performance issue is that my plugin is using a DOM Parser, and that’s an advantage for many things, as the old plugin from johnogg (he is actually not the developer of it, and does not maintain it) is using regexp to modify the HTML, which doesn’t work in many, many cases.

I still need to add options in my plugin. Originally, it didn’t use the DOM Parser, and only used the filters available in WP. Thanks to that, it was super fast and worked really well. Unfortunately, to support old-style install of WordPress (the ones not using Responsive Images for example), I had to scan the HTML, and for that, I had to use the DOM Parser. I could have done it with regexp, it might be faster in many cases, but makes the code really difficult/tricky and difficult to maintain, which is far from being my ideal goal for this plugin.

There will be options soon, I promise ??

thanks! What was killing our database servers was searching by guid for every img tag in the page, whether or not they were part of a gallery dom element.