Tyson

Blesta supports staff-configurable language now. What is it you're changing the language for in your event?

I've just tested provisioning a service with Vesta and it did so successfully. Are you connecting over SSL and have a valid SSL certificate? It sounds as though the VestaCP webserver is blocking connections on port 8083 or may not be able to negotiate a proper SSL/TLS encryption algorithm to facilitate communication. You might try disabling SSL on the module to communicate insecurely for the purpose of testing whether you still encounter the same error.

A cron log of output already exists and any php errors that could stall a cron task are already logged to file.

The Process Service Renewals task says it has completed too? The cron log is missing an end date for that task, so it is either still running (unlikely) or has failed to complete (e.g. encountered a php error). You should be able to clear the task lock by going to the Settings > Company > Automation page, scrolling down to the Process Service Renewals task and clicking the Clear Task Lock link, assuming that link is available for the task, which I think it should be based on your description. Then you may want to run the cron manually from the Settings > System > Automation page so that the output is displayed in your browser and you can check whether an error occurs during that task's execution.

Are you using Blesta v4.2.0 or greater? After you get that error, can you look under Tools > Logs > Module (tab) and click on the top table row for VestaCP and take a look at the raw output information to see what response VestaCP replied to Blesta with. There may be a more descriptive error there.

It sounds like you're trying to create your own "auto-complete". Auto-complete functionality is already supported. You can call the jQuery function "autocomplete()". Take a look at the admin_tickets.pdt template file for reference. You'll probably need to create a new controller method to retrieve the information you're going to fetch in an AJAX request.

The Blesta installer resets the sql_mode to TRADITIONAL automatically, so I wouldn't expect that to be an issue whether it's enabled in MySQL or not.

What version of php? What happens when you follow links or go to another page, like /admin/login/?

I've created CORE-2600 to look into that issue. It's extra interesting because a deprecated feature should still work. I'm sad their API removes functionality.

It sounds like a configuration issue with the web server for HTTPS support. @Joseph H's reply might help you get that configured correctly. Also, FYI, make sure that the old Blesta installation and cron are no longer being used now that you've moved to another server.

Just to confirm, since you're running php 7.1, you did update the files in your installation with the files in /hotfix-php71/ of the ZIP, correct? Since the database tables were partially constructed, I wonder if there may be a table-creation query that your version of MySQL doesn't like, or if your web server timed out before it could process the entire request. You can try dropping all tables from the database that it did create and attempt to run the install again via CLI. You can also check your php error logs for any errors that may have been encountered.

Are you using the .htaccess file that comes with Blesta? What web server are you using?

The 'd' is the problem. Something like a module, as @Blesta Addons mentioned, is likely the culprit. It is printing out the 'd' character causing the JSON to not be parsed and displayed in the UI. You'll need to find where the 'd' is being printed and remove it.

Yes. CORE-2597

Have you checked out https://stackoverflow.com/questions/23261766/paypal-gateway-has-rejected-request-security-header-is-not-valid-10002-secur#23265150

What version of Blesta are you using? It is typical for a widget to be missing if there is a php fatal error attempting to load it. You should check your php error logs to see what the error may be.

An invoice that is scheduled to be delivered will be re-attempted if it failed. The demo account resets itself every day, so you don't need to worry about extraneous data on it.

The current Stripe integration processes payments server-side, so the card number passes through the server even if it is not storing it for any length of time after the payment is processed. The current integration also stores the last four digits of the card number in the transaction for reference. If you have Blesta configured to store card information offsite with Stripe, then client payment accounts will not store the card number on the server.

Thanks for the notice, I've created CORE-2596 to address this at some point.

I'm not sure I understand your question. From your first example, if you choose a non-approved status for a new transaction you create, then you can update it later to 'Approved'. The amount will then be a credit on the account, and you can use it to pay invoices.

It's not about what they're called, but how they function in the grand design of the system so that they can do what you want. It's very important to get a good design down early or there will be problems down the road.

Based on the response from Authorize.net, there should be a pending transaction created in Blesta for it. Since you have to take manual action in Authorize.net to accept/decline the payment, you'll need to take manual action in Blesta to do the same since Authorize.net does not make a callback to Blesta to allow the state to be transitioned after you accept it in their system.

The cron line shown in Blesta is an example generated from what Blesta believes the path would be, but it's not used for anything. Your cPanel cron job looks correct. You can check under Settings > System > Automation to see the last time the cron was run. It should follow a 10 minute interval based on your cPanel cron line. You may need to wait until you have other invoices due that should be autodebited to see if they are autodebited on the correct day or not.

From what you describe, it sounds like Blesta should treat LogicBoxes' response as a success in that case, otherwise the domain could renew on LogicBoxes 15 minutes later, but not be updated in Blesta.

You wouldn't happen to have a link to their API documentation would you? Also, do you know what the status "InvoicePaid" means? Did LogicBoxes perform an action on that domain? The current API rejects failed or error status responses. It seems like LogicBoxes performed some type of action (i.e. "InvoicePaid") for the order/domain, but I'm not sure. It would be helpful to take a look at their API docs and see what other statuses they could return too.