alexeynikolayev

Thank you for the PHP snippet; that does work as a fix for me, and performance is back to normal.

I’ll mark the thread as resolved, but hope the permanent solution will be added in one of the future releases.

Thank you for the quick response!

I may suggest to update the code to something like this

	public function join_download_count_compatibility( $join ) {
		global $wpdb;

		if ( ! DLM_Utils::table_checker( $wpdb->dlm_downloads ) ) {
			return $join;
		}

		$join .= " LEFT JOIN {$wpdb->dlm_downloads} ON ({$wpdb->posts}.ID = {$wpdb->dlm_downloads}.download_id) ";
    	$join .= "LEFT JOIN {$wpdb->postmeta} AS meta_downloads ON ({$wpdb->posts}.ID = meta_downloads.post_id AND meta_downloads.meta_key = '_download_count')";
		return $join;
	}

So the end query become

SELECT 
    wp_posts.*, 
    wp_dlm_downloads.download_count, 
    (IFNULL(wp_dlm_downloads.download_count, 0) + IFNULL(meta_downloads.meta_value, 0)) AS total_downloads, 
    wp_dlm_downloads.download_versions
FROM 
    wp_posts
LEFT JOIN 
    wp_dlm_downloads ON (wp_posts.ID = wp_dlm_downloads.download_id)
LEFT JOIN 
    wp_postmeta AS meta_downloads ON (wp_posts.ID = meta_downloads.post_id AND meta_downloads.meta_key = '_download_count') -- Changed join structure
WHERE 
    1=1 
    AND wp_posts.ID = 134068 
    AND wp_posts.post_type = 'dlm_download'
ORDER BY 
    wp_posts.post_date DESC;

That executes 0.001 sec rather than 2 sec on my local, but needs to be tested in case of functionality.