Tyson

If that happens again, can you run the following query and look for any duplicates under the `user_id` column? SELECT `l1`.* FROM `log_users` AS `l1` INNER JOIN ( SELECT `log_users`.*, MAX(`log_users`.`date_updated`) AS `date_logged` FROM `log_users` WHERE `log_users`.`result` = 'success' GROUP BY `log_users`.`user_id` ) AS `online` ON `l1`.`user_id` = `online`.`user_id` AND `l1`.`date_updated` = `online`.`date_logged` LEFT JOIN `staff` ON `staff`.`user_id` = `l1`.`user_id` LEFT JOIN `clients` ON `clients`.`user_id` = `l1`.`user_id` LEFT JOIN `contacts` ON `contacts`.`client_id` = `clients`.`id` AND `contacts`.`contact_type` = 'primary' LEFT JOIN `contacts` AS `contacts2` ON `contacts2`.`user_id` = `l1`.`user_id` WHERE `l1`.`company_id` = 1 ORDER BY `l1`.`date_updated` DESC LIMIT 15; Are there duplicates? Is the entire record duplicate (all fields identical) between those with the same `user_id`?

When making a payment without being logged in, the system looks for a hash to be included to verify the user. If it is not included, or it is invalid, you will be redirected to log in. If you aren't already, I would suggest making sure you are running the latest version of Blesta, currently v4.5.2. There was a change in that version that resolved a similar issue that might cause the behavior you experience, but only if you click that pay link while you are currently logged in as an admin.

How do you think that should work? Should you add SMTP details that the Mass Mailer plugin will save? Then you can select which details you would like to use when you create the email piece?

Does your Service Suspension automation task run at a later time-of-day than the due date on the invoice for that servce? For example, if the invoice is due at 12:00:00, but the cron runs at 10:00:00 it may not suspend the service because it is still not past 12:00:00. I think that it would make sense for the Service Suspension task to suspend any service that would be past due (i.e. Suspend Services Days After Due) for the entire day. That is, if the invoice is due May 6 at 12:00:00, but the cron runs May 7 at 10:00:00, it should still suspend it because the invoice was due the day before and the Suspend Services Days After Due is set to 1 day. Would that make sense? It sounds like this might be the issue in your case, except because the cron did not suspend it on May 7 at 10:00:00 it only suspended it the next time the cron ran, the next day, May 8 at 10:00:00. You mentioned that you want to suspend services immediately based on the invoice due date time, e.g., if an invoice is due at 14:00 and it is now 14:01, the service should be suspended. The problem with this is that the Service Suspension automated task only runs once a day, similar to invoice creation and service renewals, so I would expect them to act on records for the entire day from 00:00:00 to 23:59:59. Sometimes invoices are set to be due at the beginning of the day (i.e. 00:00:00 midnight) even though they may have been created later (e.g. 15:25:00), so the time can not be relied upon like the day can since Blesta focuses on the "day of". The Suspend Services Days After Due setting does not currently have a "Same Day" option. This is so that customers can pay for the invoice any time on that day (even at 23:59:00) and the service does not get suspended until the next day (at least 00:00:00 the next day). Would a "Same Day" option help you here? It could lead to services being suspended on the day the invoice is due, and depending on when your automation tasks run, before the customer has a chance to pay for it that day.

The CWP module removes the user's account on CWP when the service is canceled in Blesta. I don't recall whether that removes the website, but I imagine it would. Synching might be possible, but is not currently supported by the module. You can create a service in Blesta that is tied to an existing CWP account by adding a service in the admin UI, entering the domain, username, and password, and ensuring "Use Module" is unchecked when you create it.

Typically, when a service is canceled, it is deleted from the connected server (CWP in your case). The fact it was not is the reason you could simply change the status of the service in Blesta to get it working again. You would normally create a new service.

The error is likely caused by ioncube. Blesta is not ioncube-encoded to support php 7.3 yet. You will need to use a version of php >= 5.4 and <=7.2. We will be adding support for the new ioncube loaders that support php 7.3 in Blesta soon. Your server will also need to be configured to use those loaders if you want to run Blesta on php 7.3 at that time.

Is this a question? When you log in, you will be taken to the last page you were viewing when you were logged out, or the page you tried to view before you were asked to log in.

That shows transactions applied, but not any credits currently on the account. The invoice will change frequently if we show credits from the account on each invoice in the same currency.

The routes configuration can be updated to map to specific controllers/methods in the framework. The .htaccess can be updated to rewrite specific URLs. Either way will require some knowledge of regular expressions.

So you want a place on the invoice to list the total credit on the account in the invoice's currency?

You can create a rewrite rule in the .htaccess or you can update the URI routes in /config/routes.php for the order plugin

Just search by order number, or some other criteria?

Yes, upgrades from Blesta will not contain your customizations, so you should merge them in when you do a Blesta upgrade or they will be overwritten. This type of content (i.e. fields, links) are defined in the order templates. I highly recommend using a text editor search feature to find them. The link can be changed in the cart template (views/templates/wizard/cart.pdt). The signup form is defined in views/templates/standard/types/registration/signup.pdt for the dedicated registration form and views/templates/wizard/signup.pdt for the signup form for that order template type.

You're using the Wizard order template, so you can find the language under /plugins/order/views/templates/wizard/language/en_us/cart.php. I recommend searching the language files for the wording you're looking to change. Most text editors come with the option to search files.

There has not been many requests for that module over the past few years, which was originally mentioned in a feature request: https://www.blesta.com/forums/index.php?/topic/2187-domain-registrar-module-ventraip-wholesale/ It sounds like they are willing to work on creating a module for Blesta, as they did for WHMCS, but only if the demand is there to make it worth it. You might consider getting several people together that want that module and let them know there is significant interest.

If you move Blesta's installed location, you should update the paths under System > Settings > General. You may also need to re-issue your license so that it can be used in its new location.

When you "Run Cron Manually" from within Blesta, it does not use the server-configured cron job. Instead, Blesta processes the automation tasks itself through the application. The cron command shown under Settings > System > Automation is only for display purposes; it has no effect on anything. Rather, you need to setup a cron job on your server, and that cron command is an educated guess by Blesta as to what command you need to provide when you setup that cron job. The path to php may differ depending on your server environment and configuration, as you've noticed above, which is why Blesta's displayed cron command is a suggestion based on what it can infer about the server environment it's installed on. The command set for your cron job is clearly not working. The cron job should run automatically every 5 minutes when setup correctly on the server. No, Blesta is not the problem here, so upgrading to any other version will not resolve the problem with your cron job not running. The cron job executed by the server runs in CLI mode. The command you listed is CLI command that essentially says to use php to run the index.php file and pass the parameter "cron". When you run the cron manually from within Blesta, you are processing the automation tasks from the web server over HTTP, not CLI. You want a cron job to be setup on the server to execute via CLI so that the server automatically runs Blesta's automation tasks at a set interval, every 5 minutes.

Every forum gets spam. You can already report posts as spam for moderators to look at, which many people have already done to help remove hundreds of spam posts from our forums. The moderators normally take care of them quickly. All you need to do is hover over the spam post with your mouse and click "Report post".

The options and dates are the line item descriptions. You can update them in the language files under /core/Pricing/Modifier/Type/Description/language/en_us/option.php The cart quantity is shown as apart of the order plugin, which you can update in /plugins/order/language/en_us/cart.php I'm not sure what you mean for option group and backups.

It depends on the module, the features it needs to support, and how quickly someone can work through the API documentation to build it. WHMCS modules cannot be converted to Blesta modules without a developer rebuilding it.

A cancellation date will be set on the service. When that date comes to pass, the service will be canceled in Blesta and in cPanel. You can remove that cancellation date and upgrade the service to another package (the $45/year one) after the $10 service is created and it will renew at that price. Alternatively, I believe you can set an override price on the service, but this is less flexible since it overrides the package price.

As mentioned in the docs, you should also set Configure::set("System.debug", true); If you don't have that, you may be running an old version of Blesta. Enabling that will show the error stack trace, which gives out more information. Once you have that, you can disable debugging.

There's an error with some data on his account that is expected to exist, but doesn't. The error isn't descriptive enough to determine where the cause originated from, but you can enable debugging in your config file and then encounter the error again to get more information, like the stack trace, which will help determine where the error is coming from, and then it can be investigated further.

Currently, you would probably want to configure a package for 1 year @ $10 and then check "Cancel at end of term". After the year, transition them to another package that is $45/year. We're working on separate renewal prices at the moment, so once that is released you will be able to accomplish this more naturally by setting up $10 for the first year that renews for $45 each year afterward.