Paul

There is not an official module for WHMPHP for Blesta (But there is one here: I would suggest using this 3rd party WHMPHP Module, or getting your own root access server if you want to sell reseller accounts.

Is this what you're looking for? https://blesta-addons.com/plugin/membership_club/main/

blesta.store is pretty cheap without a coupon, but you can message them on their site if you want to try to negotiate

We have a task now https://dev.blesta.com/browse/CORE-2857

Blesta Addons will be cheaper, but if you need help let us know. Some of the changes, like using the customers name as the hostname and hiding the field is something that we wouldn't be likely to release to the public and would be a custom build. I could see how being able to specify which templates can be chosen from on the package level would be useful.

Welcome, let us know if we can help with anything

I re-issued some trials via email this weekend. If you weren't one of them, please PM me the URL to your Blesta installation.

Is the URL to the page with the white screen your Blesta install or Alipay's website? You can enable error reporting and see if any errors are output. You can also check your logs.. see https://docs.blesta.com/pages/viewpage.action?pageId=10551368#Debugging/Tools-EnablingErrorReporting&Debugging for more details on how to do this. Most likely a white page means there is an error, so we just need to know what the error is.

I believe this is an issue in 4.3. The solution is to extend the coupon out by 1 term. So if it's a 1 month service, add 1 month to the coupon, 1 year, add 1 year. Here's the task for this, assuming of course this is the issue impacting you https://dev.blesta.com/browse/CORE-2829

There's a bug in 4.3 where prorata services ordered on the prorata day can come up with a price of 0. The service is scheduled to renew the same day, so the customer would be invoiced shortly for the second month. If you use prorata settings in your packages, this issue is resolved in 4.4, however here's some steps to resolve now if you need to. Be sure to back up the file first, and be sure to be running 4.3.2. You should be able to patch this issue yourself by making a simple file change as described below: Open the file /core/Pricing/Modifier/Type/Proration/Proration.php Find the following lines: Above that, add the following lines: The result should look like the following: Save that change and the issue should be resolved.

Maybe you should do a full translation? If it is good, we can make sure your definitions are used instead of any others.

It's not no. It would be possible through the use of a config option to have a minimum requirement for things like quantity, but addons are services and there is no mechanism to force the selection of an addon when ordering the parent service. I can see a use case for that. If you want to make a feature request, please think through how you'd like this to work and feel free to make a feature request at https://requests.blesta.com

Ok, unless this comes up again I'd consider it a fluke. Most likely the date was not set for whatever reason in the database, and this is what caused the invoices to be "back billed" from unix epoch. If anyone else experiences this, please let us know.

I'm not able to duplicate this. Most likely there was no date, or an empty date set for invoices_recur.date_renews however it's not possible to not set any date when creating a recurring invoice. I would suggest checking invoices_recur and see that there is a valid date set for all under date_renews. Check also date_last_renewed which should be a valid date in the not too distant past or NULL.

So you had a recurring invoice that you created prior to upgrading to 4.3 and that one renewed correctly, but you created a new recurring invoice after upgrading to 4.3 and that's the one that had the issue? How many actual invoices did it generated? Just trying to confirm my hypothesis.

So you're having invoices go out and the invoices are due in 4 months? This setting can exist in 2 places: Settings > Company > Billing/Payment: Invoice Days Before Renewal Settings > Company > Client Group: Invoice Days Before Renewal Client group settings override company settings if set. However, the maximum allowed in the interface is 60 days, so it would be unusual unless you modified the database for invoices to be generated 4 months in advance.

UPDATE: Are there roughly 576 invoices? Because that's how many months between 1970 and 2018. If you had no date set, or it was set to 1970 then it'd make sense it would catch up to today. It's as if your cron didn't run since 1970 and played catchup. Unless any other recurring invoices did the same thing, I don't expect it will happen again.

When did you create the recurring invoice? Was it prior to upgrading to 4.3.2? Did it work as expected for a time? When the invoice is generated, the renew date should be bumped forward a month. If your dates show 1970 (unix epoch time) then chances are there's a missing date someplace. What does your invoices table look like for this recurring invoice?

Great, thanks a task for SolusVM has been created as well.

Additionally I've created the Epic https://dev.blesta.com/browse/CORE-2832 and we have 2 modules apart of that: Vultr and cPanel. Is anyone aware of any other modules that this is an issue with? We need a task for each that we'll be updating, and I am not able to look at them all right now.

What version of Blesta are you running? This was changed in 4.1, see https://dev.blesta.com/browse/CORE-2284 If you are running 4.1+ try testing with the Wizard List order form, I've personally seen the out of stock button appear on this order form. If it's an issue with wizard boxes we can look into it. If you're not running 4.3.2, you should be.

That's right. If it's an owned license and the reseller disappears, we will transfer in their licenses at no cost to the customer. Be prepared to prove that you own the license. Your original invoice and license key will help. Also, we may have to look at whois data to ensure you own the domain the license is currently installed at. We just need to confirm that you're the rightful owner.

Maybe I haven't tried paying using the Pay Now link in some time. Is this what the client is always shown? The login page with the message embedded? If so, then yes, I think we should improve this.

Is it just the initial ticket received email, or is it after staff reply also? I think this initial received reply is different, and doesn't contain a modified subject to track the ticket. Maybe it should, so that they could reply to it and update the ticket. In that case, it would definitely need to have a reply-to set to the department email.

Sounds like the issue is unique to that one Plesk server. Have you reached out to Plesk support?