I installed an instance of SuiteCRM for my club to use as a management platform, and we’ve been using it since 2017. This instance has survived multiple upgrades, server migrations, physical server relocations, and the problems related with having a CRM running for nearly a decade. Our club treasurer uses the Email Compose module to send messages to our members, and he recently encountered a problem which he reported to me. After working through the problem and resolving it, I wanted to share this information in case it might help someone else with the same, or a similar, problem.
For several weeks, attempting to send an email from the CRM’s email compose module fails. After clicking send, the status dialog (a JS alert dialog) appears with spinning dots which spin indefinitely. Normal behavior is for them to spin for a moment and then display whether email sending failed or succeeded. There were no errors related to this abnormal behavior recorded in the suitecrm.log, the suitecrm error log, or any other log file on the system.
Since there were no errors being recorded, I attempted to upgrade SuiteCRM to the latest version first before further troubleshooting or asking for assistance. At this time, the SuiteCRM version running was 7.14.2 (still in the 7.X tree, not 8.X) and there was an upgrade available for 7.14.6. After downloading the upgrade package, I attempted the standard upgrade procedure through the web. Unfortunately, this was not successful. After passing the initial pre-upgrade tests, upon committing the upgrade, the CRM just displayed a blank white page (index.php?module=UpgradeWizard&action=index&step=4&additional_step=true). Attempting to go to any other CRM page presented the same blank white page. Again, no errors were recorded in any of the log files.
After reverting the VM to the latest snapshot, which would be a recurring operation during this process, I started reading some semi-relevant articles online and attempting some other things. I found that there was a CLI upgrade tool which was recently made available in SuiteCRM. Unfortunately, after attempting the CLI upgrade process, it also failed. However, this time, it reported a vague error: Database Failure. This seemed odd, since the suitecrm database was clearly operational. I was able to login to the CRM, run reports, and do everything except send email or, apparently, upgrade the CRM version.
Thinking that there may be some sort of odd compatibility between the SuiteCRM version running and the MariaDB version running (10.3), I upgraded MariaDB to 10.11.6. This did not resolve any of the problems. I then applied upgrades for all available system packages, to no avail. One post (Upgrade wizard the screen is blank) stated that this was the result of incorrect permissions being applied to the SuiteCRM files and directories. I eliminated that possibility by issuing the following commands from the CRM’s root directory:
chown -R www-data:www-data .
chmod -R 755 .
chmod -R 775 cache custom modules themes data upload
Once again, none of this resolved the problem.
Another article I encountered recommended using the Quick Repair and Rebuild function in the SuiteCRM Admin Panel.
I tried that and the Diagnostic module earlier, but I wasn’t clear on what the Quick Repair and Rebuild process did. All I could remember was that the Diagnostic module just stayed at 0% and didn’t progress at all. So, I decided to try the Quick Repair and Rebuild process again. This process ran seemingly successfully until some database operations towards the end of the process. At this point it threw an error: Database Failure. This error was similar to the error received during the CLI upgrade attempt; however, despite the vague error, it did produce a database query which it recommended running manually using a DB management application:
ALTER TABLE emails_text ADD COLUMN `email_id` CHAR(36) NULL, ADD COLUMN `from_addr` VARCHAR(250) NULL, ADD COLUMN `reply_to_addr` VARCHAR(250) NULL, ADD COLUMN `to_addrs` TEXT NULL, ADD COLUMN `cc_addrs` TEXT NULL, ADD COLUMN `bcc_addrs` TEXT NULL, ADD COLUMN `description` LONGTEXT NULL, ADD COLUMN `description_html` LONGTEXT NULL, ADD COLUMN `raw_source` LONGTEXT NULL, ADD COLUMN `deleted` BOOL DEFAULT '0' NULL, ADD INDEX emails_textfromaddr (from_addr);
Additional, erroneous spaces present in the original have been removed.
This query acts on the emails_text table, so I decided to view the contents of that table. When I attempted to do so using SQLyog, it reported that the emails_text table had crashed and needed to be repaired. Knowing that, I went back to the CLI and issued this command to repair the table (and any other crashed tables):
mysqlcheck -u root -p --repair --all-databases
Once that command completed, I went back to the Email Compose module and attempted to send a test email. This time the test was successful.
I went back to SQLyog to view the contents of the emails_text table and I realized that its name is quite literal. The contents of any email sent from the CRM is stored in this table. So, it makes sense that if the table isn’t accessible, the email sending function in Email Compose wouldn’t work. However, I would have expected it to either time out or throw some sort of error.
Presumably, the upgrade process will also work now, but I have not attempted that yet.
Suggestions for SuiteCRM Developers and Maintainers
As mentioned earlier, it would be helpful if the email sending function would throw an error if it’s unable to successfully insert a record into the emails_text table. Secondarily, a timeout value would be beneficial.
I think it would also be helpful if there were a record in the suitecrm.log file, or another log file, when the email sending function fails or there is any error encountered when SuiteCRM interacts with a database table. I do find it useful that queries are logged in the suitecrm.log file at the INFO logging level, but (purely based on my own log files) this seems to only be true for SELECT queries and not other query types. Logging INSERT and UPDATE queries would be great at the INFO logging level, and recording errors related to these statements would also be great.
I’m curious why the Diagnostic function just froze at 0% and didn’t produce any results. If there were a problem with any database tables, that’s one of the places I’d expect to find evidence of that. It seems like the Diagnostic function would identify and report any crashed tables.
Similarly, the Quick Repair and Rebuild function should also identify crashed tables and attempt to repair them.
Perhaps some of this has been addressed in version 8.
I just haven’t had a chance to try it yet.