Okayā¦letās give this another shot. I appreciate your help. Here is my list of things that are going wrong. Maybe you can help.
Iām getting the ādefinedā error on a number of dialogue boxes. I have changed my permissions and done a rebuild. The problem seems to be with the .htaccess file which I cannot rebuild through the UI. When I try to rebuild it the system doesnāt confirm it has been rebuilt.
Iām not really sure how to change the email editor. I vaguely remember seeing the option, but I really canāt use Moziak to do emails. Where is the option to change editors?
The DB.versions table was not created during installation. I donāt think it is a big dealā¦itās just a little weird to always see that error in the log. I would backtrack through the installation script to see if it was left out, but it seems like a lot of effort for a table that appears to be tracking what version of the software I am using.
4.The recurring time zone error in the log is also annoying. Is there any way to get rid of it?
About the email editor choice: in v.7.9.x, click your user name at the top-right, or open that menu and select profile. Scroll to the bottom.
Apart from that: your installation is clearly not correct yet. Multiple undefined errors usually mean problems with ownership and/or permissions. Sometimes these issues are tricky to really fix, so we might need to go into more detail here.
Then there is the issue of the cron jobs, another important part of the set up. This normally uses a different php.ini so your timezone errors could be coming from there. You really need to fix that error, it is a FATAL error, itās stopping PHP on its tracks and breaking things. Check the part of this recent thread that deals with php.ini, youāll find instructions there: https://suitecrm.com/forum/suitecrm-7-0-discussion/16248-email-contact-search-issue
Also, the cron jobs need to run under the same user as the SuiteCRM app, otherwise they will access files and leave them with bad permissions. This might explain cases of degrading permissions (was working fine, then broke again).
I ended up staying on v7.8.x, the emailer was easier to debug. Iām found a workaround for what I was trying to do in email. I started editing templates via Template Section Line. Are you familiar with how that works? Itās probably the best solution to what I am trying to do.
Regarding my time zone error - it may be showing the log as a fatal error, but my cronjob is performing all of the other tasks as scheduled so I canāt really say Iām all that worried about it. Iām looking for the best version of PHP to run the cron job. So you have a suggestion? Right now Iām running php7-cli but I can run any version.
I have SSH accessā¦
Iāll probably do some more debugging later. Iāll let you know how it goes.
You need to fix all FATAL errors, they always means some program is stopping abruptly, you donāt know how much damage/incoherence that might cause. If you allow yourself to run a system with regular FATAL errors, youāre inviting random problems.
Itās pretty easy to fix that Timezone error, all it takes is a simple setting in the correct php.ini.
I copied a local php.ini file to the root folder and switched the timezoneā¦the error still appears in the log. When checking the info.php file in diagnostics the timezone appears to be correct. Thoughts?
the cron jobs are probably using a different php.ini (for CLI) and they are probably generating that timezone error. If you see the error every minute, or at a regular interval corresponding to a specific Scheduler job, that should be it.
The command didnāt produce an output via the terminal. I didnāt receive an error, but I didnāt receive an output either. Iām getting the timezone error at regular intervals, so I assume youāre right about the error being associated with the cronjob. Iām going to run the cronjob using a different version of PHP and see if that helps. Iām going to wait an hour and run the diagnostic process again.
do you get a long listing with the entire PHP config? If so, then the absence of the output with grep simply means it (timezone parameter) is not set.
To set it, normally you add it to the php.ini of the CLI (which is a different file from the php.ini of the Web server). If youāre hosting doesnāt facilitate this, you can try other ways.
This is an attempt to pass that setting through the command-line when calling cron (I donāt know if it works):
When I try to send a test email, the resulting error is in three parts.
Tue Oct 31 20:51:40 2017 [15986][1][FATAL] SugarPHPMailer encountered an error: An outgoing mail server is not configured to send emails. Please configure an outgoing mail server or select an outgoing mail server for the mail account that you are using in Settings >> Mail Account.
Tue Oct 31 20:51:40 2017 [15986][1][FATAL] SugarPHPMailer encountered an error: SMTP connect() failed. https://github.com/PHPMailer/PHPMailer/wiki/Troubleshooting
Tue Oct 31 20:51:40 2017 [18577][-none-][FATAL] Retrieving record by id users:1 found Query Failed: SELECT users.* FROM users WHERE users.id = ā1ā AND users.deleted=0 LIMIT 0,1: MySQL error 2006: MySQL server has gone away
I have to assume these errors are all related based on the timestamp of their creation. Since the crontab edit did not fix this, do you want to try something else?
How did you set the timezone? Was it with the command-line parameter? Iād like to have a confirmation if that works.
The SMTP errors we can handle on the other thread.
The āSQL has gone awayā error is problematic, itās SQL crashing or timing out. I sure hope it disappears when you fix the SMTP problems, if not, youāll have to check your database setup, corruption, rebuild indexes, etc.
Sorry, I have to reopen this thread. As I resumed troubleshooting this morning I realized there was a typo in my crontab and the timezone error did not go away, the cronjob simply was not running. Upon resuming the cronjob, the error reappeared, so I loaded a new php.ini file in the root directory and changed some settings to confirm Suite was pulling the right information. I changed my max post size and the diagnostic tool picked up the change immediately, so I know it is seeing the correct PHP configuration. With that said, the time zone is set correctly in the file, but SuiteCRM is still throwing the error. I tried manually passing the timezone variable in the crontab, as you suggested, but that did not fix the error.