Tyson

I recommend making a list and backing up files from your Blesta installation that you have changed or added customizations to. Then before you upgrade in the future, you can compare your custom changes with the new Blesta files and then merge your customizations back into it.

I suspect everyone here is having trouble because of the error mentioned above: "Call to undefined method HtmlInvoicePdf::AliasNbPages()" at /path/to/blesta/components/invoice_templates/html_invoice/html_invoice_pdf.php line 152 I have not taken a look at that custom template, but most-likely you can simply comment out the offending line (i.e. line 152 of that file) to not make a call to "AliasNbPages". You can also contact the original author of the template to ask them to update it to support v4.4.0.

This will be updated in CORE-2941 for v4.4.1.

This will be fixed in CORE-2939 for v4.4.1.

Thanks for letting us know. This is a bug. To fix, you can do the following: Open the file /plugins/order/views/templates/ajax/javascript/order.js On line 47 of that file you'll find a section that reads: // Handle slider var slide_val = 0; $('#package_slider').slider({ tooltip: 'hide' }).on('slide', function(e) { var cur_val = $(this).slider('getValue'); if (slide_val != cur_val && !isNaN(cur_val)) { $(".package-block").removeClass("active"); $("#package_" + cur_val).addClass("active"); } }).on('slideStop', function(e) { var cur_val = $(this).slider('getValue'); if (slide_val != cur_val && !isNaN(cur_val)) { slide_val = cur_val; // Load config section fetchConfig(packages[cur_val].group_id, packages[cur_val].pricing_id, function() { // Animate to config section if (slide_val != 0) $('html,body').animate({scrollTop: $('#package-config').offset().top}, 'slow'); }); } }); Replace all of that text with the following instead: // Handle slider if ($('#package_slider').length) { var slide_val = 0; $('#package_slider').slider({ tooltip: 'hide' }).on('slide', function(e) { var cur_val = $(this).slider('getValue'); if (slide_val != cur_val && !isNaN(cur_val)) { $(".package-block").removeClass("active"); $("#package_" + cur_val).addClass("active"); } }).on('slideStop', function(e) { var cur_val = $(this).slider('getValue'); if (slide_val != cur_val && !isNaN(cur_val)) { slide_val = cur_val; // Load config section fetchConfig(packages[cur_val].group_id, packages[cur_val].pricing_id, function() { // Animate to config section if (slide_val != 0) $('html,body').animate({scrollTop: $('#package-config').offset().top}, 'slow'); }); } }); } Save the file and reload the AJAX template order

This is fixed in CORE-2911 for v4.4.1.

Thanks for the report. Where in the system are you observing tax displayed in the total as opposed to not in the total depending on your tax inclusive/exclusive setting?

You may want to contact the author of that module to get some help with it

I believe the GoCardless gateway with Blesta does the same thing that your current invoicing system does. The client will pay for an invoice and choose whether or not they want to setup a subscription or pay a single invoice one-time. Whether subscription payments or single payments are supported is dependent upon how you have the gateway configured in Blesta and whether the invoice being paid is recurring.

What version of Blesta are you using? You referenced "line 61 of ...Session.php" changes the php ini settings, but that is only on an old version of Blesta. You may need to upgrade.

Yes, the minimum php requirements are 5.4

Thanks, we'll take a look as apart of CORE-2911

Is there nothing on the page below what is shown in the screenshot? There is a section called "Client Information" that appears further down the page and gives you a button to checkout and pay. It is loaded via AJAX, so if it is missing there might be a JavaScript error on the page.

What does that mean? Can you provide an example and say what column(s) in the report is erroneous?

What do you mean that it doesn't calculate the addon prices for lines? What column(s) in the report is inaccurate? I'm not seeing an issue with the Date Closed being incorrect. The date in the report is converting the UTC date from the database into the company timezone and displaying it using the company's defined "Date Time Format". In my case, I am at UTC-7, so a closed invoice I have is stored in UTC at "2018-11-02 16:52:41" and displayed in the report as "Nov 02, 2018 9:52:41 AM", which is the accurate.

It's best practice to use the version of the extension that is provided with Blesta or a newer version if it is compatible.

CORE-2785 is currently an open issue.

You should stop using MyISAM tables and use InnoDB. MyISAM does not support transactions, which would be very useful, and is Blesta's expectation to preserve data integrity.

We'll take a look at the module and see what's going on.

The errors you get appear to be caused by the module options. Do you have a section called "Module Options" on the package? It should appear automatically when you select the module. It could be an error with the module, but you should check the module logs under Tools > Logs to see if there is a bad response from the API.

Looks like he was able to solve the problem after looking at the module log. Some browsers can translate them automatically, e.g. Chrome has an option to "Translate to English" when you right-click the page.

Which service dates are you referring to? A service's line item should contain the service date range if it is a recurring service, e.g. "My Service (Oct 1, 2018 - Nov 1, 2018)"

Do/did you have a pending transaction from GoCardless? GoCardless can take up to 5 days to process the payment, at which point the payment will go through and Blesta will be notified. So after those 5 days, the invoices in Blesta should be marked paid.

Creating a service without validating the service first sounds like a logical mistake. If your module does not need to validate the service you could have it always return true from it's validate method.

Yes, that's correct. You won't be able to submit files via the API; you essentially submit a reference to it. The files are expected to already exist in the server's temp directory (or whatever directory is set for 'tmp_name'), and then you provide details of that file (i.e. that reference) in the $files you submit via SupportManagerTickets::addReply. So, in order for you to attach a file to a ticket reply, you will first need to upload the file to the server separately.