How to Find Slow WordPress Queries with Query Monitor

A slow WordPress page often has a database problem hiding behind a polished design. When we troubleshoot slow WordPress queries, Query Monitor shows which request is taking time, who triggered it, and whether a plugin or theme is responsible.

You don’t need to guess, deactivate every plugin at random, or move to a more expensive server before checking the evidence. With a few focused tests, you can find the bottleneck and choose the right fix.

Why Slow WordPress Queries Matter

Every WordPress page load can trigger database queries. WordPress uses them to retrieve posts, products, settings, users, menus, custom fields, and plugin data.

Most queries finish quickly. Problems appear when one query takes too long, when a plugin sends the same query repeatedly, or when dozens of small queries add up to a noticeable delay.

The result is familiar:

Pages take longer to open.
The WordPress admin feels sluggish.
WooCommerce product and checkout pages lag.
Visitors wait before seeing useful content.
Search engines and performance tools report a high time to first byte.

A slow query isn’t always the only problem. Large images, third-party scripts, PHP errors, and limited hosting resources can also slow a site. Query Monitor helps us separate those issues instead of treating every performance problem as a database problem.

A query that takes 20 milliseconds once may not matter. The same query repeated 200 times can become the reason a page feels slow.

The first step is to test the page where visitors feel the delay. Don’t check only the homepage. Look at search results, contact forms, WooCommerce products, cart pages, and any page connected to a recent plugin change.

Prepare the Site Before Testing

Query Monitor is a diagnostic tool, not a permanent speed solution. It collects detailed information during each request, so we recommend using it on a staging site whenever possible.

Use a safe testing environment

If your host provides staging, create a copy of the website before installing diagnostic plugins or changing database settings. A staging site gives you space to test plugin conflicts without affecting customers.

If staging isn’t available, take a current backup first. Avoid testing during a busy sales period, and don’t make live changes based on one result.

We also recommend opening the site in a private browser window for visitor-facing tests. Then compare it with a logged-in administrator session. WordPress can load different content, caching rules, and toolbar data for each user type.

Test the exact slow page

Choose one page that consistently loads slowly. Record what happens before installing Query Monitor:

Note the page URL and approximate load time.
Test it two or three times.
Check whether the problem happens on desktop, mobile, or both.
Test another page that loads normally.
Record whether the delay happens before content appears or during the final visual loading.

This comparison gives you a baseline. If every page is slow, hosting or a site-wide plugin may be involved. If only the shop, form, or search page is slow, start with the features used there.

Install and Open Query Monitor

Query Monitor is a free WordPress debugging plugin. You can install it through the WordPress dashboard, or review the project files in the Query Monitor project repository.

From WordPress, go to Plugins > Add New. Search for “Query Monitor,” check that the plugin is from John Blackbourn, then install and activate it.

The plugin supports modern WordPress sites and requires PHP 7.4 or later. If your website runs an older PHP version, ask your host to update it after checking theme and plugin compatibility.

Once activated, open the slow page while logged in as an administrator. Query Monitor adds a panel to the WordPress admin toolbar. Select its entry to view information about that request.

The panel may appear at the bottom of the page or open through the toolbar, depending on the site setup and WordPress admin bar. The official Query Monitor usage guide covers the main panels and filtering options.

Keep the test focused. Open one page at a time, wait for it to finish loading, and read the results before moving to another URL. That makes it easier to connect a query to a page feature.

How to Find slow WordPress queries in Query Monitor

Open the Query Monitor panel and choose Queries. This area shows the SQL queries WordPress ran during the current page request.

The main table can include:

The SQL statement.
The query type, such as SELECT, INSERT, UPDATE, or DELETE.
The function that called the query.
The plugin, theme, or WordPress component responsible.
The number of rows returned or changed.
The execution time.
Any database error message.

The WP VIP Query Monitor reference also explains how query details can show the query, caller, and execution time. Those three details usually give us the fastest route to the cause.

Start with the Slow Queries panel

Query Monitor includes a Slow Queries panel that filters out faster requests and highlights queries that cross its slow-time threshold.

If the panel contains a query, sort or review it by execution time. Look for statements that take noticeably longer than the others. A query returning a large number of rows may also deserve attention, especially on a search, archive, or store page.

An empty Slow Queries panel doesn’t prove that the database is healthy. The threshold may not catch a collection of medium-speed queries. Open the full Queries panel and look for repetition, high totals, and database errors.

Check totals, not only the biggest number

Suppose one query takes 90 milliseconds. That may be worth investigating, but 30 separate queries taking 15 milliseconds each could create a larger delay.

Query Monitor groups queries by caller and query type. Review the total time spent by each group, not only the slowest individual line. A plugin that adds many small queries to every page can create more damage than one isolated query on a special page.

Duplicate queries are another warning sign. If the same SQL statement appears again and again, check why it repeats. Some repetition is normal, but excessive duplication can point to a plugin setting, an inefficient theme function, or missing object caching.

Trace the Query Back to a Plugin or Theme

A database query is only the symptom. The caller and component tell you where to investigate next.

Use Queries by Component

Open Queries by Component to see how much database work comes from WordPress core, your active theme, and each plugin. If one plugin accounts for most of the query time, test that plugin first.

The result doesn’t automatically mean the plugin is poorly built. A plugin may need extra queries on a product filter, membership page, or reporting screen. The useful question is whether those queries run on pages that don’t need the feature.

For example, a booking plugin shouldn’t load its full availability data on a basic About page. A form plugin shouldn’t query every form on every front-end request. Plugin settings, conditional loading, or a recent update may change that behavior.

Read the caller and call stack

The caller shows the PHP function that requested the SQL. The full call stack provides more context.

Look for recognizable names:

A plugin folder name often points to the responsible plugin.
A theme function may identify a custom template or feature.
WP_Query can indicate a post, archive, or custom content query.
WooCommerce functions often appear on product, cart, and checkout requests.
WordPress core functions may still be triggered by a plugin or theme hook.

A core function in the caller column isn’t always the real culprit. Plugins often ask WordPress to run a query through standard functions. Follow the stack until you see the code or component that initiated the request.

Don’t edit the SQL directly. Query Monitor shows what happened, but it doesn’t rewrite the underlying plugin logic safely.

Separate Database Delays from Other Bottlenecks

Query Monitor collects more than SQL data. Use the other panels before deciding that slow WordPress queries are the main issue.

Check HTTP API calls

A page can wait for an external service, such as a payment provider, email platform, analytics tool, map service, or product feed. These requests can delay the server response even when the database queries are quick.

Open the HTTP API Calls panel and check the request time. A third-party call that takes several seconds deserves attention.

You may be able to disable the integration, load it later, reduce its frequency, or contact the provider. If the service is required for checkout or account features, test it carefully on staging before changing it.

Review PHP errors and hooks

Warnings, notices, and fatal errors can add work or prevent caching from working correctly. Check the PHP Errors panel for messages that appear on the slow page.

The Hooks and Actions panel can also help when a theme or plugin attaches heavy functions to common WordPress hooks. A function running on every page load has a wider effect than one that runs only on a special page.

For a practical performance walkthrough that combines Query Monitor with other checks, see this Query Monitor optimization guide.

Compare server response time

If Query Monitor shows fast queries, few PHP errors, and no slow HTTP calls, the hosting environment may need attention. Limited PHP workers, high server load, outdated PHP, low memory, or a busy shared server can all affect time to first byte.

Run the same page test at different times. Compare a cached page with an uncached request, if your caching system allows it. A site that slows down only during busy periods may need more hosting resources rather than a plugin change.

Fix the Cause and Test Again

Once you know which component is responsible, make one change at a time. That keeps the result clear.

Start with updates for WordPress core, the active theme, and the plugin connected to the slow request. Developers often fix query problems in later releases, but read the changelog and test updates on staging first.

If a plugin is responsible, review its settings before removing it. Look for options related to logging, reports, search, related products, database tables, scheduled tasks, or loading features site-wide.

For a plugin conflict, deactivate the suspected plugin on staging and test the same page. If the page improves, reactivate other plugins one by one until the delay returns. That points to the responsible feature without turning the live site into a guessing exercise.

Database cleanup can help when tables contain years of expired transients, revisions, logs, or abandoned records. Always back up first. Database optimization and index changes should be handled by someone who understands the site schema, especially on WooCommerce or membership websites.

Persistent object caching can also reduce repeated database work. Page caching helps with complete public pages, while object caching stores repeated results used during PHP requests. The right cache depends on the site and hosting setup.

After every change, retest:

The original slow page.
A normal page.
A logged-out visitor view.
Any related form, product, cart, or account feature.
Query time, page response time, and visible errors.

If the database is still slow after plugin and theme checks, the server may not have enough room for the website’s current traffic. Our ZADiC WordPress hosting plans give small businesses a simpler place to run WordPress, with one-click setup, free SSL on many plans, backups, security monitoring, and 24/7 human support. For busier websites, managed Hosting Plus or VPS hosting can provide a better fit than staying on an overloaded entry-level plan.

Keep Query Monitor as a Diagnostic Tool

Query Monitor is useful during troubleshooting, but it doesn’t belong on every production site forever. Once you’ve identified and fixed the issue, deactivate it unless you still need it for development.

Keep a record of the original query time, the change you made, and the result after testing. That simple habit helps you recognize future problems faster.

Run another review after major plugin updates, a theme redesign, a WooCommerce change, or a hosting migration. Performance problems often arrive with a new feature, not because WordPress suddenly changed on its own.

A clean monitoring routine can be simple:

Check the page that visitors say feels slow.
Review slow and duplicate queries.
Identify the responsible component.
Check HTTP calls and PHP errors.
Change one thing.
Test the result again.

That process gives you useful evidence before you spend money or remove a feature customers rely on.

Conclusion

Query Monitor turns a vague complaint, “WordPress is slow,” into a practical investigation. The slow WordPress queries panel shows the requests worth checking, while callers and components point toward the plugin, theme, or feature behind them.

Start with the exact slow page, test safely, review total query time, and separate database work from external calls and hosting delays. When the application is clean but the server still struggles, reliable WordPress hosting can give your site the support and resources it needs to keep moving.

Submit a Comment Cancel reply

What's New?

WordPressHow to Find Slow WordPress Queries with Query MonitorA slow WordPress page often has a database problem hiding behind a polished design. When we troubleshoot slow WordPress queries, Query Monitor shows which request is taking time, who triggered it, and whether a plugin or theme is responsible. You don’t need to guess, deactivate every plugin at random, or move to a more expensive server before checking the evidence. With a few focused tests, you can find the bottleneck and choose the right fix. Why Slow WordPress Queries Matter Every WordPress page load can trigger database queries. WordPress uses them to retrieve posts, products, settings, users, menus, custom fields, and plugin data. Most queries finish quickly. Problems appear when one query takes too long, when a plugin sends the same query repeatedly, or when dozens of small queries add up to a noticeable delay. The result is familiar: Pages take longer to open. The WordPress admin feels sluggish. WooCommerce product and checkout pages lag. Visitors wait before seeing useful content. Search engines and performance tools report a high time to first byte. A slow query isn’t always the only problem. Large images, third-party scripts, PHP errors, and limited hosting resources can also slow a site. Query Monitor helps us separate those issues instead of treating every performance problem as a database problem. A query that takes 20 milliseconds once may not matter. The same query repeated 200 times can become the reason a page feels slow. The first step is to test the page where visitors feel the delay. Don’t check only the homepage. Look at search results, contact forms, WooCommerce products, cart pages, and any page connected to a recent plugin change. Prepare the Site Before Testing Query Monitor is a diagnostic tool, not a permanent speed solution. It collects detailed information during each request, so we recommend using it on a staging site whenever possible. Use a safe testing environment If your host provides staging, create a copy of the website before installing diagnostic plugins or changing database settings. A staging site gives you space to test plugin conflicts without affecting customers. If staging isn’t available, take a current backup first. Avoid testing during a busy sales period, and don’t make live changes based on one result. We also recommend opening the site in a private browser window for visitor-facing tests. Then compare it with a logged-in administrator session. WordPress can load different content, caching rules, and toolbar data for each user type. Test the exact slow page Choose one page that consistently loads slowly. Record what happens before installing Query Monitor: Note the page URL and approximate load time. Test it two or three times. Check whether the problem happens on desktop, mobile, or both. Test another page that loads normally. Record whether the delay happens before content appears or during the final visual loading. This comparison gives you a baseline. If every page is slow, hosting or a site-wide plugin may be involved. If only the shop, form, or search page is slow, start with the features used there. Install and Open Query Monitor Query Monitor is a free WordPress debugging plugin. You can install it through the WordPress dashboard, or review the project files in the Query Monitor project repository. From WordPress, go to Plugins > Add New. Search for “Query Monitor,” check that the plugin is from John Blackbourn, then install and activate it. The plugin supports modern WordPress sites and requires PHP 7.4 or later. If your website runs an older PHP version, ask your host to update it after checking theme and plugin compatibility. Once activated, open the slow page while logged in as an administrator. Query Monitor adds a panel to the WordPress admin toolbar. Select its entry to view information about that request. The panel may appear at the bottom of the page or open through the toolbar, depending on the site setup and WordPress admin bar. The official Query Monitor usage guide covers the main panels and filtering options. Keep the test focused. Open one page at a time, wait for it to finish loading, and read the results before moving to another URL. That makes it easier to connect a query to a page feature. How to Find slow WordPress queries in Query Monitor Open the Query Monitor panel and choose Queries. This area shows the SQL queries WordPress ran during the current page request. The main table can include: The SQL statement. The query type, such as SELECT, INSERT, UPDATE, or DELETE. The function that called the query. The plugin, theme, or WordPress component responsible. The number of rows returned or changed. The execution time. Any database error message. The WP VIP Query Monitor reference also explains how query details can show the query, caller, and execution time. Those three details usually give us the fastest route to the cause. Start with the Slow Queries panel Query Monitor includes a Slow Queries panel that filters out faster requests and highlights queries that cross its slow-time threshold. If the panel contains a query, sort or review it by execution time. Look for statements that take noticeably longer than the others. A query returning a large number of rows may also deserve attention, especially on a search, archive, or store page. An empty Slow Queries panel doesn’t prove that the database is healthy. The threshold may not catch a collection of medium-speed queries. Open the full Queries panel and look for repetition, high totals, and database errors. Check totals, not only the biggest number Suppose one query takes 90 milliseconds. That may be worth investigating, but 30 separate queries taking 15 milliseconds each could create a larger delay. Query Monitor groups queries by caller and query type. Review the total time spent by each group, not only the slowest individual line. A plugin that adds many small queries to every page can create more damage than one isolated query on a special page. Duplicate queries are another warning sign. If the same SQL statement appears again and again, check why it repeats. Some repetition is normal, but excessive duplication can point to a plugin setting, an inefficient theme function, or missing object caching. Trace the Query Back to a Plugin or Theme A database query is only the symptom. The caller and component tell you where to investigate next. Use Queries by Component Open Queries by Component to see how much database work comes from WordPress core, your active theme, and each plugin. If one plugin accounts for most of the query time, test that plugin first. The result doesn’t automatically mean the plugin is poorly built. A plugin may need extra queries on a product filter, membership page, or reporting screen. The useful question is whether those queries run on pages that don’t need the feature. For example, a booking plugin shouldn’t load its full availability data on a basic About page. A form plugin shouldn’t query every form on every front-end request. Plugin settings, conditional loading, or a recent update may change that behavior. Read the caller and call stack The caller shows the PHP function that requested the SQL. The full call stack provides more context. Look for recognizable names: A plugin folder name often points to the responsible plugin. A theme function may identify a custom template or feature. WP_Query can indicate a post, archive, or custom content query. WooCommerce functions often appear on product, cart, and checkout requests. WordPress core functions may still be triggered by a plugin or theme hook. A core function in the caller column isn’t always the real culprit. Plugins often ask WordPress to run a query through standard functions. Follow the stack until you see the code or component that initiated the request. Don’t edit the SQL directly. Query Monitor shows what happened, but it doesn’t rewrite the underlying plugin logic safely. Separate Database Delays from Other Bottlenecks Query Monitor collects more than SQL data. Use the other panels before deciding that slow WordPress queries are the main issue. Check HTTP API calls A page can wait for an external service, such as a payment provider, email platform, analytics tool, map service, or product feed. These requests can delay the server response even when the database queries are quick. Open the HTTP API Calls panel and check the request time. A third-party call that takes several seconds deserves attention. You may be able to disable the integration, load it later, reduce its frequency, or contact the provider. If the service is required for checkout or account features, test it carefully on staging before changing it. Review PHP errors and hooks Warnings, notices, and fatal errors can add work or prevent caching from working correctly. Check the PHP Errors panel for messages that appear on the slow page. The Hooks and Actions panel can also help when a theme or plugin attaches heavy functions to common WordPress hooks. A function running on every page load has a wider effect than one that runs only on a special page. For a practical performance walkthrough that combines Query Monitor with other checks, see this Query Monitor optimization guide. Compare server response time If Query Monitor shows fast queries, few PHP errors, and no slow HTTP calls, the hosting environment may need attention. Limited PHP workers, high server load, outdated PHP, low memory, or a busy shared server can all affect time to first byte. Run the same page test at different times. Compare a cached page with an uncached request, if your caching system allows it. A site that slows down only during busy periods may need more hosting resources rather than a plugin change. Fix the Cause and Test Again Once you know which component is responsible, make one change at a time. That keeps the result clear. Start with updates for WordPress core, the active theme, and the plugin connected to the slow request. Developers often fix query problems in later releases, but read the changelog and test updates on staging first. If a plugin is responsible, review its settings before removing it. Look for options related to logging, reports, search, related products, database tables, scheduled tasks, or loading features site-wide. For a plugin conflict, deactivate the suspected plugin on staging and test the same page. If the page improves, reactivate other plugins one by one until the delay returns. That points to the responsible feature without turning the live site into a guessing exercise. Database cleanup can help when tables contain years of expired transients, revisions, logs, or abandoned records. Always back up first. Database optimization and index changes should be handled by someone who understands the site schema, especially on WooCommerce or membership websites. Persistent object caching can also reduce repeated database work. Page caching helps with complete public pages, while object caching stores repeated results used during PHP requests. The right cache depends on the site and hosting setup. After every change, retest: The original slow page. A normal page. A logged-out visitor view. Any related form, product, cart, or account feature. Query time, page response time, and visible errors. If the database is still slow after plugin and theme checks, the server may not have enough room for the website’s current traffic. Our ZADiC WordPress hosting plans give small businesses a simpler place to run WordPress, with one-click setup, free SSL on many plans, backups, security monitoring, and 24/7 human support. For busier websites, managed Hosting Plus or VPS hosting can provide a better fit than staying on an overloaded entry-level plan. Keep Query Monitor as a Diagnostic Tool Query Monitor is useful during troubleshooting, but it doesn’t belong on every production site forever. Once you’ve identified and fixed the issue, deactivate it unless you still need it for development. Keep a record of the original query time, the change you made, and the result after testing. That simple habit helps you recognize future problems faster. Run another review after major plugin updates, a theme redesign, a WooCommerce change, or a hosting migration. Performance problems often arrive with a new feature, not because WordPress suddenly changed on its own. A clean monitoring routine can be simple: Check the page that visitors say feels slow. Review slow and duplicate queries. Identify the responsible component. Check HTTP calls and PHP errors. Change one thing. Test the result again. That process gives you useful evidence before you spend money or remove a feature customers rely on. Conclusion Query Monitor turns a vague complaint, “WordPress is slow,” into a practical investigation. The slow WordPress queries panel shows the requests worth checking, while callers and components point toward the plugin, theme, or feature behind them. Start with the exact slow page, test safely, review total query time, and separate database work from external calls and hosting delays. When the application is clean but the server still struggles, reliable WordPress hosting can give your site the support and resources it needs to keep moving. [...]
Read more...
WordPressHow to Configure Redis Object Caching for WordPressRedis object caching can make a WordPress site feel faster without changing its design or rebuilding every page. It stores frequently used database results in memory, so WordPress doesn’t need to repeat the same work on every request. When visitors, customers, or logged-in users notice delays, the problem often sits behind the page. Redis helps reduce that repeated database work. The setup is straightforward when your hosting account has the right Redis service, PHP client, and connection details. Let’s start with what it changes. What Redis object caching changes WordPress uses an object cache to store temporary data such as database query results, settings, menu data, and other values created during a request. By default, much of that cache disappears when the request ends. A persistent Redis cache keeps those objects available for later requests. The result is less repeated work for PHP and MySQL, especially on sites with busy plugins or dynamic content. Object cache is not page cache These two caching systems work at different levels. A page cache stores finished HTML pages. When a visitor requests the same page, the server can return that saved page instead of running WordPress again. An object cache stores smaller pieces of WordPress data. WordPress can reuse those pieces while building a page, processing an AJAX request, loading the dashboard, or handling a logged-in session. That difference matters. Redis won’t replace a page cache, image optimization, a content delivery network, or good hosting. It adds another layer that helps WordPress handle repeated database tasks. WordPress core includes the WP_Object_Cache class, but persistent storage needs a compatible plugin and a working Redis server. The WP_CACHE constant alone doesn’t create persistent Redis caching. Where the improvement shows Redis object caching becomes more useful as a site grows more complex. WooCommerce stores product, cart, session, and user data. Membership sites process account details and restricted content. Large publishing sites often run several plugins that request the same settings and database values. You may notice better response times in: WooCommerce product and checkout workflows. WordPress admin screens for logged-in users. Membership dashboards and account pages. Search, filtering, and AJAX-powered features. Sites with many plugins and frequent database activity. A small brochure site may see a smaller improvement. That doesn’t make Redis useless, but it means other changes, such as better hosting or image compression, may deliver more value first. Check whether hosting supports Redis Before installing a plugin, check the server. A WordPress plugin can’t connect to Redis if Redis isn’t running somewhere your site can reach. You need three pieces: A Redis service, either on the same server or on a private remote server. A PHP client such as PhpRedis, Predis, or Relay. Connection details, including the host, port, password, or Unix socket path. Hosting setupWhat to confirmTypical next stepManaged WordPress hostingRedis availability and provider instructionsEnable the host-supported object cachecPanel or shared hostingRedis service, PHP extension, and socket detailsAsk the host for the exact configurationVPS hostingRedis service, firewall rules, PHP client, and memory limitsInstall and secure Redis before connecting WordPress On a VPS, Redis may need to be installed, secured, and limited to local or private connections. On shared hosting, you may not have permission to install it yourself. If your current plan doesn’t provide Redis, ZADiC’s WordPress hosting, managed Web Hosting Plus, and VPS options give you different levels of control. Our support team can help identify the setup that fits your traffic, plugins, and technical comfort. You shouldn’t have to guess which server settings belong in wp-config.php. Custom WordPress stacks need extra care. Sites using Bedrock or Trellis can follow environment-specific approaches, such as the setup discussed in this Bedrock and Trellis Redis guide. Prepare WordPress before configuration A few minutes of preparation can prevent a messy cache problem later. Redis stores data generated by WordPress, so the site should be stable before you add another caching layer. Back up the site and test changes Create a current backup of your files and database. If your host provides automatic backups, confirm that the latest backup completed successfully. A staging site is even better. Install Redis there first, test the checkout and login flows, then apply the same settings to production. This matters for WooCommerce, membership plugins, multilingual sites, and custom themes. Update WordPress, your active theme, and important plugins before testing. An outdated plugin may create errors that look like a Redis problem. Check for existing object-cache files Look inside wp-content for object-cache.php. This file is the WordPress drop-in that connects the normal object-cache system to a persistent backend. Only one object-cache drop-in should control the site. If your host already installed Object Cache Pro or another Redis integration, don’t install a second object-cache system on top of it. Two competing drop-ins can create confusing connection errors and unpredictable cache behavior. Keep your Redis credentials private. The wp-config.php file contains sensitive settings, so don’t commit it to a public repository or paste passwords into an open support forum. Install the Redis Object Cache plugin The free Redis Object Cache plugin is a common option for WordPress sites. As of August 2026, its WordPress.org listing requires WordPress 4.6 or newer and PHP 5.6 or newer. Those are minimum requirements, not a recommendation to run old software. Use the current PHP version your host supports. Use the WordPress admin In your WordPress dashboard: Open Plugins > Add New Plugin. Search for Redis Object Cache. Install the plugin published by Till Kruss. Activate it. Open Settings > Redis. Select Enable Object Cache. If Redis is already available and the connection values are correct, the plugin should create or activate wp-content/object-cache.php. Don’t stop at plugin activation. Installing the plugin only gives WordPress the connector. The Redis service still needs to be running, reachable, and configured for your account. Use WP-CLI on managed hosting or a VPS WP-CLI is faster when you manage several sites or work from the server terminal. From the WordPress installation directory, run: wp plugin install redis-cache --activate wp redis enable The wp redis enable command activates the object-cache drop-in. If another drop-in already exists, don’t overwrite it without checking which caching system your host uses. The --force option can overwrite an existing object-cache.php, so use it only when you’re certain the current file should be replaced. For more command details and advanced Redis support, the plugin’s Redis Object Cache repository is a useful reference. Managed WordPress providers may install a different plugin, such as Object Cache Pro, automatically. Follow the provider’s instructions instead of forcing the free plugin into a host-managed setup. Add the right Redis connection settings Most setup problems come from using the wrong connection details. Redis may run locally on port 6379, through a private hostname, on a custom port, or through a Unix socket. Your hosting provider should give you the exact values. Never assume that 127.0.0.1 is correct. Configure a TCP connection For a local or private network connection, the settings may look like this: define( 'WP_REDIS_HOST', '127.0.0.1' ); define( 'WP_REDIS_PORT', 6379 ); define( 'WP_CACHE_KEY_SALT', 'example.com:' ); The host can be a private IP address or a hostname. The port may be different from the standard Redis port. If authentication is required, your provider may also give you a password or another authentication setting. A cache key salt gives the site a unique prefix. This is important when multiple WordPress sites share one Redis service. Use a different salt for each site, such as example.com: and store.example.com:. Otherwise, one site could collide with another site’s cached keys. Place these definitions in wp-config.php before the line that says WordPress stops editing. Use the values supplied by your host, not the sample values above. Configure a Unix socket Some cPanel-style environments expose Redis through a local socket instead of a TCP port. In that case, the configuration may look like this: define( 'WP_REDIS_SCHEME', 'unix' ); define( 'WP_REDIS_PATH', '/home/username/redis/redis.sock' ); define( 'WP_CACHE_KEY_SALT', 'example.com:' ); The socket path is unique to the hosting account. A single missing character can cause a connection failure, so copy it carefully. Unix sockets can work well when Redis runs on the same server. They aren’t appropriate when Redis is hosted on a separate machine. Ask your provider which connection method your plan uses before adding either configuration. Confirm that persistent caching is active A successful plugin installation doesn’t prove that WordPress is using Redis. Check the connection before measuring performance. Check the plugin and Site Health Return to Settings > Redis. The status should show a successful connection, usually with details about the Redis client and connection. If the page reports that Redis is disabled or unreachable, fix that first. WordPress Site Health can also report whether a persistent object cache is available. Open Tools > Site Health and review the status and information panels. You can also check whether wp-content/object-cache.php exists. Without that drop-in, WordPress may continue working normally, but the object cache won’t persist between requests. A green plugin screen means WordPress reached Redis. It doesn’t automatically mean every performance problem has been fixed. On the command line, wp redis enable is the standard activation command for supported Redis integrations. If you need to remove the drop-in while troubleshooting, wp redis disable is safer than deleting files at random. Measure the right things Test the site before and after activation. Compare similar pages under similar conditions, and test while logged out as well as logged in. Look at: Time to first byte. Server response time. Database query time. Admin page loading speed. WooCommerce cart and checkout behavior. Error logs and PHP warnings. Clear any page cache before each comparison. Otherwise, a saved HTML page may hide whether Redis made a difference. Redis may improve server response time without making a large visual change. That is normal. It reduces repeated backend work, not the size of images or JavaScript files delivered to the browser. Fix common Redis setup problems Most Redis errors have a short list of likely causes. Check the connection details before changing unrelated plugins. Connection refused or unavailable A “connection refused” message usually means Redis isn’t running, the host or port is wrong, or a firewall blocks the connection. On a VPS, check the Redis service and its binding rules. Redis shouldn’t be exposed publicly with an open firewall port. A missing PHP client can create a different error. Ask your host whether PhpRedis, Predis, or Relay is available for the PHP version assigned to your domain. If the plugin reports authentication errors, request fresh credentials from the provider. Don’t keep guessing passwords or ports. Stale data or plugin conflicts Redis object caching can hold an old value until WordPress or a plugin updates it. Use the plugin’s flush option after major configuration changes, theme updates, imports, or database migrations. Be careful on production sites. Flushing Redis removes cached objects for every site sharing that database unless the host separates them. A site-specific cache salt helps prevent collisions, but it doesn’t make a shared flush harmless. Multilingual sites need extra testing. WPML provides Redis caching guidance for multilingual WordPress, including checks for language-specific content and cache behavior. If a site becomes unstable after enabling Redis, disable the object cache temporarily and review the logs. A host-provided cache and a manually installed cache plugin may both be trying to manage the same drop-in. Know what Redis cannot fix Redis is one part of a fast WordPress setup. It won’t repair slow third-party APIs, oversized images, bloated plugins, poor database indexes, weak PHP resources, or an overloaded server. A practical performance stack may include: Reliable WordPress hosting with enough CPU and memory. A full-page cache for public pages. Redis for repeated object and database data. Modern PHP and a suitable PHP memory limit. Compressed images and fewer heavy scripts. Backups, SSL, security monitoring, and regular updates. Hosting quality affects every layer. If Redis keeps disconnecting or your server lacks memory, changing WordPress settings won’t solve the root problem. ZADiC helps small businesses choose between standard WordPress hosting, managed Web Hosting Plus, and VPS hosting without forcing every site owner to become a server administrator. With backups, security services, and 24/7 human support available, you can focus on your website while we help with the technical foundation. Conclusion Redis object caching gives WordPress a persistent memory layer for frequently used data. The setup works best when your hosting provider supplies a reachable Redis service, a supported PHP client, and clear connection details. Install one compatible object-cache plugin, use a unique cache salt, verify object-cache.php, and test real pages before and after activation. If your current hosting doesn’t provide the access Redis needs, choosing a managed Web Hosting Plus or VPS plan can be a simpler path to reliable performance. [...]
Read more...
WordPressCheck WordPress PHP Extensions Before Installing PluginsOne missing PHP module can stop a plugin before you ever reach its settings page. Before installing, we check the PHP extensions loaded by the same PHP version serving the website. That quick step can prevent failed updates, broken image tools, database errors, and frustrating white screens. You don’t need to be a server administrator when your host offers active support for unclear requirements. We can check the basics inside WordPress, confirm the exact PHP extensions with phpinfo(), or review them in cPanel to verify PHP compatibility. Let’s start with what matters most. Key Takeaways Check the PHP version and extensions used by the live website before installing a plugin, rather than relying on the command-line version or account default. Use WordPress Site Health for a broad server check, then confirm exact loaded modules with phpinfo(), cPanel, or the correct command-line PHP binary. Compare the plugin’s required PHP version and extensions with your active runtime, paying close attention to modules such as curl, mbstring, zip, imagick, gd, mysqli, and openssl. If an extension is missing, save the error message, confirm the domain’s PHP handler, and ask your hosting provider or plugin developer for an approved solution. Test important pages and connected services after installation, especially when using image processing, object caching, payment, email, or other integrations. Why Check PHP Extensions Before Installing a Plugin? PHP powers WordPress core. PHP extensions are add-on components that give the engine extra abilities, such as connecting to a MySQL database, processing images, reading XML, or making secure connections to other websites. Plugins depend on the same server environment. If a required component is missing, it can affect PHP compatibility, prevent activation, or break a specific feature. Plugin requirements live on the server Plugin documentation may list PHP extensions and requirements such as: PHP 8.2 or newer The mbstring extension for UTF-8 text handling The zip extension for package installation and updates The curl extension for external API requests imagick or gd for image processing Installing the plugin first and checking later is like buying a printer before checking whether your computer has the right connection. Sometimes it works. Sometimes you’re left troubleshooting a problem that was easy to prevent. PHP version comes first The PHP version and its extensions work together, so their combination affects PHP compatibility. Check the PHP version assigned to your domain in your hosting environment. A plugin tested on PHP 8.3 may behave differently on PHP 8.4, especially if it uses older PHP functions. WordPress.org’s current requirements page recommends PHP 8.3 or greater for WordPress. Check your current runtime before adding a plugin, then review the developer’s notes for plugin compatibility and known conflicts. Newer isn’t always better when a plugin hasn’t caught up. Test major PHP changes on a staging site to confirm PHP compatibility, especially before moving to PHP 8.4. Keep a backup, apply security updates, and update WordPress, themes, and plugins before changing the server version. If requirements remain unclear, ask the plugin developer or host whether the plugin has active support for your environment. WordPress PHP extensions to check first The WordPress Hosting Handbook’s server environment guide separates PHP extensions into required, recommended, and cache-related groups. The listed PHP modules are loaded by a particular runtime. Treat this list as a baseline, then check the plugin’s supported environment and stated PHP version requirement for PHP compatibility. CategoryExtensions to checkMain purposeRequiredjson, mysqli or mysqlnd, curlData processing, MySQL database connections, database interactions, and remote requestsRecommendeddom, exif, fileinfo, hash, igbinary, imagick, intl, mbstring, openssl, pcre, xml, zipText, images, uploads, updates, security, and external dataCache-relatedapcu, memcached, OPcache, redisBytecode and object caching, with Redis and Memcached used only when configured Required extensions don’t mean every checkbox The database requirement is usually satisfied by mysqli or mysqlnd. These PHP extensions don’t normally need to be installed together just because they appear in different setup guides. The json extension is bundled with PHP 8.0 and newer, so it may not appear as a separate option in your hosting panel. curl handles remote requests, including connections used by updates, APIs, and some integrations. If one of these required extensions is missing, stop before installing the plugin. Ask your host to confirm the PHP handler assigned to your domain. Recommended PHP extensions depend on your plugins The recommended PHP extensions depend on each plugin’s features and integrations. Imagick supports advanced image processing and PDF thumbnails. The GD Library (gd) offers basic processing as an alternative. mbstring helps plugins work with international text, while intl supports locale and formatting functions. Extensions such as simplexml, xmlreader, zlib, iconv, filter, bcmath, ftp, ssh2, and sockets are often feature-specific, while others act as fallback extensions. Match each extension to the plugin or feature that needs it. Start With WordPress Site Health WordPress gives you a useful first check with Site Health without leaving the dashboard. Find the server details Log in to WordPress and open Tools > Site Health > Info. Expand the Server section to review details such as: The active PHP version The web server PHP memory limits Maximum upload size Maximum post size Maximum input variables The Database section can also reveal connection details and the database software in use. These checks help you compare your site’s server environment with the plugin’s installation requirements. Know what Site Health cannot show Site Health is a good starting point, but it may not display every loaded PHP extensions. This provides a broad PHP compatibility check, not a complete runtime inventory. If the plugin names a particular module, confirm it with phpinfo() or the hosting control panel. Use this dashboard check to confirm the broad environment first. Then use a more direct method for the exact module list. If the results remain unclear, your host’s active support team can confirm the exact runtime. Two minutes here can save an hour of guessing. Use phpinfo() to See the Active Web Modules A phpinfo() page reports the PHP runtime used by the web server. That distinction matters for PHP compatibility because the PHP version in your hosting panel may not match the command-line version on the same account. Create a temporary check page Create a temporary PHP file in your website’s document root with <?php phpinfo(); ?> inside it. Name it something difficult to guess, such as server-check.php, then open that file in your browser. If your hosting panel shows PHP 8.4, confirm that the page reports the same runtime before testing a plugin. Search the page for Loaded Modules to see the active PHP modules and loaded PHP extensions. You can also search for individual PHP extensions, such as curl, dom, Imagick, mbstring, mysqli, openssl, and zip. The page shows the PHP version, loaded extensions, configuration values, and active server settings. For official details, see PHP’s phpinfo() documentation. If it conflicts with your hosting panel, contact your host for active support before checking plugin requirements. Delete the file as soon as you’re finished. A public phpinfo() page exposes configuration details that visitors don’t need to see. Review Extensions in cPanel cPanel is often the quickest option when your host gives you PHP version control. Its interface exposes PHP extensions for the selected domain. The wording varies between hosting providers. Check the correct domain and runtime Select the domain where you plan to install the plugin, since it may use a different runtime than the account default. Confirm the plugin’s PHP compatibility and match its extension list to the runtime serving the site. A PHP 8.4 list may not apply to a site using another version. Review the PHP extensions listed for that domain, including modules such as: curl dom fileinfo imagick (Imagick) or gd (GD Library) intl mbstring mysqli or mysqlnd openssl xml zip Select only the modules your WordPress installation or plugin needs, then save the changes. Clear any server or WordPress cache before testing again. If the plugin depends on object caching, also verify the host’s documented Redis or Memcached setup. cPanel’s PHP extension documentation explains where administrators can locate and install PHP versions or extensions. In a shared hosting environment, you may see the modules but lack permission to change them, so your provider’s active support team may need to enable one. If you want simple server control without managing a full VPS, our cPanel hosting for WordPress offers a familiar dashboard for website, email, database, and PHP management, plus active support. Check Extensions From the Command Line SSH access makes extension checks quick and repeatable. Run: php -v This confirms the PHP version used by the command line. Then run: php -m This lists loaded PHP modules and shows the PHP extensions available to the command line. To filter common WordPress requirements from those PHP extensions, use: php -m | grep -Ei 'curl|dom|fileinfo|imagick|intl|mbstring|mysqli|mysqlnd|openssl|xml|zip' You can also inspect the active configuration files with: php --ini Watch for a PHP runtime mismatch The command-line PHP version may not match the PHP runtime used by Apache, Nginx, or PHP-FPM on the web server. A web server can show mysqli in php -m while the site reports that a MySQL database extension is missing or uses different object caching settings. That is why we compare command-line results with phpinfo() or the hosting panel for accurate PHP compatibility checks. Always trust the runtime serving the domain, not a different PHP binary on the account. On some managed servers, versioned commands such as ea-php83 for PHP 8.3 or ea-php84 for PHP 8.4 replace php. Ask your hosting provider’s active support team for the correct versioned command instead of guessing. Match the Plugin’s Requirements Before Installation Checking the server’s PHP extensions is only half the job. Read the plugin’s installation requirements, then compare its required extensions with the actual runtime to confirm PHP compatibility. An image optimization plugin may need Imagick or gd for image processing. A multilingual tool may depend on mbstring and intl. A plugin that connects to a payment, email, shipping, or CRM service may need curl and openssl. Check the plugin’s PHP support Look for three details in the plugin documentation: The minimum PHP version and whether the plugin supports PHP 8.3 or PHP 8.4. The extensions it requires or recommends, plus notes about PHP compatibility. Any known conflicts with other plugins, themes, or server settings that could affect plugin compatibility. Don’t rely only on the WordPress plugin directory description. Visit the developer’s installation guide and changelog when the plugin handles payments, membership accounts, customer data, or important site functions. If the requirements remain unclear, contact the developer through an active support channel or ticket system before installing. Test performance-related modules correctly PHP extensions can affect speed, but adding more modules doesn’t automatically make a website faster. OPcache can reduce repeated PHP compilation. Redis and Memcached can support object caching. The image library and GD affect how images are created and resized. Those tools need correct server and plugin configuration. Configure them deliberately for performance and security. Misconfigured object caching can create stale pages or interfere with carts, forms, and logged-in sessions. After installing a plugin, test the homepage, contact forms, login page, checkout, media library, and any connected service. Check error logs if something feels wrong. If problems continue, ask your host’s active support team to review the runtime and logs. What to Do When an Extension Is Missing Don’t force the installation when a needed module isn’t available. For better error handling, save the exact error message and check the logs. Record the domain and PHP version, then contact your host with a clear request. Ask your host which PHP extensions are active for the PHP release serving your domain. Your host’s active support team can identify the active handler and explain whether the missing PHP extensions can be enabled. If you need Imagick, intl, or zip, ask whether the module can be enabled. You can also ask whether the plugin has an approved alternative with better PHP compatibility. VPS owners can usually install server packages, but the package depends on the operating system and PHP installation. Your hosting environment matters, so active support can confirm the package when shared hosting or cPanel limits access. Back up first, make changes during a quiet period, and test performance and security afterward. If you don’t want to manage PHP modules, updates, backups, and security settings yourself, our managed WordPress hosting handles much of that server work for you. Plans include automatic backups, security updates, SSL, and 24/7 active support. Frequently Asked Questions How can I check which PHP extensions WordPress is using? Start with Tools > Site Health > Info to review your site’s PHP version and server details. For the complete list of active modules, use a temporary phpinfo() page or check the PHP extensions for the correct domain and runtime in cPanel. Is php -m enough to verify WordPress PHP extensions? Not always, because php -m usually reports the command-line PHP runtime. Compare its results with phpinfo() or your hosting panel to confirm the extensions loaded by the web server serving your domain. Which PHP extensions should I check before installing a plugin? Common requirements include curl, dom, fileinfo, mbstring, mysqli or mysqlnd, openssl, xml, and zip. Image plugins may need imagick or gd, while plugins using object caching may require a configured Redis or Memcached service. What should I do if a required PHP extension is missing? Do not force the installation; save the exact error message and record the domain and PHP version. Ask your hosting provider whether the module can be enabled for the PHP runtime serving your site, or contact the plugin developer about an approved alternative. Can installing more PHP extensions make my WordPress site faster? Not automatically, since performance extensions need proper server and plugin configuration. OPcache, Redis, Memcached, and image libraries can help in the right setup, but misconfigured caching may cause stale content or interfere with forms, carts, and logged-in sessions. Install Plugins With Confidence A safe plugin install starts before the upload button. Check the PHP version and inspect the PHP extensions loaded by the live website. Compare them with the plugin’s requirements, then test important pages after activation. The right server configuration gives WordPress and its plugins the tools they need. A suitable host provides a clear place to review settings and reliable backups when changes go wrong. It may also offer configured services such as object caching and active support when a server setting gets in the way. [...]
Read more...
WordPressWordPress Site Health: Fix Problems FasterA red warning in your WordPress dashboard can make a small problem feel much bigger. The good news? The tool provides a health check before you change plugins, edit server files, or contact your host. We use the Site Health tool to separate urgent issues from useful improvements, collect the technical details support teams need, and trace failures back to PHP, SSL, REST API, or hosting settings. Start with the site health status view, then use the information screen for answers, not a complete site performance audit. How WordPress Site Health sorts your next move WordPress added Site Health in version 5.2 to help site owners spot problems without opening a server terminal. You can find the Site Health tool in your WordPress dashboard under Tools > Site Health. The screen has two main tabs, Status and Info. They work together, but they have different jobs. Start with the Status tab Status shows your site’s site health status and serves as your first health check. It checks the site and groups results into: critical issues, which can affect security, stability, updates, or important WordPress functions. recommended improvements, which may not break the site today but can make it safer or easier to maintain. Good results, which need no action. Open each result and read the details before changing anything. Site Health may flag an outdated PHP version, disabled automatic updates, failed background updates, an active debug mode, missing PHP modules, blocked HTTP requests, or an expired SSL certificate. Before making changes, check whether debug mode is active and review the update settings. It can also recommend removing inactive plugins and inactive themes. Those items may not be loading on the front end, but old files still belong to the website and can create security and maintenance problems. Fix the highest-risk item first Don’t chase the number of green results. Start with the critical issues and fix the problem that can cause the most damage. An outdated server runtime deserves attention before a minor recommendation about housekeeping. A failed loopback request matters more when scheduled tasks or plugin editing are already failing. If the site is public but the REST API is blocked, your editor, forms, integrations, or mobile tools may stop working. The official Site Health documentation explains where the screen lives and what information it reports. We recommend opening the details for every critical issue, copying the exact message, and recording when it appeared. A green Site Health screen means WordPress found no listed problems. It doesn’t promise fast pages, perfect uptime, or strong hosting resources. Use Site Health Info for faster support The Info tab is where troubleshooting gets practical. Status tells you that something is wrong. Info helps you show support staff what the website is running on. Read the server details, not only the summary Open Tools > Site Health > Info to view Site Health Info, then expand each section. You’ll find details about WordPress, the active theme, plugins, inactive themes, the server, database, PHP, media handling, and filesystem permissions. Pay close attention to: The PHP version and memory limit. The WordPress version and the database version. The web server and operating system. The active theme and plugin list. Whether GD or Imagick handles image processing. HTTPS settings and WordPress URL values. API endpoints and loopback-related information. This data can explain why one website works while another site on the same account fails. A plugin may need more memory, or GD and Imagick may differ in media handling. File uploads can expose that issue, and the server may reject outbound requests. These details document the initial health check and give support useful evidence. Copy the Site Health information to your hosting provider. Remove passwords, keys, tokens, and private details before sharing it publicly. Give support the details that matter A support request that says “WordPress is broken” starts slowly. A request that includes the failed test, PHP version, error code, active plugins, and approximate time can move much faster. We usually send: The exact Site Health warning. The affected URL, if it’s safe to share. The steps that caused the error. The timestamp and timezone of the failure. A copy of relevant Site Health Info. Any recent plugin, theme, PHP, DNS, or hosting changes. Ask your hosting provider to review PHP and web server logs, error logging, firewall events, cron activity, and outbound request rules. Site Health points to the problem, while server logs often reveal the line that caused it. Fix PHP and plugin warnings before they grow Many Site Health warnings point to software that needs attention. Treat them as maintenance signals, not background noise. Move to a supported PHP version PHP runs WordPress, themes, and plugins. An outdated PHP version can create compatibility problems, reduce performance, and leave the server exposed to security vulnerabilities. As of 2026, WordPress recommends PHP 8.3 or later. The WordPress requirements page says WordPress can still run on PHP 7.4 or newer, but older PHP releases have reached official end of life. The WordPress PHP requirements explain the security concern clearly. The Hosting Team recommends PHP 8.4 or later for production environments. WordPress 6.8 and later fully support PHP 8.4, while WordPress 6.9 and later fully support PHP 8.5, according to the current PHP support clarification. Before changing PHP: Create a current backup. Update WordPress, the theme, and plugins. Check whether important plugins support the target version. Test the change on staging when possible. Change PHP through your hosting panel or ask support to do it. Test the homepage, login, forms, checkout, media handling, and admin editor. If the site shows a fatal error after the change, switch back to the previous PHP version or use WordPress Recovery Mode. Then identify the plugin or theme that needs an update. Remove software you don’t use Inactive themes and plugins are easy to ignore. They shouldn’t stay forever. Delete inactive plugins you no longer need, rather than leaving them inactive. Keep one default WordPress theme available for recovery, but remove other unused themes after confirming they aren’t needed for a child theme setup or rollback. Before deleting or changing a parent theme, verify whether an active child theme depends on it. Take a backup first. Then remove one item at a time and test the site. If a warning returns after cleanup, check whether a management plugin, host tool, or deployment process is reinstalling the files. Repair HTTPS and REST API checks A secure connection and reliable communication between WordPress components support more than visitor trust. They also affect editing, forms, integrations, and communication between site components. Check the SSL certificate and site URLs An SSL certificate allows your site to load through HTTPS. Site Health can flag certificate and HTTPS problems when the certificate is missing, expired, mismatched, or incorrectly configured. Start by opening the site in a private browser window. Check the SSL certificate, then review the homepage, login page, contact forms, and a few image URLs. Look for certificate warnings, redirects between HTTP and HTTPS, or a browser message showing that the page contains insecure content. Inside Settings > General, confirm that both the WordPress Address and Site Address use https://. Don’t change those fields without a backup if you’re unsure. A wrong URL can lock you out of the dashboard. Mixed content often comes from old image URLs, theme settings, page builders, CDN files, or plugin options. Our guide to fixing mixed content errors covers the places those old HTTP links often hide. If certificate renewal or installation keeps failing, a managed option can remove the guesswork. ZADiC’s managed SSL service is built for site owners who want certificate management handled with their hosting setup. Investigate REST API failures The REST API lets WordPress components and approved services exchange data. The block editor, plugin integrations, forms, and external tools may depend on it. Open the Site Health warning and record the response code: A 401 or 403 often points to authentication, a firewall, a security plugin, or server rules. A 404 can indicate rewrite or permalink problems. A 500 usually requires checking PHP or server logs. A timeout can point to resource limits, DNS, outbound request blocks, or a slow plugin. The WordPress Site Health REST API reference documents Site Health test records, including the loopback-request test. That detail helps developers and hosts work from the same technical language. Solve a failed loopback request step by step A loopback request is WordPress asking the same site to respond. WordPress uses loopbacks for tasks such as starting a new WP-Cron instance and editing a plugin or theme. That makes a failed loopback more serious than a harmless dashboard warning. Backups may be delayed, scheduled events may not run, and plugin or theme editing can fail. Check the site from the outside Begin with a practical health check by confirming that the site loads normally over HTTPS. Check the homepage, login page, and a simple public post from a different network if possible. Next, identify anything that could block WordPress from reaching itself: Maintenance mode or password protection. Basic authentication on the whole site. A firewall or security plugin blocking the server IP. A CDN or WAF rule challenging server requests. Broken DNS records. An SSL mismatch or bad redirect. A server rule that blocks wp-cron.php or WordPress REST requests. Don’t disable every security tool at once. Test one change at a time, preferably on staging, and turn protection back on after the test. The WP_Site_Health class reference describes loopbacks as WordPress querying itself. Use that simple model for a troubleshooting sequence across the server layers. Know when the host must step in If the site loads for visitors but loopbacks fail, the hosting account may be blocking server-to-server requests. Ask your provider to test a request from the server back to the site and review firewall, DNS, SSL, cURL, and cron logs, including relevant error logging. Send the exact Site Health message, timestamp, domain, response code, and recent changes. Ask whether outbound HTTP requests are allowed and whether the server can resolve the domain to the correct address. If the same warning returns after every plugin fix, stop repeating the plugin fix. The server, firewall, DNS, or hosting account may be the real problem. Choose hosting that prevents repeat warnings Site Health is a diagnostic tool, not a replacement for dependable hosting. If your site repeatedly reports old PHP, failed loopbacks, weak resources, SSL problems, or update failures, ask your hosting provider to review the environment. For a small business site, reliable WordPress hosting should include a current PHP version, automatic backups, SSL, monitoring for security vulnerabilities, and support that can inspect server logs. ZADiC WordPress hosting plans include automatic setup, backups, automatic updates, free SSL on many plans, and 24/7 human support. If you don’t want to manage server settings yourself, managed WordPress hosting can handle more routine maintenance, PHP setup, caching, security, and backup work. That gives you fewer warnings to chase and more time to run the business. For sites that have outgrown shared resources, stronger hosting may be the better fix. Our guide to speeding up WordPress explains when cleaner server resources, caching, CDN support, or a VPS may improve site performance more than another optimization plugin. Frequently Asked Questions Where can I find WordPress Site Health? You can find it in the WordPress dashboard under Tools > Site Health. The Status tab checks for problems, while the Info tab shows the technical details support teams may need. Does a green Site Health result mean my site is performing well? No. A green result means WordPress found no listed Site Health problems, but it doesn’t guarantee fast pages, perfect uptime, or strong hosting resources. What should I fix first in Site Health? Start with critical issues that could affect security, stability, updates, or important WordPress functions. Fix the highest-risk problem first, such as outdated PHP, failed loopbacks, blocked REST API requests, or SSL errors. When should I contact my hosting provider? Contact your host when the warning points to PHP, DNS, SSL, firewall rules, server logs, cron activity, or blocked outbound requests. Include the exact message, response code, timestamp, recent changes, and relevant Site Health Info so support can investigate faster. Conclusion WordPress Site Health turns a vague “something is wrong” feeling into a practical troubleshooting path. Start with Status, fix critical issues first, use Info to collect evidence, and involve your host when problems reach PHP, DNS, SSL, firewalls, or server logs. We’ve found that the fastest fixes come from matching each warning to the right layer. Update WordPress software when the issue is inside WordPress. Improve hosting when the same server-level problems keep returning. [...]
Read more...
WordPressFix WordPress “failed to open stream” Errors FastA WordPress site can look completely broken when one PHP file is missing, unreadable, or referenced incorrectly. The “failed to open stream” error message names the path PHP tried to access, making it our fastest diagnostic clue. We don’t start by reinstalling WordPress or changing random permissions. We identify the file path first, then check whether PHP can access it or whether the PHP version may cause a compatibility issue. We also don’t edit wp-config.php unless the error points to it. A resulting fatal error can stop the site or dashboard from loading. Key Takeaways Copy the complete “failed to open stream” message and identify the exact file path before changing anything. Check whether the named file is missing, incorrectly referenced, unreadable, or affected by a PHP version mismatch. Use debug logging, FTP, cPanel, or phpMyAdmin to repair plugins, themes, WordPress core files, paths, permissions, and ownership when the dashboard is unavailable. Avoid risky fixes such as setting permissions to 777 or editing wp-config.php unless the error specifically points to it. Keep current backups of site files and the database, and test updates, migrations, PHP changes, and permission changes before applying them to production. What the “failed to open stream” Error Really Means PHP uses functions such as include, require, and fopen to open files. The require function stops execution when its file is unavailable, while the include function reports a warning and continues when possible. A stream is the connection PHP tries to create with that file. When PHP can’t create it, WordPress reports a “failed to open stream” error. You may see an error like Warning: require(...): Failed to open stream, followed by Fatal error: Uncaught Error. This error message identifies an access problem. The fatal error stops the rest of the request. The warning points to the cause, while the fatal error prevents WordPress from continuing. The wording for a missing file doesn’t always mean the file was deleted. The full file path is usually the main clue, so copy the complete error string before troubleshooting. The path may be wrong, the server may use another folder, or a PHP version mismatch may change application behavior. Read the final part of the error message Start at the end of the file path. Look for the plugin, theme, WordPress core folder, vendor directory, or wp-config.php named there. For example, a path containing /wp-content/plugins/example-plugin/ points us toward a plugin problem. A path containing /wp-content/themes/ suggests a theme issue. A path under /vendor/ usually points to Composer-managed dependency files in the vendor folder or a custom PHP application. The error message’s ending gives us another useful clue: Error endingLikely causeFirst checkNo such file or directoryMissing file or incorrect pathConfirm the full path and filenamePermission deniedFile ownership or permissionsCheck access for the web serverIs a directoryCode expects a file but finds a folderReview the filename and pathFailed opening requiredrequire could not load the fileRepair the missing dependency The PHP include manual explains how PHP resolves included files. That matters when a relative path works on one server but fails after a migration. Also confirm the PHP version used by the site when comparing behavior across servers. Find the Exact File Before Changing Anything Guessing creates more problems. A failed to open stream error can lead to a fatal error, so change one thing at a time, starting with the exact file named in the error. A failed update, server migration, deleted plugin, incomplete upload, or changed PHP path can trigger the problem. Write down what changed before the site failed, including whether the host changed the web server’s PHP version. That detail often points straight to the cause. Turn on the WordPress debug log safely If you can access wp-config.php, open it through cPanel, FTP, or SSH. Edit wp-config.php to enable logging privately, without displaying errors to visitors. The constants belong in wp-config.php; add these lines before the comment that says That's all, stop editing: define( 'WP_DEBUG', true ); define( 'WP_DEBUG_DISPLAY', false ); define( 'WP_DEBUG_LOG', true ); If these constants already exist in wp-config.php, edit their values instead of adding duplicates. WordPress normally writes the error log to wp-content/debug.log. You can also set a custom writable path, such as define( 'WP_DEBUG_LOG', '/tmp/wp-errors.log' );. Visit the broken page or repeat the action that caused the error message. Before editing any files, copy the complete error string and note its timestamp. Then open the error log through cPanel File Manager, FTP, or another file transfer method, and read the newest entries. WordPress documents this process in its guide to debugging WordPress errors. After reviewing the log, remove the temporary settings from wp-config.php and turn off debug mode. Debug logs can contain passwords, file paths, and other private details. Protect wp-config.php from public access, and don’t leave debugging active longer than needed. Check the file and the recent changes Use File Manager or FTP to inspect the exact file path named in the error. Check all of these details: Does the file exist with the same spelling and capitalization? Is the path pointing to the current domain folder? Did a plugin or theme update stop partway through? Did the error begin after moving to a new host, and does the current PHP version match the environment that previously worked? Does the file have a zero-byte size or look incomplete? Can the web server user read the file? If the file exists but PHP still reports “no such file or directory,” inspect the parent folders and verify each part of the file path. A single incorrect directory name can break the whole path. Server logs can also reveal failures that happen during cron jobs or background requests, so analyzing server logs for SEO issues can help when the browser shows very little. Restore Missing WordPress Files Without the Dashboard A fatal error can remove access to /wp-admin/, but the dashboard isn’t required for every failed to open stream repair. Hosting control panels, FTP, and phpMyAdmin provide other recovery routes. Before replacing files, create a backup if you can. Back up wp-config.php before any FTP or cPanel file transfer. This gives you a safe return point if the first fix doesn’t work. Disable a plugin through FTP or cPanel If the error identifies a plugin, open wp-content and rename the plugins folder to plugins.off. WordPress will stop loading the plugin files, which often restores the site and admin area. If the site comes back, rename the folder to plugins again. Then rename individual plugin folders one at a time until you find the one causing the failure. Update, replace, or remove that plugin only after confirming the source. Don’t delete the whole plugin folder as a first move. Renaming preserves the files and gives us a quick rollback. Repair a theme or WordPress core file When the active theme is missing or damaged, rename its folder. WordPress may then switch to an installed default theme while keeping the theme files available. If it doesn’t, use phpMyAdmin to inspect the site’s options table and check that the template and stylesheet values match an installed theme folder. Change those values only when you know the correct theme directory. Before uploading replacement files, confirm the PHP version and choose a package supported by that environment. For damaged WordPress core files, upload a fresh copy of the matching WordPress version. Replace the core folders and files, but leave wp-config.php and .htaccess untouched during the replacement. If the reported location identifies wp-config.php, restore or inspect it instead. Afterward, run integrity checks, such as a checksum or equivalent verification, on the WordPress core files. Use phpMyAdmin to confirm database access after the file repair. If you have a clean restore point, cPanel website backup restoration can be safer than manually rebuilding a broken installation. Restore the site files and database together when both changed around the same time. After restoration, confirm the site runs on the expected PHP version. Fix WordPress File Paths and Permissions Many failed to open stream errors appear after a hosting move. Code may still point to an old location, even when the file exists. Others happen because the file is present but PHP cannot read it. Replace hardcoded paths with WordPress constants A hardcoded file path can survive a server migration, then fail when the account name, domain folder, or server changes. WordPress provides path constants that follow the current installation. Inside WordPress-loaded code, use: require_once ABSPATH . 'wp-load.php'; $file = WP_CONTENT_DIR . '/uploads/example.txt'; require_once __DIR__ . '/includes/helpers.php'; ABSPATH and WP_CONTENT_DIR are path constants. ABSPATH points to the WordPress installation directory. WP_CONTENT_DIR points to the content folder on the server. Together, they produce an absolute path, not a web address. These path constants are for filesystem access, not browser URLs. For a browser URL, use the relevant URL constant instead. In a plugin, __DIR__ is often the safest way to reference a file stored beside the current PHP file. It avoids assumptions about the working directory. Verify the constructed file path with file_exists() before opening it when an optional file shouldn’t stop the entire request. After the move, test path-related code with the site’s current PHP version. Confirm the repaired code runs on the current PHP version before deploying it. Set safe permissions and correct ownership WordPress documentation generally recommends 644 or 640 for files and 755 or 750 for directories. See the official guide to WordPress file permissions before changing access settings. A typical setup looks like this: ItemCommon settingRegular PHP, CSS, and image files644WordPress directories755wp-config.phpMore restrictive, where supportedDebug logWritable only when logging is active Keep wp-config.php more restrictive where supported. Don’t alter wp-config.php unless the reported path points to it. Don’t change file permissions to 777 to make the error disappear. It grants far more access than WordPress needs and can create a security problem. Permissions aren’t the whole story. A file set to 644 can still fail when it belongs to the wrong server user or group. If PHP reports Permission denied, ask your host to correct ownership rather than applying broad recursive permission changes. Handle Custom PHP, MVC, and Laravel Paths The same “failed to open stream” error appears outside WordPress too. In a custom MVC structure or Laravel app, the error message points to the same first step: identify the exact path PHP tried to open. Stop relying on fragile relative paths A relative path may work when a file loads directly, then fail through another controller, cron job, or command line process. PHP’s working directory isn’t always the folder you expect, so check the web runtime’s PHP version when entry points differ. Use path constants to build a stable file path instead: __DIR__ . '/config/database.php' dirname(__DIR__) . '/vendor/autoload.php' $_SERVER can build an absolute path during a normal web request, such as $_SERVER . '/includes/file.php'. The document root isn’t dependable for CLI scripts, queue workers, or cron jobs because those processes may not provide the same server variable. A defined application base directory is safer, and Laravel or custom MVC applications shouldn’t assume WordPress’s wp-config.php conventions. Check Composer dependencies in Laravel If the error names a missing PHP file under vendor, Laravel is trying to load a Composer dependency that isn’t present or readable. Common causes include an incomplete deployment, a missing vendor folder, a mismatch between composer.lock and uploaded files, or incorrect ownership. Run integrity checks on the lock file, autoload mappings, and uploaded deployment files. Check the deployment directory and the deployment CLI’s PHP version, then confirm production matches the required PHP version. Then run the deployment’s normal Composer install process using the server’s supported PHP version. Don’t copy one random file into the vendor folder; Composer manages related files and autoload mappings together. The require function produces a fatal error when its target can’t load. The include function usually raises a warning and allows execution to continue. Use require for files the application can’t operate without, and include for genuinely optional files. Either function still needs a valid, readable path. Prevent Future PHP File Access Problems A good repair fixes the immediate file problem. A good hosting setup makes recovery faster next time. Keep WordPress core files, plugin files, theme files, the PHP version, and server software updated. Test major changes in a staging environment when your plan supports it. Check compatibility with your PHP version before production updates. Remove plugins and themes you no longer use, because unused files create security risks. Backups should include both site files and the database, with a copy of wp-config.php. Automatic daily copies, on-demand restore points, malware scans, integrity checks, SSL, and human support turn a long emergency into a short recovery. Export the database through phpMyAdmin when needed, and protect wp-config.php because it contains database credentials and other sensitive configuration. After migrations or changes involving file permissions, verify wp-config.php and test the site. Our WordPress hosting with automatic backups includes tools built for that kind of protection. If you need a simple control panel for files, databases, backups, and one-click WordPress setup, compare cPanel WordPress hosting. When traffic, memory needs, or technical demands grow, managed hosting can take routine updates and monitoring off your plate. The cheapest fix is often the one you can complete without rebuilding the site. Keep a clean backup before updates, migrations, and permission changes. Frequently Asked Questions What does “failed to open stream” mean in WordPress? It means PHP could not open a file that WordPress or another PHP application tried to load. The file may be missing, referenced by an incorrect path, unreadable because of permissions, or affected by a PHP compatibility issue. How do I find which file is causing the error? Read the complete error message and copy the full path named after require, include, or fopen. The folder usually identifies whether the problem involves a plugin, theme, WordPress core, vendor dependency, or wp-config.php. Can I fix the error if I cannot access WordPress admin? Yes. Use FTP or cPanel to rename the suspected plugin or theme folder, restore missing files, or inspect permissions. phpMyAdmin can also help switch to an installed theme when a damaged active theme prevents the site from loading. Should I set WordPress file permissions to 777? No. WordPress generally uses 644 or 640 for files and 755 or 750 for directories, depending on the server setup. If the error says Permission denied, incorrect ownership may be the real cause, so ask the host to correct it instead of applying broad permissions. Why does the error happen after moving hosts or updating PHP? A migration can leave hardcoded paths pointing to the old server location, while an update can expose incompatible code or missing dependencies. Check the current PHP version, verify the complete file path, and replace fragile paths with constants such as ABSPATH, WP_CONTENT_DIR, or __DIR__ where appropriate. Conclusion A WordPress failed to open stream error usually means the location is wrong, the file is missing, or PHP can’t access it. Read the complete error message, enable logging, inspect the named file, then repair only the affected component, location, or permission. You don’t need to panic when the dashboard disappears. FTP, cPanel, and phpMyAdmin, along with reliable backups and responsive hosting support, offer practical recovery options. Protect wp-config.php and confirm the site’s PHP version before making changes. Most cases are repairable, not a fatal error, so one missing file doesn’t have to become a lost weekend. [...]
Read more...
WordPressHow to Fix the WordPress Too Many Redirects ErrorA website that keeps bouncing between the same pages is more than annoying. It can lock visitors out, block your WordPress login, and make your business site look broken. The WordPress too many redirects error usually appears when parts of your setup disagree. WordPress may expect HTTPS while your server sends HTTP, or your domain may switch between www and non-www. Plugins, caching systems, .htaccess, and Cloudflare can also create conflicting rules. We’ll start with the quickest checks, then move into server and hosting settings if the problem remains. Key Takeaways The WordPress too many redirects error usually comes from conflicting HTTPS, domain, plugin, server, CDN, or caching settings. Trace the redirect chain first to identify whether the loop involves HTTP and HTTPS, or www and non-www URLs. Make sure the WordPress Address URL and Site Address URL match exactly, and use wp-config.php if you can’t access the dashboard. Deactivate redirect, security, SSL, and caching plugins, then purge caches across WordPress, hosting, your CDN, Cloudflare, and the browser. Use one clear owner for HTTPS redirects and align Cloudflare, proxy, origin server, and SSL certificate settings. What ERR_TOO_MANY_REDIRECTS Actually Means Your browser requests a page, but the server responds with instructions to visit another URL. That URL sends the browser back again, creating a redirect loop error. Chrome, Firefox, or Safari eventually stops after detecting an infinite loop. The most common loops look like this: http://example.com redirects to https://example.com, then back to HTTP. example.com redirects to www.example.com, then returns to the non-www version. Cloudflare sends HTTP to your server while your server forces HTTPS. A WordPress plugin adds a redirect that conflicts with a hosting rule. Cached 301 responses keep showing an old redirect after the real issue is fixed. The goal is simple: one preferred domain, one preferred protocol, and one clear redirect path. Trace the redirect chain first Don’t change five settings at once. Find the redirect that repeats. Open your browser’s developer tools, select the Network tab, turn on Preserve log, and reload the affected page. Look for repeated 301 or 302 responses and inspect the Location header. It shows where each request is being sent. You can also test the headers with curl -I https://example.com from a terminal. If the chain alternates between HTTP and HTTPS, the protocol is the problem. If it switches between www and non-www, your domain settings disagree. Cloudflare lists SSL mode, Edge Certificate settings, and redirect settings among the common causes in its redirect loop troubleshooting guide. How to clear browser cookies and cache Before editing WordPress, try a private window. If it works there, clear browser cache and remove its cookies. Stale cookies and cached redirect responses can make the repaired site look broken. Delete the domain’s stored data, then close and reopen the browser. A cached redirect can make a fixed website look broken on one device while it works normally elsewhere. This check takes a minute. It’s worth doing first. Fix the WordPress Address and Site Address WordPress stores two important URLs in its settings: WordPress Address URL, which points to the WordPress installation. Site Address URL, which is the public address visitors use. For most sites, both values should match exactly. Use the same https:// protocol, domain, www preference, and trailing-slash convention where applicable. URL mismatches often appear after a site migration or domain change. Match both URLs in the dashboard If you can access the admin dashboard, go to Settings > General. Check both URL fields carefully, including the HTTPS settings. For a standard site, the correct setup might be: https://example.com Both fields should use that same address. Don’t leave one set to http://example.com and the other set to https://example.com. The same applies to www. If your preferred address is https://www.example.com, use it in both fields. A small difference can create a large problem. WordPress provides additional guidance on changing these settings in its site URL documentation. Save the settings once, then clear your caching layers before testing again. If WordPress immediately redirects you out of the dashboard, use the next method. Set the URLs in wp-config.php When the admin area is unavailable, you can temporarily define the correct values in the wp-config.php file. Use your hosting file manager, cPanel, or an FTP client to open the file in your WordPress root directory. Add these lines above the /* That's all, stop editing! */ line: define( 'WP_HOME', 'https://example.com' ); define( 'WP_SITEURL', 'https://example.com' ); Replace example.com with your real domain. Use HTTPS only if your certificate is active and your server supports HTTPS. These constants override incorrect values stored in the WordPress database, including the relevant wp_options table. WordPress also explains the file’s role in its wp-config.php editing guide. Create a backup before editing the file. One missing quote or semicolon can cause a different error, so slow down for this step. If the site starts working, update the database values later or keep the definitions in place. Remember that these lines can make the URL fields in the dashboard read-only. Disable Plugins and Purge Caches A plugin can create a redirect loop without affecting every page. This often involves redirect, security, SSL, and caching tools. Look closely at Redirection, Really Simple Security, WP Rocket, and WP Fastest Cache. Test the caching plugin’s layer separately from the redirect and security tools. The issue isn’t that these tools are bad. It usually comes from two systems trying to control the same redirect. Deactivate plugins without dashboard access If you can still log in, deactivate plugins one at a time. Start with redirect, SSL, security, and caching tools, then test the site after each change. If you can’t reach the admin dashboard, use FTP or your hosting file manager instead. Open wp-content/plugins and rename the suspected plugin folder, such as redirection to redirection.off. If you can’t identify the plugin, rename the entire plugins folder to plugins.off. WordPress will deactivate all the plugins. This deactivates the tools without deleting their settings or website content. Rename the folder back after testing, then restore plugins one at a time until the loop returns. That process takes longer, but it identifies the source while preserving your plugin settings and website content. Purge every caching layer Run one cache flush across your WordPress plugin, hosting account, content delivery network (CDN), and browser. Include Cloudflare if it’s active. Some hosting security systems and Cloudflare Automatic Platform Optimization can cache redirect responses. That can preserve a bad 301 even after you fix the rule that created it. Test in a private window after the flush. If the page works privately but not normally, the regular browser session may still hold stale data. Reset the .htaccess File Apache and LiteSpeed servers often use an htaccess file (.htaccess) for redirects and rewrites. A damaged or duplicated rewrite rule can send every request into an infinite loop. Before changing the file, download a backup. Then rename .htaccess to .htaccess.bak. Renaming is safer than deleting because you can restore the original file if needed. Identify all owners of HTTP-to-HTTPS redirect rules in your hosting control panel, .htaccess, WordPress plugins, and CDN settings. You usually need one clear owner for that redirect. Try loading the site. If the redirect error disappears, .htaccess caused the problem. Once you can access WordPress, go to Settings > Permalinks and click Save Changes. WordPress will usually generate a fresh set of basic rewrite rules. Remove duplicate HTTPS rules Remove duplicate redirect rules from the hosting panel, file, plugins, or CDN. For example, an HTTPS rule in .htaccess can conflict with a hosting panel rule. A CDN may add another redirect at the edge. Multiple rules can turn one simple action into a loop. If your site runs behind a proxy or load balancer, the server may see the connection as HTTP even when the visitor used HTTPS. In that setup, redirect logic must correctly read the X-Forwarded-Proto header. Ask your hosting provider to check this rather than adding random rewrite rules. Nginx servers don’t use .htaccess. If renaming the file changes nothing, inspect Nginx configuration, hosting redirects, or your CDN instead. Fix Cloudflare Flexible SSL Loops Cloudflare Flexible SSL is a common cause of redirect loops in WordPress. With Flexible mode, the visitor connects to Cloudflare over HTTPS, but Cloudflare connects to the origin server over HTTP. A consistent SSL configuration requires agreement between the edge mode, origin protocol, and certificate. If your WordPress host automatically redirects HTTP to HTTPS, the cycle looks like this: The visitor requests HTTPS. Cloudflare connects to the origin using HTTP. The origin sends an HTTPS redirect. Cloudflare repeats the same HTTP request. The process starts over. Cloudflare documents this exact problem in its explanation of ERR_TOO_MANY_REDIRECTS and SSL modes. Use Full or Full (strict) with a valid certificate If your hosting account has a working SSL certificate, open Cloudflare and go to SSL/TLS > Overview. Choose: Full (strict) when the origin has a valid certificate that matches the domain. Full when the origin supports HTTPS but the certificate doesn’t pass Cloudflare’s full verification. Full (strict) is the stronger option because Cloudflare encrypts the connection to your server and checks the origin certificate. Don’t use Flexible mode while your origin server forces HTTPS. Either remove the origin redirect, which is rarely the preferred long-term choice, or move Cloudflare to Full or Full (strict). After changing the mode, run a cache flush in Cloudflare. Check your redirect rules and Page Rules too. An edge rule can conflict with a WordPress or hosting rule even when the SSL mode is correct. Check the certificate and origin settings Make sure the certificate covers the exact domain you use. Check both example.com and www.example.com if your site supports both. You can test the certificate with the Qualys SSL test. If the certificate is expired, missing a hostname, or installed on the wrong server, fix that before changing more redirects. If you’re using ZADiC hosting, its SSL certificates and WordPress hosting options keep these settings together. Fewer separate layers can make HTTPS issues easier to troubleshoot. Fix a Login Page That Keeps Redirecting When only /wp-login.php or /wp-admin loops, the cause is often different from a whole-site redirect. Start by using clear browser cookies for the domain. WordPress uses authentication cookies, and a stale cookie can send you back to the login page even after the main site works. Then check these settings: The two WordPress URL values match. The HTTPS settings match between your proxy, WordPress, and server. Your security plugin isn’t blocking or rewriting login requests. Cloudflare isn’t using Flexible mode with an origin that forces HTTPS. Your domain’s www and non-www versions resolve consistently. If you added define( 'FORCE_SSL_ADMIN', true ); to wp-config.php, the server and proxy must correctly recognize that the original request was HTTPS. Otherwise, WordPress can treat every secure login request as plain HTTP and redirect it again. Your hosting provider can inspect the server headers and authentication cookies faster than repeated trial and error. Human support is a practical escalation when those checks are needed. Prevent Redirect Problems on Your Hosting Account Once the site loads, test more than the homepage. Open the login page, a post, an image, and both www and non-www versions. Test the HTTP version too, and confirm every request reaches one final HTTPS URL. Keep a record of the canonical domain you chose. Use that same version in WordPress, your hosting panel, Cloudflare, Google Search Console, email links, and marketing materials. Test future domain or HTTPS changes on a staging site when possible, before applying them to production. If redirect problems keep returning, a simpler hosting architecture may reduce the systems controlling redirects. Ask your hosting provider whether the setup can be simplified. ZADiC offers WordPress hosting, cPanel hosting, managed Web Hosting Plus, and VPS options, so you can choose the level of control your site needs. Our goal is straightforward: dependable hosting, security monitoring, and 24/7 human support when something breaks. You shouldn’t need to become a server administrator to keep your website online. Frequently Asked Questions What causes the WordPress too many redirects error? The error usually happens when WordPress, the server, Cloudflare, or a plugin sends conflicting redirect instructions. Common examples include HTTP-to-HTTPS loops and repeated switches between www and non-www URLs. How can I fix the error if I can’t access WordPress? First, define matching WP_HOME and WP_SITEURL values in wp-config.php. You can also deactivate plugins by renaming their folders through FTP or your hosting file manager, then test the site again. Can a WordPress plugin cause a redirect loop? Yes. Redirect, SSL, security, and caching plugins can conflict with hosting or CDN rules. Deactivate suspected plugins one at a time, or temporarily rename the entire plugins folder if you can’t reach the dashboard. Why does Cloudflare cause too many redirects? Cloudflare Flexible SSL can create a loop when the visitor connects over HTTPS but Cloudflare connects to an origin server that automatically redirects HTTP to HTTPS. Use Full or Full (strict) mode when the origin supports HTTPS, then purge the Cloudflare cache. What should I check after fixing the redirect error? Test the homepage, login page, posts, images, and both www and non-www versions of the domain. Confirm that HTTP requests and alternate domain versions reach one final canonical HTTPS URL without additional loops. Conclusion The WordPress too many redirects error usually comes from conflicting URL values, SSL settings, server rules, plugins, or cached responses. Compare the request path, correct mismatched settings, remove conflicts, refresh server rules, and align the proxy with the origin when HTTPS is enforced. A working site needs one canonical domain and one clear HTTPS path. With the right hosting setup and support behind it, resolving those conflicts becomes manageable instead of a day-consuming mystery. [...]
Read more...
WordPressHow to Remove Unused WordPress Themes and Plugins SafelyYour WordPress site doesn’t need a theme museum or a collection of plugins you tested once and forgot. When we remove unused WordPress themes and plugins, we reduce security risks, save server storage, and support WordPress security. Cleaning up old autoloaded settings may also improve loading speed. A careful theme cleanup starts with a site backup and a dependency check. We then remove items through the WordPress dashboard when possible and review leftover database settings. A few careful steps now can prevent a much bigger repair later. Key Takeaways Back up the complete WordPress database and file structure before removing themes or plugins, and use staging for higher-risk cleanup. Check the active theme and child-parent relationships before deleting anything; never remove an active theme or its required parent theme. Deactivate plugins before deleting them, and use the WordPress dashboard when possible so uninstall routines can run correctly. FTP or cPanel removal is useful when the dashboard is unavailable, but manual deletion may leave database settings behind. Review leftover database entries carefully, test important site features afterward, and schedule regular cleanup to prevent future clutter. Why remove unused WordPress themes and plugins? Inactive themes and plugins may look harmless because they aren’t running. They still remain on your hosting server, inside your backups, and sometimes in your database. Inactive files can create security risks An inactive theme usually isn’t displaying your pages, but its theme files are still present. Outdated code in those files can contain security vulnerabilities or malicious code. Inactive components aren’t automatically exploitable, but attackers may still target vulnerable files. The same applies to deactivated plugins. Old code creates more files to monitor and more software to keep updated. WordPress’s hardening guidance treats deleting unused plugins as part of WordPress security and recommends getting themes and plugins only from trusted sources. Removing old files doesn’t replace updates, strong passwords, or malware scanning. It does reduce unnecessary exposure. If cleanup reveals suspicious files, redirects, or unfamiliar administrator accounts, stop deleting files and investigate the wider site. Our guide to WordPress security issue remediation covers the access, hosting, and file checks that come next. Cleanup reduces storage and database clutter Unused themes and plugins take up server storage. They also increase the size of backup files, which can make restores slower and harder to manage. There may be database leftovers too. Plugin settings can remain in the wp_options table after plugin files are gone, contributing to database bloat. Some options load on every page request, so a large collection of old entries can add unnecessary work and affect loading speed. The impact won’t be identical on every site. Still, clean hosting is easier to maintain, back up, and troubleshoot. What to check before deleting anything We treat WordPress theme cleanup like a small maintenance job, not a button-clicking spree. Take a few minutes to confirm what the site needs before removing anything permanently. Back up the full website Create a recent backup of both the database and all WordPress files. Include wp-content, the WordPress core files, wp-config.php, and .htaccess if your site uses it. The official WordPress upgrade backup instructions recommend backing up the database and every file in the WordPress directory. A backup is only useful if you can restore it, so check that the files exist and that the backup completed successfully. Before a higher-risk cleanup, we also prefer a staging environment. Remove the themes and plugins there first, check the site, then repeat the change on the live website. Check active themes and child themes Open Appearance > Themes and identify the active theme. If you see a child theme, find its parent theme before deleting anything. A child theme inherits files and functionality from its parent. It may contain only a stylesheet and a few custom templates, while the parent provides most of the site’s structure. WordPress’s child theme documentation explains how that relationship works. Never delete a parent theme while its child theme is active. Keep both themes unless you have moved the site to another theme and confirmed that the child theme is no longer needed. Also record any theme-specific widgets, menus, templates, customizer settings, or page-builder layouts before removal. These settings may remain, but the site’s appearance can change after the theme is removed. How to delete themes and plugins in the WordPress dashboard The dashboard is the safest and easiest place to remove unused items because WordPress can apply its normal deactivation and uninstall process through its admin interface. Remove an unused WordPress theme From the dashboard, delete WordPress theme files safely by following these steps: Sign in to WordPress with an administrator account. Go to Appearance > Themes. Select the theme you want to remove. Click Theme Details. Choose Delete and confirm. WordPress won’t offer the delete option for the active theme. Switch to another theme first, then check that the replacement works on desktop and mobile. Don’t delete every theme except the active one without checking your recovery needs. Keeping one clean, unused default theme can help with troubleshooting, although WordPress’s housekeeping guidance generally recommends removing themes that aren’t needed. Delete an unused plugin correctly Plugins need one extra step: Go to Plugins > Installed Plugins. Click Deactivate beside the plugin. Test the site, especially forms, checkout pages, analytics, and logged-in features. Click Delete. Confirm the removal. The official WordPress housekeeping steps use this deactivate-then-delete process. Deactivation stops the plugin from running. It doesn’t remove the plugin’s files or database settings. Deletion removes the plugin files, while a proper uninstall routine may also remove its settings and tables. That’s why clicking Delete in the dashboard is better than immediately removing the folder. Removing themes and plugins with FTP or cPanel Manual removal helps when the dashboard is unavailable, a theme causes a fatal error, or a plugin blocks access to the admin area. It also carries more risk because the usual uninstall process may not run. Delete files through an FTP client Connect to your hosting account with an FTP client that supports SFTP, such as FileZilla. Inside the FTP client, open the WordPress installation directory, then go to: wp-content/themes/ wp-content/plugins/ Use the FTP client to download a copy of the folder before removing it. Then use the FTP client to select only the folder matching the unused theme or plugin. Never delete the active theme folder. If a child theme is active, keep its parent theme folder too. If WordPress is broken after a plugin update, use the FTP client to rename the plugin folder first. Add a short suffix such as -disabled, then reload the site. If access returns, you can log in, deactivate the plugin properly, and remove it through the dashboard. Use cPanel File Manager cPanel provides the same file-level access through your browser. Open the file manager, locate the WordPress installation, and browse to wp-content. Select the unused theme or plugin folder, download a backup copy, and delete the folder. Check the folder name carefully, and ask your hosting company for help if you’re unsure before confirming. A one-letter mistake can disable the wrong component. If you want direct file access and one-click WordPress tools, cPanel hosting for WordPress keeps those controls in one hosting dashboard. We still recommend a full backup before using File Manager. Manual deletion can bypass uninstall routines. That means the website may work while old database settings remain behind. Continue with the database check instead of treating the deleted theme files as the end of cleanup. How to clean leftover database settings safely Deleting files and database maintenance are separate jobs. Treat this review as one careful step in broader theme cleanup. Don’t run broad database queries simply because an option name looks old. Let the plugin uninstall routine work first When you delete a plugin through WordPress, it may run an uninstall routine. That routine can remove plugin-specific options, settings, and database tables. The WordPress Plugin Handbook on uninstall methods explains how plugins should remove their own data. A well-made plugin may also give you a setting such as “Delete data on uninstall.” Read that option before deleting the plugin, especially if you may reinstall it later. Theme options and plugin settings can remain after either item is removed, so review them separately before deleting related data. If you removed a plugin through FTP or cPanel, check its documentation for cleanup instructions. Don’t assume every database table with a familiar-looking name belongs to that plugin. Review wp_options with care Use a staging site or a verified database backup before changing database records. The wp_options table may not be named wp_options if your installation uses a different table prefix. A safe review looks like this: Search the options table for the exact plugin slug or theme stylesheet name. Inspect the option name and value before changing anything. Check whether the option is marked autoload. Excessive or unnecessary autoloaded options can sometimes add work during requests and affect loading speed, but the impact varies by site. Confirm that the setting belongs only to the removed item. Remove one small group of confirmed leftovers. Test the site before making another change. Theme settings often use names similar to theme_mods_THEME-SLUG, but naming varies. Plugin settings may use a unique prefix, a serialized value, or several related rows. Don’t delete rows because they contain a common word such as settings, cache, or options. Don’t empty the entire options table. Serialized data can contain multiple settings in one value, and careless editing can cause errors across the site. When the ownership of a database entry isn’t clear, leave it alone or ask your hosting support team to review it. A small amount of harmless data is safer than a broken login, blank page, or missing site configuration. Verify the site and prevent future clutter Cleanup isn’t finished when the delete button disappears. Give the site a short inspection while the changes are fresh. Test the important pages Open the homepage, contact form, blog, checkout, account area, and any page using a builder or custom template. These checks help confirm website performance after cleanup. Check mobile optimization on a phone, then test the site in a desktop browser. Clear your caching layers, compare loading speed before and after, and review: Navigation menus and widgets Logo, fonts, colors, and homepage settings Forms, payments, and email notifications Search Console and analytics tracking PHP error logs and visible warnings WordPress, theme, and plugin update screens If something breaks, restore the backup or reinstall the component instead of guessing at database edits. Keep the site lean Before installing a new plugin, check whether WordPress or your current tools already provide the feature. Keep a short record of why each active plugin is installed, who manages it, and what it connects to. Set a monthly or quarterly cleanup reminder. Remove abandoned plugins, replace unsupported themes, and keep the remaining software updated. Our WordPress hosting plans include tools such as automatic setup, backups, updates, and support that can reduce the maintenance load. For sites where updates, backups, malware scans, and restores need more hands-on help, ZADiC WordPress hosting provides a simpler base for ongoing site management. Frequently Asked Questions Is it safe to delete unused WordPress themes? Yes, deleting unused themes is generally safe after confirming that the theme is not active and is not the parent of an active child theme. Keep a recent backup and consider retaining one clean default theme for troubleshooting. Should I deactivate a plugin before deleting it? Yes, deactivate the plugin first and test important site features such as forms, checkout, analytics, and logged-in areas. Then use the Delete option in the WordPress dashboard so the plugin’s uninstall routine has a chance to remove its settings. Can I remove a WordPress theme or plugin with FTP or cPanel? Yes, manual removal through FTP or cPanel can help when the dashboard is unavailable or a component causes a fatal error. Download a backup copy, select the exact folder, and remember that manual deletion may leave database settings behind. Do deleted plugins leave data in the WordPress database? They can, especially when a plugin is removed manually or does not include a complete uninstall routine. Review the options table carefully on a staging site or after confirming a database backup, and remove only entries that clearly belong to the deleted plugin. How often should I clean up unused WordPress themes and plugins? A monthly or quarterly review is a practical schedule for most sites. During each review, remove abandoned components, replace unsupported software, check backups, and keep the remaining themes and plugins updated. Conclusion To remove unused WordPress themes safely, back up the complete site, check for child-parent dependencies, and use the dashboard whenever possible. Deactivate plugins before deleting them, protect the active theme, and treat database cleanup as a separate job. A clean WordPress installation has fewer files to monitor, smaller backups, and less clutter, making theme cleanup easier when something goes wrong. With dependable hosting and a regular maintenance habit, your site can stay secure, manageable, and ready for its next stage of growth. [...]
Read more...