Thank you for your follow-up and for letting us know about the access issue.
I will promptly check the problem with the server permissions and will work on restoring the functions.php file or the entire theme with a fresh copy from our live site. I will also ensure that your access is fully restored so you can proceed with the testing without any further interruptions.
I will provide you with the latest cloned version of the live site on the staging environment as soon as possible.
In the meantime, please continue your investigation on the local copy that you have created earlier using the files we provided.
Thank you for your patience, and I will update you once the staging site is operational again.
Our second tier supported checked the access, but sadly they do not have permission to access the theme folder on this installation. So can you provide provide unrestricted server access.
Also our second tier mentioned that that those slow queries only occur if the custom theme is enabled. So can you use a default theme and check the issue and monitor the performance?
I apologize for the oversight regarding the access permissions. We also faced similar issues when accessing the folders and files inside the wp-content directory. However, we have now adjusted the permissions and access settings, and the issue should be resolved. However the file modification is not possible with that account. So, we have created another SFTP account with more privileges, if you enable the private/secure message option, i can share the details.
Regarding your suggestion to test the default theme: the default theme does not display posts from other languages; it only shows English posts. Additionally, it lacks the separate sections on the homepage to display articles by category, which is a key feature of our custom theme. This is precisely why we built a custom theme and implemented WPML.
Disabling WPML does indeed improve the website's performance and speed significantly. As you’ve likely noticed, the website loads perfectly when using our custom theme with WPML disabled. Currently, we have over 58,000 posts in total, with only about 19,000 in English. Disabling WPML and its related plugins allows the website to function properly, regardless of whether we use the default "Twenty Twenty-Four" theme or our custom theme. However, once WPML is activated, the site performance starts to decline. The slow queries you have observed are also related to WPML. I encourage you to deactivate WPML, test again, and note the performance difference when WPML is both activated and deactivated.
As for using the default theme instead of the custom one, the default theme does not have pages and sections similar to what we currently use. If we were to switch, we would need to customize the default theme to match our requirements. Additionally, we have a specific design and layout for our website, which would also need to be integrated into the default theme, requiring further customization.
Please review our custom theme code; it only uses the WP Query method to display posts, with no other complex or slow functions involved. If we were to use the default theme, we would have to implement similar functions and code, so the performance issue might persist if WPML is still active.
We look forward to your further insights and recommendations on how to address the performance issues related to WPML.
You can create the keys here, if needed: hidden link
I enabled WP DEBUG and did not catch any errors.
At the moment, QUERY MONITOR was displaying any slow query on the hompage. The homepage loads in all languages in 0.8-0.9 seconds.
We saw a slightly slow query on tag archives, like: hidden link
The query filtered for the tag IDs:
2278,2291,6406
This comes from:
PostFetcher->fetch_posts()
wp-content/themes/coinedition/functions.php:361 where new WP_Query($args); is called.
public function fetch_posts()
{
$args = array(
'post_type' => 'post', //"post" post type
'post_status' => 'publish', //only published articles
'orderby' => 'date', // Order by date
'order' => 'DESC', // Order in descending order (newest first)
'suppress_filters' => false, // Let WPML apply its filters
'fields' => 'ids', // Only retrieves post IDs
);
` if ($this->offset) {` ` $args['offset'] = $this->offset;` ` }`
if ($this->posts_per_page) {
$args['posts_per_page'] = $this->posts_per_page;
}
` if ($this->is_tag) {` ` $args['tag'] = $this->is_tag;` ` }`
if ($this->category) {
$args['category_name'] = $this->category;
}
` if ($this->category_id) {` ` $args['cat'] = array($this->category_id);` ` }`
if ($this->paged) {
$args['paged'] = $this->paged;
$args['no_found_rows'] = false;
} else {
$args['no_found_rows'] = true;
}
` if ($this->author) {` ` $args['author'] = $this->author;` ` }`
if ($this->exclude) {
$args['post__not_in'] = array($this->exclude);
}
` $query = new WP_Query($args);`
return $query;
}
}
I replaced this query with a default query, then reverted my changes and I am not sure why, but at the moment the slow query is gone and the archive page load in German in 0.5 seconds:
See: hidden link hidden link
I can currently not see the issue anymore on the Staging Site. I have revised more than a dozen archive pages (post categories and tags) in German, and there is not any slow query occurring. All pages load in 0.6 seconds.
Could you please have another look into that and let me know if you can still confirm the slow query on the staging site?
Thank you for your detailed response and for informing us about the missing nonce key in the wp-config.php file. We appreciate your efforts in generating the necessary keys, and we will ensure that the appropriate changes are made as soon as possible.
It's great to hear that the slow queries are no longer appearing on the website. However, it's quite peculiar that simply reverting your changes resolved the issue. As we are using Redis object caching, I’m wondering if the disappearance of the slow queries might be related to the object caching mechanism. Since object caching is designed to store and retrieve cached query results, it’s possible that the slow queries were cached and are not showing up now due to this.
Could you please check the staging site performance again after disabling the object cache? You can easily disable object caching through the settings. I’ve attached a screenshot for your reference on how to disable it.
Additionally, we have previously reported some issues with the Redis object cache, particularly when interacting with the WPML plugin. It seems that our Redis object cache fails to function properly due to the excessive number of requests made by WPML. You can find more details in the earlier messages of this ticket. If you need further information, such as Access Logs, Error Logs, Redis Logs, or anything else, please let us know, and we will be happy to provide them.
We will also check the website from our side how it is working now.
Thank you for your support, and we look forward to your findings.
I can see that the slow query is back on the staging, when visiting the German "Blockchain 101" archive.
It takes 0.6-0.8 seconds or load time.
This is the query:
SELECT wp_posts.ID
FROM wp_posts JOIN wp_icl_translations wpml_translations
ON wp_posts.ID = wpml_translations.element_id
AND wpml_translations.element_type = CONCAT('post_', wp_posts.post_type)
WHERE 1=1
AND ( wp_posts.ID NOT IN (
SELECT object_id
FROM wp_term_relationships
WHERE term_taxonomy_id IN (2278,2291,6406) ) )
AND wp_posts.post_type = 'post'
AND ((wp_posts.post_status = 'publish'))
AND ( ( ( wpml_translations.language_code = 'de'
OR ( wpml_translations.language_code = 'en'
AND wp_posts.post_type IN ( 'page' )
AND ( ( (
SELECT COUNT(element_id)
FROM wp_icl_translations
WHERE trid = wpml_translations.trid
AND language_code = 'de' ) = 0 )
OR ( (
SELECT COUNT(element_id)
FROM wp_icl_translations t2 JOIN wp_posts p
ON p.id = t2.element_id
WHERE t2.trid = wpml_translations.trid
AND t2.language_code = 'de'
AND ( p.post_status = 'publish'
OR p.post_status = 'private'
OR ( p.post_type='attachment'
AND p.post_status = 'inherit' ) ) ) = 0 ) ) ) )
AND wp_posts.post_type IN ('post','page','attachment','wp_block','wp_template','wp_template_part','wp_navigation','cookielawinfo' ) )
OR wp_posts.post_type NOT IN ('post','page','attachment','wp_block','wp_template','wp_template_part','wp_navigation','cookielawinfo' ) )
GROUP BY wp_posts.ID
ORDER BY wp_posts.post_date DESC
LIMIT 0, 6
The Call Stack is:
WP_Query->get_posts()
wp-includes/class-wp-query.php:3238
WP_Query->query()
wp-includes/class-wp-query.php:3852
WP_Query->__construct()
wp-includes/class-wp-query.php:3984
PostFetcher->fetch_posts()
wp-content/themes/coinedition/functions.php:361
Now, this query from your functions.php file has many conditions as it seems to be a general query solution for various use cases.
---
Recommendation:
Maybe it would be advisable to use a smaller query, simply designed to call nothing else but the posts assigned to such tag, direclty on the template file for such a tag-archive?
Let's say you would have a template parts file called:
tag-blockchain-101.php
You could use WP_QUERY to call the posts specifically for this archive template:
Example:
<?php
// Define the term ID
// Set up the WP_Query arguments
$args = array(
'post_type' => 'post', // Specify the post type
'post_status' => 'publish', // Only published posts
'posts_per_page' => -1, // Retrieve all posts (you can set a specific number if desired)
'tax_query' => array(
array(
'taxonomy' => 'post_tag', // Specify the taxonomy
'field' => 'term_id',
),
),
'supress_filters' = false,
);
// Create a new WP_Query instance
$query = new WP_Query($args);
// Check if there are posts
if ($query->have_posts()) {
echo '<h1>Posts Tagged with Term ID ' . esc_html($term_id) . '</h1>';
while ($query->have_posts()) {
$query->the_post();
// Output post title and link (customize as needed)
echo '<h2><a href="' . get_permalink() . '">' . get_the_title() . '</a></h2>';
}
// Reset post data
wp_reset_postdata();
} else {
echo '<p>No posts found for this term ID.</p>';
}
?>
Like this the SQL query would just look like this and load way faster:
Example:
SELECT wp_posts.ID
FROM wp_posts
JOIN wp_term_relationships ON wp_posts.ID = wp_term_relationships.object_id
WHERE wp_term_relationships.term_taxonomy_id IN (2278, 2291, 6406)
AND wp_posts.post_type = 'post'
AND wp_posts.post_status = 'publish'
ORDER BY wp_posts.post_date DESC
LIMIT 0, 6;
