[RRowley]

I encourage you to use the master_2019.2 version to make sure you have the most current corrections as well as working with a version that more easily supported. That said, is there additional information about this error in the tmp/log/php.log file?

[RRowley]

Please be specific as to the items set and the values they were set to so I can replicate and test it.

[RRowley]

In the templates/default/cron/add.tpl file on line 114. Remove the “/” before the terminating “>” sign. So this:
<input type=”hidden” name=”domain_id” value={if isset($domain_id)}{$domain_id}{/if}/>
becomes this:
<input type=”hidden” name=”domain_id” value={if isset($domain_id)}{$domain_id}{/if}>

[RRowley]

There is some database setting the is not allowing an empty string to work as the same as the numeric 0 default value for a field. The si_customers table default_invoice field is int type and has a default value of 0. The update command was sending in an empty string (”) when this field was not set. This caused an error to be thrown. This default works on my database but not yours which is why I think it is some DB setting that differs on you set up vs mine.

I updated the customer update screen to send a 0 in for this field. This change has been uploaded to the SI version github. The new SI version is 2019.2.11. You can copy the templates/default/customers/details.tpl file from github and replace the one on your install. See if that helps. If so, you should pull the entire update and replace what you have so the the version and other info gets updated also.

While this might fix the customer update, you might encounter a similar issue on other screens. So determining the database setting that lets mine work and yours not, will be the best all around solution. I’ll keep checking to see if I can find this.

[RRowley]

When you say “master release for php 5.2,” are you talking about a fearless359 version of SI or the original version of SI? The fearless359 master version has a version number of 2018.2.8_1 in the config/config.php file. If you are using the fearless359 master version, you should use php 5.6 as a minimum level.

If you can update to php 7.2 or higher, then you should consider upgrading to master_2019 or master_2019.2

[RRowley]

#3 above shows the error comes from a call of line 113 in the Inc/Claz/Email.php file. This does not match the current version of this source currently checked into github. Please download and install the current version of Fearless359 SI and test again. There was a specific change to the email security logic that was in version 2019.2.7.

If you have a gmail account, you might try routing through it. Here are the settings I use for testing sans username and password.

email.host = smtp.gmail.com
email.smtp_auth = true
email.smtpport = 465
email.secure = SSL

If the problem persists, excluding the username and password, send me the settings you have in custom.config.php for the email configuration.

[RRowley]

The fields would need to be present on the table list screens to be search items. There isn’t room for this. The way to do it would be to make a report for that purpose. You can do this by creating an extension.

[RRowley]

Check the email value settings in the config/custom.config.php file. Also might check the tmp/log/php.log file to see if there is more detail on the error.

One thing I had to do was enclose the password in single quotes (double will probably work). I think this was because I have special characters in my password.

[RRowley]

The numbering logic is complex. It keys off of the Invoice Preference setting for the invoice which in the preferences table, the record for that value specifies the Invoice Numbering Group to be used. This then ties back to records in the si_index table keyed by the constant node value of “invoice” and the sub_node value that comes from the Invoice Number Group. If you are confused, I don’t blame you.

To help, I uploaded changes for 2019.2.8 version that adds information to several screens and I updated the “How To …” topic for the “change the invoice number starting point” topic accessed from the menu on the left.

You need to have things set up correctly to get numbering to work. If you want any type of invoice to use that same numbering sequence, in the Inv Prefs records (under the Settings tab) should have the Invoice numbering group set to Invoice. Then they all use the same record.

[RRowley]

Uploaded fix that adds the email secure value to the encryption parameter for Swift Mailer transport object. I verified that this logic works with three different SMTP servers. So hopefully the email issue is resolved.

[RRowley]

Oops. That should be $config->email->secure (not encryption).

[RRowley]

The change to make is to use $config->email->encryption. I’ve been working with this set but haven’t finished testing. I’m still having some issues that I’m trying to track down.

[RRowley]

The previous logic used Zend email logic. The version of Zend used by SI is no longer supported (Framework 1). So I have been trying to replace its functionality with other packages maintained via composer. Swiftmailer has good reviews and was easy to implement.

[RRowley]

The issue is that the value of the “id” field in the si_index table is not set correctly. It should be set to the value of the “index_id” of the last si_invoice record. The si_index table “id” plus 1 will be the value assigned to the next invoice.

[RRowley]

I’ve been working with new ways to handle mail but have not had much success. All I can say for now is make sure your email parameters including the smtp_auth option are properly set.

[Author]

Posts