Last night I wanted to print off a couple of pages.
I’m using Linux Mint 14 (Nadia) and a wireless HP Officejet J4680.
For some reason, the first page got stuck in the queue and refused to print. What was worse, I couldn’t cancel it. I tried all the usual rebooting but to no avail. The Preferences –> Printers showed the queue but the Stop button had no effect.
The solution, as always is simple.
Open http://localhost:631/jobs/ in your browser.
That’ll do the trick.
One of the more important jobs in running a WordPress site (or any site for that matter) is backing up.
There are two parts to this – the files and the database.
Not all files need to be backed up, as in the event of catastrophic failure, the core WordPress files can be restored using the standard installation. However the contents of the wp-contents folder are critical, as this is where the images, plugins etc are kept. Granted, plugins also can be restored using available files from the Web but restoring them from a backup can save a lot of time and effort.
I experimented with several plugins to do my backing up, but had to abandon all as they were unreliable, unworkable or very resource hungry. I had to find an alternative method, as the idea of connecting to several sites, and doing an FTP download plus doing a PhpMySQLAdmin dump each and every day was a non-runner.
I decided that Cron was my solution.
I set up a couple of small files – one to compress the contents of wp-content and the other to do a mysqldump.
Files –
/bin/tar –czf /usr/local/hosts/webspace/httpdocs/backups/backup-‘date +%d.%m.%y’ .tar.gz /usr/local/hosts/webspace/httpdocs/www/wp-content
Database –
/usr/bin/mysqldump –host=dbserver –user=dbusername –password=dbpassword databasename –quick > /usr/local/hosts/webspace/httpdocs/backups/backupdb-‘date +%d.%m.%y’ .sql
(need I point out that the paths, names and passwords are not the actual ones used?!)
I saved both files on the server and then set up a Cron Tab to run each file.
This worked perfectly on two of the sites I was testing on, but the third refused to work properly. The ‘mysqldump’ function threw up an empty file each time, despite the code being identical in structure across all three sites.
It took a while to find the problem, but I eventually solved it. It didn’t accept the password for the database as the password started with an ampersand ‘&’. I tried various methods, such as escaping the ampersand and inserting quotes around the password but each time it failed. In the end, I took the simple route – I set up an additional user for the database and gave that user a slightly simpler password. It worked!
I now have a series of sites set up and all are running smoothly. Because of the flexibility of Cron I could set the backups to run anywhere from once a minute to once a year. However I have chosen a more sensible option. The databases are backed up every night and the files are backed up every week. That should be sufficient?
My next job is to refine the Files backup to ignore all cached files, as they are very bulky and aren’t necessary for a restore anyway.
In my quest for efficiency I have been experimenting with CDN.
Content Delivery Network promises a lot in return for a simple setup. I decided to give it a try.
I signed up with CloudFlare, as they have a fair reputation and are free. Setuip was simple, as all I had to do was to give them the name of the site. I then pointed the site’s domain at their name-servers and sat back to watch results.
To test the effectiveness, I measured site load speed on three sites and the following are the results I obtained from the three –
| Domain name | Size | Load Time | Average Speed per KB |
| headrambles.com | 52.75 KB | 0.63 seconds | 0.01 seconds |
| apipeandakeyboard.com | 57.08 KB | 0.58 seconds | 0.01 seconds |
| smokingoutthetruth.com | 39.77 KB | 0.95 seconds | 0.02 seconds |
Of the three, this site is the fastest, and it is also the site that is registered with CloudFlare. However as the difference in speed is a matter of a few milliseconds, I doubt if I will bother setting up Smoking or Rambles.
On another note, I have also been playing around with caching. Having tried several caching plugins (one of which caused an almost total failure of the site) I settled back into WP Super Cache. I had heard that it conflicts with my theme, but having tested the site on both browser and mobile phone I could see no problems.
However one thing I did discover is that by playing around with the Advanced settings, I could gain an appreciable increase in speed. Using the default settings, Smoking loaded in around 3.41 seconds. Having tweaked Super Cache, that dropped to the 0.93 seconds as shown in the table above.
Now that is what I call an appreciable return.
On Friday, I installed a copy of Windows 7 on a new VirtualBox virtual PC.
Yesterday I set about installing software into Windows 7. In the course of the installation, I noticed that Windows was downloading updates, though for some reason it wouldn’t load the progress screen.
When I finished my installations I checked, and I was informed that all downloads were complete. I switched off Windows 7.
As expected, The power down produced that familiar screen – to the effect that Windows is installing updates and that I mustn’t power off or interrupt the process. Apparently there were 150 updates to be applied. That was at 4pm.
At 11:15pm the process finished and the virtual machine powered off.
Seven and a quarter hours to install software that is already downloaded? And during this time the machine was useless in that I couldn’t run anything on it or power it down? That has to be some kind of record?
And on the next power-up it still took a further ten minutes to “update the registry”.
Just in case anyone wonders why I hate Windows and love Linux………..
For some time now I have been running Better WP Security on several sites.
One of the many excellent features of this plugin is to alert on requests for non-existent files. Every 404 is listed along with date and IP address.
404 requests fall into three categories –
The last category is the one that interests me. The files that have been sought are for example, /signup.php, /register.php and /join.php. Other examples are presumably searches for known vulnerabilities in various plugins which I don’t even use.
I have been collecting the IP addresses of all the 404 logs and have added them to the Banned User lists within Better WP Security. Incidentally, the latter has a nice feature that whenever an IP is added to the list, it automatically sorts the list and removes duplicates.
One thing I noticed was that a very high percentage of IP addresses were allocated to the Fujian Provence of China. I have therefore added wild cards to my list to eliminate as many of their addresses as possible, particularly where a class of address frequently occurs.
I have uploaded a text file of these IP addresses if anyone is interested. It can be used to populate your own version of Better WP Security, your .htaccess file or any other plugin that bans visitors such as No Soup.