Bug in new CWP Update: Yum Manager stuck on "Checking for updates..." due to 404

I am using Alma 8 with CWP

Description:
After the latest CWP update, the Yum Manager interface (yum_manager) is broken and permanently stuck on the "Checking for updates..." loading animation.

Steps to reproduce:
1. Open the Control Web Panel.
2. Navigate to the Yum Manager module.
3. The page remains stuck in an infinite loading state.

Technical Analysis (from Browser Developer Console):
The issue is caused by a missing asset path (404 Not Found) which breaks the subsequent jQuery/JavaScript execution chain.

1. 404 Not Found Error:
   The panel tries to fetch a sparkline chart script from an invalid path:
   GET https://<server-ip>:2031/cwp_<hash>/admin/design/charts/sparkline... net::ERR_ABORTED 404 (Not Found)

2. Uncaught TypeError (JavaScript Crash):
   Because the file is missing, blank.js fails with:
   Uncaught TypeError: $(...).sparkline is not a function at blank.js:13:13

3. Status Breakdown:
   This uncaught exception causes the main updates-fetching script to crash completely, preventing the status retrieval from processing:
   Uncaught TypeError: Cannot read properties of null (reading 'status') at index.php?module=yum_manager:650:22

Expected Fix:
Please verify the file path of the asset in the new design layout update and fix the reference to the sparkline script within the yum_manager module layout.

+1

The 404 and the stuck module are two independent bugs. zakrpa spotted the 404
in the Alma 9 / 1.3 thread and noted that fixing it doesn't resolve the stuck
modules — correct, because the hang has a different cause.

Root cause of the hang: jQuery is loaded twice, in two different versions.

  design/img/js.php                    (head)   -> jQuery 1.7.1
  design/js/libs/jquery-2.1.1.min.js   (footer) -> jQuery 2.1.1

DataTables is injected mid-body (design/3rdparty/datatables/js/
jquery.dataTables.min.js, HTTP 200, loads fine) and registers on the jQuery
active at that moment: 1.7.1. The footer script then replaces window.jQuery and
$ with a fresh 2.1.1 instance. When document.ready fires, $ resolves to 2.1.1,
which has no .dataTable.

Verified in console on a stuck mod_security page:

  $.fn.jquery           -> "2.1.1"
  typeof $.fn.dataTable -> "undefined"

and the module dies at:

  Uncaught TypeError: Cannot read properties of undefined (reading 'ext')
  at $.fn.dataTable.ext.search.push(...)

That handler is what calls initModSecModule(), so the spinner never resolves
and no XHR is ever sent — the server never receives a module request at all.
The backend is fine; the page renders correct data (cwp_pro, modsec_installed,
domains_list are all populated).

Affected on my server, all with the same console error: mod_security,
yum_manager, php_switch_v2, firewallv2, csf. Modules whose plugins load after
the footer jQuery work normally — list_accounts renders its DataTable fine.

The separate 404: the template requests
  design/charts/sparklines/jquery.sparkline.js
while the file ships at
  design/plugins/charts/sparklines/jquery.sparkline.js
That only breaks the sparklines in blank.js.

For anyone thinking of symlinking around it: /usr/local/cwpsrv/htdocs/admin/
and all of design/ are chattr +i, so it can't be worked around locally. Both
issues need a vendor fix.

Environment: AlmaLinux 8.10, cwpsrv-1.24.0-2, cwpphp-7.2.30-3.

+

Facing the same issue.

I contacted José on Telegram; I think he should see the message and step in quickly.