Paul

Follow the moving Blesta guide at https://docs.blesta.com/display/user/Moving+Blesta if you are moving Blesta. You do not change your system key, it must remain the same as generated on initial install or your installation will be irreversibly broken.

Nobody is deleting your tickets. I see a ticket from you, but it's not attached to any client account. Probably you emailed from a different address than we have on file for you and no match was found, or you weren't logged in to the client area when you opened the ticket, so it wasn't attached to your account. The ticket says that I have your Blesta admin login details? Where did you send those, are they in another ticket or??

Did you follow the moving Blesta guide? https://docs.blesta.com/display/user/Moving+Blesta CPU usage depends on what is happening. I don't recommend rate limiting resources for Blesta, if you are doing so it's possible your server killed or interrupted the cron while it was in the middle of something important. Most of the heavy lifting happens via cron.

That's not what I mean. I mean your cron job on your server should run to provision it. You are doing it through a web browser, which is making an HTTP request to the same server that is restarting Apache and dropping the connection. That's the issue here. The problem is that Blesta and Virtualmin are on the same server, and Virtualmin drops the connection when you do it in a browser. Let the cron job run on the server automatically, and it should work. You won't have this problem if the Virtualmin server is external to Blesta.

A license change has no impact on functionality, so I 'm not sure how that could be related. Does it take more than 100 seconds for Virtualmin to create the account? I'd expect only 5-10 seconds or so. I think you should test with a Virtualmin server that is external to your Blesta install. I suspect that Virtualmin is dropping the connection after Blesta makes the request because it is restarting/reloading Apache. Alternatively you can add the service as a PENDING service, and let your CRON job run and try to provision the service. The cron may work because the connection to you as an admin would not be dropped if this is in fact the cause. So, give that a try - either try to provision on another Virtualmin server OR let the cron provision the service by setting it to PENDING when you add it, and letting the cron run.

If you want to PM me all the details (CWP and Blesta credentials) and steps to reproduce the issue I can take a look.

Is Blesta installed on the same Virtualmin server? When do you get the error exactly, as a client placing an order through the order form or as an admin provisioning it manually? Normally when a client places an order, the cron will provision the service. If the error happens at the same time that the API call is made to create the service with Virtualmin and that's when you get the error, and Blesta is on the same server, Virtualmin may be restarting/reloading Apache in the middle of the request which would explain everything.

What template is that? I'm not familiar with it.

The screenshot you posted from Tools > Logs > Module log had a CyberPanel entry. Click the row (Not the link) and it will expand and show you the raw input/output with the API, which may be helpful in determining what the issue is.

Friends don't let friends use wimps.

Much better!

Version 4.5.2 is now available, please see the release announcement. Patching Blesta See Patching Blesta in the User Manual for instructions. Installing Blesta See Installing Blesta in the User Manual for instructions. Upgrading Blesta See Upgrading Blesta in the User Manual for instructions. Migrating to Blesta See Migrating to Blesta in the User Manual for instructions. Release Notes See Blesta Core - Version 4.5.2. For older releases see all Change Logs.

You can try uninstalling and re-installing the payment gateway, that may cause it to recognize the change if you translated it properly.

From the source docs, you may be able to use this for client login http://source-docs.blesta.com/class-ClientLogin.html API docs https://docs.blesta.com/display/dev/API That's where I would start.

Eeew. Hold my trash can while I fill it with my lunch.

Normally someone would have to buy the theme directly, and buy the integration from you.

Contact @Blesta.Store through the forums here via PM. Mike should be able to get you sorted.

Each extension has its own language, look under /components/gateways/nonmerchant/ for each gateway.

If you check the box, then Blesta will not store the cards. Checking this option is recommended. Blesta will store a token to use to charge cards.

You should be able to re-issue the license in blesta.store's client area.

Yes, as Tyson mentioned check the module log. Also check your firewall. Your Blesta server needs to make an outgoing connection to CWP, so your Blesta server should allow the egress connection and your CWP server should allow the ingress connection.

We do not make users create an account to start a trial for a couple reasons, including: More people install the free trial when we don't require them to create an account. I can say that this is true, because prior to Blesta v3 we did require them to create an account and way more people install the free trial now. There are many hundreds of active trials at all times. Not every trial user converts to a paid user, we don't want to collect names and addresses of people who aren't going to become a customer. I guess we could market to them, but in the end we care more about privacy -- and we want the most people possible to install a free trial, which they are more likely to do if it's easy and they don't have to provide any personal details. Maybe we should send an introductory email to users who install the free trial.. and actually, we have plans to do this to help users that have a trial. We can include more information about how to become a paid user and what they need to do. But we aren't going to make an account for them unless they place an order. Thanks for your feedback!

If you have the token, you may be able to create a payment account in the database directly that uses the token. The problem is that some other information may be missing. Also, we have not tested this, so I can't say for sure whether it will work, but I don't see why not.

We are considering a change or option that would allow the new term to take affect immediately. To get around that you could make the change, then change the renew date to the desired renew date and it will prorate that. There will be 2 invoices, but the sum should be correct.

And then it lets you continue?