Commands for Cron Jobs

I got totally lost the other day when I couldn’t get a cron job to work. Now, what path was that?

WordPress Database Backup is a plugin that I’d relied on in the past to keep a randomly backed up copy of a WordPress site. Unfortunately, that’s not a complete solution as the images or uploads folder, as well as any modified theme pages, won’t be saved during the database backup. Nor will the blog links! Keep an archive copy of everything you put on your website, so everything can be reconstructed in the case of a disaster or even a host switch. In case a website is made up of more than one database, you’d need a different backup solution than what a WordPress plugin can provide.

Use CRON jobs to automate the task of backing up all your hard work. It might take a while to figure things out, but once you do you’ll be secure in the knowledge that you did it and your data is safe.

At first I didn’t have the command part right for the cron job to work. After the time elements you need to indicate the path to sh, any flags (none used here), and the path to the shell script. In this case the command was –

/bin/sh /home/owner/backup/

where “owner” is the CPanel login name, and “backup” is an empty directory or folder that you create above the public_html directory. Some hosts will have a folder called “etc” already created for you. Check with your host!

In this case the /bin/sh directory was already created at the server level, in other words, I didn’t have to create it. The corresponding first line in the .sh file was –


Originally, the .sh file had an opening #!/bin/bash, but that didn’t work on this particular host.

The host tells me the script is running successfully, so I know the lack of output is my fault – somewhere. Checks the paths…found it! An error in the path for the configuration file lead to the script trying to run with default parameters, some of them blank. The script ran as far as it could so there was no error reported by the cron daemon to my email address. When the output is successful a log file is sent to that address.

When I finally got the paths straightened out, the backup files were zipped and in their proper places and an email log was sent to the proper address at the time the cron job was to run. It worked! Now I’ll go back and set up a couple of other cron jobs to back up other databases. I’ll use the same script, modified to back up different sets of databases on different schedules.

  • If you’re looking for a simple script to make one database backup and save that on your server, check out DaniWeb’s CRON job for backup.

Once you have your sites backed up automatically, you can do away with any backup plugins that you may have relied on in the past. When at all possible, automate the task of backing up a database. It’ll make your life easier!

Block Comment Spam on Older WordPress Posts

Here’s a spam blocking tip for ya!

If you get lots of comment spam and DO have the Akismet plugin installed and updated in your WordPress, check the dates of the posts that the spam-comments are being left on. Chances are high that much of the spam is left on older posts. I guess the spammers figured we wouldn’t notice?

Take a look at the Discussion settings from the WP main menu. Note under Other comment settings the third line down where you can fill in the number of days after which an article can’t be commented on.

Discussion Settings in WordPress
Discussion Settings in WordPress

Fill in some value less than 30 days and that will knock down the number of spam comments left on your blog. Don’t forget to scroll down the discussion settings page and hit the Save Changes button.

There is at least one alternative WordPress plugin (and there’s probably many more, but I haven’t needed to check for any) that was commented on in a positive way, called WP-Spam Free. Might be worth checking out.

Keep bloggin!

Enhanced by Zemanta