Changing or Fixing the Site URL for SuiteCRM

Recently I moved my SuiteCRM from a slow shared host over to a Digital Ocean droplet to speed things up. It worked very well, by the way. So fast, and probably I save 10 minutes per day just not waiting for server, haha.

Anyways, everything went pretty well except one thing: the emails that were sent out from the Workflow module now all had the wrong, old urls so when you click the links it takes you to the old server (big problem).

(Be sure to read to the bottom of this post to see one humourous part of the problem….)

When emails go out from suitecrm (ie. from workflow emails) you may have embedded the $url option into the email template. This is super useful, of course, because when the email recipient clicks it, it takes them directly to suitecrm instance. If they are logged in, it will take them right to the exact record. Super useful.

However, if you move your server, or accidentally had something wrong with your server URL, it might be broken and taking you to the wrong place when you click.

To fix it, all you need to do is make sure the site_url variable in the config.php file is matching what it should be. This page from the suitecrm documentation is pretty good.

Here is a step by step example of updating an incorrect ‘wrongdomain.com’ to the correct ‘correctdomain.com’ using ubuntu terminal.

Step-by-Step Guide to Changing site_url

1. cd to your Suitecrm directory where all the files are
2. sudo nano config.php (probably you should back this file up first before messing…)
3. control + w (search feature) using nano and enter ‘site_url’ and enter. This should bring you to the line that looks like this:

'site_url' => 'https://wrongurl.com',

4. Change it to the correct URL of your new server name etc
5. Cntl + X and say yes to save changes.
6. Repair and Rebuild in Admin in SuiteCRM to clear cache stuff.
7. Hope it works??

Humourous Story and Solution that Fixed the Continual Wrong URLs

After changing the site_url entry as per above, when I ran a test workflow everything worked perfectly. As soon as I saved the entry, the email came out and the embedded $url was working perfectly and taking me to the new server. However, at 10am, when I had it set to run a big task, I would get all the emails for this one particular workflow with the WRONG URL! How could this be happening? I searched other config files, reached out to experienced developers, opened and edited many workflow entries and their emails to confirm it was normal, but every day the problem continued.

Guess what the problem was?
…drum roll…
… I had forgotten to DISABLE THE ORIGINAL SUITECRM INSTANCE on the original server!

So both servers were sending out the stuff – one with the old, wrong, URL (obviously).

After that, I just went into the old suitecrm instance, into the ‘scheduler’ part of ‘admin’ and changed the following scheduler items to ‘inactive’ which then (at least) stopped the old server from sending out old and confusing workflow emails:

• Process Workflow Tasks
• Run Report Generation Scheduled Tasks
• Run Email Reminder Notifications

Then I went into my new instance in the same place and confirmed everything looked good

Crontabbin’ It

I noticed and recalled that one must make sure the crontab stuff is set up properly in the server. It was listing this in my case:

In order to run SuiteCRM Schedulers, edit your web server user's crontab file with this command:
sudo crontab -e -u www-data
... and add the following line to the crontab file:
*    *    *    *    *     cd /var/www/html/suitecrm/crm; php -f cron.php > /dev/null 2>&1 

So, I took the advice of suitecrm and ran the command, and selected ‘nano’ when given option:

sudo crontab -e -u www-data

and then I entered their recommended entry (yours will likely be different):
* * * * * cd /var/www/html/suitecrm/crm; php -f cron.php > /dev/null 2>&1

Tip: when copying the command from suitecrm it grabs a bunch of blank space which I think shouldn’t be there so I remove it all so there is just one space between items above like this:

* * * * * cd /var/www/html/suitecrm/crm; php -f cron.php > /dev/null 2>&1

And then saved the file.

Not sure if I needed to but I restarted apache just in case with:

sudo systemctl restart apache2.service

Then I waited until the usual time to see if it would spit out the right stuff from the right server…

but still it did not work.

then finally (smart me…) I opened the suitecrm.log file and there was my answer. The user running it was my database user, not the user (www-data) recommended by the suitecrm scheduler page.

Then i went back to this great documentation post and thought.. hmm.. maybe I can simply add ‘correctdbuser’ to the allowable cron job user list… then revert to the recommended settings?

I did:
nano config.php to inspect this config file.

Did cntl + w to search for allowed_cron_users, and found it.
Realized that ‘correctdbuser’ was listed but ‘www-data’ user was not. This explains why it was failing to run the cron task…

This is what I found with ‘correctdbuser’ being the mysql user that is successfully working now with suitecrm and the one that migrated over to the new server with the database:

array (
0 => ‘apache’,
1 => ‘correctdbuser’
),

So, I simply added ‘www-data’ as a user to the array as follows:

array (
0 => ‘apache’,
1 => ‘correctdbuser’,
2 => ‘www-data’
),

TIP: don’t forget the little comma after the second entry!

And did a cntl + x to save the changes

Then I did the usual quick repair and rebuild in admin of SCRM

Then I did the usual apache restart, just because with sudo systemctl restart apache2.service

And things started working…

Dumb Stuff I did that you shouldn’t do

1. I accidentally copied the crontab entry from the old crm into the crontab entry on the new server. That was pretty dumb and cost me some pain
2. I didn’t start by checking the suitecrm.log file

Conclusions

I hope that some or all of this helps some or all of you…

Extra stuff to go with this journey

I also found that in config.php there is a ‘hostname’ entry which looks like this:

),
‘hide_subpanels’ => true,
‘history_max_viewed’ => 50,
‘host_name’ => ‘wrongdomain.com’,
‘imap_test’ => false,
‘import_max_execution_time’ => 3600,
‘import_max_records_per_file’ => 100,
‘import_max_records_total_limit’ => ”,
‘installer_locked’ => true,
‘jobs’ =>
array (

I can’t figure out what this block actually is but apperas to be related to email IMAP stuff so I updated it to ‘correctdomain.com’ for the host_name line to see if that helps.

I also did a quick Repair and Rebuild from within the Admin area to see if that helps.