Hello,

I am experiencing a CWP admin interface issue on multiple servers, and I would like to know whether anyone has already found a fix or workaround.

The problem occurs both:

• on a fresh CWP installation; and

• after upgrading working CWP 0.9.x installations to CWP Pro 1.2, 1.3 or 1.4.

The affected systems run AlmaLinux 9.x latest

Several essential CWP functions no longer complete their AJAX operations. For example:

• PHP installation;

• DNF update;

• ModSecurity installation;

• some dashboard and main-page lists.

The loading icon keeps spinning, while the browser console reports the following errors:

GET https://hostname:2031/<CWP_ADMIN_SECURE_PATH>/admin/design/charts/sparklines/jquery.sparkline.js
net::ERR_ABORTED 404 (Not Found)

blank.js:13 Uncaught TypeError: $(...).sparkline is not a function
    at blank.js:13:13

Another error is also displayed on some affected pages:

Uncaught TypeError: Cannot read properties of undefined (reading 'ext')

The first error appears to be the primary problem: CWP’s own admin interface requests:

/admin/design/charts/sparklines/jquery.sparkline.js

but the file is not available at that location. Consequently, the sparkline() function is undefined, and CWP’s blank.js fails.

CWP support has already corrected part of the underlying installation problem, but these frontend errors remain and prevent several admin functions from working properly.

I have also noticed that CWP’s directories contain a node_modules directory. This raises another possibility: perhaps the affected CWP release requires an internal frontend asset build or deployment step that was not executed, failed silently, or was omitted from the installation/update process.

There may be a CWP-specific build command, deployment script or package-maintenance command responsible for copying the JavaScript dependencies into the public admin asset directory.

Has anyone encountered and resolved this in CWP Pro 1.3 or 1.4?

In particular, I would appreciate information about:

1. Where jquery.sparkline.js is supposed to be installed in the current CWP version.

2. Whether the CWP packages or node_modules contain the file under another path.

3. Whether there is an official CWP asset build, deployment or repair command that restores the missing frontend files.

4. Whether the installer or updater normally runs an npm, Webpack, Gulp, Vite or other asset-processing step.

5. Whether a package reinstall can safely restore the missing assets.

6. Whether copying or symlinking the file from its actual location is a safe temporary workaround.

7. Whether additional JavaScript dependencies are missing, which might explain the reading 'ext' error.

If someone has a working CWP Pro 1.4 installation, it would also be helpful to compare:

• the relevant package.json scripts;

• the location of jquery.sparkline.js;

• the contents and permissions of the public sparklines asset directory;

• any CWP installer or updater logs related to frontend asset deployment.

The relevant public directory may be similar to:

/usr/local/cwpsrv/htdocs/resources/admin/design/charts/sparklines/

or another corresponding directory used by the current release.

For safety, I do not want to run npm install, npm update or an unknown build command inside CWP’s production directories without first identifying the official CWP procedure. Such a command could change dependency versions or overwrite vendor-managed assets.

Any confirmed workaround, official command, package name, file location or diagnostic result would be very useful. I can also forward the technical findings to @Sandeep B. . at CWP support to assist with the permanent correction.

Thank you.

Temporary workaround for the missing Sparkline asset in CWP Pro 1.4

The issue is caused by an incorrect asset path generated by the CWP admin interface.

CWP requests:

/admin/design/charts/sparklines/jquery.sparkline.js

but the file is actually installed at:

/admin/design/plugins/charts/sparklines/jquery.sparkline.js

Creating a symlink from the requested location to the existing CWP file restored most of the affected admin functions, including:

• ModSecurity installation;

• PHP-FPM configuration;

• starting the PHP compiler;

• several AJAX-based administration functions.

The CWP admin directories may have the immutable filesystem attribute enabled. Therefore, running mkdir directly may fail with:

Operation not permitted

The following temporary workaround worked on the affected servers.

Run these commands as root.

1. Confirm the immutable attribute

lsattr -d \
  /usr/local/cwpsrv/htdocs/admin \
  /usr/local/cwpsrv/htdocs/admin/design

The result may look like:

----i---------e------- /usr/local/cwpsrv/htdocs/admin
----i---------e------- /usr/local/cwpsrv/htdocs/admin/design

The i flag means that the directory is immutable.

2. Temporarily remove the immutable flag from the design directory

Only the design directory needs to be changed:

chattr -i /usr/local/cwpsrv/htdocs/admin/design

There is no need to remove the immutable flag from the parent admin directory.

3. Create the missing directory structure

mkdir -p \
  /usr/local/cwpsrv/htdocs/admin/design/charts/sparklines

Set appropriate ownership and permissions:

chown root:root \
  /usr/local/cwpsrv/htdocs/admin/design/charts \
  /usr/local/cwpsrv/htdocs/admin/design/charts/sparklines

chmod 750 \
  /usr/local/cwpsrv/htdocs/admin/design/charts \
  /usr/local/cwpsrv/htdocs/admin/design/charts/sparklines

4. Create the symlink

ln -s \
  /usr/local/cwpsrv/htdocs/admin/design/plugins/charts/sparklines/jquery.sparkline.js \
  /usr/local/cwpsrv/htdocs/admin/design/charts/sparklines/jquery.sparkline.js

Verify the target:

readlink -f \
  /usr/local/cwpsrv/htdocs/admin/design/charts/sparklines/jquery.sparkline.js

The expected result is:

/usr/local/cwpsrv/htdocs/admin/design/plugins/charts/sparklines/jquery.sparkline.js

5. Restore the filesystem protection

Protect the newly created directories:

chattr +i \
  /usr/local/cwpsrv/htdocs/admin/design/charts/sparklines \
  /usr/local/cwpsrv/htdocs/admin/design/charts

Restore the immutable flag on the original design directory:

chattr +i /usr/local/cwpsrv/htdocs/admin/design

6. Verify the final state

lsattr -d \
  /usr/local/cwpsrv/htdocs/admin/design \
  /usr/local/cwpsrv/htdocs/admin/design/charts \
  /usr/local/cwpsrv/htdocs/admin/design/charts/sparklines

ls -l \
  /usr/local/cwpsrv/htdocs/admin/design/charts/sparklines/jquery.sparkline.js

Finally, reload the CWP admin interface using a hard refresh:

Ctrl+Shift+R

This is only a temporary workaround. The permanent CWP correction should change the generated asset URL from:

- /admin/design/charts/sparklines/jquery.sparkline.js
+ /admin/design/plugins/charts/sparklines/jquery.sparkline.js

A future CWP update may remove the workaround, so the official package or admin template should be corrected.

@Sandeep B. Please use the findings in the corrections in the CWP update.

Since I need to fix the admin interface of 15+ servers at least at a basic level, I summarized the above steps in a correction script.

#!/usr/bin/env bash

set -Eeuo pipefail

DESIGN_DIR="/usr/local/cwpsrv/htdocs/admin/design"
CHARTS_DIR="${DESIGN_DIR}/charts"
SPARKLINE_DIR="${CHARTS_DIR}/sparklines"
SOURCE_FILE="${DESIGN_DIR}/plugins/charts/sparklines/jquery.sparkline.js"
LINK_FILE="${SPARKLINE_DIR}/jquery.sparkline.js"

design_was_immutable=0
design_unlocked=0

log() {
    printf '[cwp-sparkline-fix] %s\n' "$*"
}

fail() {
    log "ERROR: $*" >&2
    exit 1
}

restore_design_protection() {
    if (( design_unlocked == 1 && design_was_immutable == 1 )); then
        if chattr +i "$DESIGN_DIR"; then
            design_unlocked=0
            log "Restored the immutable flag on ${DESIGN_DIR}."
        else
            log "WARNING: Could not restore the immutable flag on ${DESIGN_DIR}." >&2
        fi
    fi
}

on_error() {
    local exit_code=$?
    log "The repair stopped because a command failed." >&2
    restore_design_protection
    exit "$exit_code"
}

trap on_error ERR
trap restore_design_protection EXIT

[[ ${EUID:-$(id -u)} -eq 0 ]] || fail "Run this script as root."
command -v chattr >/dev/null 2>&1 || fail "The chattr command is not available."
command -v lsattr >/dev/null 2>&1 || fail "The lsattr command is not available."

[[ -d "$DESIGN_DIR" ]] || fail "CWP design directory not found: ${DESIGN_DIR}"
[[ -f "$SOURCE_FILE" ]] || fail "Sparkline source file not found: ${SOURCE_FILE}"

if [[ -L "$LINK_FILE" ]]; then
    resolved_link=$(readlink -f "$LINK_FILE" || true)
    resolved_source=$(readlink -f "$SOURCE_FILE")

    if [[ "$resolved_link" == "$resolved_source" ]]; then
        log "The correct symlink already exists. No changes are required."
        exit 0
    fi

    fail "A symlink already exists at ${LINK_FILE}, but it points to ${resolved_link:-an invalid target}."
fi

[[ ! -e "$LINK_FILE" ]] || fail "A non-symlink file already exists at ${LINK_FILE}."

design_attributes=$(lsattr -d "$DESIGN_DIR" | awk '{print $1}')
if [[ "$design_attributes" == *i* ]]; then
    design_was_immutable=1
    log "Temporarily removing the immutable flag from ${DESIGN_DIR}."
    chattr -i "$DESIGN_DIR"
    design_unlocked=1
else
    log "The design directory is not immutable; no flag change is needed."
fi

log "Creating the missing CWP asset path."
mkdir -p "$SPARKLINE_DIR"
chown root:root "$CHARTS_DIR" "$SPARKLINE_DIR"
chmod 750 "$CHARTS_DIR" "$SPARKLINE_DIR"

log "Creating the Sparkline symlink."
ln -s "$SOURCE_FILE" "$LINK_FILE"

resolved_link=$(readlink -f "$LINK_FILE")
resolved_source=$(readlink -f "$SOURCE_FILE")
[[ "$resolved_link" == "$resolved_source" ]] || fail "Symlink verification failed."

log "Protecting the new directories with the immutable flag."
chattr +i "$SPARKLINE_DIR"
chattr +i "$CHARTS_DIR"

restore_design_protection

log "Repair completed successfully."
log "Symlink: ${LINK_FILE} -> ${resolved_link}"
log "Reload the CWP admin interface with Ctrl+Shift+R."

On the given server, copy it to the /root directory, then:

cd /root
chmod 750 cwp-fix-sparkline-path.sh
./cwp-fix-sparkline-path.sh

Or simple

sh /root/cwp-fix-sparkline-path.sh

The script:

• checks root permissions and the source file;

• detects if the fix already exists;

• does not overwrite any invalid or unknown files/symlinks;

• temporarily unsets the immutable attribute of the design;

• creates the directories and symlinks;

• checks the target of the symlink;

• resets immutable protection;

• attempts to reset the design directory protection even if an error occurs.