Websites, Domains, SSL, Cache, and CDN
Manage the running status, domains, certificates, cache, logs, and real visitor IPs of WordPress or generic PHP websites.
Create and Manage Websites
Creating a website will simultaneously generate an independent system user, website directory, PHP-FPM, Nginx configuration, and database. Pausing a website only stops external access and does not delete files or the database.
Deletion and reinstallation are high-risk operations. WordPress reinstallation will recreate files and the database, which is not equivalent to a version upgrade that preserves content.
Domains and Document Root
- After modifying the primary domain or aliases, check DNS, SSL, and the WordPress site address.
- Document Root is only used for projects that explicitly need to serve web pages from a subdirectory.
- Custom Nginx configuration must maintain correct syntax; if saving fails, the panel will try to preserve the original working configuration.
SSL Certificates
Supports application, manual replacement, deletion, download, and automatic renewal. When using a CDN, the browser sees the CDN certificate, while the origin server certificate is still used for CDN origin-pull connections.
If automatic renewal fails, first check the brief reason in the prompt. When using a proxy like Cloudflare, also check whether the ACME validation path can reach the origin server; if automatic issuance is not possible, you can manually upload a certificate.
FastCGI Cache
Sites can enable page caching, set a validity period, and manually clear it. After enabling, do not install another WordPress page caching plugin simultaneously to avoid two layers of cache interfering with each other.
- 404 pages use a shorter cache to reduce repeated PHP execution for invalid requests.
- When a normal cache expires, visitors can see the old page first, and the server refreshes the content in the background.
- Common ad tracking parameters do not generate a separate cache copy.
- Generic PHP websites will more strictly adhere to the program„s “no-cache„ directives to avoid caching login states or personalized content.
Redis object cache and FastCGI page cache serve different purposes and can be used together as needed. If the page still shows old results after code updates, first clear the website cache, and if necessary, clear OPcache in Software Management.
CDN Real IP Mode
Strict mode only trusts the selected CDN's origin-pull IPs and is the recommended method. CDNs that provide trusted origin-pull IP ranges should use strict mode.
Generic CDN (compatibility mode) is suitable for services that cannot obtain fixed origin-pull IPs. It accepts visitor IP information carried by all connections, which is less secure than strict mode and cannot be enabled simultaneously with strict CDN groups.
Access Logs
You can choose to log only errors, simplified access logs, or full access logs, and set a retention period. Logs will retain both visitor addresses and actual connection sources to facilitate CDN configuration troubleshooting.
AI Development Access
You can temporarily enable 「AI Development Access」 for a specific website, allowing AI coding tools to connect to this website through a secure channel for development, troubleshooting, or modifications. The authorization applies only to this website and does not affect other websites.
- Once enabled, a 「connection package」 will be generated, containing the connection script and a one-time private key. It can only be downloaded once, so please store it securely.
- AI tools can read and write the website's files and database, but cannot use sudo to manage the entire server.
- Downloading the connection package again will automatically rotate the key, and the old key will become invalid immediately.
- After finishing, promptly disable the authorization. The panel will revoke the key and disconnect existing connections.
After downloading and extracting the connection package, run the connection script inside to connect your AI tool to the website. The script will automatically handle access permissions, no manual configuration required.
WordPress Managed Email
WordPress sites can send low-frequency transactional emails through the external SMTP configured in WP Panel, such as password resets, account notifications, and form alerts. The SMTP host, account, and authorization code are stored only in the panel and are not delivered to the site.
- The server administrator first authorizes the current site in „Site Details → WordPress Managed Email“; the site administrator then confirms in „WP Panel Optimizer → Managed Email“. Both confirmations are required.
- Only when the panel has authorized it will the WordPress admin display the Managed Email tab and the „Settings“ sidebar entry; when the panel status is unavailable, they are hidden by default. Sites that have already enabled it will still retain a recovery entry to disable takeover.
- The site administrator can set the default sender name and Reply-To; if the server administrator locks the sender name, it can only be viewed in the plugin and the lock cannot be bypassed.
- „Send Test Email“ will use the real managed SMTP path, count toward the site and server-wide quotas, and be logged in the site„s logs like a normal email. A successful test only means the SMTP provider has accepted it, not that it will necessarily reach the inbox.
Email Logs and Privacy
Logs are stored in the current site„s own WordPress database. The list records time, status, subject, and recipient; clicking “View„ will display in a popup the sender name, To/CC/BCC, Reply-To, Message-ID, duration, size, attachments, custom email headers, a sanitized HTML preview, and the full escaped original text. Viewing the body requires a dedicated permission and records the viewer and time.
Limitations and Failure Behavior
- Suitable only for low-frequency transactional emails, not for marketing bulk sends; there is no persistent queue, automatic retry, bounce handling, or final delivery tracking.
- If managed sending fails after it starts, it will not silently fall back to PHP mail; please handle the issue based on the logs and panel prompts before sending again.
- When a known third-party SMTP plugin is detected, takeover is paused. After removing the conflicting plugin, the old conflict status will be cleared, but it will not automatically re-enable; the site administrator still needs to confirm again.
- WordPress Multisite is not currently supported.
After pausing a site, which tasks will continue to run?
Pausing a site will not delete site data, nor will it disable existing task policies. Tasks already started will continue to completion; after re-enabling the site, deferred tasks will naturally resume from their next scheduled cycle, without concentrated catch-up runs.
- Deferred:Automatic database backups not yet started, automatic file backups, WP Cron, custom commands run as the site user, and remote backup background maintenance.
- Continue:SSL renewal, security maintenance, and WordPress inventory refresh.
Pausing is not a backup, nor is it maintenance authorization; before important operations, you should still separately create and verify backups.
What should I do if enabling or disabling AI development access fails on a high-traffic site?
When force-enabling, the panel will handle the continuously regenerating PHP processes for this site and display a processing status for the entire region. When disabling, it will first revoke the SSH key and terminate authorized sessions; if this site's PHP workers still briefly occupy the system user, the panel will only gently terminate this site's workers with limited retries, and will not stop the PHP-FPM master process or affect other sites.
Please wait for the page to display the final success or failure result, and do not repeatedly click. If it still fails after reaching the retry limit, check the server status according to the page error message and try again; other types of errors may fail directly, and forced operations are not guaranteed to succeed.