Tyson

You would need to update some files. An example is provided in a different thread that only allows email as the username. You would do the opposite and only allow the username to be specified.

I believe the CKEditor JavaScript file must also be set to the view in the appropriate controller, e.g.
$this->Javascript->setFile('ckeditor/ckeditor.js', 'head', VENDORWEBDIR);  

I believe the CKEditor JavaScript file must also be set to the view in the appropriate controller, e.g.
$this->Javascript->setFile('ckeditor/ckeditor.js', 'head', VENDORWEBDIR);  

I appreciate the report and we are aware of concerns some have expressed (such as here) with the tax types in some regions. The difference between inclusive/exclusive on the tax rules is purely visual--the tax is shown in the total (inclusive) or it is not (exclusive). We will need to include additional support in the future for package pricing to support "price includes tax" or "price excludes tax", as you are alluding to.

I appreciate the report and we are aware of concerns some have expressed (such as here) with the tax types in some regions. The difference between inclusive/exclusive on the tax rules is purely visual--the tax is shown in the total (inclusive) or it is not (exclusive). We will need to include additional support in the future for package pricing to support "price includes tax" or "price excludes tax", as you are alluding to.

I reverted the database and edited config/blesta.php. Everything ran and once I updated the cron, everything is green and good. Thanks!!

Sounds like another table (i.e. system_events) exists, probably from a previous incomplete upgrade. I would recommend restoring the database backup from earlier, and then running the upgrade again. You'll want to make sure that you don't have either the service_invoices table or the system_events table prior to upgrading.

Sounds like another table (i.e. system_events) exists, probably from a previous incomplete upgrade. I would recommend restoring the database backup from earlier, and then running the upgrade again. You'll want to make sure that you don't have either the service_invoices table or the system_events table prior to upgrading.

Thanks guys, detailed explanations help.

Just wanted to chime in here that the Blesta version 3-series (e.g. v3.6.0) will never support php 7+. It simply can not. There are backward incompatible changes introduced in php 7 that prevents Blesta v3.6 from being runnable on that version of php.
In order for Blesta to support php 7+, Blesta must be updated to resolve those backward incompatible php 7 changes, and in so doing has to introduce backward incompatible changes in itself. This means that in order to support php 7, an update to Blesta requires a major software release (i.e. moving from version 3.x to version 4 following semantic versioning standards). This is precisely what we did do by releasing Blesta v4.0, and with that version you can run php 5.4+ or php 7+ using the provided ioncube-encoded files for php 5, php 7, or php7.1+ respectively.
Ioncube itself does not support php 7+ with its php 5 encoded files, so that's why different encoded files must be used for your particular php version.

Just wanted to chime in here that the Blesta version 3-series (e.g. v3.6.0) will never support php 7+. It simply can not. There are backward incompatible changes introduced in php 7 that prevents Blesta v3.6 from being runnable on that version of php.
In order for Blesta to support php 7+, Blesta must be updated to resolve those backward incompatible php 7 changes, and in so doing has to introduce backward incompatible changes in itself. This means that in order to support php 7, an update to Blesta requires a major software release (i.e. moving from version 3.x to version 4 following semantic versioning standards). This is precisely what we did do by releasing Blesta v4.0, and with that version you can run php 5.4+ or php 7+ using the provided ioncube-encoded files for php 5, php 7, or php7.1+ respectively.
Ioncube itself does not support php 7+ with its php 5 encoded files, so that's why different encoded files must be used for your particular php version.

Just wanted to chime in here that the Blesta version 3-series (e.g. v3.6.0) will never support php 7+. It simply can not. There are backward incompatible changes introduced in php 7 that prevents Blesta v3.6 from being runnable on that version of php.
In order for Blesta to support php 7+, Blesta must be updated to resolve those backward incompatible php 7 changes, and in so doing has to introduce backward incompatible changes in itself. This means that in order to support php 7, an update to Blesta requires a major software release (i.e. moving from version 3.x to version 4 following semantic versioning standards). This is precisely what we did do by releasing Blesta v4.0, and with that version you can run php 5.4+ or php 7+ using the provided ioncube-encoded files for php 5, php 7, or php7.1+ respectively.
Ioncube itself does not support php 7+ with its php 5 encoded files, so that's why different encoded files must be used for your particular php version.

Just wanted to chime in here that the Blesta version 3-series (e.g. v3.6.0) will never support php 7+. It simply can not. There are backward incompatible changes introduced in php 7 that prevents Blesta v3.6 from being runnable on that version of php.
In order for Blesta to support php 7+, Blesta must be updated to resolve those backward incompatible php 7 changes, and in so doing has to introduce backward incompatible changes in itself. This means that in order to support php 7, an update to Blesta requires a major software release (i.e. moving from version 3.x to version 4 following semantic versioning standards). This is precisely what we did do by releasing Blesta v4.0, and with that version you can run php 5.4+ or php 7+ using the provided ioncube-encoded files for php 5, php 7, or php7.1+ respectively.
Ioncube itself does not support php 7+ with its php 5 encoded files, so that's why different encoded files must be used for your particular php version.

I don't encounter that particular error, but it looks like a simple fix nonetheless. CORE-2812

Thanks. This is fixed in CORE-2813 for v4.4.0.
In the interim, you can patch this yourself by updating /components/reports/tax_liability/tax_liability.php
Find the following line:
'invoices.subtotal', 'invoices.currency', 'invoices.date_closed', Replace it with:
'invoices.id', 'invoices.subtotal', 'invoices.currency', 'invoices.date_closed',  

I don't encounter that particular error, but it looks like a simple fix nonetheless. CORE-2812

That will be fixed in v4.4.
You may have a misconfigured add-on service, or the client may be intentionally submitting bad input, which causes that error.

php 7.1 added an error notice when calling tempnam in which it falls back to using the system's temporary directory. That will be displayed if error reporting is enabled.
 
This is a new requirement added in php 7.2. A simple fix can be added to that module template to resolve that issue, which should be in the next version.

You added the product to the Universal Module, from the administration area goto Settings->Modules and click manage on the Universal Module.

i will try it later , thank for the info .

The event listeners will fallback to the default location of the core observers if you do not specific your own callback when registering the event.
Don't use the Events component, it has been deprecated and will be removed. Use \Blesta\Core\Util\Events\* as described in the documentation. Also take a look at the README under /blesta/core/Util/Events/ on the file system.

php 7.1 added an error notice when calling tempnam in which it falls back to using the system's temporary directory. That will be displayed if error reporting is enabled.
 
This is a new requirement added in php 7.2. A simple fix can be added to that module template to resolve that issue, which should be in the next version.

I would suggest uninstalling and reinstalling the Billing Overview plugin.

Thank you for providing additional information to help us duplicate the issue.
I'm not sure exactly why the package option was created without a value set, however, you should be able to delete that package option from the system and create another one instead.
I did encounter the error, as you described, when the "min" quantity is left blank. We will look into fixing that soon in CORE-2804.

Thank you for providing additional information to help us duplicate the issue.
I'm not sure exactly why the package option was created without a value set, however, you should be able to delete that package option from the system and create another one instead.
I did encounter the error, as you described, when the "min" quantity is left blank. We will look into fixing that soon in CORE-2804.