Advanced settings (my.swiftpress.io) — explained
What each Advanced option does—restart PHP, database tools, maintenance mode, WordPress debug, caching—and when to use or avoid them.
Advanced settings in my.swiftpress.io let you tune performance, troubleshooting, and visitor-facing behaviour for your WordPress site. They’re powerful—use them when you understand the trade-offs.
Path: Site → Advanced (or Advanced settings—labels may vary slightly).
Restart PHP server
What it does: Restarts the PHP process for this site (and add-on domains tied to it) so new PHP and Redis-related configuration is picked up.
Why it’s useful: After changing PHP version, limits, extensions, or Redis settings, a restart ensures nothing is still running with old values in memory.
Risks / notes: Visitors may see a brief glitch or slow request while workers restart—do it at a quiet time if possible. It’s not a substitute for fixing bad code; it only reloads the runtime.
Database management
What it does: Opens access to your MySQL administration tool (e.g. phpMyAdmin-style or equivalent) for direct SQL work.
Why it’s useful: Running queries, imports, exports, or repairs when you know what you’re doing—migrations, manual fixes, search-replace with care.
Risks / notes: High. Wrong DELETE or UPDATE can destroy data. Back up (see Backups & restore) before bulk changes. Prefer WordPress-native tools when possible. Intended for users comfortable with SQL.
Maintenance mode
What it does: Shows a maintenance notice to public visitors while the site still works for logged-in administrators (typical pattern—confirm behaviour in your UI).
Why it’s useful: Safer theme switches, plugin bulk updates, or content overhauls without exposing half-broken pages to everyone.
Risks / notes: Don’t leave it on by accident—remember to disable when finished. SEO and crawlers may see a maintenance page if left enabled too long.
WordPress debug mode
What it does: Turns on WordPress’s WP_DEBUG style behaviour so core and plugins can emit more diagnostic information.
Why it’s useful: Development and staging—helps developers see why something is failing.
Risks / notes: On live sites, extra notices can leak paths or behaviour to users if combined with display on screen. Prefer debug log (below) on production, or use only short windows during investigation.
WordPress debug log
What it does: Writes PHP/WordPress notices and errors to wp-content/debug.log (when enabled).
Why it’s useful: Captures errors that don’t display on screen—great for intermittent issues, AJAX, cron, or REST failures. You can review later or share redacted lines with support.
Risks / notes: The log file can grow and may contain sensitive paths. Rotate or clear when done; disable when you no longer need it. Don’t paste full logs publicly.
WordPress error display
What it does: Shows debug messages inline in HTML output (visitor-facing pages).
Why it’s useful: Local or staging debugging when you want immediate visual feedback.
Risks / notes: Dangerous on live sites—can expose paths, stack traces, or internal details to everyone, including bots. Do not leave enabled on production. Disable before going live or after fixing the issue.
PHP performance cache (OPcache)
What it does: Caches compiled PHP bytecode (often OPcache) so PHP doesn’t recompile the same files on every request.
Why it’s useful: Lower CPU, faster page loads—especially for busy sites. Recommended on production in almost all cases.
Risks / notes: After major code deploys, if something looks “stuck,” a PHP restart (above) can clear stale opcode cache. Rarely you may need to flush depending on platform—ask support if behaviour seems cached incorrectly.
Redis object caching
What it does: Stores database query results and WordPress object cache data in Redis so repeat queries don’t hit MySQL as hard.
Why it’s useful: Faster WordPress, especially WooCommerce, membership, and heavy plugins. Lower database load.
Risks / notes: If Redis is misconfigured or flushes incorrectly, you might see stale options until cache clears—usually rare on managed hosting. After migrations or URL changes, support may advise a flush. Don’t toggle randomly while debugging unless you know cache is the suspect.
Cache reserve
What it does: Persistent edge-style caching (implementation: Redis at the edge in your description) so hot content survives server restarts and stays fast and reliable.
Why it’s useful: Higher cache hit rate, more stable performance under load, less origin work for repeat visitors.
Risks / notes: Highly dynamic or personalised pages should bypass or vary cache (see CDN/WAF rules). If you publish time-sensitive content, confirm you’re not seeing stale pages—purge edge cache if your workflow includes that tool.
Quick reference: safe defaults
| Setting | Live / production typical |
|---|---|
| PHP performance cache (OPcache) | On |
| Redis object cache | On (when offered and supported) |
| Cache reserve | On if you want max edge persistence—watch for stale content workflows |
| Debug mode / debug log / error display | Off or log-only; never leave error display on live |
| Maintenance mode | Off except during planned work |
Need help?
Use — same as the Support link in the site footer (opens the chat widget). You can also sign in at my.swiftpress.io. We don’t offer email support — see How to contact customer support. If something in this article doesn’t match your dashboard, and we’ll point you to the right screen.