Diagnosing a Stuck AccelerateWP Installation in WP Squared

An AccelerateWP installation in WP Squared can fail without presenting a useful message in the browser. The operator clicks Install, the interface remains in place, and repeated server reinstallation does not change the outcome. In one such case, /var/log/clwpos/main.log contained the real failure:

Failed to enable feature "accelerate_wp" for website "".
...
enabled_status = enable_result['feature']['enabled']
KeyError: 'feature'

Those lines provide two strong observations. The operation reached the CloudLinux WP Optimization service, but the logged website identifier was empty. The caller then received a structure without the feature key it expected and failed while processing that response.

They do not prove why the identifier was empty or what the upstream response contained. Treat this as an integration failure to investigate, not permission to patch vendor Python code or repeatedly rebuild the server.

Preserve the Failure Before Changing Anything

Capture a short diagnostic bundle immediately after reproducing the problem once:

date -Is
tail -n 200 /var/log/clwpos/main.log
rpm -qa | grep -Ei 'accelerate|clwpos|cloudlinux|lve-utils' | sort
cloudlinux-awp-admin --help
cloudlinux-awp-admin --api-version 1 get-stat

If a particular hosting account or site is involved, CloudLinux also documents a per-user log at ~/.clwpos/main.log for installation problems. Collect only the relevant window and remove domain names, usernames, IP addresses, tokens, and license identifiers before sharing logs publicly.

Record the following outside the log:

  • WP Squared version and operating-system build.
  • CloudLinux license edition and whether it is active.
  • Exact time of the click, including time zone.
  • Whether a WordPress site already exists in the panel.
  • The selected domain and document root, if the UI displayed them.
  • Whether the failure occurs for one site or before any site can be selected.

The empty website "" value makes the last two points especially important.

Separate Suite Availability from Site Activation

CloudLinux’s current AccelerateWP administrator documentation distinguishes between making a suite available and activating its features on compatible WordPress sites.

First inspect availability:

cloudlinux-awp-admin --api-version 1 get-stat

If the installed product and license support AccelerateWP, the documented administrator command for enabling the free suite is:

cloudlinux-awp-admin --api-version 1 \
  set-suite --suites=accelerate_wp --allowed-for-all

This changes entitlement for users. It does not prove that the blank-site WP Squared workflow is fixed, and it should not be used as a substitute for identifying the broken mapping.

CloudLinux also documents a server-wide scan-and-activate workflow:

cloudlinux-awp-admin --api-version 1 enable-feature --all
cloudlinux-awp-admin --api-version 1 enable-feature --status

Do not start there on a production host. The command can touch every compatible WordPress installation. Use it only after reviewing the installed CLI help, confirming the documented API version, taking a configuration backup, and accepting the site-wide scope.

Check Whether the Target Site Is Eligible

Eligibility errors should normally be reported cleanly rather than raising a Python KeyError, but they still belong in the evidence package. The current CloudLinux documentation lists these baseline requirements for the AccelerateWP suite:

  • Apache or LiteSpeed web server.
  • A supported CloudLinux OS license edition.
  • PHP 7.3 or later.
  • WordPress 5.8 or later.
  • No competing page-cache plugin.
  • No WordPress Multisite installation.

Feature-specific requirements can be stricter. Object caching, for example, also depends on its PHP extensions and cache configuration. Compare requirements with the actual site rather than the system-wide php -v, because a control panel can assign a different PHP version and handler to each domain.

CloudLinux’s end-user documentation says that when an installation problem persists, the host should attach the relevant .clwpos/main.log to a support case. That is the appropriate route when the panel supplies no human-readable incompatibility message.

What the Traceback Does and Does Not Say

The traceback is useful because it identifies the boundary where the failure became visible:

enable_result['feature']['enabled']

The code assumed that enable_result contained a feature object. Because the key was absent, the exception was raised. Plausible upstream conditions include an error object, a changed response schema, or a request that could not be associated with a site. Without the preceding request/response or vendor diagnostics, choosing among them would be speculation.

Do not:

  • Add a fake feature key to the installed vendor code.
  • Hard-code a website inside wpos_admin.py.
  • suppress the exception and assume the feature was enabled.
  • reinstall the entire server again before collecting a reproducible trace.
  • enable premium suites without checking billing and entitlement effects.

A local patch may disappear during an update and can hide the actual state from the control panel.

A Controlled Reproduction

Use the smallest possible test:

  1. Confirm that the license is active and the AccelerateWP suite appears in get-stat.
  2. Create or select one ordinary, supported WordPress site.
  3. Confirm the domain, document root, PHP version, handler, WordPress version, and cache-plugin state.
  4. Follow the WP Squared Install action once.
  5. Capture the log window with timestamps.
  6. Confirm whether the log still records website "".
  7. Stop before a global activation or another server reinstall.

If the site works through the documented AccelerateWP CLI but fails only through WP Squared, report that exact difference. If both fail, include both outputs. Do not include application passwords, license keys, or the complete contents of unrelated logs.

A Concise Support Ticket

The support ticket should lead with observed behavior and attach the evidence, without presenting an unproven diagnosis:

Subject: WP Squared AccelerateWP installation remains stuck

Hello CloudLinux Support,

I purchased a license and installed WP Squared, but I cannot install
AccelerateWP. When I click Install, the interface remains stuck and no
useful error is displayed.

I reproduced the issue after a clean installation. At the same time,
/var/log/clwpos/main.log records:

Failed to enable feature "accelerate_wp" for website "".
KeyError: 'feature'

I have attached a sanitized log excerpt, package versions, license edition,
and the exact reproduction time. Please confirm whether this is a WP Squared
site-mapping/API issue and advise the supported repair procedure.

Thank you.

Add the product versions and environment details as attachments or a short appendix. The concise body makes the failure easy to route; the diagnostics make it possible to reproduce.

Recovery and Verification

After a vendor repair or package update, verify more than the disappearance of the spinner:

  • The target WordPress site is named correctly in the log.
  • The installation command returns a documented success response.
  • The plugin is installed and active only on the intended site.
  • The site remains reachable while logged out.
  • No existing cache plugin was silently left active.
  • Page caching and optional features report a healthy state.
  • A second click does not create a duplicate or restart a failed job.

Keep the original trace and the fixed package versions with the change record. That history is far more useful than another clean reinstall if the integration regresses.

Conclusion

The decisive evidence in this incident was not the unresponsive Install button. It was the combination of an empty website identifier and an unhandled missing feature key in clwpos. That narrows the problem to the WP Squared–AccelerateWP integration path while leaving the root cause open for the vendor to confirm.

Collect the small, relevant log window; verify suite availability and site eligibility; reproduce against one site; and escalate with a concise ticket. This preserves the server, avoids unsupported code patches, and gives CloudLinux Support the information needed to fix the actual boundary failure.

© Copyright 2026, All Rights Reserved