Paul

You can modify this if you want, but I don't know if it will accomplish what you're trying to do. This code tries to replace Vultr branding so the client doesn't see it. But if you are seeing Vultr branding elsewhere, then it either isn't being replaced like this or can't be replaced like this. I would like to see what you are seeing.

Where are you seeing this? Screenshot?

To change the logo, edit the theme under Settings > Company > Look and Feel. If using the default theme FOUR for client or admin, you must first EXPORT it to your computer, then IMPORT it to Blesta so it'll be a new theme, then you can edit it and set your logo URL and select it for use.

You can add it to Blesta by unchecking the "Use Module" option, and then it won't try to add it through the Virtualmin API, just to Blesta. You may need to edit it after and update any fields like the username field though (and uncheck use module again) and save.

What does the Blesta module log show? Tools > Logs: Module, click on the cPanel row to expand and display input/output.

Also, to add.. if you want to have /index.php/ in your URLs, it's usually sufficient to just delete the .htaccess file included with Blesta from your server. That would certainly be the fastest way to get things working if you don't want to mess with your Nginx config.

Blesta URLs rely on mod_rewrite, an Apache module. Nginx requires a special configuration to rewrite URLs to index.php, otherwise you must add /index.php/ in front of your URLs. See https://docs.blesta.com/display/user/Installing+Blesta#InstallingBlesta-Nginx for a sample config and required steps. If Nginx is running as a reverse proxy in front of Apache, then you shouldn't have to do this.

Yes, it asks you to enter a one-time password as you would be requested going forward to ensure that you have set it up correctly. Because if you haven't, then you would effectively lock yourself out.

I noticed. Stuff is happening in the background.

I don't have any ETA's. I have no reason to believe that 4.6 won't follow our typical release cycle, but I'm not going to make any predictions about the domain update. There will be a beta when we are ready for a beta.

@Amit Kumar Mishra The license has been transferred.

The only update I have is to say that we are adding a special feature to the core in 4.6 that will make the domain update possible in a future release. The feature we're adding in 4.6 is necessary to the foundation of the domain update, which can only come after it's completed. The feature is useful by itself also, and we'll release more information about it as we get closer to releasing 4.6.

I believe you can do this through the Vultr module, have you installed the free trial and given it a try? If you want to sell WordPress VPS's through another provider, then you'll probably need to make some customizations.. a startup bash script with an OS image that will install on first boot could work.

We don't copy code from other extensions into our own. If there are features of this plugin that you want to see in ours, then make a feature request for each one individually at https://requests.blesta.com

I responded to your PM. The license needs valid support & updates to be transferred, and cannot be pushed off to a later time.

This license is with us and eligible for transfer. We don't handle transfers on reseller licenses.

Your cron should specify the full path to PHP, ie /usr/bin/php /home/username/public_html/backstage/index.php cron > /dev/null (etcwhatever is here) Check Settings > System > Automation to see the recommended command. Blesta attempts to locate your PHP and show the right thing. It may not be 100% accurate all the time, but it's a good place to start. If Apache is running PHP 7.2, then CLI should be also.

I can confirm it is eligible for transfer.

How long has it been "stuck"? If it fails, Blesta should pick up and retry when the task runs next. Check Settings > Company > Automation to see if the task appears to still be running, when it last ran, and what the schedule is. If the task appears to be running but should have been completed, it may have crashed. Check your logs ../logs_blesta/ defined under Settings > System > General.

That's right, but the headers can be spoofed, that's why the ticket hash.

How do you mean? CC and BCC recipients receive a copy of the original email, so subject & body would necessarily be the same. If a ticket is sent to multiple recipients, then I think we'd generate each email separately and it wouldn't be a CC. The ticket hash provides necessary security and verification.. I forgot that I was composing this, and may have had more to say and got distracted. So, I'll leave it at this for now

{ticket_hash_code} is designed in such a way that Blesta can use it to identify the proper ticket, without leaving room for someone to maliciously modify the code to reply with updates to tickets that belong to other customers. It's designed with security in mind. ticket.id and ticket.code have direct relationships with real tickets, particularly ticket.id which is auto incrementing. Someone who receives a ticket with an ID of 100 can be reasonably sure that the ticket with an ID of 99 has already been created just before this one and is probably still open, and that ticket ID 101 will follow.

Is your cron job running as root? Did you install as root? Cron should run as the same user as your web server runs as.

Do you have a ticket open? When you updated from 4.5.0 to 4.5.1 did you apply the patch originally or the full version? There's nothing in the update that should cause the error you received, unless it was a coincidence and your license hadn't been validated in quite some time. When you updated to 4.5.0 was everything working fine? Did you run /admin/upgrade to upgrade the database? If it was working fine, and was upgraded properly, then applying the 4.5.1 update should be fine. However, you could pretty easily roll it back by re-uploading the 4.5.0 release, or restoring from backup. Does it work if you do that?

Blesta provisions paid pending orders. This means that the order is approved and paid, then the cron provisions the service. Whether the order is approved depends on your settings and any anti-fraud. Check Packages > Order Forms > Settings for anti-fraud options. Edit the order form to make sure "Require Manual Review and Approval of All Orders" is unchecked. Make sure your cron is running, it provisions orders that are approved and paid.