iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
If Settings > General is blank, spins indefinitely, or will not save, first determine whether the failure is limited to your browser or affects the site itself. Open the page in a private window or a different browser with extensions disabled. If it works there, clear the affected browser’s cache or remove the conflicting extension. If it fails in every browser, collect the JavaScript, REST API, PHP, and server evidence below, then isolate plugins and themes.
The General Settings screen manages the site title, tagline, WordPress and site addresses, user registration, language, timezone, date format, and time format. A page that never finishes loading can therefore involve the browser, admin JavaScript, the REST API, a plugin or theme, PHP, the database, or hosting configuration.
Start with a browser-versus-site test
Do not deactivate plugins or edit files before this quick comparison. It tells you whether the problem is local to one browser session or reproducible by the site.
- Open the dashboard in a private or incognito window.
- Try a second browser on the same computer.
- Temporarily disable browser extensions, especially ad blockers, script blockers, security extensions, password managers, and administrator toolbars.
- Sign in again and open Settings > General.
| Result | Most likely branch | Next action |
|---|---|---|
| It works in a private window or another browser | Cached JavaScript, a browser extension, or a browser-specific policy | Clear the original browser’s site data, update it, and re-enable extensions one at a time. |
| It fails in every browser | Site-wide JavaScript, REST, plugin/theme, PHP, database, or hosting failure | Use Developer Tools, Site Health, debug logging, and a conflict test. |
| It loads but saving fails | REST authorization, nonce, security filtering, PHP, or database error | Inspect the failed request and the corresponding PHP/server log entry. |
WordPress’s browser troubleshooting guidance treats a failure in all browsers as evidence of a JavaScript or plugin/theme problem rather than a problem confined to one browser.
Inspect the JavaScript error before changing the site
A spinning screen usually means an administrator script stopped before it could render or save the form. Capture the complete error before refreshing or closing the tab; the filename, line number, error type, and stack trace often identify the responsible component.
Open the Console
- Open Settings > General.
- Open your browser’s Developer Tools (usually F12 or Ctrl+Shift+I; on macOS, Cmd+Option+I).
- Select the Console tab, enable preservation of logs if available, and reload the page.
- Copy every red error, including its stack trace, script filename, and line and column numbers.
- Open the Network tab, reload, and filter for
fetch,XHR, orwp-json. Record requests returning 4xx or 5xx status codes and their response body.
Do not report only “uncaught error.” The full message can distinguish a blocked REST request from a missing JavaScript dependency, a syntax error, a security plugin response, or a PHP-generated error embedded in the page.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Use unminified core scripts temporarily
Production WordPress normally serves compressed, concatenated scripts. To make a core failure readable, add this temporary line to wp-config.php before the line that says WordPress has stopped editing:
define( 'SCRIPT_DEBUG', true );Reload the page and capture the new console filename and stack trace. Remove the line or set it back to false after diagnosis; unminified scripts are for troubleshooting, not a permanent production setting.
Check what the General Settings screen is supposed to load
The screen is not just a static form. Its values correspond to site configuration such as the title, description, URL, email address, timezone, and date formats. The authenticated REST settings resource represents fields including title, description, url, email, timezone, and date-format values. A failed request to that resource is a meaningful explanation for a form that never completes.
Test the REST request in the browser
- In Developer Tools, reload Settings > General with the Network panel open.
- Find the request whose path contains
/wp-json/wp/v2/settings(the exact request may include a site prefix). - Check its status and response. A 200 response indicates that the request returned data; 401 or 403 suggests authentication, nonce, security filtering, or permission interference; 404 can indicate a disabled or misrouted REST endpoint; and 500-series responses require server-side investigation.
- Compare the response with the console error, then save both when requesting help. Remove cookies, authorization headers, and other secrets before sharing logs publicly.
A REST request can succeed while a later save request fails, so inspect both the initial load and the request generated when you press Save Changes.
Recommended Free Tools
Run the built-in Site Health checks
Go to Tools > Site Health > Status. Pay particular attention to:
- REST API availability: a failed test supports the REST branch identified in the Network panel.
- Loopback requests: WordPress uses requests back to the site for scheduled tasks and other internal operations. A loopback failure can expose a plugin, theme, HTTP authentication, firewall, DNS, or server restriction.
- Blocked HTTP requests: outbound-request restrictions, firewalls, or a host policy may prevent WordPress components from completing.
- Debug configuration: Site Health can warn when debugging is enabled in a way that exposes visitors to diagnostic output.
The most common cause of a loopback failure is a plugin or theme conflict, but the check can also reveal hosting-level restrictions. Record the full test details rather than only the red or orange status label.
Rank #3
Capture PHP and server evidence safely
When the Console points to an AJAX or REST failure, the cause may exist in PHP even though the symptom appears in the browser. Temporarily enable WordPress logging in wp-config.php, above the “That’s all, stop editing” line:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );- Make the change during a short maintenance window or with a backup of the file.
- Open General Settings and reproduce the failure once.
- Inspect
wp-content/debug.logimmediately, noting the timestamp, PHP file, line number, and stack trace. - Check the hosting control panel’s PHP error log, web-server error log, and, where available, database log for the same timestamp.
- Turn off debug mode and logging after collecting the evidence.
Never leave public debug display enabled on a live site. Error output can reveal filesystem paths, SQL details, credentials embedded in configuration, or other information useful to an attacker. Logging can also accumulate sensitive request data, so restrict access to the log and remove or rotate it according to your host’s procedure.
Free tools Windows power users keep installed
One-click scans. No signup required.
What different log entries imply
| Evidence | Likely cause | Useful follow-up |
|---|---|---|
| JavaScript syntax error or missing function in a plugin file | Incompatible or partially updated plugin script | Test with that plugin disabled and check its version compatibility. |
| PHP fatal error naming a plugin or theme | Code incompatibility, missing dependency, or exhausted memory | Disable the named component, verify supported PHP and WordPress versions, and review its update or rollback path. |
| Database connection, query, or table error | Database availability, permissions, corruption, or a plugin query | Use the host’s database diagnostics and do not run repair operations without a backup. |
| 403, firewall, ModSecurity, or request-block message | Hosting security rule or security plugin blocking admin/REST traffic | Ask the host to review the exact timestamp, URL, and rule ID; do not broadly disable protection on a production site. |
Check URL constants and configuration overrides
Open wp-config.php and search for WP_HOME and WP_SITEURL. If WP_HOME is defined, WordPress displays that value but does not allow the site URL to be edited from General Settings. That behavior is intentional and is different from a page that fails to load.
define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com' );Do not replace the values with your own domain unless you have verified the correct scheme, hostname, path, and multisite configuration. An incorrect constant can redirect the dashboard, create mixed-content problems, or make the site unreachable. If the field is merely locked, manage the URL in the configuration or deployment system that defines it; if the entire screen spins, continue with the REST and conflict branches.
Isolate plugin and theme conflicts without taking the site down
Use Health Check troubleshooting mode
Health Check & Troubleshooting mode changes the environment only for your logged-in session. Visitors continue to see the normal site, while your session can run with plugins disabled and a default theme selected.
- Install or open the Health Check & Troubleshooting tool from the WordPress dashboard.
- Enable troubleshooting mode for your account.
- Leave all plugins disabled and use an installed default theme, then reload Settings > General.
- If the page works, re-enable plugins one at a time, reloading after each activation.
- When the page fails again, the last component enabled is the primary suspect. Disable it, then test the theme separately.
- Exit troubleshooting mode after the test so your account returns to the normal site configuration.
Record the order and result of each activation. A conflict can require two components together, so if every item works alone, test combinations involving the components that alter admin JavaScript, REST permissions, caching, security headers, or settings pages.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →Deactivate components from the normal dashboard
If troubleshooting mode is unavailable, create a recent backup and deactivate plugins from Plugins > Installed Plugins. Switch temporarily to an installed default theme under Appearance > Themes. Reload General Settings after each meaningful change, and reactivate one item at a time rather than all at once.
Recover when wp-admin is inaccessible
When a fatal theme error prevents dashboard access, use FTP or SFTP and open wp-content/themes/. Rename the active theme directory, for example from custom-theme to custom-theme.disabled. WordPress will fall back to an installed default theme. After regaining access, inspect the PHP log, restore the original directory name, and resolve the theme problem before reactivating it. Do not rename the directory if you are unsure which theme is active or if no default theme is installed; ask the host to create a backup and confirm the active theme first.
Use the symptom to choose the next branch
| Symptom | Check first | Evidence to retain |
|---|---|---|
| Blank page with a console error | Console stack trace and SCRIPT_DEBUG output | Full error, script path, line number, and browser used |
Spinner with a failed wp-json request |
REST status, response body, nonce, and Site Health REST test | Request URL, status, timestamp, and redacted response |
| Page loads but Save Changes returns an error | Save request, PHP log, security-plugin and firewall events | Request status, returned message, and matching server log entry |
| Only one browser fails | Extensions, cached site data, browser update, and private-window result | Working browser and extension combinations |
| Failure begins after an update | Recently updated plugin, theme, WordPress core, or PHP version | Update time, component versions, and first error timestamp |
| Loopback and REST tests fail together | Plugin/theme conflict, firewall, HTTP authentication, DNS, or host policy | Complete Site Health details and host error-log entries |
When to escalate to your host or a plugin author
Escalate after testing a clean browser, reviewing the REST request, checking Site Health, capturing logs, and running a conflict test. Send a concise evidence bundle:
- WordPress and PHP versions, active theme, and the component versions changed just before the failure.
- The exact console error and stack trace, with secrets and personal data removed.
- The REST load or save request status and response, including the timestamp and site path.
- The relevant lines from
wp-content/debug.logand the hosting PHP/web-server log. - Whether General Settings works with plugins disabled and a default theme.
- Whether the problem affects all browsers, logged-in administrators only, or visitors as well.
Give the host the exact timestamp and request path so it can correlate firewall, PHP-worker, database, and web-server records. Give a plugin or theme author the isolated reproduction and the first stack-trace frame that points into its code. Avoid posting complete configuration files or unrestricted debug logs in public forums.
Prevent the next General Settings failure
- Test major WordPress, PHP, plugin, and theme updates on a staging copy before production.
- Keep a current backup of files and the database before configuration or theme changes.
- Monitor Site Health and address REST, loopback, and blocked-request warnings before they become admin failures.
- Keep production debug display disabled; enable logging only for a controlled reproduction.
- Document constants such as
WP_HOMEandWP_SITEURLso administrators know when a URL field is intentionally locked. - Retain the browser, REST, and server evidence for recurring failures instead of repeatedly clearing caches without identifying the trigger.
What a successful repair looks like
After correcting the offending layer, test the complete workflow rather than stopping when the spinner disappears. In a normal browser, open General Settings, confirm the displayed title, URLs, language, timezone, and date formats, change one noncritical value, select Save Changes, and reload the page. Confirm that the value persists, the Console is clear of new errors, the REST request returns successfully, and Site Health no longer reports the related failure. Then remove temporary SCRIPT_DEBUG and debug settings and verify that public pages do not display diagnostic output.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
