Manually Upgrading WordPress

  1. Get the latest WordPress tar.gz file.
  2. Unpack it on your computer
  3. Deactivate plugins on your wordpress site.
  4. Using filezilla, rename the old wp-includes and wp-admin directories on your web host.
  5. Using filezilla, upload the new wp-includes and wp-admin directories to your web host, in place of the previously renamed directories.
  6. Upload the individual files from the new wp-content folder to your existing wp-content folder, overwriting existing files. Do NOT delete your existing wp-content folder. Do NOT delete any files or folders in your existing wp-content directory (except for the one being overwritten by new files).
  7. Upload all new loose files from the root directory of the new version to your existing wordpress root directory.
  8. Reconnect to admin page.  If a database update is required it’ll automatically notify you.
  9. Reactivate all plugins.
  10. Any problems, restore easyspace backups from control panel.

nohup and disown your long running jobs

Ever started a job and thought “this is running on a bit longer than I expected”, then wondered whats going to happen when you go home and come back in to work tomorrow morning to find your remote session gone, which leaves you wondering “did that job complete?”.

Mmm, me too, which is where the nohup or disown commands come in.  nohup (no hangup) is a well known job control utility which will prevent a process from reacting to the hangup signal when a shell is disconnected.  Usually you’d preceed your actual command with it, e.g.

nohup rsync -auvc /Source/* /Destination/

but if your command is already running, you’re left wishing you’d nohup‘d it to start with – unless you’re running Solaris or AIX in which case the nohup command has a convenient -p switch to specify the process id (use ps -ef | grep rsync to obtain the PID of that long running data migration process, then nohup -p 9675 (or whatever the PID is of your running job).

If you’re not running Solaris or AIX, then pray you started the command in the bash shell (Linux default shell so more likely than not).  If you did, then you can


to pause the current job running in the foreground, then use the


command to determine its job number (most likely 1 if there’s no other sysadmins running backgrounded jobs), then background the process with

bg 1 

then finally

disown %1

to disconnect the process from the current shell.  Running


again will show that your job is no longer in the list, but

ps -ef

will reveal that it is in fact still running.

Your shell can now be closed without the fear of your running job being killed with it.  Yay.