Website administrators and WordPress developers know the importance of securing their websites with HTTPS. However, the move to a fully secure environment often introduces a frustrating challenge known as mixed content warnings. These warnings can severely impact user trust, SEO rankings, and overall site performance. One plugin in particular—TranslatePress—can inadvertently contribute to these issues if not handled correctly post-migration. This article provides a detailed account of how mixed content issues emerged after forcing HTTPS on a WordPress installation running TranslatePress, and how a smart search/replace approach helped resolve the problem by rooting out old HTTP asset references.
TLDR (Too long, didn’t read)
After migrating a WordPress site to HTTPS, persistent mixed content warnings appeared, traced back to TranslatePress. These warnings were caused by hardcoded HTTP asset URLs stored in the database. The solution involved a systematic search and replace operation in the WordPress database that updated old links to HTTPS. This eliminated browser security warnings without disrupting site translations or stability.
Identifying the Problem: Persistent Mixed Content Warnings
Once HTTPS was enforced site-wide through a combination of hosting-level SSL support and WordPress Site Address URL changes, the frontend behavior was expected to be seamless. Instead, browsers began issuing “Your connection to this site is not fully secure” alerts. Inspecting the browser’s developer console revealed several mixed content warnings—resources such as images, CSS, and JavaScript files were still being requested via http://.
The culprit? These resources weren’t from third-party plugins or themes alone—they were embedded directly into the TranslatePress translations and language-specific pages. TranslatePress, while highly useful for building multilingual sites, stores translated strings in the database, including raw HTML references and asset URLs.
Since TranslatePress cached references to site assets from when the site operated under HTTP, forcing HTTPS at the system level did not update those existing links. The result: updated links at the configuration level, outdated links at the content level.
Why Mixed Content Warnings Matter
- SEO Impact: Google penalizes sites that present non-secure elements, which may lower rankings.
- User Trust: Modern browsers like Chrome and Firefox display warning symbols in the URL bar when encountering mixed content, discouraging visitors.
- Data Security: HTTP resources can be intercepted during transfer, undermining the protection HTTPS offers.
Even though these warnings may seem minor, they present a significant challenge, especially for multilingual portfolios, ecommerce platforms, and educational websites that rely heavily on site credibility and search engine visibility.
Where TranslatePress Stores Its Content
TranslatePress uses custom database tables in conjunction with WordPress posts and options to store translations. During development or initial deployment, content editors may use URLs with http:// prefixes due to localhost constraints or temporary domain setups. Once TranslatePress records a URL this way, it becomes part of the translated content unless explicitly updated or purged.
This includes:
- Image sources (
<img src="http://..."/>) - Links (
<a href="http://..."/>) - Scripts and stylesheets included via shortcodes or custom HTML
Even content generated through visual builders or imported via CSV/XML often keeps the original HTTP format in these tables.
Investigating the Database
The first action item was to perform a manual SQL search using phpMyAdmin to inspect typical TranslatePress entries. Queries like the following exposed hundreds of HTTP-tagged assets:
SELECT * FROM wp_options WHERE option_value LIKE '%http://%';
SELECT * FROM wp_posts WHERE post_content LIKE '%http://%';
SELECT * FROM wp_trp_%';It became clear that old URL versions were deeply embedded in both the wp_posts content and various TranslatePress-related rows identified with wp_trp_ prefix.
A Safe and Tested Search/Replace Method
Many users turn to plugins like Better Search Replace or WP Migrate DB to perform bulk content modifications. However, care must be taken with serialized data within the database—blind replacements risk corrupting arrays and breaking TranslatePress behaviors.
We took a conservative, phased approach using the “Better Search Replace” plugin from Delicious Brains, which respects serialization when enabled.
Steps followed:
- Backup: A full database backup was created using UpdraftPlus and downloaded locally.
- Dry-run scan: Conducted a dry run to estimate the number of changes. Old domain used:
http://example.com; new:https://example.com. - Targeted database replacement: Ran the search/replace across all tables, especially selecting
wp_options,wp_posts, andwp_trp_*tables. - Cache cleared: Flushed all WordPress and plugin caches including TranslatePress string cache.
There was no downtime, no broken formatting, and no plugin conflicts. The operation succeeded in cleansing hundreds of hardcoded references to HTTP assets that were causing frontend warnings.
Preventing the Issue Going Forward
Preventive actions can save hours of troubleshooting after HTTPS migration. Key strategies include the following:
- Always launch in HTTPS: Even in development, configure your local and staging environments to use HTTPS to prevent non-secure URLs from being stored from the start.
- Post-migration content audit: After site migration or domain change, always run a double-check for hardcoded URLs across content, widgets, and plugin tables.
- Limit visual builder HTML entries: When possible, avoid embedding raw HTML unless you control every asset inside it.
Another security trick is to use Content Security Policy headers. These can help browsers reject non-secure assets if their security policy doesn’t permit HTTP-based resources on HTTPS pages.
What Didn’t Work
Before resorting to the search/replace strategy, several “quick fix” attempts failed:
- Changing Site URL in WordPress settings: This helped new content, not old translated entries.
- Using HTTPS redirection plugins temporarily masked the real issue by simply forcing the redirect; the resources were still loaded incorrectly.
- Clearing the TranslatePress cache alone wasn’t enough because the data was deeply saved as static content.
Final Outcome and Lessons Learned
Mixed content warnings disappeared across all translated pages post-cleanup. The TranslatePress interface continued to work as designed, retaining all translation memory and language rules. Perhaps even more importantly, page scores on tools like Google PageSpeed Insights and GTMetrix improved modestly due to consistent HTTPS delivery of assets.
Going forward, full HTTPS consistency should be a core WordPress deployment checklist item. Especially for multilingual or content-heavy websites where content may be duplicated, stored, and displayed via different methods, it’s imperative to consider where and how URLs are stored.
Conclusion
Enforcing HTTPS on a WordPress site is a best practice—but it’s not a single-task operation. With plugins like TranslatePress storing translated content directly in the database, migration can leave behind HTTP artifacts that introduce security issues. A careful, serialized-aware search and replace strategy that targets TranslatePress tables helped resolve persistent mixed content warnings effectively. By identifying the underlying problem and deploying a precise remedy, website administrators can ensure both user trust and SEO performance remain intact.