[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.

[RRowley]

What is the version number and date for you installation?

Also, show the complete error from the error log. It will state with a display of the SQL statement that was being executed followed by the debug backtrace of the call stack,

[RRowley]

Don’t ask me why, but there are several places where you need to change the language. The setting in custom.config.php controls the default locale that affects formatting of currency and other data fields.

You also need to change the language in the Settings -> SI Defaults which will change the language for most everything else.

Then there are language settings in the Settings -> Inv Pregs for each invoice type, etc.

When the changes are made, you should have the language changed across the board. If then you see values not translated, it is likely that that info in the lang/nl_NL/lang.php file has not been translated or is missing. If you fix this, it would be helpful if you could send me the updated file to put in the library.

Note that the way the lang files work, is that if wording is in the specified lang file, it is used. If not, the wording in the default lang file (lang/en_US/lang.php) is used.

For example, the $LANG[‘save_inventory_failure’] text exists in the lang/nl_NL/lang.php file but has not been translated. But the $LANG[‘help_company_logo’] text only exists in the lang/en_US/lang.php file, so it is used.

To fix this, you would simple translate the $LANG[‘save_inventory_failure’] text in the lang/nl_NL/lang.php file but need to copy the $LANG[‘help_company_logo’] message to the lang/nl_NL/lang.php file and then translate it. Doing this and providing me with the updated file, I can include it in the library so your changes are lost in future updates and will benefit others that want to use this file.

Note that the info in the lang.php file is alphabetized by the $LANG index value (which must remain as english for the code to work).

• This reply was modified 5 years, 6 months ago by fearless359.
• This reply was modified 5 years, 6 months ago by fearless359.

[RRowley]

I’m not sure what your problem is. I assume you are NOT using the free hosting service on byethost as it has limitations on email.

Although difficult to find, I did locate the email setup instructions for premium host user on byethost. It is consistent with what you have. However, the same documentation only shows PHP versions up to 5.6x. You are definitely on 7.2x. So it is possible that the knowledge base doc is out of date and there is another email setup option that you can use; possibly using TLS.

I suggest you talk with your web host support team. They might be able to look at their logs and see why your connection is timing out.

Other than that, I’m at a loss as to why you are having an issue.

[RRowley]

Have you verified the email settings in your config/custom.config.php file? Below is an example of what needs to be set. Your settings will likely vary and should be provided by your email provider.

email.host = <myemailhostname>
email.smtp_auth = true
email.username = <myusername>
email.password = ‘<mypassword>‘
email.smtpport = 26
email.secure = TLS
email.ack = false
email.use_local_sendmail = false

• This reply was modified 5 years, 6 months ago by RRowley.

[Author]

Posts