Paul

It does appear that the user may be lacking some permissions, check that the user has all privileges. The logs you attached don't seem to be related. What version of PHP are you running?

Did you run /admin/upgrade after replacing the files? A blank page is most often associated with an error, usually a MySQL error when it happens as a result of upgrading. It's safe to run /admin/upgrade again if you already did. If you ran /admin/upgrade and still get the white page, check your error logs, typically at ../logs_blesta/ What is written to the logs when you get the white page?

Super weird, but glad to hear it's working!

I PM'd you a trial key.

Did you have any errors in ../logs_blesta/ also, from the import? The first error usually kicks off the others. In this case, it looks like a contact is trying to be created that may not be associated with a client_id. Do you have any contacts in your WHMCS database that have a null client_id? Not associated with a client? If so, this is likely the reason.

I believe the service becomes "active" in Blesta if the transfer is initiated and the registrar returns a successful response to the API command. This doesn't mean the transfer has been completed, only that it's been initiated. Your cron command would potentially be useful for checking whether the transfer has failed, but I would expect the service status to be "active" during that process. Maybe that's not the best way to do it, but I'm pretty sure other modules behave this way currently.

A white page indicates an error, it's likely that you've saved something in the template that is not acceptable. If you are using styles, they should be inline. Regarding the logo not appearing in emails, many mail clients will not load external images by default unless the user select to do so. If that is not the issue, have you checked the source of the email to see if the image is linked correctly?

I'm not sure I understand, what is the full path to your document root, where is Blesta installed, and where as the logs_blesta directory created? logs_blesta should always be created one level above document root.

If this is for embedding an HTML table into your own website that has the pricing, we have created a task here for that https://dev.blesta.com/browse/CORE-4213 and will implement in a future version.

Here's the task: CORE-4213

This is a good idea, I'll create a task for this today. If you have any other use cases that we should consider let me know.

The domain update will let you set prices for domains in a grid, it simplifies setting prices. Are you trying to set prices, or are you trying to fetch all prices to list them somewhere outside of Blesta?

That setting is how many days in advance of a services renew date that it should be invoiced. I refer to that value only to say that when you adjust the services renew date (Manage > Actions: Change Renew date) in order to force a renewal, the date must be in this window. The default value is 5 days, so based on that example you'd need to set the renew date for the service to 5 days from now or sooner. Then, when the invoice cron runs next it'll invoice the service for renewal and bump out the renew date. Paying the resulting invoice will result in a renew command sent to the module. But the renew date of the domain will now be wrong and must be corrected after this all occurs. So, it's a bit tedious. The simpler thing to do is to manually invoice the client for the # of years they want to add, and when they pay do 2 things: Add the years with your registrar manually Push out the services renew date. If it normally would renew on May 1, 2022, and they buy 2 years change it to May 2, 2024.

Where do you see 60 days? I'm not sure what you are doing. The term for domains should be in years, 1 year, 2 years, 3.. to 10. If you enable it, clients can update so that at renewal it will renew for a different term.. 1yr to 5yrs for example.

We figured this one out today, just posting in case anyone else experiences this. In this case, the Package was set to use a Server Group that was created within the module but had no servers assigned to it. Adding a server to the group resolved the issue.

You can change the renew date to be within your "invoice days before renewal" and at the next invoice cron run it'll generate an invoice.. and once paid, initiate the module renew option. However, the renew date in Blesta will then be incorrect and will need to be adjusted. We will be adding a feature to "add years" to domains, after the initial domain manager update.

You just need to link to the package with any options you want to use, so no need to use a form. If you have a button though, just link it to the right URL. See https://docs.blesta.com/display/user/Order+System#OrderSystem-LinkingtoOrderPages on how to link to order forms. You can link to a specific package, select a specific term, apply a specific coupon, even submit any config option data to pre-populate.

Yes, if replying to a ticket the original ticket should be updated. This assumes that the necessary information is retained in the subject of the reply email and that the reply address matches the address defined for the department (Support > Department > Edit) and that you have piping or imap/pop configured for importing tickets.

I pushed this up a bit in our backlog. Is there a specific use-case that we could consider? Normally we wouldn't expect modules to send any notifications on their own.. I guess if the reason can be pushed to an external system and seen there.

I pushed this task up in our backlog and reworded it a bit. https://dev.blesta.com/browse/CORE-1996

Thanks for the update, that'll do it

What's your ticket #? What isn't working with the module? Are you getting any errors? Did you follow the documentation at https://docs.blesta.com/display/user/ISPConfig ?

Yep, good idea. task https://dev.blesta.com/browse/CORE-4185

The default Paper Size in Blesta is Letter, but Blesta also supports A4. You can update it under Settings > Company > Billing/Payment > Invoice Customization.

It's recommended that each TLD have it's own Package, and all domain Packages be assigned to a single Package Group for domains. That's what the order form type "Domain and Other" expects. If you have a lot of TLD's, obviously that can be tedious. It is possible to have a single Package for multiple TLD's, but that pins their pricing to be the same. Some more details on how this is configured is in our Selling Domains guide. The domain manager update we're working on will provide a pricing grid to simplify this process, and manage a Package per TLD automatically in the background. I'm not sure the best way to handle re-directing of TLDs to different registrars, other than marking an existing package as Inactive and creating a new one for the TLD that uses a different registrar module. We might need to explore that scenario a bit more. I don't know if this helps, if you have any specific questions or I missed anything please let us know.