WordPress Site Health: Fix Problems Faster

Glowing monitor with dashboard panels and red, green, and amber status indicators.

A 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.

Submit a Comment Cancel reply

What's New?

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...
WordPressHow to Rotate WordPress Security Salts After a BreachA suspected WordPress breach changes the priority list fast. You need to limit access, protect your files, and stop stolen login sessions before you start digging into every detail. Rotating WordPress security salts is one of the quickest steps you can take. It invalidates existing authentication cookies, which logs users out and forces fresh sign-ins. That can cut off an attacker who still has an active session. The process is manageable, but the order matters. We recommend protecting the site first, replacing the full salt block, then reviewing every account and access point. How WordPress security salts protect your site WordPress security salts are secret random values stored in wp-config.php. They work with security keys to help protect authentication cookies, logged-in sessions, and nonces. Think of them as part of the lock system for your website. Changing one doesn’t repair a hacked site, but replacing the full set makes old session data unusable. The standard WordPress configuration includes eight values: AUTH_KEY helps protect authentication cookies. SECURE_AUTH_KEY supports secure authentication. LOGGED_IN_KEY protects logged-in user cookies. NONCE_KEY supports nonce creation. AUTH_SALT adds another secret value to authentication data. SECURE_AUTH_SALT adds protection to secure authentication data. LOGGED_IN_SALT supports logged-in cookie security. NONCE_SALT adds protection to WordPress nonces. The official wp-config.php documentation explains how these values fit into WordPress configuration. The wp_salt() reference also shows how WordPress uses secret keys and salts when generating protected values. Why changing salts logs users out When WordPress creates an authentication cookie, it uses the security keys and salts in the process. After you replace those values, old cookies no longer match. The result is immediate: Existing WordPress sessions stop working. Administrators and editors must sign in again. Stolen login cookies lose their value. Existing nonces may stop working and need to be regenerated. That forced logout is the main reason to rotate salts after a suspected breach. It doesn’t remove malware or repair unauthorized changes, but it closes one access route quickly. Rotating salts is an access-control step, not a complete malware cleanup. Prepare the site before rotating salts Don’t edit wp-config.php while an attacker may still be changing files or accounts. Take a few minutes to contain the situation first. Start by putting the site into maintenance mode if you can do so without hiding important evidence. If the site is actively being abused, ask your host to isolate it or suspend public access temporarily. Next, create a backup of the current site and database. Keep the backup in a safe location, and label it with the time and date. Preserve at least one copy for investigation, but don’t treat an old backup as clean automatically. Before changing anything, record useful details: The time you noticed unusual activity. Unknown administrator accounts or recent users. Suspicious plugins, themes, files, or scheduled tasks. Recent password-reset emails. Unexpected redirects, pop-ups, or new content. Security alerts and hosting access logs. Make a second backup of wp-config.php before editing it. The file contains database connection details and other sensitive settings. Store it outside the public website directory, protect its permissions, and don’t send it through an unsecured email thread. If you use cPanel or another hosting panel, open the file through the file manager or connect with SFTP. If you have shell access, WP-CLI is usually the cleaner option. Either way, edit the correct WordPress installation. Our WordPress hardening guidance should sit alongside this response, not replace it. Salt rotation helps end sessions, while hardening addresses wider risks such as weak accounts, outdated software, and unsafe configuration. How to rotate WordPress security salts safely There are two practical methods. Use WP-CLI if your hosting plan provides shell access. Use the WordPress salt generator when you need to edit wp-config.php manually. Option 1: Replace the block in wp-config.php Open the wp-config.php file in the root directory of the affected WordPress installation. Find the existing block containing the key and salt definitions. Replace the entire block with newly generated values. Don’t change one line and leave the other seven untouched. A partial replacement gives you less certainty during an incident. WordPress provides a generator that returns fresh random values for all eight constants. Copy the complete result, then paste it over the existing key and salt block. The new entries should look like this structure, but every value must be newly generated: define('AUTH_KEY', 'new-random-value'); define('SECURE_AUTH_KEY', 'new-random-value'); define('LOGGED_IN_KEY', 'new-random-value'); define('NONCE_KEY', 'new-random-value'); define('AUTH_SALT', 'new-random-value'); define('SECURE_AUTH_SALT', 'new-random-value'); define('LOGGED_IN_SALT', 'new-random-value'); define('NONCE_SALT', 'new-random-value'); Don’t invent values, shorten them, or reuse keys from another website. Save the file, upload it if you used SFTP, and visit the site in a private browser window. If the site shows a PHP error or stops loading, restore the backup copy immediately. A missing quote, extra character, or damaged PHP line can prevent WordPress from loading. Option 2: Use WP-CLI WP-CLI can update the file without requiring you to copy and paste long values manually. From the WordPress installation directory, run wp config shuffle-salts. The command changes the salt values in wp-config.php in place. Check your hosting account’s PHP and WP-CLI setup before running it on a live site. The official WordPress configuration command documentation covers the file and its placement. Keep a backup before using any command that modifies configuration files. After the command completes, open a new private browser session and test the login page. Existing browser sessions should no longer work. If another administrator remains logged in, ask them to close the session and sign in again. Complete the breach response after rotation Rotating WordPress security salts is an important first move, but it isn’t the finish line. If an attacker accessed the site, assume other credentials or files may be exposed. Change passwords for every WordPress administrator, hosting-panel user, SFTP account, database user, and email account connected to the website. Use separate, strong passwords for each service. Don’t keep an old password because it seems unrelated. Review the Users screen carefully. Remove unknown accounts, delete unused administrator profiles, and reduce trusted users to the permissions they need. WordPress recommends avoiding the username admin and reviewing old accounts in its brute-force protection guidance. Update WordPress core, plugins, and themes. Remove anything you don’t need, including inactive plugins. An inactive plugin can still become a problem if its files remain outdated or vulnerable. Then inspect the site for changes: Compare plugin and theme files with trusted original copies. Check for unfamiliar PHP files in wp-content. Review recently modified files. Search posts and pages for injected links or scripts. Check cron jobs and scheduled tasks for unknown entries. Review redirects, DNS records, and administrator email addresses. Scan the website with a reputable security service. If wp-config.php may have been exposed, rotate the database password too. The file stores database credentials, so changing salts alone doesn’t protect a database account that an attacker may already know. Application passwords need separate attention. The official salt guidance clearly covers cookies and nonces, but it doesn’t state that salt rotation resets every application password. Review and revoke application passwords individually where your site uses them. Don’t restore an old backup without checking it. A backup made after the intrusion can put the same malicious file right back on the server. When hosting support should take over Manual salt rotation works well for a small, isolated incident. A larger breach needs a wider response, especially when you can’t identify what changed. This is where dependable hosting support earns its place. With ZADiC, you can choose WordPress hosting, managed Web Hosting Plus, or VPS hosting based on how much control and support your site needs. Security monitoring, SSL, backups, and human support reduce the number of moving parts you need to manage alone. We recommend managed hosting when you don’t want to spend your day checking logs, patching software, and wondering whether a strange file belongs on the server. You still control your website, but you have a team and a stronger hosting setup behind it. For a small business, that matters. The goal isn’t to become a full-time security administrator. The goal is to keep your site available, your customers confident, and your business moving. Conclusion Changing WordPress security salts can end active login sessions within minutes. Replace all eight values, test the site, then reset passwords and inspect the wider hosting environment. Don’t mistake a forced logout for a full cleanup. Check users, plugins, themes, database credentials, backups, and hosting access before you call the incident closed. When the technical work becomes too much, managed WordPress hosting gives you reliable infrastructure and support without making security your full-time job. [...]
Read more...
WordPressBlock PHP Uploads in WordPress Before They RunOne vulnerable upload can give an attacker a quiet way into your website. A single disguised script may expose passwords, alter pages, or create a backdoor that keeps returning after cleanup. The safest way to block PHP uploads WordPress sites receive is to stop uploaded scripts from executing. We also need strong file rules, updated plugins, sensible permissions, and hosting that watches for trouble. Let’s start with the risk inside the uploads folder. Why the WordPress uploads folder needs protection WordPress normally stores images, PDFs, videos, and other media in wp-content/uploads. Those files need to be publicly available so visitors can view them. That public access creates a target. An attacker doesn’t need to upload a file named malware.php. They may use a double extension, a less common PHP extension, or a vulnerable plugin that handles uploads poorly. If the server treats that file as executable code, the attacker may run commands through its URL. The result can be serious: Malicious code may create administrator accounts. Attackers may inject spam links into posts and pages. Website files may be changed or deleted. Database credentials may be exposed. A backdoor may remain after the original file disappears. A media upload folder should store content, not run code. That distinction gives us a practical security rule: PHP execution has no place inside a normal WordPress uploads directory. WordPress itself checks many common upload types, but those checks aren’t a complete security boundary. A plugin can introduce a file-handling flaw. A compromised administrator account can also bypass normal expectations. That’s why server-level protection matters. Even if a harmful script reaches wp-content/uploads, the web server should refuse to execute it. Block PHP uploads WordPress sites cannot safely execute The exact fix depends on your hosting stack. Apache servers usually use .htaccess. Nginx servers ignore .htaccess, so the rule belongs in the server configuration. Before changing anything, create a backup of the current file and confirm whether your website uses Apache, LiteSpeed, or Nginx. If you’re unsure, ask your hosting provider. A wrong server rule can produce errors or fail without giving you any warning. Apache and LiteSpeed: add an uploads rule On Apache or LiteSpeed, create a file named .htaccess inside: wp-content/uploads/ Do not place this rule in the website’s root .htaccess unless your hosting support team tells you to. The uploads folder is the narrowest location, so the protection affects media files without interfering with WordPress core. For Apache 2.4 and newer, use: <FilesMatch "\.(php|phtml|php?|phar)$"> Require all denied </FilesMatch> This blocks common PHP variations, including .php, .phtml, .php5, and .phar files. The server returns a forbidden response instead of handing the file to PHP. Some older Apache setups use this syntax instead: <FilesMatch "\.(php|phtml|php?|phar)$"> Order Allow,Deny Deny from all </FilesMatch> Use one version, not both. If your host uses cPanel, you can create the file through File Manager. For a step-by-step file-manager example, see one.com’s guide to disabling file execution. The same approach is commonly recommended in the WordPress.org support discussion about disabling PHP execution. The rule is small, but its location matters. It must sit directly inside the uploads directory. Nginx: add a server-level location rule Nginx doesn’t read .htaccess. Adding that file to wp-content/uploads won’t protect the directory on an Nginx server. Your host needs to add a rule to the Nginx server block: location ~* ^/wp-content/uploads/.*\.(php|phtml|php?|phar)$ { deny all; return 403; } The rule matches PHP-related extensions below wp-content/uploads and returns HTTP status 403. That means the file can exist, but the web server won’t allow it to run. Nginx rules can interact with other location blocks, especially a general PHP handler. The order and pattern need to match your server’s existing configuration. This is one reason we don’t recommend editing production Nginx settings without a backup and a way to restore the previous version. If your website uses managed hosting, send the rule to support rather than guessing. A hosting technician can check the active web server, place the rule correctly, and reload the configuration safely. Test the protection before trusting it A rule that looks correct isn’t enough. Test the result. Upload a harmless file named test.php containing plain text, or ask your host to test the path without placing a real script there. Then request its URL, such as: https://example.com/wp-content/uploads/test.php A working block should return 403 Forbidden or another non-executable response. You should not see PHP output, a blank page generated by PHP, or a download that exposes source code. Delete the test file after checking it. If the request returns a normal page or executes code, contact your host immediately. The protection isn’t active yet. Strong upload security needs more than one rule Blocking execution closes one dangerous door. It doesn’t replace the rest of your WordPress security work. Start with the upload process itself. Only allow the file types your website needs. A photography site may need JPEG, PNG, WebP, and PDF files. It probably doesn’t need PHP, JavaScript, shell scripts, or server-side templates. Use trusted plugins that receive regular updates. Pay attention to plugins that accept profile pictures, contact form attachments, ZIP files, or document submissions. Upload features deserve extra scrutiny because they move files from a visitor’s browser onto your server. Keep WordPress core, themes, and plugins updated. Security fixes only help when they reach your site. Remove plugins and themes you no longer use instead of leaving inactive software in place. File permissions matter too. WordPress needs enough access to manage media, but every account and process shouldn’t have unrestricted control over every file. Your hosting provider can recommend the right ownership and permission setup for its server. A practical baseline includes: Blocking PHP execution in wp-content/uploads. Disabling unused plugins, themes, and server features. Using separate administrator accounts instead of sharing one login. Requiring strong passwords and two-factor authentication where available. Keeping off-site backups that you can restore. Reviewing security alerts, login activity, and unexpected file changes. Don’t overlook older files. If an attacker already placed a backdoor in the uploads folder, adding .htaccess won’t remove it. Review recently modified files, scan the website, check administrator accounts, and restore from a clean backup when needed. A security plugin can help with scanning and alerts, but it shouldn’t be your only control. Application tools, server rules, account security, and reliable backups work better together. How hosting makes WordPress upload protection easier Website owners often know they need protection but don’t want to edit server files every week. That’s reasonable. Your time belongs on customers, orders, and growth, not on hunting through configuration menus. The right hosting plan reduces that burden. ZADiC provides WordPress hosting and cPanel hosting for site owners who want simple setup without giving up dependable infrastructure. With cPanel access, you can manage files, domains, SSL, backups, and email in one familiar place. When you need more help, our managed Web Hosting Plus options add hands-on support and room to grow. We can help confirm whether your site runs Apache, LiteSpeed, or Nginx, then point you toward the correct protection for that environment. Our VPS options fit websites that need more control over server settings. That flexibility is useful when you manage Nginx rules, custom applications, or several WordPress installations. It also means you need a clear maintenance plan, so managed support can be a better fit if you don’t want server administration on your plate. Security monitoring and 24/7 human support give you another practical advantage. When a file behaves strangely or a website suddenly shows a forbidden error, you have someone to contact instead of relying on trial and error. Free SSL on many plans protects data moving between your visitors and website. One-click WordPress setup gets the site online quickly. The goal is straightforward: secure hosting that lets you focus on the business using the website. Check your WordPress uploads protection today If you want to block PHP uploads WordPress sites should never execute, begin with the server rule in wp-content/uploads. Apache and LiteSpeed need a local .htaccess file. Nginx needs a server-block rule. Then test the result with a harmless file request, remove the test file, and review the rest of your security setup. Update software, restrict upload types, protect administrator accounts, maintain clean backups, and monitor unexpected changes. A malicious PHP file is dangerous because it can look like an ordinary upload until the server runs it. Stop that execution path first. With the right hosting setup and a few focused controls, your uploads folder can stay useful without becoming an open door. [...]
Read more...
WordPressHow to disable WordPress file editor accessA hacked WordPress admin account can turn a tiny edit into a full website problem. The built-in file editor gives privileged users a direct path to your theme and plugin code. If you want to disable WordPress file editor, you don’t need another plugin. One line in wp-config.php removes the Theme File Editor and Plugin File Editor from wp-admin. Code changes then happen through a controlled server tool instead. We recommend this setting for business sites, especially when several people manage content or plugins. The change takes minutes, but the code must sit in the right place. Why disable the WordPress theme and plugin editors? WordPress includes browser-based editors under Appearance > Theme File Editor and Plugins > Plugin File Editor. They can be useful for quick changes, but they also put sensitive files close to the login screen. If someone gains administrator access, they may use the editor to add malicious code, create a backdoor, or break a plugin. A small account security issue can become a site recovery job. The editor also makes accidental damage easier. One missing character in a PHP file can trigger a critical error and take your site offline. Editing files through cPanel, SFTP, or SSH creates a more deliberate process. We don’t treat this setting as a complete security solution. We treat it as one sensible lock on an unnecessary door. DISALLOW_FILE_EDIT removes the dashboard editors, but it doesn’t stop file changes through SFTP, SSH, or a hosting file manager. How to disable WordPress file editor in wp-config.php Before editing a configuration file, create a current backup of your WordPress files and database. If something goes wrong, a backup gives you a clear way back. You’ll need access to the WordPress root directory. Most hosting accounts provide this through cPanel File Manager. You can also use SFTP or SSH if those tools are part of your hosting plan. Follow these steps: Open the WordPress root folder, often named public_html, and locate wp-config.php. Download a backup copy before making any changes. Open the file in the hosting editor or a plain-text code editor. Add the following line above the comment that says /* That's all, stop editing! Happy publishing. */. Save the file and return to your WordPress dashboard. define( 'DISALLOW_FILE_EDIT', true ); The spelling, capital letters, brackets, and semicolon all matter. Add the line only once. Avoid placing it inside another setting or PHP statement. You won’t need to restart the web server. Reload the dashboard, then check the Appearance and Plugins menus. The file editor options should no longer appear. one.com’s file-editing guide also recommends adding this constant in wp-config.php. When to use DISALLOW_FILE_MODS instead Sometimes you want to block more than code editing. WordPress also supports the DISALLOW_FILE_MODS constant: define( 'DISALLOW_FILE_MODS', true ); This setting disables the Theme and Plugin File Editors, along with dashboard actions that modify plugin and theme files. That includes installing, updating, and deleting plugins or themes through wp-admin. Use it on tightly controlled sites where updates happen through a maintenance process, staging site, or hosting team. It can be too restrictive for a small business owner who handles regular updates from the dashboard. For most sites, DISALLOW_FILE_EDIT is the better starting point. It removes the risky browser editor while leaving normal plugin and theme management available. Don’t add both settings unless you have a clear reason. DISALLOW_FILE_MODS already disables the editors, so the narrower setting adds little in that situation. Check the change and recover safely After saving wp-config.php, sign in again and look for the editor links. Administrators should no longer see Theme File Editor under Appearance or Plugin File Editor under Plugins. Try opening the old editor address directly if you want an extra check. WordPress should block access or show a permissions message instead of loading the editing screen. Need to restore editor access temporarily? Remove the line, or change true to false, then save the file again. We recommend turning the editor off once the emergency change is complete. If the site shows a critical error after saving, don’t keep editing randomly. Replace the file with your backup, or remove the new line through cPanel File Manager or SFTP. Your hosting provider’s support team can often help restore access without changing the rest of the site. Know what this setting doesn’t protect Disabling the editor only blocks changes made through the WordPress dashboard. It doesn’t prevent someone with hosting credentials from changing files through cPanel, SSH, SFTP, or another file manager. It also doesn’t fix vulnerable plugins, weak passwords, stolen login cookies, or an outdated WordPress installation. Keep WordPress, themes, and plugins updated. Use strong, unique passwords and enable two-factor authentication where available. Regular backups matter too. A security feature can reduce risk, but a clean backup is what helps you recover when prevention fails. For another layer, add malware scanning, login protection, and monitoring through reliable website security features. Jetpack’s security guidance also treats file editor restrictions as one part of broader WordPress protection. Make WordPress administration easier with ZADiC Safe maintenance shouldn’t require you to become a server administrator. Your hosting should give you a clear way to manage files, restore backups, and get help when a configuration change causes trouble. Our ZADiC WordPress hosting plans provide WordPress hosting with cPanel access, one-click setup, free SSL on many plans, and 24/7 human support. That gives you a practical alternative to making sensitive edits inside the WordPress dashboard. You can disable the editor in wp-config.php, handle approved changes through cPanel, and add security monitoring as your site grows. Fewer risky shortcuts. More control when you need it. Conclusion A single DISALLOW_FILE_EDIT line can remove the WordPress theme and plugin editors from wp-admin. Back up your site first, place the code above the WordPress stop-editing comment, and check both dashboard menus afterward. The setting won’t replace updates, strong login protection, or backups. It closes one unnecessary access point, giving your site a safer and more controlled maintenance routine. [...]
Read more...