[Resolved] Fatal error in WPML and Disappearing Translated Images

Thanks — this is progress.

1. Cloudflare note: the IPs listed (172.x / 162.x / 198.41.x) are Cloudflare edge IPs, so they don’t identify the real visitor. To pinpoint the source, we’ll need the requested URLs and/or the real client IP via Cloudflare headers (e.g. CF-Connecting-IP / X-Forwarded-For) or Cloudflare analytics/logs for that same time window.

2. Raw slow queries: could you please paste here the full content of 1–3 slow-query blocks from slow_queries_over5s_recent20.log, especially the one with Query_time: 72.953276? Each block should include the # Query_time… header lines and the full SELECT … statement. With that, we can identify which post type/meta keys/taxonomies are involved and whether it originates from a specific plugin/theme filter/search page.

3. Immediate mitigation: please ensure page caching is enabled for non-logged-in visitors, and if you’re using Cloudflare, add a rate limit / cache rule for common heavy endpoints (/wp-admin/admin-ajax.php, /wp-json/) and any filter/listing pages. This reduces repeated uncached DB-heavy requests and usually prevents another spike even before the root cause is confirmed.

We don't have cpanel access, so please upload the logs/files to something like DropBox or Google Drive and share the links here. You can use my email lauren.j@onthegosystems.com to share the documents with. Thanks!

Hi Rogelio!

Thank you for your patience! I have read all the conversation and now I have a better sense of the situation.

Let me start with the mysql spikes situation:
This a problem that is going beyond to the WPML ecosystem because this situation brings more things in context like the following:

1. A large and heavy query generated by a filtering feature. Sometimes, filters bring situations like this in the way how the database increase or the site start receiving visits.
2. A weird quantity of visits from an origin as reported in the logs.

So, based on this knowledge, let's start with some "short terms" improvements:

1. Page caching: Enable full page cache for logged-out visitors on listing and archive pages so repeated hits do not hit MySQL. (think that Lauren already recommended this before)
2. Cloudflare (or similar): Rate limiting for admin-ajax.php, /wp-json/, and for the main property listing/filter URLs. It will help to mitigate possible DDoS or weird requests (looks like we are experimenting this)
Cache rules so that listing pages (or their main variants) can be cached where possible.
3. Object cache: If the server offers Redis or Memcached, enable WordPress object cache. This reduces repeated meta/option lookups and can lower DB load during spikes. (This is so so important when we have filtering features like the one you have on your site)
4. Block/limit bad traffic: As done for 207.180.211.2, block or challenge IPs that hit suspicious URLs and cause unnecessary load.

Now, I have reviewed the theme code in order to see what else we can do and found some "long terms" improvements to follow (these probably will require a developer):

1. Target AJAX first: Rate-limit or cache responses for:
- admin-ajax.php with action=houzez_loadmore_properties
- admin-ajax.php with action=houzez_half_map_listings
Cache key should include a hash of the request params (filters, paged, etc.) so different filter combinations get different cache entries. Short TTL (e.g. 1–5 minutes) is often enough to absorb traffic spikes.

2. Sort by title: If listing or search default sort is "Sort by Title" (a_title / d_title), consider changing the default to "Newest first" (d_date) in theme options (listing page meta fave_properties_sort, or options search_default_order / taxonomy_default_order). Title ordering on large posts + postmeta joins is expensive.

3. Indexes: Since we have hard filtering, always indexing is important to improve the performance on SQL queries. So, ensure

wp_postmeta

has a composite index on (meta_key, meta_value(X)) for the main filter keys (fave_property_price, fave_property_bedrooms, fave_property_bathrooms, fave_agents, fave_property_agency, fave_featured).

Your site uses several filters: price, bedrooms, bathrooms, agents, agencies, etc. We are not asking for a different index for each of those. We’re asking for one index that works for all of them.

That one index is built so the server can quickly find rows by:
- first “type of data” (e.g. price, bedrooms, agents), and
- then the value (e.g. “between 100k and 500k”, “2 or more”, etc.).

So the same index helps when someone filters by price, by bedrooms, by agents, or by any combination. One change, all those lookups get faster.

IMPORTANT: For this improvement, I do recommend do this first on a test or staging environment. Would be great to have a developer to attack this one. Please let me know if you need more information about it.

4. Reduce meta_query clauses: Where possible, avoid stacking many fave_* meta_query conditions in a single query. The theme's Houzez_Data_Source::property_filter_callback and Houzez_Property_Search::properties_search add all active filters; if the site uses many filters at once, consider (with theme/developer) a two-step approach (e.g. taxonomy + one main meta filter first, then refine) or a denormalized table for filterable fields.

Conclusions
It is important that this situation will probably continue if we do not cover at least one of the recommendations. The main problem is that we have hard queries created by the filtering feature for properties. Personally, having the object-cache running with Redis or Memcached is really important, almost crucial to improve all this.

Hi Rogelio,

I have dedicated some extra time investigating here the situation because we have similar situation like this in our track list. So, from our end we are working on finding an improvement for these filtering cases. However, your particular issue is more focused on the theme you are using right now. Here are some thoughts about it:

- The Houzez theme is causing the heavy database load; it does not follow good practices on the main listing/search paths (caching exists but isn’t used there, and there’s no protection against repeated heavy requests).
- WPML only adds language filtering to the same queries; it is not the root cause of the spikes.
- Implementing caching (theme + page + object cache), rate limiting, and database indexes will reduce or prevent the MySQL spikes. The customer should involve their developer for theme/cache changes and their host for server cache, object cache, and indexes.

So, this information is helpful to provide to a developer in order to improve the theme. Important to clarify that main issue is on the theme and the way how it runs queries on the filtering features.

Regarding the other question on adding the new languages. Adding more languages will be equal to have the same issue. The problem is not how many languages do you have, the problem is the way how the queries are running on the theme when customer navigates/uses the filtering.

If you need more information about the issue, I'll happy to help.

Best,
Ddavid