If a WPML-related database table keeps growing, identify its purpose and measure the change before deleting rows. The URL resolution cache, a persistent object cache such as Redis, and a page-cache copy of HTML are different layers. Clearing one does not establish that you repaired the others.
Check whether the reported release correction fits
The WPML 5.2.0 changelog lists a correction for unbounded URL resolution cache growth and unnecessary whole-table counting when routing settings are saved. That makes the installed version relevant. It does not prove that any large table, or every slow settings screen, has this defect.
Record the exact table identified by the host, the installation or subsite it belongs to, and the installed WPML components. Ask the developer to confirm ownership from the actual installation. Table prefixes and deployment layouts vary; do not copy a table name from an unrelated screenshot into a cleanup command.
If the symptom is a translated menu showing the wrong language with Redis, start with the WPML menu and persistent-object-cache guide. If the public page is correct but an authorized draft preview uses the wrong domain, use the preview language and domain diagnostic. Neither symptom alone demonstrates database growth.
Collect two snapshots, not one alarming number
Ask the host for a bounded observation window and use the same measurement method at both ends. Record data size, index size, how row count was obtained, and observation time. A database's estimated row count and an exact count are not interchangeable. Avoid scheduling repeated full-table counts on a database already under load.
Include the request pattern during the interval: ordinary browsing, imports, a crawl, language changes or routing-settings saves. Use existing logs and host metrics where available instead of generating a flood of requests to make the table grow. Redact query parameters and visitor information from anything shared outside the team.
| Evidence |
Why it matters |
| Table identity and owner |
Prevents cleanup of unrelated application data |
| Data and index size at two times |
Distinguishes current footprint from growth |
| Approximate or exact row-count method |
Keeps measurements comparable |
| Request volume and relevant admin actions |
Provides context for the change |
| Error or settings-save duration |
Connects storage observations to user impact |
Compare a table-size snapshot with growth over a defined interval. A large table can be stable, and a small table can be growing quickly. Illustrative shapes, not measured results. Explanatory diagram.
Use a narrow staging comparison
Keep a restorable database and file backup. On protected staging, preserve the language URL format and enough representative content to exercise routing. Disable outgoing production integrations and avoid copying unnecessary personal data. A miniature empty site may verify installation but cannot demonstrate behavior under your site's workload.
Reproduce a small, documented sequence of normal requests and the affected settings action before updating. Apply the supported WPML update path with compatible add-ons, then repeat the same sequence. Keep other cache settings unchanged initially. This isolates the application update from a simultaneous Redis flush, hosting change or database cleanup.
If additional instrumentation is authorized, Query Monitor's guide explains how to identify query callers and durations for a completed request. Its observations concern that page load, so keep your own before-and-after record. A screenshot of a different request cannot establish why the settings save was slow.
Updating does not prove old storage has been reclaimed
A fix that prevents repeated growth and a cleanup that reduces existing storage are separate outcomes. Do not promise that installing an update will immediately shrink the database file or remove all previously accumulated rows. Confirm the vendor's supported cleanup behavior for the installed version before scheduling maintenance.
Avoid blanket SQL deletes, guessed expiry rules and indiscriminate table truncation. Even cache-related maintenance can create a sudden rebuild workload. If cleanup is necessary, agree on scope, recovery, monitoring and an appropriate maintenance window with the responsible developer and host.
For an urgent capacity incident, involve the host promptly. Temporary capacity relief may be needed while the application cause is investigated, but record it as containment rather than proof of repair. Preserve the evidence needed to explain what was growing.
Verify routing as well as storage behavior
Check a known source URL and its approved translations, the language switcher, a representative product or custom post type, and the settings operation that was slow. Record final URLs and content language without sharing private preview tokens. The site must still resolve to the intended content after an update or approved maintenance action.
Continue observing growth over a comparable interval. Do not treat a quiet five-minute period as proof that a traffic-dependent issue cannot recur. HandL WP can investigate multilingual database growth with the table ownership, bounded measurements and request context. The useful outcome is correct routing with understood storage behavior, not simply a smaller number after an unexplained purge.
Sources reviewed November 4, 2026. Examples and diagrams are diagnostic aids, not customer test results.