We all know CPanel sucks but…

I was really unaware of the “level of FAIL” that it was capable of demonstrating… until now.

1) frontend/x3/diskusage/index.html , go to a folder with lots of files in it.
2) Click “Size (MB)” column header to sort.
3) Watch cPanel sort a numeric column alphabetically, but don’t blink because
it also auto-refreshes the page a second later with the original by-name sort
4) Be amazed at the level of FAIL exhibited by a product claiming to be in its
11th iteration.

While the guy does an excellent job in describing what the issue is, the wording is somewhat humorous.

4 thoughts on “We all know CPanel sucks but…”

  1. There are 4 builds of cPanel/WHM: EDGE, CURRENT, RELEASE and STABLE, each with differing levels of quality control.

    As new features are added to cPanel/WHM, they propagate through the builds. A feature would first appear in EDGE. EDGE is not production-worthy due to the fact this build receives relatively little testing (compared with the other builds). The EDGE build is available for developers and those who absolutely want the latest functionality but are skillful enough to cope with any stability issues that can arise from newly released software.

    Next, after quality assurance testing to indicate that the feature performs as it should without ill affects to any other component in the cPanel/WHM environment, it enters CURRENT. Features that make it to CURRENT are considered debugged and worthy of production use. However, at this build sometimes a distribution-specific issue arises, or an unforeseen issue that is the result of circumstances we can’t easily replicate in a lab setting can cause issues with cPanel/WHM. This can be anything from third party software that conflicts with cPanel/WHM to someone using an ancient configuration (such as using mbox instead of maildir). While we hope to catch these issues in EDGE, on relatively rare occasion they surface in CURRENT. While the QA staff generates scenarios to simulate how people would attempt to use our product in production environments, these scenarios simply cannot compensate for every possible hardware/software configuration.

    RELEASE is our default build. It has the balance of stability vs. contemporary functionality that most of our customers desire. The quality standards that need to be met before something reaches RELEASE is even more strict as this is the build that the majority of our customers would be using (since it is the default). By this time all the major and minor bugs have been accounted for. However, trivial issues such as the one you mentioned here can arise. While it doesn’t adversely affect data on the server or substantially impede your ability to perform a major task, it is still something that shouldn’t happen.

    STABLE is our most conservative build. It is extremely rare that a bug propagates all the way to STABLE due to the extremely stringent quality standards we have for STABLE. I cannot go into details that aren’t public knowledge, I will say the quality assurance methodologies for STABLE are the reason STABLE earns its name.

    In-house, we do run various builds of cPanel (typically more on the EDGE side of things). While we do appreciate the input from the EDGE users (and all of our users), we rely on our quality assurance team and internal use to ensure features meet our quality standards.

    With cPanel/WHM, you can control which build you wish to use (WHM -> Server Settings -> Update Config). So if you prefer a stable software experience and are willing to wait a while for new functionality to be thoroughly tested before it reaches your servers, set yourself for STABLE. If you’re an experienced Sysadmin and can cope with some issues, then use CURRENT. However, the majority of our customers stick with the default, RELEASE.

    While we encourage the general public as well as our customers to use our feature request/bug reporting system, sometimes it is difficult for us to replicate a particular issue. In that scenario, we will request via the bug report that you submit a support ticket directly to us (all it costs is time) so our staff can login and determine the cause of the issue and the corrective action that needs to take place.

  2. I never understand the amount of bugs that are in each release of CPanel. Is there really ever much testing that is completed in house before you allow for the updates to be rolled out? What kind of testing phases do you have? And what kind of testers at that? I have seen many releases from you guys that look like they were just written and released for the general public to play with and report back the multiple bugs.

Comments are closed.