Cody

There could be multiple cron tasks configured to run the same script at the same time, or you could have multiple cron daemons running.

I would suggest sending mail out via SMTP instead of PHP. If the problem persists then it's likely an issue with cron being configured incorrectly on your system. You may have more than one instance of the cron daemon running on your server.

You could try upgrading to 3.0.7.

The answer to your question is unequivocally no. But like I said, you can accomplish the same thing using conditional logic placed in the structure.pdt file similar to what I showed.

Sounds like it could be an issue with an older version of the migrator. Did you use the migrator included in the 3.1.0-b1 installation, or the one downloaded from the forums? You should use the one included with 3.1.0-b1.

You have to use conditional logic within the structure.pdt file as in my example. If you receive a blank page it's probably due to a syntax error.

Moved to feature requests.

Update /app/views/clients/default/structure.pdt and use PHP to only show that nav if the GET parameter template is not "custom". Setting it to custom will then hide the nav. <?php if ($this->Html->ifSet($logged_in) && $this->Html->ifSet($_GET['template']) != "custom") { ?> <section class="outer_nav"> <section class="layout"> .... <?php } ?>

You won't find queries, per se, as they're all built programmatically. Nevertheless, queries pulled from WHMCS are in /plugins/import_manager/components/migrators/whmcs/5.2/models/. I'm not sure studying them would be of much use as those don't do much in terms of data translation. That's all handled by the migrator (/plugins/import_manager/components/migrators/whmcs/whmcs_migrator.php).

If you did that you could only use the second route. You'd have to delete the first. Regardless, I would advise against it since it could cause conflicts with the default order plugin routes.

See my post on Short Order Routes.

Some users have requested shorter URIs for order landing pages. Here are a couple routes you can add to the bottom of your /config/routes.php file to take advantage of shorter URIs: Router::route("^order/configure/(.+)", "/order/main/configure/$1"); Router::route("^order/id/(.+)", "/order/main/index/$1"); Using the above routes you can link users to: /order/id/ORDER_FORM_LABEL/ /order/configure/ORDER_FORM_LABEL/?group_id=1&pricing_id=1 Replace the bold items with the correct values for your setup.

CORE-948 has been fixed for 3.0.8 and 3.1.0-b2.

CORE-964 has been fixed for 3.0.8 and 3.1.0-b2.

There's a couple tasks slated for 3.2 related to custom interfaces, one is: CORE-961 - Add ability to select view for client interface per company. This would allow you to clone an existing set of views, customize them, then choose which company to render the customizations for.

We simply don't recommend direct SQL queries because they bypass the application layer which enforces rules on the data. While the database structure is designed to prevent anomalies, it can't prevent logical errors. That said, if you're diligent and aware of the potential issues I see no problem with it. With regard to support for direct querying, we don't publish documentation on the schema so there's not much we can do there aside from explaining the relation between tables (which is more or less self-explanatory). I really know nothing of Freeside, but to give you a rough idea the WHMCS migrator took ~60 hours start to finish (our rate is $95/hr). Your Freeside migrator may not be as complex, or may not need to be as complete.

If you have existing subscriptions set up they may be using a different business email address than the one configured in Blesta. Ensure that the business email address matches. You can also update your settings in PayPal to set your default business email address to the one that you configured in Blesta. This will ensure that all subscriptions sent to Blesta have the correct address. Check to ensure that the client is configured to accept email delivery for their invoices on the client profile page. If they are set to Email, verify that your email settings are correct.

Blesta will not cancel the subscription when the service is cancelled. Blesta ships with PayPal Payments Standard. This API does not support cancelling or modifying subscriptions. Only PayPal Express Checkout supports this option. Feel free to make a Feature Request if you want PayPal Express Checkout.

The variables sent in the POST or email through the universal module for provisioning services are those that are configured for the universal product. See Service Options.

If your taxes change each year all you have to do is update them on the 1st of the year (or whatever date they change). I could see it might be useful to create the tax rules in advance and have them automatically updated on the 1st of the year. In which case a plugin would be a good solution for people that need that. Once an invoice is created the tax rules that exist at that moment are applied to it and never change unless the invoice is updated.

Yes. I'm not sure there would be much purpose in an import that didn't import transactions and invoices.

Use the API. Specifically Transactions::add(). No need to apply the transactions explicitly as that will be done through the cron automatically when needed. Yes, using the API linked above. Blesta will automatically apply the credit as necessary. It sounds like you could use the existing "in house credit" transaction type, so no reason to create a new transaction type. Just set type to other, and type_id to the ID value of the in_house_credit transaction type (as returned by Transactions::getTypes()). If you really wanted a different transaction type made special for this purpose, you'd use Transactions::addType() to add it, then specify that ID as the type_id instead when adding the transaction.

No, the clients.id_value field is for display purposes only.

The issue you're experiencing has nothing to do with the way the cron executes, but rather the code that it executes. Not all cron tasks run all the time, so manually running the cron does not guarantee every task will be executed. In fact, if you've scheduled a task to execute the cron at every 5 minutes, running it manually will generally do nothing. Check your PHP error logs for the rest of the error. Generally you'll see something like: The file that's causing the error is the most important piece of the puzzle. Without it, the best advice I could give would be to re-upload all Blesta installation files (backing up your existing files first, of course).

My guess is the file (which is not mentioned in the error you pasted) was not fully uploaded or is corrupt, or you've got some custom code (not shipped with Blesta) that is buggy.