-Chris

In fact the are in place in the subsequent version of the script here:
http://www.thecodecave.com/downloads/EasyWPUpdate.txt

The latest version of this script will always be reachable from:
http://www.thecodecave.com/EasyWPUpdate

(That said I haven’t updated it in a year and a half and really should now that I’ve been living in unix for all that time…)

Thanks for your work on this script. I know this article is dusty, but here’s a few suggestions. First, explicitely define the shell you’re calling, e.g. BASH:

#!/bin/bash

…That will solve problems for people who use unusual shells like FISH or whatever. Next, please make it UTF-8! That will solve a lot of syntax problems across international borders. Finally, some Wordpress updates require a DB update too, not just files. This can accomplished by adding a parallel set of site variables, for example:

BlogURLs[1]=”http://somesite.whatever”
BlogURLs[2]=”https://anothersite.someplace/blog”
“”

…then add another loop to touch the update page(s) with wget (or curl, telnet, etc.):

for CurURLs in “${BlogURLs[@]}”
do
echo “Updating database for: $CurURLs”
# Touch the upgrade script to trigger a DB update if necessary
wget -q -O - $CurURLs/wp-admin/upgrade.php?step=1 > /dev/null
echo “$CurURLs database update complete”
done

All the best,
-Chris

haha gotta love Windows……

• If you provide any sort of backup, then you should also provide a way to restore.
• A nice-to-have would be the ability to CREATE NEW WordPress-installs. For this of course the script needs to create new databases and users and needs to have SQL-admin priviliges
• Send emails to the individual blog owners that their WP has been upgraded and that they need to finish the WP-side of the upgrade…
  … or - if possible - let your script finish the update itself.
• Check permissions in all target dir’s first
• Log upgrade process to syslog
• Set proper permissions after install (fixes errors of previous installs)

Can’t think of anything more right now.

I’d use #!/bin/sh unless I knew for sure I could use something else.

Or do I specify #!/bin/sh and assume that any linux sys admin will override it?

What is the more correct thing to do?

I could write it for bash and get more features, but is that then going to limit the servers? Does every server have bash?

Programming is like putting a puzzle together, you know the final picture that you want, But different companies cut the pieces in different shapes. With each new language you learn, you just have to recognise how the shapes fit together to make the same picture. But choosing which shebang to use based upon its adoption rate in the *nix world doesn’t fit into that analogy.

Any suggestions?