Kal

Thanks for testing and confirming the bug. Any ETA on when it might be fixed? Any chance it will be a simple change I can replicate, or will I need to renew my paid support?

@Paul, I've done some more tests and worked out that the problem is with the `DirectAdmin.password_length` setting. Regardless of what I set this to, the error appears if I enter a password of less than 12 characters. The `DirectAdmin.password_requirements` setting works as expected. For example: Configure::set('DirectAdmin.password_requirements', [ ["A-Z"], ["a-z"] ]); Configure::set('DirectAdmin.password_length', 9); With these settings, a password of 'Abcdefghijkl' (12 characters) passes, but a password of 'Abcdefghijk' (11 characters) fails. Is this a bug, or have I missed something?

Okay, so DA has the option 'Allow API logins with the current User/password', which is ticked. Just to be sure, I temporarily turned off 2FA, but the problem persists. Any other ideas?

Something just occurred to me… I have two-factor authentication turned on in DA (as every security-minded admin should). Is this incompatible with the module?

Hi Paul, and thanks for offering to help. Yes, no and yes. I edited the error message under the same directory, as you described, and I can confirm that the error message has now changed—so it's certainly the correct (and only) copy of Blesta on the server. Yes, it exceeds the requirements. I was testing the 'Add Service' command on an existing account, and the password is the one that is already used by that account. I unticked 'Provision using the DirectAdmin module when activated'. Am I doing something wrong perhaps? The accounts are already set up in DirectAdmin—I just want to link them to Blesta so I can start using it for billing. I also tried creating a new account by specifying a new username and domain, but I just get the same error again, even if I use Blesta's 'Generated Password' feature. So despite the error, I suspect the problem is not with the password requirements. What else could cause this error to get triggered? Last time I checked, DirectAdmin's `enforce_difficult_passwords` option is turned off by default, and if you turn it on, the default minimum password requirements are 6 characters including an upper-case letter, lower-case letter and number. See: Difficult password enforcement option. When you say that you 'go with the strictest possible requirement', how can you know how a user has configured this in DirectAdmin? Password checking is performed by a script, and there is no limit to how the server admin could configure this.

I have edited this file as described, removing unwanted requirements and reducing the minimum password length to 9, but as soon as I try to add a service I still get the same message: Help! (BTW, for anyone who still believes that character-composition requirements are a good idea, you might want to read the advice of security experts like Troy Hunt, NIST and Microsoft who all advise against this practice. See: Passwords Evolved: Authentication Guidance for the Modern Era. A poor decision for Blesta to turn this on by default IMO.)

I've now made this a feature request: Friendly URLs (permalinks).

Friendly URLs are, in my opinion, an essential element of any content management system. No one likes a long, ugly URL. But more importantly, no one likes link rot—least of all the site owner who may lose their precious search engine rank when a URL changes. For this reason, a URL should never be dependant on the underlying platform. Here's an example of such a URL, from Blesta's Knowledge Base plugin: https://blesta.example.com/plugin/support_manager/knowledgebase/view/12/testing-your-website-before-it-goes-live/5/ Aside from being unnecessarily long, the URL also includes the following, platform-specific data: Blesta's Knowledge Base is a 'plugin'. The plug-in is called 'Support Manager'. The article is the 12th one that was added to the database. The article belongs to the 5th category that was added to the database. Each of these is a point at which the URL is likely to break if and when the underlying software platform changes. A platform agnostic URL, or permalink, is a URL that should never change, and it's a critical element of website design/development. Tim Berners-Lee stated this firmly in the 1998 article, Cool URIs don't change, where he espoused the concept of URI design. I request that Blesta introduce a permalink feature, which is accessible via the UI, easy to use, and central to the design of the whole system. The Knowledge Base, perhaps, needs special attention, so that database table row IDs are never part of the article URLs. (routes.php does not fulfil these requirements.) Without this feature, the user must go to considerable effort to manually create many individual redirects using Apache configuration files or .htaccess files.

I did rummage through your old posts around the time (December 2016), but couldn't find it. Are you able to remember and share, even briefly, the process?

Thanks for the info about routes.php. I can see from the code, for example, how `/admin/settings/company/general/localization/` really points to `/admin_company_general/localization/`. By the same logic, `/admin/plugin/support_manager/admin_knowledgebase/` should point to `/support_manager/admin_knowledgebase/`, but trying to load that second URL in a browser doesn't work—so I guess there's something I'm not getting about how it works. Anyway, I suspect I can't achieve what I want with routes, because the table row IDs for knowledge base articles are essential parts of the URLs. Ideally, I'd like the option of having human-readable and platform-agnostic URLs like this: https://account.example.com/help/docs/article-title I don't like that the URLs include table row IDs, which don't reflect anything meaningful, only what order I created the articles. That kind of thing should be hidden from the user IMHO.

Is there a way to get Blesta to generate friendlier URLs? I'm thinking of the Knowledge Base in particular. Instead of this: https://blesta.example.com/plugin/support_manager/knowledgebase/view/6/testing-your-website-before-it-goes-live/5/ I'd like to have something like this: https://blesta.example.com/knowledgebase/testing-your-website-before-it-goes-live

Thanks Paul, that's very useful. Is there any way to choose a default if the client navigates to the order form from within the Blesta UI?

Did any progress get made on this? I can't find any option to choose which package is selected by default.

Perfect!! While I'm saying thank you, thanks for all the great new features in 4.11 too. I especially appreciate the ability to enforce email address usernames—something I switched on straight away. ?

I had wondered if structure.pdt would get overwritten with an update. Indeed it does. This also makes the official instructions for Removing Branding a temporary fix, which isn't mentioned in the docs. Since that feature is advertised on Blesta's pricing page, I'd have hoped for a more robust method. DirectAdmin has a feature where customised config files can be placed within 'custom' subdirectories to protect them from being overwritten. Maybe something like that could work for Blesta? Adding these features to the UI would be even better though. @Paul, you mentioned above that style overrides were coming to themes, and there was talk on this thread of possibly removing branding automatically from unbranded licenses in the future. Are those features still on the roadmap?

@turner2f Did you end up writing that post? This is exactly what I'm looking for, but this is the only thread I can find on the topic.

Emoji support would be good. I'm surprised this hasn't come up before—I just assume many people would try inserting emoji, so I tested it. Failing that, could you just strip out any non-recognised characters so that the message still goes through?

Yes, when I said 'departments', I wasn't specifically referring to Blesta's feature for categorising support tickets—rather the actual departments they refer to in your business. They are the common link aren't they, between these currently unconnected elements in Blesta? A simple table of corporate departments could contain the email address, signature and even the support category (Department) for each one. While I suppose you're right—it doesn't take that long to go through and change each template—wouldn't this still be an improvement? Is there a good reason to leave it as is, and require the user to update the same email address repeatedly throughout the system? That approach invariably leads to human error, as illustrated by one or two inconsistencies in Blesta's own default templates. This is what relational databases are supposed to save us from, no? Perhaps my suggested feature would break things for existing users. If that's the case, sure, giving users the ability to simply change the domain used for email addresses would be an improvement. You could even make it recognise subdomains and choose the main domain by default, since probably 99%+ of users are going to use email addresses like billing@yourdomain.com, not billing@blesta.yourdomain.com. Edit: I just noticed that this was requested here: Update Global Email Address.

Entering an emoji into a support ticket message (by either client or staff) causes the Reply/Update to fail. There is no error given—just a blank screen. (I'm testing on macOS, using the standard character panel to insert emoji.)

The email templating system pre-populates the 'From Email' fields with addresses like billing@yourdomain.com and sales@yourdomain.com. If you install Blesta on a subdomain, you'll get email addresses that look something like billing@blesta.yourdomain.com, when you probably want billing@yourdomain.com. Or maybe you want something different, like accounts@yourdomain.com. Either way, the only way to fix this appears to be to manually edit the From address in each and every template. (See where others have asked about this: From emails how to change?, Problem With Sending From Email Address and Wrong Email.) Could Blesta not store an email address for each department (admin, billing, sales, support), much like it stores email signatures? It might also make sense to link a default 'From Name' and Signature to each department, so you only have to specify the address (or the department) and everything matches up automatically. (As if to illustrate the potential for mistakes, when these details aren't linked, the default Account Registration template is from Sales, but the From Name is set to 'Billing Department'.)

Did this ever happen? I'd like to lose the drop shadows too. ? Edit: I worked around it by creating a custom CSS file in app/views/client/bootstrap/css/: .nav-content .navbar-default .navbar-nav > li > a { text-shadow: none !important; } Then I linked to it from app/views/client/bootstrap/structure.pdt. It works, but is there a better way to do it?

No worries! I was just checking out Blesta as I consider whether to automate my billing (for a small number of clients), and signed up to the forum when I saw this discussion, as I thought the Rack911 audit could help others here. (Blesta looks great BTW.) Yeah, sounds like everyone (Rack911 included) had high hopes for it! What a shame they developed it without the necessary security focus or knowledge. For me, this means paying license fees I thought I could save by moving away from cPanel… ? but I figure it's just not worth compromising on security with web servers.

One factor not mentioned here so far is security. RACK911 Labs just did a security audit of alternative control panels and the results are enlightening! I was thinking about going with CWP or CyberPanel before I read this. After reading it, I decided to go with DirectAdmin instead. (I can't comment on it beyond that, as I haven't switched yet.)