Thank you for your response and for the detailed recommendation.
Currently, we are not using any specific templates for categories and tags. We use archive.php as a common template for all the taxonomies on the website. I would like to get your opinion on using a common tag template (tag.php) instead of a "tag-slug.php" template for a specific term. We chose a common archive template because the design is similar for all listing pages.
If you think creating a common tag template (tag.php) for all tags would be beneficial, we are open to proceeding in that direction. However, creating separate tag-archive templates for each individual tag is not feasible since we have more than 500 tags in English alone. Could you please share your thoughts on this approach?
In the meantime, we will look into implementing the tag.php template and observe the results.
Languages: English (English )Spanish (Español )German (Deutsch )
Timezone: America/Lima (GMT-05:00)
Hello Vimal,
Thank you for your answer!
I believe a common tag template would be ideal for testing. If all templates are identical, then there should be no need to create specific templates for each tag.
I really hope that this suggestion can solve the issue.
Thank you for your response and for confirming the approach.
We will proceed with implementing a common tag template (`tag.php`) and will monitor the results. I appreciate your suggestions, and I hope this resolves the issue as well.
In addition, I have noticed a 500 response in the access logs, and I investigated the issue further by checking both the Apache error log and Redis errors. Below are the relevant errors for your review:
Apache Error Log:-
[Thu Sep 19 10:26:24.914289 2024] [proxy_fcgi:error] [pid 3005015:tid 127717406148288] [client 172.70.110.220:27296] AH01071: Got error 'PHP message: PHP Warning: Undefined array key 0 in /var/www/html/wp-content/plugins/wpml-media-translation/classes/class-wpml-media-attachment-by-url-query.php on line 99;
Multiple similar warnings appear regarding undefined array keys in WPML Media Translation.
Additionally, I’ve attached the Redis error logs for your reference.
Could you please confirm if you've had a chance to check the Redis object cache issue that I mentioned earlier? It seems that we are facing problems due to too many requests from the WPML plugin, which is affecting the Redis object cache performance. If you need any further details or additional logs, feel free to let me know.
Regarding the Yoast Premium issue, we had encountered the same problem on our live website, which was resolved by disabling the Wincher integration, following the recommendation from the Yoast plugin support team. I have applied the same fix to the staging site, and I believe this should address the error you highlighted.
However, our primary concern relates to the Redis issues. We are experiencing challenges when using the WPML plugin in combination with the Redis Object Cache plugin. These issues have been affecting performance, and we've raised similar concerns in previous communications.
If further investigation is required, we can provide the latest Apache, Error, and Redis logs from the live website to assist in troubleshooting. Please let us know how you'd like to proceed and if any additional information is needed.
Languages: English (English )Spanish (Español )German (Deutsch )
Timezone: America/Lima (GMT-05:00)
My apologies for the delay in answering.
I enabled Redis Cache on the Staging yesterday and I would need some more details about, if you can currently see similar issues on the staging site and if so, where can I see them?
---
Regarding the slow query which we talked about earlier:
IMPORTANT:
I suggest again using a tag.php template and using a simplified query, designed to obtain the posts for each archive instead of a general query located on functions.php that servers for various purposes.
Would you agree if we give this a test on the staging site?
Example: hidden link
Average Load time 1.0 seconds on first-page load including a slow query from WPML of 0.5 seconds.
This persists when testing only with the Custom Theme, Advanced Ads, ACF PRO and Redis Object Cache, WP Rocket, WPML and String Translation.
I can still confirm this slow query on the original and translated tag archives that sometimes occurs on the first-page load only or can occur persistently.
---
Revising WPML > Taxonomy Translation > Tags shows that not all tags have been translated and the taxonomy base "tag" was not translated. I suggest completing those translations.
I further have a question:
Is there a reason for having for example 1834 Korean tags on the site? Those seem to be original tags and they are not created in the site's default language.
If you create an original post in English, then it will make use of available categories and tags that were created in English. The translations of those posts will then use the translations of the categories and tags.
Or are you trying to use different tags on translated posts and not sync them between the original posts and their translations?
Please revise the list of tags at WPML > Taxonomy Translation > Tags.
Revise between pages 19-50. You will find many tags that are registered in languages other than the site's default language.
I would suggest cleaning those up and only using tags that are registered in the site's default language. The translated posts will use the translations of those tags automatically, once they are translated.
---
After cleaning up, I also suggest going to WPML > Support > Troubleshooting and running all available options to clean up the database and optimize WPML's tables.
Thank you for your detailed response and suggestions.
We will share the requested logs with you shortly to assist in your further investigation.
In the meantime, we will review and address the recommendations you provided, including the tag translation and cleanup in WPML, as well as testing a simplified query with the tag.php template on the staging site.
We appreciate your continued support and will keep you updated on our progress.
As promised, please find attached the latest Apache, Error, and Redis logs from the live site. These logs should provide more insight into the issues we've been facing with the Redis Object Cache when used alongside the WPML plugin, as well as when WPML is used on its own.
Logs :- hidden link
Please let us know if you need any additional information.
I hope this email finds you well. I would like to inform you that we are still working on the issues and appreciate your continued assistance. We are actively monitoring the situation and will update you with further details once we have more information or if we require additional support.
Thank you for your understanding, and we look forward to resolving this soon.
Languages: English (English )Spanish (Español )German (Deutsch )
Timezone: America/Lima (GMT-05:00)
Hi Vimal,
I am running WPML > Settings > Media Translation > Start which will create the media entries for all the uploaded media. This is necessary to display the original media on all languages.
There are more than 200k entries that needed to be created, which means this could take various hours.
I will contact you tomorrow, once I will be able to continue testing.
Languages: English (English )Spanish (Español )German (Deutsch )
Timezone: America/Lima (GMT-05:00)
The media appears to be synced now.
The website has around 30.000 images and 9 active languages. This makes 270.000 entries inside the media library (once for each language).
Could you please run a test on the staging site and let me know if you can still experience the issues regarding slow media queries?
Question:
Is the whole media really used on the website or would you consider to try to clean up the media library and remove media that is not in use on any of the posts or pages?
Thank you for your continued testing and the update regarding the media synchronization.
Since we operate a news/blog website, it's common for us to upload images for every article, both as featured images and inline images. However, with 270,000 media entries across 9 languages, we are concerned that this might be an unusually large amount. Could such a large number of images affect website performance, or cause any other issues? We would appreciate your feedback on this.
Additionally, we upload only one image for each article, which is then duplicated across all languages. We don't require different images for each language version of the same article unless there’s a specific need. Is there a way to prevent automatic duplication of images across translations, and only upload different images when necessary? Ideally, we would like the same image used across all languages unless manually specified otherwise. Could you guide us on whether this can be managed through any settings or adjustments?
Looking forward to your feedback.
Best regards,
Vimal Roy
The topic ‘[Closed] Very slow queries’ is closed to new replies.
