AdminsForum - aaPanel WordPress Guides

Run WordPress Scheduled Tasks with aaPanel Cron

Tue, 13 Oct 2026 11:42:03 +0800

Quick answer
Create one aaPanel task that runs your site's wp-cron.php using the correct PHP interpreter and website user. Verify a due event actually runs, then keep traffic-triggered WP-Cron disabled for that site. Our lab now has one five-minute task for wp.adminslab.com; its native log and a due WordPress test event both passed.

Why use a server schedule?
WordPress normally checks scheduled events during website traffic. A low-traffic site can therefore run due work late. A server scheduler gives WordPress regular opportunities to process its due queue, even when nobody visits the site. It does not make every plugin task safe, repair broken callbacks or force future events to run early.

1. Check the actual website and PHP
Record the exact document root and active PHP version. Our website root is /www/wwwroot/wp.adminslab.com and its active PHP-FPM runtime is PHP 8.5.11. The matching CLI interpreter is /www/server/php/85/bin/php. Verify those paths on your own server instead of copying 85 for a website using another version.
WordPress Site Health reports the web runtime. The server's generic php command may point to another interpreter with different extensions and limits. Test the executable you will schedule.
Also identify the website's OS user. Our site files use www. Running the PHP workload as the website user helps avoid root-owned generated files.

2. Create one task
In aaPanel, open Cron and keep Task type set to Shell Script. Give it a specific name such as “WordPress scheduled tasks — wp.adminslab.com”. Choose N Minutes and set the interval to 5. Check that the description says it executes every five minutes, rather than a daily time or a five-hour interval.

wordpress-cron-settings-branded-20261013.jpg (Size: 101.45 KB / Downloads: 6)
Our panel stores the scheduler wrapper as root, and the command explicitly runs PHP as www. If your panel supports selecting the correct website user directly, use that with the corresponding plain PHP command instead. Do not substitute another OS account without checking its access.

3. Use a command with visible exit status
The exact tested lab wrapper is:

Code:

/usr/sbin/runuser -u www -- /www/server/php/85/bin/php -q /www/wwwroot/wp.adminslab.com/wp-cron.php
af_status=$?
echo "WordPress scheduler finished; exit code: $af_status"
exit "$af_status"

Change the website path, PHP interpreter and website user to match your setup. The wrapper's scheduler account must be allowed to use runuser; a non-root task cannot generally switch to arbitrary accounts.
Keep the exit status: it makes a failed PHP invocation visible. Do not suppress every error and then print a misleading success message. Our first silent version gave an unhelpful empty log, so the tested final version reports the interpreter's result.
Save the task once. Check the task list for an existing equivalent job before adding another.

4. Verify the native task
Use Execute for this specific task, confirm the named task and inspect its Log. An empty output is not by itself proof that a due WordPress callback ran.

wordpress-cron-log-branded-20261013.jpg (Size: 75.79 KB / Downloads: 8)
Our final native log reported exit code 0 and Successful. A subsequent automatic five-minute run also logged success. The existing certificate-renewal task stayed running, and the earlier website/database backup demo tasks stayed stopped.

5. Verify an actual due WordPress event
For the lab, we registered a temporary, uniquely named test hook, scheduled it as due and had its callback write a timestamp. The native task processed it. A separate check read the recorded execution time and confirmed DISABLE_WP_CRON was true. The test hook and marker were then cleaned up.

wordpress-cron-proof-branded-20261013.jpg (Size: 41.17 KB / Downloads: 6)
This is stronger evidence than the task's Running label. For your real site, inspect a known due event or a scheduled post after its due time, and review any plugin-specific errors. Do not change every plugin schedule just to create a test.

6. Replace traffic-triggered WP-Cron
Back up wp-config.php privately. Once the server task is ready and its operation is verified, add the following before WordPress loads wp-settings.php:

Code:

define('DISABLE_WP_CRON', true);

Check first whether that constant is already defined. Do not create duplicate definitions. Lint the configuration and confirm the site still loads.
If the new task fails, restore the previous scheduling behavior while you fix the task. Leaving both traffic-triggered and external scheduling disabled can prevent due work from running. The lab's final state keeps the verified five-minute task running and traffic-triggered execution disabled for this site.

Troubleshooting

PHP executable not found: use the full installed interpreter path for the website's intended PHP version.
Permission denied: check the website user, directory permissions and command wrapper. Avoid making the entire website world-writable.
Task exits successfully but an event remains overdue: inspect that event's callback, application logs and any cron lock; scheduler invocation alone cannot repair plugin logic.
Task runs twice: check for duplicate native jobs, external schedulers and the site's DISABLE_WP_CRON configuration.
Wrong timestamps: distinguish server/log timezone from WordPress display timezone. The lab verification timestamp was recorded in UTC.

Rollback
Restore traffic-triggered scheduling if needed, then stop the equivalent aaPanel task so you do not leave redundant schedulers. Verify a due event again. Do not disable unrelated SSL renewal, mail or backup tasks.

References: WordPress system-scheduler documentation and aaPanel Cron documentation. © AdminsForum.

Enable Redis Object Cache for WordPress in aaPanel

Tue, 13 Oct 2026 11:37:33 +0800

Quick answer
Install the official Redis Object Cache plugin, configure its connection before enabling it and verify the cache really persists. Our lab uses Redis 7.4.11 on localhost, database 15 and the prefix af_wp_lab:. The plugin connects through Predis; a PhpRedis extension was not required for this tested free-plugin setup.

What this cache does
A persistent object cache stores WordPress objects between requests and can reduce repeated database work. It differs from HTML page caching and PHP OPcache. Enabling Redis does not by itself configure a CDN, LiteSpeed page cache or every website on the server.

1. Check Redis before changing WordPress
In aaPanel App Store, locate Redis. Install the official package if absent; if installed, open its settings and check its service and configuration. Our lab already had Redis because the mail stack uses it. We did not reinstall it or change the mail service's database.

panel-tls-proof-branded-20261013.jpg (Size: 61.42 KB / Downloads: 7)
Our checks found bind 127.0.0.1, protected-mode yes, port 6379 and an existing authentication requirement. The active listener was localhost only. No public Redis firewall port was added.
Do not remove authentication to solve a WordPress connection error. Read the existing configuration privately and give the intended client the correct authorized configuration.

2. Choose an isolated cache namespace
Pick an unused Redis database and a unique prefix for the WordPress site. The lab had 16 logical databases, and database 15 was empty before use. We selected it without clearing anything. Do not assume database 15 is free on your server; check first.
A database number and prefix prevent accidental key collisions, but they are not a security boundary between mutually untrusted users. On a production server shared with mail or other applications, plan an appropriately restricted Redis identity or separate instance. Do not share an unrestricted administrator credential between unrelated users.
Avoid global cache flushes. Clearing all Redis data can remove mail filtering or other application state.

3. Install the correct WordPress plugin
In WordPress, open Plugins → Add Plugin and search for Redis Object Cache. Verify the author is Till Krüss, use Install Now and then Activate. Our installed version was 3.0.0. A similarly named cache plugin may have a different configuration or backend.
Activation alone does not mean persistence is enabled. Initially our plugin reported Redis unreachable because the server requires authentication; after the proper configuration and reload, it reported Reachable.

4. Configure wp-config.php privately
Back up wp-config.php outside the publicly served website before editing. Add the connection constants before the line that loads wp-settings.php. Our tested configuration was:

Code:

define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
define('WP_REDIS_DATABASE', 15);
define('WP_REDIS_PREFIX', 'af_wp_lab:');
define('WP_REDIS_CLIENT', 'predis');
define('WP_REDIS_PASSWORD', 'YOUR_EXISTING_AUTHORIZED_REDIS_PASSWORD');

Replace the password placeholder privately and choose your own unused database/prefix. Do not paste the real secret into a public support request. The screenshot masks it.
Check PHP syntax before reloading the website. Our PHP 8.5 configuration lint passed. A typo in wp-config.php can break the whole site, so keep the backup ready.

5. Enable Object Cache
Open Settings → Redis. Confirm Redis says Reachable, then select Enable Object Cache. The plugin installs its object-cache drop-in and should report Connected.

redis-connected-branded-20261013.jpg (Size: 93.8 KB / Downloads: 6)
Our page showed Connected, a writable filesystem, host 127.0.0.1, port 6379, database 15, the separate prefix and Predis 2.4.1. The free plugin was connected even though the separate Pro promotion noted that PhpRedis was absent; that promotion is not the same as the free plugin's connection status.
If another plugin already manages an object-cache.php drop-in, resolve ownership before replacing it. Do not enable two competing persistent object-cache implementations at once.

6. Verify persistence, not just the status label
We loaded the same WordPress installation in two separate PHP processes. The first stored a temporary value through wp_cache_set. The second retrieved it through wp_cache_get and checked the content, then removed only that test key.

redis-persistence-branded-20261013.jpg (Size: 31.56 KB / Downloads: 7)
Both checks passed. Without persistence, a value stored only in the first process's memory would not survive into the second. We also reloaded the administration page successfully after enabling the cache.
This proves the tested connection and persistence. It is not a benchmark or a claim that every site will load a particular percentage faster. Measure your own workload after configuration.

Troubleshooting

NOAUTH: check the intended Redis credential in private configuration. Do not make the service unauthenticated.
Connection refused: confirm Redis is running and the configured address/port match its listener. Keep a local-only setup local.
Not enabled but Reachable: the connection works, but the persistent drop-in still needs enabling.
Drop-in conflict: identify which cache plugin owns object-cache.php before modifying it.
Unexpected cached data: confirm each site has a unique database/prefix and review the application's cache policy. Do not use FLUSHALL as a first response.

Rollback
Use Disable Object Cache in the plugin before deactivating it, then check the site still loads. Keep the private wp-config.php backup. If WordPress cannot load at all, use your established file-management/recovery route to inspect the drop-in and restore the correct configuration. Do not stop a shared Redis server used by mail merely to disable one WordPress cache.
The tested lab cache remains enabled on its separate database/prefix. No other Redis database was flushed.

References: Redis Object Cache plugin and aaPanel Redis documentation. © AdminsForum.

Install LiteSpeed Cache in aaPanel WordPress and Verify Cache Hits

Tue, 13 Oct 2026 02:57:54 +0800

Quick answer
Install the official LiteSpeed Cache WordPress plugin, confirm your website actually uses OpenLiteSpeed, enable public-page caching and check repeated anonymous HTTPS requests for X-LiteSpeed-Cache: hit. Test purging separately. A plugin activation message or green settings switch is not proof that visitors receive cached pages.

Our test used aaPanel 8.0.6, OpenLiteSpeed 1.8.5, lsphp 8.5.11 and LiteSpeed Cache 7.9.1 on an isolated Ubuntu 22.04 lab on 12 October 2026. We verified real cache hits, observed misses after a homepage purge, and then disabled/deactivated the plugin before returning the lab site to Nginx.

1. Verify the backend before installing a cache plugin
This guide tests OpenLiteSpeed's server page cache. The WordPress plugin also has other optimization features, but those do not make its LiteSpeed server cache work on an ordinary Nginx/PHP-FPM backend.

Open WordPress Tools → Site Health → Info → Server. Our test reported Web server: LiteSpeed and PHP SAPI: litespeed after selecting Nginx + Openlitespeed in aaPanel. Follow the engine-switch and rollback walkthrough first if necessary.

Keep a current website/database/configuration backup. Record other cache plugins or reverse-proxy caching already in use so you do not mistake one cache layer for another. Our lab had no other active WordPress plugin when this test began.

2. Install the official plugin
In WordPress, open Plugins → Add Plugin. Search for LiteSpeed Cache. Identify the plugin published by LiteSpeed Technologies, then click Install Now. Wait until installation finishes and the button becomes Activate. Click Activate and confirm the installed plugin is active.

ols-cache-install-branded-20261012.jpg (Size: 175.09 KB / Downloads: 11)

We installed version 7.9.1 through WordPress's native Plugin Directory interface. Do not install a similarly named package from an unknown download page.

3. Use a simple public-page configuration
Open LiteSpeed Cache → Cache → the Cache tab. Confirm Enable Cache is ON. For this public-page lab test we set Cache Logged-in Users, Cache Commenters and Cache REST API to OFF, then clicked Save Changes. Cache Login Page and Cache Mobile were already OFF.

ols-cache-settings-branded-20261012.jpg (Size: 106.87 KB / Downloads: 11)

These choices keep the test focused on anonymous public pages. They are not a universal performance preset. Evaluate membership, shopping-cart, personalized and API behavior separately before enabling additional caching. We did not add Force Public Cache URIs or force private/account pages into public cache.

We did not connect QUIC.cloud, enable a CDN, request remote image optimization or enable the crawler. None of those steps was needed to verify the local OpenLiteSpeed page cache in this lab. Avoid changing minification and other optimization settings while diagnosing basic caching.

4. Test without your administrator login cookies
An administrator browser session is not a reliable anonymous cache test. Use a separate signed-out browser session and inspect the document response headers, or run cookie-free requests from a terminal.

This is the exact spaced request test we used. Replace the URL with your public homepage. It makes three ordinary HTTPS GET requests without login cookies, checks curl's exit code, and prints only the relevant response headers:

Code:

python3 - <<'PY'
import subprocess,time
for n in range(1,4):
 print('Anonymous GET',n)
 r=subprocess.run(['curl','-sS','--max-time','20','-D','-','-o','/dev/null','https://wp.adminslab.com/'],capture_output=True,text=True)
 print('curl exit:',r.returncode)
 for line in r.stdout.splitlines():
  if line.lower().startswith(('http/','server:','x-litespeed-cache:','x-litespeed-cache-control:','cache-control:','age:')):print(line)
 if r.returncode:print('Request failed; inspect connectivity before retrying')
 time.sleep(2)
PY

This uses GET rather than assuming that a HEAD request behaves identically. It does not log in, weaken certificate verification or print authentication/cookie headers.

Interpret the result

HTTP 200 and curl exit 0: the requested page was reached successfully.
X-LiteSpeed-Cache: miss: this response was not served from a stored LiteSpeed cache entry.
X-LiteSpeed-Cache: hit: this response was served from LiteSpeed's page cache.
No hit/miss header: confirm the selected backend, cache configuration and eligible URL before claiming caching works.

Our first tests returned repeated misses. Later anonymous requests returned hits. A cold cache or operation still completing can affect the first results; recheck after processing finishes rather than treating one immediate miss as a finished diagnosis. If misses persist, inspect cache storage permissions, server configuration, exclusions and conflicting layers using the official troubleshooting documentation.

Nginx remained the public front end, so the response's Server header said nginx even when X-LiteSpeed-Cache reported hit. The backend was independently verified through WordPress's litespeed SAPI.

5. Test the purge operation
Open LiteSpeed Cache → Toolbox → Purge. For the plugin's page cache, choose Purge All - LSCache. The lab displayed Notified LiteSpeed Web Server to purge all LSCache entries. We also tested Purge Front Page to invalidate only the homepage.

ols-cache-purge-branded-20261012.jpg (Size: 160.69 KB / Downloads: 11)

Repeat the anonymous request check. Our targeted homepage purge was not instantaneous: the first observed response still showed hit, followed by subsequent miss responses. The screenshot captures that transition. This checks the actual response after the notification rather than treating the notification alone as evidence.

ols-cache-hit-branded-20261012.jpg (Size: 73 KB / Downloads: 11)

After a purge, allow the site to generate fresh eligible responses and recheck for hits before declaring it warmed again. We did not measure a purge latency guarantee or performance improvement. Do not use Empty Entire Cache as a routine substitute for the narrower plugin/page purge; its scope is broader.

6. Check normal website behavior
Open a post and a standalone page over HTTPS. In the lab, /hello-world/ and /sample-page/ rendered successfully on OpenLiteSpeed. We also opened the dashboard and uploaded an original branded JPEG through WordPress; its public HTTPS image loaded at its original dimensions.

For a real site, check logged-in and logged-out behavior separately and test any forms, carts or personalized screens before keeping new cache settings in production.

7. Disable caching before an engine return test
We set Enable Cache to OFF and saved the setting, then deactivated LiteSpeed Cache through Plugins → Installed Plugins. The plugin remained installed for future lab testing. We used aaPanel's native Rollback and a validated Nginx reload, then verified WordPress reported nginx/1.30.5 with fpm-fcgi SAPI.

Anonymous HTTPS requests still returned HTTP 200, but no longer reported a LiteSpeed cache hit/miss header. Public content and the uploaded image remained accessible. The lab is left on Nginx with LiteSpeed Cache inactive.

What this test proves
The official plugin installed and activated, public-page settings saved, anonymous requests received cache hits, and the homepage purge was followed by misses. Website content/media checks and the return to PHP-FPM passed. This is a tested setup and verification guide, not a speed benchmark or a recommendation to cache every URL.

References: official WordPress plugin listing, LiteSpeed installation/cache verification and cache troubleshooting. Screenshots are original © AdminsForum lab captures.

Set WordPress Permalinks in aaPanel and Check Nginx Rewrite Rules

Tue, 13 Oct 2026 00:25:46 +0800

Quick answer
For a new WordPress website, open Settings → Permalinks, choose Post name and click Save Changes. Then open an actual published post. On Nginx, the site also needs a WordPress routing rule so URLs such as /hello-world/ reach index.php.

This walkthrough was tested on our isolated AdminsForum lab on 12 October 2026: aaPanel 8.0.6, Nginx 1.30.5, PHP 8.5 and WordPress 7.1.3. We changed Plain to Post name and opened the resulting published post successfully. The required rewrite rule was already present; we inspected it rather than replacing a working configuration.

Before you start

WordPress must already be installed and accessible over HTTPS. See our WP Toolkit installation guide.
Sign in as a WordPress administrator. The aaPanel account and WordPress account are separate.
Have a current files-and-database backup. See our backup guide.
For an established site, plan redirects from existing URLs before changing the structure. Do this on staging first; existing bookmarks and external links can depend on the old URLs.

1. Open the permalink settings
In the WordPress dashboard, expand Settings and click Permalinks. Our fresh installation used Plain, which creates a URL such as https://example.com/?p=123.

Choose Post name for the /sample-post/ structure. The Custom Structure field should show

Code:

/%postname%/

Do not enter the whole domain in that field. Leave Category base and Tag base alone unless you are deliberately changing archive URLs.

The screenshot shows the resulting saved configuration: marker 1 identifies Permalinks, marker 2 identifies Post name and marker 3 identifies the confirmation message.

wp-permalinks-saved-branded-20261012.jpg (Size: 174.47 KB / Downloads: 9)

2. Save and check the confirmation
Scroll to the bottom and click Save Changes. Wait for Permalink structure updated. Reload this settings page and confirm Post name remains selected. Selecting the radio button without saving does not update the site.

wp-permalinks-savebutton-branded-20261012.jpg (Size: 106.02 KB / Downloads: 8)

3. Check the Nginx routing in aaPanel
For a site created through WP Toolkit, go to WP Toolkit → your website → Modify → Config → URL rewrite. For a manually created PHP site, open that website's configuration under Website and look for URL rewrite.

Our root-installed WordPress site used this working rule:

Code:

location /
{
    try_files $uri $uri/ /index.php?$args;
}
rewrite /wp-admin$ $scheme://$host$uri/ permanent;

The try_files line serves real files/directories first and sends other requests to WordPress's index.php, preserving the query string. The wp-admin rule adds the trailing slash to that administration URL.

wp-permalinks-rewrite-branded-20261012.jpg (Size: 112.91 KB / Downloads: 8)

Keep an already working rule. If yours is missing and pretty URLs return 404, first save a copy of the existing rule, then use the WordPress template offered by your aaPanel installation for the correct web server and site layout. Review it before saving. Do not paste a second location / block into a configuration that already has one. A WordPress installation in a subdirectory needs rules for that layout; the root-site example above is not a universal replacement.

Nginx does not read Apache .htaccess rules. If you run Apache or OpenLiteSpeed, use the configuration appropriate to that server rather than pasting this Nginx block. This tutorial tested Nginx only.

4. Test real content, not just the homepage
Open the public homepage and click the title of a published post. In our lab, Hello world! changed to

Code:

https://wp.adminslab.com/hello-world/

and opened with its content and comments intact.

wp-permalinks-result-branded-20261012.jpg (Size: 81.73 KB / Downloads: 8)

Also open a published page, such as Sample Page, directly from the navigation. Test in a logged-out/private window and refresh a deep URL directly. A working homepage alone does not prove that rewritten URLs work.

If you get a 404

Homepage works, every pretty URL fails: check the web-server rewrite rule and whether it belongs to the same domain/site root you changed.
Only one URL fails: check its actual slug, publication status and copied URL. A draft page is not a public page.
Changes look stale: clear any relevant page cache/CDN cache, then retest the exact URL.
The panel refuses the configuration: restore the saved rule and inspect the error; do not repeatedly add duplicate blocks.

For a new test site, selecting Plain again and saving can help distinguish a rewrite problem from an application problem. On a live site, use your rollback plan so a second URL change does not add confusion.

Does this guarantee better Google rankings?
No. Readable URLs help visitors understand links, but rankings still depend on useful content, indexing and the rest of the site. Avoid repeated permalink changes just to chase SEO.

Our verified result
Post name saved successfully; /hello-world/ opened the published post; the Nginx WordPress rule was visible in aaPanel. We did not simulate a broken rule or test an Apache/OpenLiteSpeed migration in this walkthrough.

Reference: WordPress permalink documentation. Screenshots are original AdminsForum lab captures.

Set a WordPress Featured Image on an aaPanel Website

Mon, 12 Oct 2026 20:50:18 +0800

How do you set a featured image in WordPress?
Open the page or post editor, select the Page or Post settings tab and click Set featured image. Choose an image from Media Library, confirm the selection, then save the content and preview it. Where it appears depends on the theme and template.

We tested this on the draft page created in our page-and-preview walkthrough. The aaPanel-hosted lab runs WordPress 7.1.3 with the Twenty Twenty-Five theme. The image selection persisted after reloading the editor and appeared in the draft preview.

Featured image versus an Image block
A featured image is associated with the page or post as a whole. Themes may display it in a header, article card or another template location. An Image block places a picture at a specific position inside the content.

Selecting a featured image does not automatically insert an Image block into your paragraph. It also does not guarantee that your SEO plugin will use it as the social-sharing image. Review the theme and any SEO/sharing settings separately.

1. Open the content editor
In WordPress choose Pages → All Pages or Posts → All Posts, then Edit the correct item. We used our saved About-this-website draft rather than changing a published page.

If the settings sidebar is closed, use Settings in the editor’s top bar. Select the Page or Post tab instead of Block. In our page editor the sidebar offered Set featured image.

2. Choose an existing image
Click Set featured image. The Featured image dialog offers Upload files and Media Library. We chose Media Library because the demonstration image was already uploaded.

Select the exact image. Check its title, thumbnail and attachment information before confirming. If your library is large, use Search media and the date/type filters to locate the intended item.

  wp-featured-select-20261012.jpg (Size: 134.08 KB / Downloads: 10)
Our selected AdminsForum image in the Featured image dialog.

For uploading a new item, follow our WordPress media-upload guide. Review screenshots for private information before uploading, and only publish images you are allowed to use.

3. Set the featured image
Click Set featured image in the dialog. The dialog closes and the editor sidebar should show a thumbnail plus Replace and Remove controls.

Our image already had useful alternative text saved in Media Library. Review image descriptions for the context in which the picture is used. Avoid using a keyword list as alternative text.

4. Save and verify persistence
Click Save draft when editing a draft. Wait for the save to finish. For existing public content the save control may differ; review what action it will perform before submitting.

Reload or reopen the editor after saving. We verified that the selected image remained associated with the draft after the editor reloaded.

  wp-featured-saved-20261012.jpg (Size: 134.48 KB / Downloads: 9)
The saved editor shows the featured image and keeps the page status as Draft.

An image visible immediately after selection is not proof that it was saved. Confirm the saved state and reopen the editor when you need to be certain.

5. Preview the page in its theme
Use View → Preview in new tab. Inspect where the theme places the image, how it scales and whether the crop is suitable for the page. Check the layout on relevant screen sizes before publishing.

  wp-featured-preview-20261012.jpg (Size: 128.23 KB / Downloads: 8)
Our Twenty Twenty-Five draft preview displayed the selected featured image.

Other themes or templates may not display a featured image in the same location—or may not display it at all. If it is saved but absent from the page, inspect the template before assuming the upload failed.

The preview is not the same as publishing. Our demonstration page stayed a draft. The uploaded image itself already had a direct file URL; draft content should not be treated as private file storage.

6. Replace or remove the association
The sidebar exposes Replace and Remove controls. Replace lets you choose another featured image. Remove clears its association with this item; it is different from deleting the file from Media Library.

We did not test those removal actions in this walkthrough. Before deleting a media file, check whether other pages use it. Deleting the shared file can affect more than one content item.

Troubleshooting

No Set featured image control: confirm that the document settings tab is selected, and check whether your theme/content type supports featured images.
Selection disappears after reload: inspect whether the save completed, whether the session expired and whether the editor reported an error.
Image saved but not shown in preview: review the theme’s page/post template and cache behavior.
Image crop is unsuitable: choose artwork that fits the template’s display area and inspect the actual preview before publication.
Social preview still uses another image: check your SEO/sharing configuration separately; featured-image selection alone does not verify Open Graph output.

Verified result
We selected an existing media item, assigned it as the featured image, saved the draft, verified the selection after reloading and confirmed the image in the theme preview. We did not publish the lab page, replace/delete the attachment or verify social-sharing metadata for that WordPress page.

Screenshots and results are from our own AdminsForum lab.

Create and Preview a WordPress Page on an aaPanel Website

Mon, 12 Oct 2026 20:48:17 +0800

How do you create a WordPress page without publishing it immediately?
Open Pages → Add Page, enter a title, add your content blocks and choose Save draft. Use View → Preview in new tab to see the page in the website’s theme. Previewing a draft does not publish it to visitors.

We tested this workflow on wp.adminslab.com, our aaPanel-hosted WordPress 7.1.3 lab. We saved a real draft page and confirmed its title and paragraph rendered in the Twenty Twenty-Five theme. The test page remains a draft.

1. Choose a page rather than a post
Sign in to WordPress. Pages are useful for content such as About or Contact pages. Posts are usually used for dated articles and a blog feed. For this demonstration choose Pages → Add Page.

The editor can offer starter patterns. In our test, a Choose a pattern dialog appeared. We used its Close button to start with a blank page. You can choose a pattern when it suits your design, but it is not required for adding basic content.

  wp-page-blank-20261012.jpg (Size: 82.88 KB / Downloads: 6)
The blank page editor before adding our title and paragraph.

2. Enter a clear page title
Click Add title and type the name of the page. We used AdminsForum Lab — About this website. Use a title that describes what visitors will find rather than an unexplained placeholder.

The title becomes part of the page content and helps identify it in your administrator page list. Do not confuse it with an independently configured SEO title or meta description supplied by an SEO plugin.

3. Add the first content block
Click Type / to choose a block or Add default block beneath the title. The editor creates a Paragraph block. Write a short introduction.

Our demonstration paragraph explains that the website is an AdminsForum tutorial lab used to test aaPanel and WordPress workflows. We kept the example simple so the saved result could be verified without extra plugins or design changes.

You can add more blocks later. Use headings to divide substantial content, and an Image block for pictures. A page made of one giant paragraph is harder to read and maintain than a few purposeful sections.

4. Save the draft
Click Save draft in the top bar. Wait for the operation to finish. Our editor displayed Draft saved.

  wp-page-draft-saved-20261012.jpg (Size: 145.38 KB / Downloads: 6)
Our saved draft contains a title and paragraph. The page has not been published.

Do not rely on having text visible in the editor as proof that it was saved. Confirm the saved state before closing the tab. The Publish button is a separate action, and we did not use it in this test.

5. Open the website preview
Click View in the editor’s top bar. The menu in our version offers desktop, tablet and mobile preview options, plus Preview in new tab. Choose Preview in new tab and wait for the page to render.

  wp-page-preview-20261012.jpg (Size: 120.1 KB / Downloads: 8)
The draft preview rendered our title and paragraph in the website’s actual theme.

Check the wording, spacing and page structure. Review the layout on the screen sizes relevant to your visitors. A preview is a useful check, but it does not prove that navigation menus, forms or every device configuration will work.

The preview may require your logged-in session. Do not treat its address as the permanent public page URL or share URLs containing private preview tokens unnecessarily.

6. Return to editing
Go back to the editor tab, adjust the content and save again when needed. Preview the new version rather than relying on an older open preview tab.

A draft can remain unfinished while you gather content or review the design. Saving it does not automatically put it in the site’s header menu or make it the homepage. Menu placement and homepage selection are separate tasks.

7. Prepare for publication when the page is ready
Before publishing a real page, check its content, links, image descriptions, visibility and intended URL. Remove placeholder text and verify any promised contact details or functionality.

WordPress’s Publish controls allow you to review the publication settings. Publishing, scheduling or changing visibility should match your intended audience. This guide stops at a saved, previewed draft because that is the workflow we tested; it does not claim a public page was published.

Troubleshooting

The pattern dialog covers the editor: choose a suitable pattern or close the dialog to start blank.
Save draft fails: preserve your text, check the error and session, and confirm whether the REST request or server response failed before continuing.
Preview shows old content: save the current draft, reopen or refresh its preview and check whether you are viewing the correct page.
The page is not in navigation: a draft is not public navigation content. Even after publication, menu/homepage placement may need separate configuration.
Editor labels differ: WordPress versions and themes can change the interface. Match the action—save, view or publish—rather than blindly clicking the same screen position.

Verified result
We created the lab page, saved its title and paragraph as a draft and confirmed its preview rendered in the original Twenty Twenty-Five theme. We did not publish it, change the homepage or edit navigation menus.

Screenshots and results are from the AdminsForum lab.

Upload Images to WordPress on an aaPanel Website

Mon, 12 Oct 2026 20:46:04 +0800

How do you upload an image to WordPress on aaPanel?
Use WordPress → Media → Add Media File, select your image and wait for the upload to finish. Open Edit to add a meaningful title, alternative text and caption, then save and verify the file URL. You do not need to open aaPanel’s file manager for an ordinary WordPress media upload.

We tested this on our aaPanel-hosted wp.adminslab.com website running WordPress 7.1.3 and PHP 8.5.11. The JPEG upload, attachment details and direct HTTPS image URL were verified.

1. Prepare the image
Use an image you have permission to publish. Give it a clear filename before uploading and choose dimensions appropriate for its purpose. Avoid uploading camera originals when a smaller image will do. Review screenshots for passwords, tokens, private messages and other information that should not become public.

For this demonstration we used our own AdminsForum-branded Site Health screenshot. A copyright mark identifies the source; it does not prevent someone from copying the file.

2. Open the uploader
Sign in to your WordPress administrator dashboard and select Media → Add Media File. Our screen offered Select Files and displayed a 50 MB maximum upload size.

wp-media-upload-before-20261012.jpg (Size: 102.69 KB / Downloads: 7)
WordPress’s upload screen on our lab. Your server may have a different limit.

The number is a maximum, not a target image size. Small, appropriately sized images usually transfer more efficiently than large originals. If your file exceeds the limit, optimize it first or review the website’s PHP configuration rather than assuming WordPress is broken.

3. Select and upload the file
Click Select Files and choose your image. Wait for the upload to complete. Do not close the tab while progress is running or retry repeatedly before the original operation finishes.

wp-media-upload-success-20261012.jpg (Size: 120.51 KB / Downloads: 6)
Our uploaded file appears with Edit and Copy URL to clipboard actions.

If the normal uploader fails, the screen also offers a browser uploader. That is an alternative upload interface, not a way to bypass server limits or file-type restrictions.

4. Add useful attachment details
Click Edit next to the uploaded file. On Edit Media, review:

Title: a useful name for finding the item in the library.
Alternative Text: a concise description of what the image communicates. Avoid repeating a list of keywords.
Image Caption: explanatory text that can be displayed with the image when the content layout uses a caption.
Description: optional additional attachment information.

We set a readable title, described the visible Site Health result in Alternative Text and added a short lab caption. Then we clicked Update.

wp-media-details-saved-20261012.jpg (Size: 201.13 KB / Downloads: 6)
Saved attachment details, file type, size, dimensions and File URL.

Alternative text should match the image’s purpose in its eventual context. The interface notes that purely decorative images can have empty alternative text. A filename alone is often a poor description.

Changing the media title does not automatically rename the uploaded file. Our filename remained unchanged after saving the title and caption.

5. Verify the actual file
Review File URL and open it in a browser tab. Our JPG loaded successfully over HTTPS at its WordPress uploads URL. The attachment reported 1912 × 893 pixels and 72 KB. These are our example’s values, not recommended dimensions for every image.

The file URL is different from an attachment-page permalink. The file URL points to the image itself; the attachment page may be a website page about that media item.

Do not upload confidential files on the assumption that a draft post makes them private. In our test, the direct media URL was accessible. Use a suitable private-storage method for material that should not be public.

6. Use the image in content
Uploading adds the image to Media Library; it does not automatically place it inside every page. In a WordPress page or post, add an Image block and choose the item from Media Library. Check its alternative text, displayed size and caption in that context, then preview the page.

This walkthrough verified the upload and attachment details. Inserting the image into a page and publishing that page are separate content-editing steps.

Troubleshooting

File too large: compare the file with the maximum shown, reduce its size where appropriate and confirm the PHP version/configuration serving the site before changing limits.
File type rejected: use a supported image format. Do not enable unrestricted uploads as a shortcut.
Upload succeeds but image does not load: inspect the exact file URL, permissions and server response. Check cache or mixed-content issues without disabling HTTPS protections.
A thumbnail looks different: WordPress may create smaller image sizes. Review the size selected in the content block and compare it with the original.

Verified result
Our image uploaded successfully, the title/alternative text/caption saved, and the direct HTTPS image loaded. No upload-limit setting, security restriction or server permission was changed. The demonstration file remains in the lab Media Library.

Screenshots and results are from our own AdminsForum test website.

Check WordPress Site Health on an aaPanel Website

Mon, 12 Oct 2026 13:36:11 +0800

How do you check WordPress Site Health on aaPanel?
Sign in to WordPress and choose Tools → Site Health. Wait for the checks to finish, open each finding to read its details, then use Info to inspect the site’s actual configuration. You do not need to install a separate health-check plugin to use this built-in screen.

We inspected our wp.adminslab.com test website, hosted through aaPanel 8.0.6 Free Edition. This guide shows actual findings from WordPress 7.1.3 on PHP 8.5.11. Your report can differ according to your server, plugins and recent activity.

1. Open Site Health and wait for the result
Use your normal WordPress administrator login. In the left menu choose Tools → Site Health. You can also reach the screen from a dashboard Site Health link if it is displayed.

The page initially showed Results are still loading in our session. Wait until checks finish before judging the report. Some tests depend on requests that take longer than the initial page load.

wp-site-health-status-20261012.jpg (Size: 148.76 KB / Downloads: 6)
Our finished Status screen: Good, with four recommended improvements.

2. Read the findings rather than just the summary label
Open the Status tab. Review any critical issues first, followed by recommended improvements. A Good label does not mean that every possible problem has been ruled out or that the website has passed a complete security audit.

Our report showed:

You should remove inactive plugins.
You should remove inactive themes.
One or more recommended modules are missing.
A scheduled event is late.

We had just completed plugin and theme demonstrations, so the inactive items were expected on this lab. For a real website, review which items are still needed, preserve any required parent/fallback theme and back up before removal. Do not delete components purely to change a score.

3. Expand a finding to see the specific cause
Click a recommendation’s heading. We opened One or more recommended modules are missing. It identified exif and imagick as optional modules that were absent or disabled.

wp-site-health-modules-20261012.jpg (Size: 181.19 KB / Downloads: 5)
The expanded finding identifies the exact optional PHP modules.

That message does not say PHP itself is missing. It concerns extensions available to the PHP environment running this website. Installing an extension for another PHP version will not necessarily resolve the warning.

If you plan to change extensions in aaPanel, first confirm the website’s PHP version, read the extension requirements and prepare for the relevant PHP service reload/restart. Verify the result through WordPress afterward. We did not install EXIF or Imagick during this diagnostic walkthrough.

4. Inspect the late scheduled-event warning separately
A late event deserves its own investigation. Expand the item and record the event name and any explanation shown. Check whether the warning persists and whether the affected application task is completing.

Do not immediately add a server cron job or disable WordPress’s scheduler simply because a warning appears. Review the existing scheduler configuration first so you avoid duplicate or conflicting jobs. This guide did not diagnose or fix the event on the lab and did not create a new cron task.

5. Use Info to check real configuration details
Choose Info at the top. It contains expandable sections such as WordPress, themes, plugins, Media Handling, Server, Database and Filesystem Permissions.

wp-site-health-info-20261012.jpg (Size: 149.33 KB / Downloads: 7)
The Info tab groups technical details into sections. Open only the section relevant to your question.

We opened Server and confirmed that the website was using PHP 8.5.11 with fpm-fcgi and nginx/1.30.5. These values come from WordPress’s runtime and are useful when aaPanel has several PHP versions installed.

The same section reported upload and memory limits. Read them before requesting a change: an administrator-screen memory allowance can differ from the general PHP memory limit. The Info page reports configuration; it does not apply new settings itself.

6. Gather a useful support question
For help, include the exact expanded error, WordPress version, the website’s PHP version, the affected component and what changed before the issue started. Add the relevant screenshot rather than an unexplained Good or Needs improvement label.

The Copy site info to clipboard control can collect a broader report, but review it before sharing. Configuration exports may contain server paths, database identifiers, usernames or details you do not need to publish. Share the smallest relevant excerpt and remove credentials, tokens and private information. We did not post a full configuration export.

For WordPress-specific questions, use WordPress Support. For an extension issue, PHP & Extensions Support is the more focused section.

7. Recheck after making a separate fix
Change one relevant item at a time, then return to Site Health and let the tests complete. Also test the actual feature that was failing. A warning disappearing does not replace a functional check of uploads, email, forms or scheduled tasks.

Keep a note of the before/after finding and the exact change. This makes later troubleshooting easier than applying several unrelated settings and losing track of which one helped.

What we verified
We opened Status, waited for completion, expanded the optional-module warning and inspected Info → Server. The lab reported Good with four recommendations. We did not remove plugins/themes, install optional modules or resolve the scheduled-event warning in this guide.

Source: WordPress Site Health documentation. Screenshots and runtime findings are from our AdminsForum lab.

Check WordPress Updates on an aaPanel Website

Mon, 12 Oct 2026 13:33:53 +0800

How do you check WordPress updates on an aaPanel website?
Sign in to WordPress and open Dashboard → Updates. Use Check again to refresh the status, then review WordPress core, plugins and themes separately. aaPanel’s WP Toolkit also shows the installed WordPress version, but the WordPress dashboard provides a useful check of the application’s own update status.

Our lab runs WordPress 7.1.3 on aaPanel 8.0.6 Free Edition with PHP 8.5. We checked both interfaces. Core, plugins and themes were already up to date, so this walkthrough verifies the checking process. It does not claim that an upgrade was performed.

1. Confirm the website in WP Toolkit
Open aaPanel → WP Toolkit and find the correct domain. Click the WordPress version in the Quick action area to open Wordpress Setting → Base setup.

Our Status message displayed WordPress 7.1.3 is already the latest version. Wait for the data to load: the fields can briefly show dashes while aaPanel retrieves the site information.

wp-updates-panel-status-20261012.jpg (Size: 196.96 KB / Downloads: 8)
The installed version and status reported by WP Toolkit. The new-password field is empty; checking updates does not require changing your password.

Do not click Generate or fill Reset password just to check a version. The Upgrade control relates to WordPress; aaPanel’s separate Upgrade now button relates to the hosting panel. PHP and the web server have their own updates too. These are different components and should not be changed together without a plan.

2. Open WordPress’s Updates screen
Sign in using your normal WordPress administrator login. If you followed our test-site setup, the dashboard is at your domain followed by /wp-admin/. Use the correct login path if you previously customized it.

In WordPress, choose Dashboard → Updates. Review Current version and the timestamp beside Last checked. Click Check again to request a fresh status check, then wait for the page to return.

wp-updates-dashboard-20261012.jpg (Size: 117.89 KB / Downloads: 7)
Our dashboard after checking: core, plugins and themes are all up to date.

3. Read each section separately

WordPress: shows the installed core version and whether a newer release is offered.
Plugins: shows plugin updates separately from the core.
Themes: shows theme updates separately from plugin updates.

In our session, all three sections reported current software. That is a valid result: no update action is necessary just to complete a tutorial.

The Re-install version button is not an upgrade to a newer version. It replaces core files with the same release and is not a routine step after every update check. We did not use it.

4. Prepare before applying an offered update
Before changing a live site, save a complete files-and-database backup and confirm a recovery plan. Follow our WP Toolkit backup guide. Keep a verified copy off the server and test recovery separately.

Record the current core, plugin, theme and PHP versions. Review the release notes and compatibility requirements for the specific changes. Test them on staging where practical and pick a quiet time for a live-site update.

On sites with orders, registrations or frequent content changes, coordinate the maintenance window so recovery from an older backup does not unexpectedly discard newer data. A successful archive creation alone is not proof of a successful restoration.

5. When an update is available
Use the action shown for the specific component on Dashboard → Updates. Follow its prompts and allow it to finish. Avoid starting several overlapping operations or repeatedly pressing an update button because progress is slow.

Afterward, confirm the reported version and check the public homepage, administrator login and important functionality. Test forms, checkout or member features if your site uses them. Clear relevant caches when needed and examine errors before treating the work as complete.

Our lab had no pending update, so these are preparation and verification instructions rather than a tested upgrade result. We did not downgrade the lab to manufacture an update scenario.

6. Review automatic updates without changing them accidentally
Read the policy displayed on the Updates page. Our site stated that it is kept current with each new WordPress version. The page offered a link to switch to maintenance/security releases only. We left the existing policy unchanged.

Core automatic updates and plugin/theme Auto update switches are separate preferences. Know which one you are changing, how backups will be retained and how failures will be noticed. A manual screenshot of today’s status does not prove future scheduled updates will run successfully.

Maintenance mode in Free Edition
Our aaPanel Maintenance Mode screen displayed This feature is only available for Pro. Do not assume the built-in panel maintenance page is available in Free Edition. We did not buy Pro or enable that feature. Plan an appropriate maintenance approach for your website before a change that could interrupt visitors.

Troubleshooting

Check again returns an error: record the message and inspect site/server connectivity and logs. Do not disable SSL verification as a shortcut.
The dashboard requests connection credentials: investigate the installation’s file ownership and update method before supplying credentials or changing permissions.
Update failed or site is unavailable: stop further changes, preserve the error and consult the official failed-update guidance. Recover using a known backup when appropriate.
Panel and dashboard disagree: refresh both, confirm they refer to the same installation and compare the actual version rather than a cached label.

Verified result
We refreshed the WordPress Updates page and confirmed core, plugins and themes were current. No upgrade, reinstallation, automatic-update preference change or maintenance-mode activation was performed.

References: WordPress update documentation and aaPanel WP Toolkit documentation. Screenshots are from our own AdminsForum lab.

Install and Change WordPress Themes in aaPanel WP Toolkit

Mon, 12 Oct 2026 13:32:03 +0800

How do you change a WordPress theme in aaPanel?
In WP Toolkit, click the WordPress version beside your domain, open the Theme tab, install the theme you want and turn on its Active switch. Then check the public website. Keep the previous theme installed so you can switch back if the new design is unsuitable.

We tested this on wp.adminslab.com with aaPanel 8.0.6 Free Edition, WordPress 7.1.3 and PHP 8.5. We installed Twenty Twenty-Two 2.2, activated it, checked its homepage and switched back to the original Twenty Twenty-Five 1.5 theme. Installation and switching worked without purchasing Pro.

Before starting

Make a fresh files-and-database backup. Follow our WP Toolkit backup guide and retain a verified copy outside the server.
Test on staging before changing a live business website. Theme changes can affect navigation, templates, typography, widgets and plugin integrations.
Record your current theme name. Keep it installed during the test.
Check the candidate theme’s official source, author, maintenance and compatibility. Avoid installing a theme merely because its preview looks attractive.

1. Open the Theme tab
Choose WP Toolkit in aaPanel. Find the correct website and click the WordPress version button in its Quick action area. In the Site modification window, choose Theme beside Base setup, Plugin and Utils.

  wp-theme-before-20261012.jpg (Size: 172.6 KB / Downloads: 7)
Our original theme list. Twenty Twenty-Five was active; other installed themes were inactive.

The table separates Active from Auto update. Active controls which theme supplies your website’s design. Auto update is a separate update preference. Installing a theme does not mean it becomes active.

2. Find and install a theme
Click Install in the Theme tab. Enter the theme’s name in the search field and press Enter. Our panel’s theme search field was labelled Please enter plugin name, even though the window was for themes. Check that you opened Theme before searching.

We searched for Twenty Twenty-Two and chose the result from the WordPress team. Review the Name, Author, WP and PHP columns; similar names can refer to different products. Requirements shown in the list do not prove compatibility with every plugin or customization on your website.

  wp-theme-search-20261012.jpg (Size: 161.75 KB / Downloads: 9)
The exact theme and author in our search result.

Click Install in the correct row once and wait for completion. Close the installation window, keeping the underlying theme manager open. Confirm that the theme appears in the installed list. In our test it appeared as Twenty Twenty-Two 2.2.

3. Activate the new theme
In the new theme’s row, turn on the Active switch. Wait for the operation to finish. Confirm that the new theme is active and the previous one is inactive. WordPress uses one active theme for the site.

  wp-theme-active-20261012.jpg (Size: 180.77 KB / Downloads: 7)
Twenty Twenty-Two is active after the switch; the other themes are inactive.

Do not switch off your only active theme first. Activate its replacement instead. The panel can display an “At least 1 theme is active” message if you attempt to disable the active theme without a replacement.

4. Check the actual website
Open the public HTTPS address and refresh the page. Check the homepage, a post, important pages, navigation, mobile layout, images and forms. A successful switch in the panel does not mean the new design meets your needs.

  wp-theme-homepage-20261012.jpg (Size: 88.06 KB / Downloads: 7)
Our lab homepage after activation. The design changed and the sample content still loaded over HTTPS.

For a block theme, further design work happens in WordPress’s Site Editor. Switching themes alone does not build menus, layouts or a complete business website. Theme-specific customizations may need adjustment.

5. Switch back to the previous theme
Return to the Theme tab and activate your previous theme using its Active switch. Wait, check the states and refresh the public website again.

During our test, we refreshed the panel and reopened the theme list before the return switch persisted. If a switch or warning looks inconsistent, reopen the list and verify the actual state instead of repeatedly clicking it. We confirmed Twenty Twenty-Five active again and the original Blog homepage restored. Twenty Twenty-Two remains installed but inactive.

Switching back is useful for a design test, but it is not a complete recovery method for every theme. A theme or associated plugin may change settings or data; a reliable backup is still necessary.

6. Understand update and removal controls
We left Auto update off during this demonstration and did not test an automatic update. Review your maintenance and monitoring plan before enabling it. The panel warns against enabling automatic theme/plugin updates while its maintenance mode is enabled.

Uninstall is different from switching themes. Review the consequences and take a backup before removing anything. Preserve an appropriate fallback theme, and avoid deleting a parent theme required by a child theme. We did not uninstall themes in this walkthrough.

Troubleshooting

Design looks unchanged: verify the Active state, refresh the public page and check whether browser/server caching is showing an older response.
Installation fails: read the error and check available disk space, source connectivity and permissions. Do not broadly weaken file permissions as a shortcut.
Layout or feature breaks: switch back to the previous theme, inspect logs and test the conflict on staging.
Search field says plugin: our tested theme dialog uses that placeholder. Confirm the Theme tab is selected; do not assume you are in the plugin manager.

Final check
You should know which theme is active, have tested the public website and have a clear way to return to the previous configuration. Our installation, activation, homepage check and switch-back were tested. Automatic updates, uninstalling and full backup restoration were not tested here.

Source: aaPanel WP Toolkit documentation. Screenshots and theme-switch results are from our own AdminsForum lab.

Install and Manage WordPress Plugins in aaPanel WP Toolkit

Mon, 12 Oct 2026 13:06:00 +0800

How do you install a WordPress plugin through aaPanel?
Open WP Toolkit, click the WordPress version beside your site, select Plugin, then click Install. Search for the exact plugin, check its author and requirements, and install it. Return to the list and enable its Active switch when you are ready to use it.

We tested installation, activation and deactivation on wp.adminslab.com using aaPanel 8.0.6 Free Edition, WordPress 7.1.3 and PHP 8.5. The example is Hello Dolly by Matt Mullenweg. It is a simple demonstration plugin, not a required component for hosting a website.

Before changing plugins

Confirm that you selected the correct website in WP Toolkit.
Take a fresh backup of files and the database. See Back Up WordPress with aaPanel WP Toolkit. Keep a verified off-server copy for recovery.
For a live website, test changes on staging first and choose a quiet maintenance period.
Check the plugin’s official listing, recent maintenance, WordPress/PHP compatibility and author. A similar name does not mean it is the same plugin.

1. Find the plugin manager
In aaPanel’s left menu choose WP Toolkit. Locate your domain. In the Quick action area, click its WordPress version button. Our button displayed 7.1.3; yours may show a different version.

The Site modification window opens with Wordpress Setting selected. Choose the Plugin tab alongside Base setup, Theme and Utils.

  wp-plugin-list-20261012.jpg (Size: 165.95 KB / Downloads: 6)
The Plugin tab before our installation. Existing plugins have separate Active and Auto update switches.

2. Understand the two switches
Active controls whether WordPress runs the plugin. An installed plugin can remain inactive.
Auto update controls automatic plugin updates. It is a separate setting: enabling it does not activate a plugin, and activating a plugin does not automatically enable it.

Do not turn on every switch together. Know which setting you are changing and verify it afterward. The panel also warns against enabling automatic plugin/theme updates while its maintenance mode is enabled.

3. Search for a plugin
Click Install. In Install Plugins, enter the plugin name in Please enter plugin name and press Enter. Wait for results to load; the table can briefly show placeholders.

For our demonstration, we searched for Hello Dolly and selected the row with Matt Mullenweg as author. Other similarly named plugins appeared, so we checked the author rather than choosing a random search result.

  wp-plugin-search-20261012.jpg (Size: 215.76 KB / Downloads: 6)
Search results include Name, Desc, Author, WP, PHP, Rating and an Install action. Verify the exact row before proceeding.

The WP and PHP columns are useful requirements information, but do not assume they mean the plugin was tested on your exact installed versions. Review the official WordPress.org listing too. A blank value or dash is not a compatibility guarantee.

4. Install and confirm the result
Click Install in the chosen plugin’s row once. Wait while the panel displays Installing, please wait. Our operation then reported Installation Success.

Close the Install Plugins window using its top-right close control. Keep the underlying Site modification window open. The new plugin should now appear in the Plugin list.

  wp-plugin-installed-20261012.jpg (Size: 168.96 KB / Downloads: 7)
Hello Dolly 1.7.2 appears in the installed list. Both switches were initially off in our test.

Installation and activation are different steps. In our lab, the plugin was installed but inactive. Do not assume that a success message means its functionality is already running.

5. Activate the plugin
Find the newly installed plugin’s row. Turn on the switch in the Active column. Wait for the operation to finish and confirm the switch stays on.

  wp-plugin-active-20261012.jpg (Size: 168.48 KB / Downloads: 6)
Our activation test: Active is on while Auto update remains off.

Now open your website and its WordPress dashboard. Test the feature you installed and the pages it might affect. For example, a form plugin needs a form submission test; a caching plugin needs a check of pages and logged-in behavior. Our homepage remained accessible after Hello Dolly activation. That basic check does not establish compatibility for every plugin or feature.

Some plugins need additional configuration, an API key or an account inside WordPress. Activation alone does not complete those separate setup steps.

6. Deactivate without uninstalling
To stop a plugin, turn off its Active switch and confirm it stays off. We tested this and left Hello Dolly installed but inactive on the lab site. Its Auto update switch was left off throughout.

Deactivation is different from Uninstall. Uninstall can remove files and, depending on the plugin, stored settings or data. Back up and review the plugin’s removal behavior before using it. We did not test uninstalling or automatic updates in this walkthrough.

If something goes wrong

Search results stay blank: wait for loading to finish, check the panel session and retry a precise name. Investigate server access to the plugin source if searches consistently fail.
Installation fails: read the error, check disk space and file permissions, and verify that PHP can access the required resources. Avoid changing ownership broadly without understanding the error.
Activation breaks a feature: switch that plugin off, check the website again and inspect the relevant WordPress/PHP logs. Do not update several unrelated plugins while isolating the problem.
An edition upgrade prompt appears: use normal WordPress dashboard access where appropriate. Our Plugin install and Active switches worked in Free Edition; password-free Login was separately Pro-gated in the earlier installation test.

Finished checklist

Correct website and exact plugin author checked.
Backup prepared before changes.
Installation success confirmed by the plugin appearing in the list.
Active state checked separately from Auto update.
Website and affected functionality tested.
Unneeded demonstration plugin left inactive.

References: aaPanel WP Toolkit documentation and Hello Dolly on WordPress.org. Screenshots and installation/activation results are from our AdminsForum lab.

Back Up WordPress with aaPanel WP Toolkit

Mon, 12 Oct 2026 12:36:45 +0800

How do you back up WordPress in aaPanel WP Toolkit?
Open WP Toolkit, select the website’s Backup link, confirm Full Backup and the storage destination, then click Backup. Wait for a successful result and verify that an archive appears before making website changes.

This walkthrough uses our HTTPS test site, wp.adminslab.com, on aaPanel 8.0.6 Free Edition. We created a real backup and checked its archive on the server. A successful backup job is not the same as a tested restoration.

Before you begin

Your WordPress site must already appear in WP Toolkit. If it does not, follow Install WordPress with aaPanel WP Toolkit first.
Have enough free disk space for the backup. Large uploads folders can make archives much larger than our example.
Avoid updating plugins, importing content or accepting important changes while the backup is running. A quiet period makes the files and database easier to keep consistent.
Check which site you selected. Our lab has other websites, so we verified the domain before starting.

1. Open the website’s backup window
Sign in to aaPanel and choose WP Toolkit in the left menu. Find the correct WordPress domain. Click the Backup link or backup count in its row. A site without a previous backup may show 0 Backup.

The window contains Backup / Restore and Schedule & Remote Storage. For this guide, stay on Backup / Restore. This is a manual backup; it does not require creating a recurring task.

wp-toolkit-backup-before-20261012.jpg (Size: 173.43 KB / Downloads: 8)
The backup window before our first backup. Check the selected backup type and destination before clicking Backup.

2. Check the backup type and destination
Our window displayed Full Backup to Local Server. If yours is different, use click here to configure and inspect the available choices before starting. Do not assume that a files-only or database-only backup can recover the whole website.

Local Server means the copy remains on the same VPS. It is useful before a plugin update, but it will not protect you if the VPS and its disk are lost. Keep an additional copy outside that server.

The panel also states Subsites not included. If you run WordPress Multisite, do not treat this walkthrough as a complete multisite recovery procedure. Verify the coverage and use a backup method appropriate to your network.

3. Run the backup and wait for completion
Click Backup once. Leave the operation running until aaPanel reports the result. A large site can take longer than this small installation. Do not repeatedly click Backup because the first job is still working.

Our result was 1 success, 0 failed. The table then showed a 35.28 MB archive, marked Full Backup with Local Server storage. Your filename, timestamp and size will differ.

wp-toolkit-backup-success-20261012.jpg (Size: 162.58 KB / Downloads: 7)
Our completed backup. The successful task result and archive row are both visible.

4. Verify the backup before relying on it
Check that the table contains a new archive with the expected time, a non-zero size and the intended storage location. A missing or unexpectedly small archive needs investigation.

We also inspected the server archive in /www/backup/wordpress/. Its ZIP integrity check passed. It contained meta.json, database.sql.gz and files.zip. The nested website archive contained wp-config.php. These checks confirm that our job produced an archive with database and website-file components; they do not prove that a restoration will succeed.

For administrators comfortable with the terminal, a read-only ZIP check is:

Code:

unzip -t /www/backup/wordpress/YOUR-BACKUP-FILENAME.zip

Replace the filename with your actual archive. Do not paste a guessed filename or publish the contents of wp-config.php: it contains database credentials.

5. Keep a copy outside the VPS
The archive row includes Download. Download it to a trusted device, confirm the file arrived and keep it in private backup storage. Check the downloaded copy’s integrity too. A backup can include credentials, private uploads and user data, so do not place it in a public website folder or attach it to a support thread.

Test limitation: our browser download did not complete during this session. The server archive and its integrity were verified, but a downloaded copy was not. Do not count an attempted download as an off-server backup.

The Schedule & Remote Storage tab is a separate workflow. Before depending on a remote destination, confirm its availability in your edition, credentials, retained copies and recovery access. This guide did not configure remote storage or a schedule.

6. Understand Restore before clicking it
The archive row also has Restore. Restoration can replace current website files and database content with an older state. That can remove changes made since the backup, including posts, orders or user registrations.

Before restoring:

Make a fresh backup of the current state and keep it outside the server.
Confirm the domain and exact archive date.
Use a staging site or maintenance window where possible.
Read the restore confirmation carefully and verify which data it will replace.

After a restore, check the homepage, WordPress login, important pages, media, forms, plugins and HTTPS. This walkthrough did not perform a restore; a dedicated recovery test is still needed before claiming the backup is recovery-tested.

Troubleshooting
Backup fails: read the task result, check disk space and inspect the relevant panel logs. Fix the reported cause before retrying.
Archive is missing: confirm the storage destination and refresh the backup list after the job finishes. Do not assume an older file is the new backup.
Download fails: check your panel session and browser downloads. Keep the server archive intact while resolving access; do not delete it just because downloading failed.
The website changed after the backup: take another copy before maintenance. An older archive cannot contain newer changes.

Final checklist

Correct WordPress domain selected.
Backup type and destination reviewed.
Task completed successfully and archive exists.
Archive integrity checked.
Private off-server copy obtained and verified before relying on it for server-loss recovery.
Restoration tested separately before calling the backup recovery-tested.

Source: aaPanel WP Toolkit documentation. Screenshots and the backup result are from our own AdminsForum lab.

Install WordPress with aaPanel WP Toolkit (Free Edition)

Mon, 12 Oct 2026 11:40:47 +0800

Quick answer
Point your domain's A record to the VPS, open WP Toolkit → Add Wordpress, enter the domain, website title and administrator email, choose PHP and WordPress versions, and confirm installation. Check HTTPS and log in at /wp-admin. On our Free Edition lab, password-free login opened a Pro upgrade prompt; normal WordPress login worked.

Tested result
We created a separate website at wp.adminslab.com using aaPanel 8.0.6 Free Edition, Nginx, PHP 8.5 and WordPress 7.1.3. The homepage loaded over HTTPS, HTTP redirected to HTTPS, and normal login reached the authenticated WordPress dashboard. The existing manually installed WordPress site was kept separate.

Before starting

A working aaPanel installation with a web server, compatible PHP and MySQL/MariaDB.
A domain or subdomain you control, pointing to the VPS.
Access to DNS settings and aaPanel. Sign in to your aaPanel vendor account if the Toolkit requires it.
An administrator email address you can use for the website.
A fresh site location. Do not reuse an existing website directory without a verified backup and migration plan.

This guide creates a new WordPress website. For an existing site, use an appropriate import or migration workflow instead of creating over it.

1. Add the domain's DNS record
We used a separate subdomain so the demonstration did not replace our existing site. In Cloudflare → DNS → Records, we added an A record with name wp and the lab VPS address, using DNS only for the initial setup. Use your own server address, not the lab address.

Wait for the domain to resolve to the intended server before applying for SSL. Avoid adding an unrelated AAAA record pointing elsewhere. If you use Cloudflare proxying, review certificate validation and your SSL mode deliberately rather than assuming a certificate is already installed at the origin.

For the DNS setup workflow, see the Cloudflare guides in the Cloudflare section.

2. Open WP Toolkit
In aaPanel's left menu, click WP Toolkit. Use Local Manage for a site hosted on this server, then click Add Wordpress. Select Create site in the dialog.

3. Fill the new-site form

Domain: enter the website hostname, such as wp.yourdomain.com.
Apply for SSL: keep this checked when DNS and validation access are ready.
Website Title: the public WordPress site title; ours was AdminsForum WordPress Lab.
Email: the website administrator email.
PHP version: choose an installed version compatible with WordPress and the plugins you intend to use.
WP version: review the version offered rather than assuming every server shows the same number.
Language: choose the installation language.

  wp-toolkit-create-form-20261012.jpg (Size: 179.49 KB / Downloads: 9)
AdminsForum lab: the new-site form. The private credential fields are not shown.

Our lab selected PHP 8.5 and WordPress 7.1.3. These are the versions actually used for this test, not a promise that future Toolkit releases show the same choices.

4. Review More settings and keep credentials private
Expand More settings when you need to inspect the administrator account, database options, table prefix, cache or subdirectory. WP Toolkit generated strong initial credentials in our test; we retained them instead of enabling weak passwords.

Record the generated username and password privately. The completed installation can show them in its result dialog. Do not include that dialog, database passwords or login tokens in tutorial screenshots. Use a password manager or another secure record for your real site.

We left the subdirectory field empty because this was a separate hostname. Installing into a subdirectory changes the expected website and login URLs. Review the cache option too, especially before later adding an application-level cache plugin.

5. Confirm and wait for completion
Click Confirm once. Wait for website creation and initialization; avoid repeating the action while it is working. The site appeared in Local Manage, and its SSL column progressed from initialization to a certificate lifetime indicator.

  wp-toolkit-installed-20261012.jpg (Size: 157.77 KB / Downloads: 11)
AdminsForum lab: the installed website in WP Toolkit, with WordPress/PHP versions and SSL status.

If creation fails, investigate the site's Log and panel run logs before retrying. Check for an existing domain/directory, missing runtime, database connection error or certificate-validation failure. Do not delete an existing website merely to dismiss an installation error.

6. Verify the public website and HTTPS
Open the site in a browser. Confirm the title and expected WordPress homepage. Check the HTTPS address loads without a certificate warning. In our test, opening HTTP redirected to HTTPS and displayed the new site.

  wp-toolkit-homepage-20261012.jpg (Size: 82.16 KB / Downloads: 10)
AdminsForum lab: the new WordPress homepage served over HTTPS.

If WordPress loads but SSL did not finish, inspect the SSL status separately. Check DNS, validation accessibility and the certificate's domain. Do not work around a browser certificate warning and call that a successful SSL test.

7. Log in normally on Free Edition
Open your site's /wp-admin address. Enter the generated WordPress username and password and click Log In. Our normal login reached the WordPress dashboard.

  wp-toolkit-dashboard-20261012.jpg (Size: 214.37 KB / Downloads: 11)
AdminsForum lab: authenticated WordPress dashboard after a successful normal login.

WP Toolkit's Login menu offered both Password-free login and Login. On this Free Edition lab, Password-free login opened a Pro upgrade prompt. We did not purchase an upgrade or claim that feature worked. Normal WordPress login was sufficient to complete the test.

8. Check the first settings and make a backup
Review Settings → General for the title and administrator email. Review Permalinks, update availability and Site Health. Treat any update or plugin installation as a separate operation to check and back up beforehand.

Before building the site further, make a backup and verify what it contains. A WordPress recovery plan needs both website files and the database. See the website backup schedule guide and database backup schedule guide. WP Toolkit's own backup workflow will be covered separately.

Common problems

Domain cannot be validated: confirm the DNS record and the actual origin serving the hostname.
PHP choice missing: install a supported runtime first and re-open the form.
Initialization remains incomplete: read the site and panel logs; do not repeatedly create duplicate sites.
Password-free login asks for Pro: use normal WordPress login on Free Edition.
A 502 error: check the assigned PHP runtime, its service status and the web-server/PHP connection.
Login fails: verify the hostname and saved WordPress credentials. The aaPanel panel password is not the WordPress account password.

Completion checklist

Domain resolves to the correct VPS.
New site appears in WP Toolkit.
Expected WordPress and PHP versions selected.
Homepage loads and HTTPS is valid.
Normal WordPress login reaches the dashboard.
Private credentials kept out of public screenshots.
Files/database backup and update plan prepared.

Reference: aaPanel official WP Toolkit Local Manage documentation.

Fix WordPress Permalink 404s in aaPanel Free Edition (Nginx)

Sun, 11 Oct 2026 13:28:42 +0800

Quick answer
If WordPress pages work with ?p=123 but pretty post URLs return 404 on aaPanel with Nginx, check both WordPress Settings → Permalinks and the site's Nginx rewrite configuration. Saving WordPress permalinks does not make Nginx read .htaccess.

Before changing rules
Back up the current rewrite configuration and record the current WordPress permalink setting. Confirm the site's web server is Nginx and whether WordPress is installed at the domain root or inside a folder. This guide is for a single WordPress installation, not Multisite.

1. Choose the WordPress URL format
Log in to WordPress, open Settings → Permalinks, choose Post name if that is the structure you want, and click Save Changes. On our fresh lab site the structure changed from plain query URLs to /%postname%/.

AdminsForum WordPress lab: Post name selected in Permalink Settings.

For an established site, changing public URL structure needs a redirect plan for existing links. This example uses a new disposable lab site.

2. Open the aaPanel rewrite configuration
Open Website → the intended site's settings → URL rewrite. Read and back up the existing rules before editing. Preserve unrelated HTTPS redirects and other application rules. Do not create duplicate location blocks.

Nginx needs a fallback to WordPress index.php for URLs that are not physical files. The official WordPress Nginx documentation describes this approach.

3. Use the rule matching the installation folder
Our lab has WordPress in /wordpress/, while the domain root contains other tutorial examples. We added this site-specific block to its rewrite configuration:

Code:

# AdminsForum WordPress subfolder tutorial
location /wordpress/ {
    try_files $uri $uri/ /wordpress/index.php?$args;
}

This checks for an existing file or directory first, then sends other requests in that folder to WordPress. Query parameters are retained. The site's existing aaPanel PHP handler remains responsible for executing PHP.

If WordPress is installed at the domain root instead, the usual fallback is:

Code:

location / {
    try_files $uri $uri/ /index.php?$args;
}

Choose the correct block, not both indiscriminately. The root example assumes the root is actually your WordPress installation. If a matching location already exists, update that block rather than adding a duplicate. Custom proxies, caching, Multisite or other applications need configuration suited to their setup.

4. Save and validate
Save the aaPanel rewrite configuration and confirm there is no configuration error. An operator with SSH can also run the aaPanel Nginx binary's configuration test:

Code:

/www/server/nginx/sbin/nginx -t

Only reload a valid configuration. If validation fails, restore your saved rules and investigate the exact error. Our lab configuration passed before reload.

5. Test an actual post URL
Open a published post using its new URL, not only the homepage. Our lab test was /wordpress/hello-world/. It returned HTTP 200 and the expected post title after the change.

Also check a page, the WordPress homepage, existing static files and any other applications sharing the domain. Our domain homepage and File Manager demo continued returning HTTP 200.

Rollback
Restore the previous rewrite configuration if the new rules cause problems. If you changed WordPress's permalink structure, restore the recorded previous setting as appropriate. Preserve the existing PHP and HTTPS configuration rather than replacing the whole virtual host.

Common problems

Duplicate location error: edit the existing matching location instead of adding another.
Homepage works but posts 404: verify the fallback path and installation folder.
Other applications stop working: a root-level catch-all may be routing their requests to WordPress. Use a correctly scoped block.
PHP source is exposed: stop and repair the site's PHP handler before proceeding; a rewrite rule alone is not PHP configuration.
Redirect loops: review HTTPS/proxy and WordPress home/siteurl settings separately.

Verified on 11 October 2026
We backed up our lab's existing rewrite configuration, added a /wordpress/ fallback, passed the Nginx configuration test, selected Post name through the WordPress dashboard and tested the published post URL. WordPress 7.1.3 ran on PHP 8.5.11 with aaPanel Free Edition 8.0.6. The domain homepage and original static demo remained available.

Related guide: Install WordPress manually in aaPanel Free Edition

wordpress-permalinks-20261011.jpg (Size: 105.59 KB / Downloads: 9)

Install WordPress Manually in aaPanel Free Edition

Sun, 11 Oct 2026 13:26:30 +0800

Quick answer
To install WordPress manually on aaPanel Free Edition, prepare a working PHP website with HTTPS, create a dedicated database/user, place the official WordPress files in the intended website folder, supply the database configuration, and complete installation. Verify both the site and login page.

Requirements

A domain already pointing to the VPS and a working HTTPS website in aaPanel.
A compatible PHP version with the extensions your application requires.
MySQL or MariaDB and a dedicated database user. Our lab uses MariaDB 10.11.
A backup if you are using a folder or database that already contains anything important.

Check the current WordPress requirements and PHP compatibility table. Theme and plugin compatibility must be checked separately from WordPress core.

1. Decide where WordPress should live
For a fresh website homepage, place the WordPress package contents in that site's document root. For a separate installation under /wordpress/, keep the package in that subfolder. Do not accidentally create an extra nested wordpress/wordpress folder.

Our dedicated lab uses https://adminslab.com/wordpress/ so the original homepage and other tutorial examples remain available. This is an example URL, not the location you should enter for your own site.

2. Create a dedicated database
Use Databases → MySQL → Add DB in aaPanel, or the equivalent panel-managed database operation. Record the database name, username, password and host privately. Use a user scoped to the application database; do not put the MariaDB root password into WordPress.

See Create a database and user in aaPanel Free Edition. A database on the same VPS does not require exposing port 3306 publicly.

3. Download the official package
Get the package from WordPress.org. Extract the ZIP on your computer and upload its contents to the chosen folder using File Manager or a secure transfer method. Confirm files such as index.php, wp-admin and wp-includes are in the intended location.

Our lab used the official ZIP package in private server staging. We checked the extracted WordPress core files against official checksums before making the completed installation available.

4. Configure the database and install
For the browser method described in the official installation guide, open the installation URL for the chosen folder. Supply the database details privately when prompted, then set your site title, administrator account and email. Use a strong unique administrator password and save it securely. Avoid screenshots containing passwords or configuration secrets.

If WordPress cannot create wp-config.php, configure that file securely using the official instructions. Never make it world-writable as a general workaround.

How our lab completed this step
We completed configuration and database installation with WP-CLI from the server, rather than entering a new administrator credential into the browser installer. This guide does not claim that the browser installation form was tested end to end.

An operator using WP-CLI should use the intended site's path and explicit URL, provide credentials privately, and check siteurl/home after moving a staged installation. We set both to the final HTTPS /wordpress address. Credentials are kept out of the public guide.

5. Check the installed site
Open the site's HTTPS URL and the wp-login.php page in its installation folder. Check that internal links point to the correct hostname and folder, and that styles and images load.

Original AdminsForum WordPress Tutorial Lab after installation on aaPanel Free Edition.

For your own site, log in and check the dashboard, save a draft, upload a small test image and verify the functions you need. A homepage response alone is not a full application acceptance test. Confirm outgoing email separately before relying on password-reset or notification messages.

6. Choose permalink rules separately
The lab initially uses plain query-string permalinks. If you enable pretty permalinks, configure the matching WordPress rewrite rules for your web server and installation folder, then test a post URL. Nginx does not apply Apache .htaccess rules. Do not paste a root-directory rewrite into a subfolder installation without adapting it.

7. Basic checks after installation

Keep WordPress, themes and plugins updated after compatibility checks and backups.
Remove unused plugins/themes and use only trusted sources.
Take both file and database backups and test recovery.
For a tutorial/staging site, discourage search indexing and use stronger access restrictions if it contains private data. A search-indexing preference is not access control.
Verify email delivery separately; it was not configured or tested in our lab.

Common problems

Error establishing a database connection: check database name, user, password, host and the database service.
Blank page or fatal error: inspect PHP logs and extension/application compatibility.
Wrong links after moving files: check WordPress Address/siteurl and Site Address/home.
Pretty permalinks return 404: verify the correct web-server rewrite rules for the actual installation folder.
Uploads fail: check ownership, permissions, PHP upload limits and free space without using 777 as a blanket fix.

Verified on 10 October 2026
Our lab installed WordPress 7.1.3 from the official ZIP, verified core checksums, configured a dedicated local database and completed installation with WP-CLI. The website runs on aaPanel Free Edition 8.0.6 with PHP 8.5.11 and MariaDB 10.11. The final HTTPS homepage and login page both returned HTTP 200, and homepage links used the correct /wordpress address. On 11 October 2026 we also verified administrator browser login and uploaded an original test image through the WordPress media uploader. Mail delivery and pretty permalinks remain separate checks.

Related guides
Upload website files with aaPanel File Manager
Back up website files
Back up the database

wordpress-lab-live-20261010.jpg (Size: 48.24 KB / Downloads: 8)