I know SuiteCRM doesnāt guarantee installation on shared hosting or on all configuration, but I am pretty good with Linux and I have always been able to make SugarCRM work, so I thought I would give SuiteCRM a change. I performed a clean install on a 1and1 shared hosting site and everything went smoothly until I tried to send SMTP emails. I ran into this problem with SugarCRM and was able to change the $mail method to āsendmailā and everything worked fine. The SuiteCRM version seems to work slightly different.
There is a separate dedicated sendTestEmal function that I was able to change to sendmailā¦that works fine.
There is an outbound email function that is written differently than the test function and switching the method to sendmail did not fix the problem.
The result is that I have an installation that can send test emails but not the real thing. Can anyone help change over the phpmail method to sendmail?
there are issues with the email in version 7.9.x (you donāt say which version youāre usingā¦).
One of these problems was that the password didnāt get saved correctly in the account settings screen, so the test would work, but not the next attempts to send.
Donāt assume the solution is to change to sendmail. Weāre way past that pointā¦ that was a long time ago, in Sugar. You should simply focus on getting the PHPMailer problems sorted out in SuiteCRM. You might need to wait for the next release of SuiteCRM.
Meanwhile, you can try to find more in your logs to make sure itās a bug, and to understand which bug you need to be tracking.
Thanks for the heads upā¦ I read it was a password problem, but I was hoping I could get around it when I was able to get the test email working. I checked to make sure I didnāt have a self-signed SSL, checked it wasnāt autoTSL, so I figured it had to be the actual āemail bug.ā Itās a pretty big bug considering the goal of a CRM. I was using the last version of SugarCRM Community Edition, and I was dreading the change in case something like this happened. Oh, and for reference, itās SuiteCRM 7.9.6.
The Email module in 7.8.x is completely different from the one in 7.9.x. Most of the problems with the new module are not present in 7.8.x.
However, not all the problems were facing are related to the new module. There is a very hard to crack SMTP bug affecting everyone. It might be a bug with PHPMailer, the software that SuiteCRM uses; or it might be a bug with SuiteCRM itself (but I donāt think so). It could also be a problem in some email providers, since it doesnāt happen for all of them.
Thanks for the replyā¦ Iāve already debugged the mailer in 7.8.x and it is working fine. I wasnāt happy with the email template creation, so I am thinking about switching to another CRM. I also ran into the āundefinedā button problem, which seemed to be related to a .js file not loading, and it was something I had not seen before 7.8.x. Either way, the email marketing templates are the most important aspect of my CRM use, and I didnāt like the way SuiteCRM built theirs out. Is it different in 7.9.x?
Note that there are new versions out today, some email bugs have been fixed, both in 7.9.x and 7.8.x.
The templates use TinyMCE or direct HTML. I think there are a few additional options in 7.9.x regarding selection of templates editor, but I donāt think itās anything too fancy, not that big a change.
I donāt think I was using either of those email clients. I want to say it was Kaiczā¦or something like that. It didnāt accept pure HTML unless I added a predesigned element as the first thing in the email. I chose the header, but my ability to import HTML straight to the editor didnāt workā¦nothing saved.
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):