Tyson

As Licensecart mentioned, this isn't a bug with Blesta. This is how your browser renders textareas--it removes both the first and last line break. This is so that you can write something like the following in HTML: <textarea name="input"> This sentence has a line break before and after it, which are both automatically removed by the browser. </textarea> ..and it will display it as one line, which is identical to: <textarea name="input">This sentence has no line breaks</textarea> The work-around, as you already discovered, is to use two line-breaks at the beginning or at the end of your text in the textarea, which will display one line-break before or after the text, respectively. I'll close this thread as not a bug.

A recent fix for CORE-1198 for v3.2.0-b2 may have addressed this issue. SolusVM's XML responses do not encode characters like &, <, >, causing the XML interpreter to fail. SolusVM should format their XML properly, but we may be supporting the new JSON responses from SolusVM in the future to avoid issues like this. I'm going to close this thread as fixed/outdated. Please create a new thread if you continue to experience a similar issue.

It's a little different. There are several fields that the module stores for a service, and the label comes from the `service_fields`.`key` = "gogetssl_fqdn". An order ID should be set as well as "gogessl_orderid".

Check the module log to see if there is any data related to the connection attempt. And make sure your username/password doesn't have any white-space before or after it.

If it worked before, but has since stopped working, what has changed between now and then? It sounds like the VNCViewer class is not accessible any longer via the associated .jar within the /vendors/vnc/ directory you added. Have you tried to update or re-include any of the files?

We're planning to release v3.2.0-b2 later today, which has a fix for this issue, and which may resolve it for you. Do you know if the cPanel server you're trying to add currently has any accounts on it? It appears as though you will receive the connection error if you have no accounts on the server. Additional logging is added as well, and should at least help debug why packages aren't loading for you. I'd say give the upcoming beta a try, and I'll take a look if you're still having issues.

Thanks for the reports. Normally we require separate bugs to be described in separate threads, but I'll make an exception here. This has been fixed in CORE-1192 for v3.2.0-b2. Fixed in CORE-1200. Fixed in CORE-1201. The SolusVM module does not support upgrades/downgrades remotely. Any package changes you make for a service occur only locally within Blesta, so I don't think this applies to your case. I'll close this thread as fixed.

Ah, since Blesta couldn't pull packages from that server, it was indeed unable to connect to it for whatever reason. I don't think the module logs requests for packages, but it probably should to help debug issues like this.

I'm not sure I understand whether you tried the change in my last post. Did you update the cPanel module as I described here and try to save the server details, create a package using that module, and then generate a service successfully on that server? I'm trying to determine whether everything works correctly with the cPanel module if Blesta no longer attempts to verify a connection, and thus no longer gives you this error when saving a new server: If you did make that change, and the service still fails to be added, what data is available in the Module Log related to it?

If you disable that error check, and try to create a package & service, does it operate correctly, adding the domain to that "Bravo" cPanel server successfully?

Where users are redirected after performing some action is currently not configurable. If such a feature were added, I suspect it would be in a system-wide configuration, rather than isolated to to a single action/page--at least I think that would be a better solution.

Is it a reseller account? If so, you may want to check the reseller's privileges, particularly regarding List Accounts (listaccts). You may be experiencing the same issue described in another thread.

We considered this when we first created the Support Manager, but it was not possible to add this dashboard integration at that time due to various limitations. We'll revisit this again in the future. FYI, threads in the Beta forums will be inaccessible after the beta is over, so feature requests like this may be better suited to the Feature Requests forum.

We've run into this issue before, and the solutions are to either run Plesk on a different server or change your Apache Restart interval such that Plesk has time to respond to Blesta's request before it shuts down. A same issue was described on Plesk's forums.

I believe this issue is related to CORE-1133, fixed in v3.2.0-b1, and described in another thread.

Tickets currently support being assigned a service, but that ability has not made its way to the interface yet.

The thread may help others who stumble upon a similar error, so we'd like to keep it. However, I've updated your post to use general paths.

Closing this thread as duplicate/already fixed.

So you're able to duplicate this with eNom, but only when the data returned from the API contains empty fields? The error you described suggests it is an object rather than a string, at least when passed to the HTML helper: Could you provide a response and var_dump of the eNom data causing the issue? I'd like to know why a non-string value is given.

Ah, the two points you described haven't been updated for v3.2, at least not with respect to the admin interface. We have a task, CORE-768, to set a loading icon for ajax requests, but it's currently incomplete and likely won't be in v3.2.

The template you're referring to is shown when you click the service row--basically, click anywhere on the table row shown in your first screenshot, and the service info will appear beneath it.

The OP's original bug report is corrected in CORE-1154.

I would need more info to duplicate this issue since I haven't run into it, and we always run with error reporting on.

Yes, that can be a problem in some places, and require the module/plugin to develop their own solution. The 3.2 client interface more-or-less takes care of this with loading bars, and we've just updated module service fields to do the same. Other ajax requests may require a custom solution in your plugin/module, depending on what you're trying to do.

The OP "RegistrantPhone" error has been fixed for v3.2 in CORE-1141.