Author Topic: CWP 1.8 – Can we have a clear Production Readiness / Fixed Issues list?  (Read 404 times)

0 Members and 2 Guests are viewing this topic.

Offline
*
**CWP 1.8 – Can we have a clear Production Readiness / Fixed Issues list?**

Hi CWP Team,

CWP 1.8 has now been released, and I am glad to see the project moving forward, including PHP 8.4/8.5 and the work that appears to be continuing on several modules.

However, I still have one important question before I can safely upgrade my production server:

**What has actually been fixed in CWP 1.8, and what is still known to be unresolved?**

I am asking this because of the problems introduced by previous CWP updates, especially the UI regressions that affected several administration modules. In my case, the situation became serious enough that I had to disable automatic updates on the production server because I could no longer confidently apply an update without risking further breakage.

I want to make one point very clear: I am **not asking CWP to manage my server for free**.

I am asking CWP to document the status of regressions and bugs introduced by CWP updates. These are two completely different things.

I have opened several tickets and contacted the team directly because my intention has always been technical and constructive. I want to continue using CWP, but I need to know whether the current release is safe and reliable enough for an existing production installation.

The recent answer I received from the CWP team was:

> “We have fixed most of the bugs in the meantime.”

This is encouraging, but unfortunately it does not tell me which bugs were fixed and which ones remain.

### Could CWP please provide a clear status for the following areas?

**Admin/UI**

* Admin panel UI regressions
* YUM Manager
* Firewall Manager / CSF integration
* ModSecurity
* PHP Selector / PHP-FPM
* SSL / AutoSSL
* Account management
* Domain / Subdomain management
* File Manager
* Roundcube
* API / administrative functions

**Backup**

* New Backup – local backup
* New Backup – remote backup
* Local backup email notification
* Remote backup email notification
* Correct reporting of successful/failed accounts
* Clear distinction between local and remote backup reports
* Failure/error reporting
* Backup verification
* **Restore functionality**

For each item, it would be extremely useful to know whether it is:

* **FIXED**
* **PARTIALLY FIXED**
* **STILL OPEN**
* **UNDER TESTING**
* **NOT REPRODUCED**

### About the New Backup module

I would also like to acknowledge a positive development.

After repeatedly reporting the lack of useful backup email reporting, I have now received a much more informative report for the local backup:

**Backup Process Summary**

**Status: COMPLETED SUCCESSFULLY**
**Date: 2026-08-11**
**Hour: 03:01:26**
**Mode: Full (Scheduled)**
**Type: Local**
**Total accounts: 5 (OK: 5 / Failed: 0)**

This is a significant improvement because it finally provides meaningful operational information about the backup job and the accounts processed.

However, I do **not** consider the backup issue completely resolved yet.

I still need to verify the reliability over time, both for local and remote backups, whether notifications consistently arrive for both destinations, whether failed accounts are correctly identified, and most importantly whether the backups can actually be restored successfully.

At the moment, the local notification appears to be working, while I am still not receiving the corresponding remote backup notification.

So I consider this **a very positive improvement, but still under validation**.

### What I am asking for

I am not asking for a promise that CWP 1.8 has no bugs.

Every complex software product has bugs.

What I am asking for is **transparency about the current state of the product**.

A simple official list such as:

**CWP 1.8 – Fixed / Known Issues / Under Testing**

would allow administrators to make an informed decision about whether to upgrade production systems.

At the moment, the changelog tells us that CWP 1.8 is the current version, but it does not give us enough information to determine whether the specific regressions reported by users have actually been resolved.

After the previous update problems, I cannot simply assume that a new version is production-ready because it has been released.

I would much rather have CWP tell us:

> “These problems are fixed, these are still open, and these are currently being tested.”

That would give me the information I need to safely evaluate CWP 1.8.

**I want to continue using CWP. I just need to know when I can trust the update process again.**

Thank you.

Offline
*
It's fine to use AI, but tone it down a bit. Ask them to use BBCode instead of Markdown.
_
Distro Name: AlmaLinux release 9.8 (Olive Jaguar)
CWPpro version: 1.8
Web Servers: nginx-apache

Offline
*
Coming back to the actual purpose of this thread

Thanks for the formatting suggestion. I will use BBCode for the forum posts.

However, I would like to bring the discussion back to the actual purpose of this thread, because the technical questions raised in the original post are still unanswered.

The purpose was not to produce a perfect-looking post, nor to complain about individual bugs.

The purpose was to try to create, together with the CWP team and the community, a single place where we can establish the current production status of CWP 1.x.

At the moment, we have individual forum threads reporting individual problems, but it is often difficult to determine:

  • whether the problem is a known CWP regression;
  • whether it was introduced by a specific update;
  • whether it has already been fixed;
  • which CWP version contains the fix;
  • whether the fix has actually been tested;
  • or whether the problem is still considered known/open.

For a system administrator running production servers, this information is extremely important.

The question is very simple:

Can I safely update my production CWP server, and if I do, what should I specifically monitor afterwards?

This is why I believe a simple, maintained status list would be much more useful than scattered individual reports.

I would especially like to keep the focus on Backup / Restore / Reporting.

The New Backup system has been in beta/development for a long time, and I think we need to distinguish three different things:

1. Backup

Does the backup job actually complete correctly, both locally and remotely?

2. Restore

Can we reliably restore an account from that backup when we actually need it?

This is probably the most important question.

A backup that reports "completed successfully" is only useful if the corresponding restore has also been tested and is reliable.

Can CWP clarify which restore scenarios are currently tested and considered production-ready?

3. Email reporting

This is a separate issue that I have personally reported.

Even when a backup job runs, the administrator needs reliable reporting:

  • local backup status;
  • remote backup status;
  • successful accounts;
  • failed accounts;
  • warnings/errors;
  • and reliable notification emails.

If the backup runs but the notification is missing or incomplete, the administrator does not have reliable visibility of the backup status.

This is why I don't think "use an external backup solution" answers the question.

Administrators can certainly use external backup systems, and many of us do.

But CWP also provides a Backup/Restore system, and it is reasonable to ask what its current production status actually is.

The same applies to the update process.

I understand that emergency security releases can sometimes require accelerated development and reduced testing.

However, after such releases, it becomes even more important to clearly communicate:

  • what changed;
  • what was tested;
  • what could not be tested;
  • what regressions are known;
  • and what has subsequently been fixed.

The CWP changelog currently does not provide enough detail for an administrator to reconstruct this information reliably.

So I would like to ask the CWP team directly:

Could you please provide an updated status for the issues raised in this thread?

Even a simple table would be enough:

Code: [Select]
Component       Status              Fixed in       Notes
--------------------------------------------------------

Backup          Stable / Beta       x.x.x          ...
Restore         Stable / Beta       x.x.x          ...
Reporting       Open / Fixed        x.x.x          ...
UI              Open / Fixed        x.x.x          ...
ModSecurity     Open / Fixed        x.x.x          ...
CSF/Firewall    Open / Fixed        x.x.x          ...
YUM Manager     Open / Fixed        x.x.x          ...
PHP Selector    Open / Fixed        x.x.x          ...

It does not need to be perfect.

What matters is having a clear reference that allows administrators to understand:

what is fixed, what is not fixed, what is still beta, and what requires attention before updating a production server.

That was the reason for opening this thread in the first place.

I would really appreciate a technical response from the CWP team so that we can turn this into something useful for the whole community.