Tag: command line

Command Line WP
In my new job, there’s a lot of command line work to be done. DreamHost has a mess of scripts I’m getting my comfort with, but also they’ve got this cool thing implemented on a lot of their servers called wp-cli, and that’s what I’m going to talk about today.

wp-cli is a command line interface to do a lot of sneaky snazzy WP things. While most people are running towards the GUI world of pretty UI and clicks, some of us really like command lines because they’re fast. I mean, I wrote my own command line upgrader just because I wanted to (and was having PHP permissions woes at the time). Command line is just something server people are always going to like, much like people who love driving a stick-shift, or who want to hand-make their own dough for pies. We like to have that extra level on control.

Aside from being control freaks, however, we CLI jockeys are also insanely lazy. If we can get everything done without having to touch the mouse, or lift our hands from the keyboard, we’re happy. If we can automate things so that all the WordPress installs on a server are magically upgraded in one fell swoop, we’re ecstatic. We all dream of being that guy who walks into a room, presses three keys, and saves the day. (I’ve been that guy, but remember he comes at a cost. I’ve also been the guy who presses three keys and reboots the money trading servers in the middle of our busiest time. Read twice, press enter once.)

Where wp-cli takes off is in the speed you can perform basic tasks. Typing wp or wp help will get you a list of commands. If you try to run any command outside the WP folders, you’ll get a nice error message. Using Multisite, you have a cool advantage of installing a plugin once and updating it for all your sites. But in cases where you need to have things separated, wp-cli fills the void by letting you script updates. Imagine just writing a simple shell script to upgrade your plugins on all sites?

Some of you perked up. There are a lot of cases where you don’t want to run Multisite (separate users, special code, whatever), and updating multiple sites under those custom installs really can be a pill. wp core update can be easily scripted to run off a list of your installs, or to just trawl through your directories, look for WP, and update when it’s there.

Installing

If you want to install this just on your own account, the directions for installing are on the wp-cli page. But me, I wanted it on my server for all my accounts. Obviously my DreamHost server has it, but this site is still on LiquidWeb (for myriad reasons, one of which is the same as why I didn’t bank at the company where I worked, old habits).

Their directions are, via git, to install in ~/git/wp-cli, which I don’t want. I decided to put it in /usr/share/wp-cli/ and to do this I just su’d into my root account. Otherwise I could do it all prefacing with sudo, but I’m dangerous like this.

My first hurdle was the issues I’ve had on git before, simply put the damn thing times out. The fix was so stupidly simple, once I really read into how git works. All I had to do was tell it ‘Use https.’
```
git config --global url."https://".insteadOf git://
```
Suddenly my commands started working and I was able to run the install directions (modified a little):
```
git clone --recursive git://github.com/wp-cli/wp-cli.git /usr/share/wp-cli/
cd /usr/share/wp-cli/
utils/dev-build
```
This ran without a hitch. And any update for this, since I’m only ever using trunk, will be as easy as git pull now and then.

Now on my server, when I try to run certain commands I git this:
```
Fatal error: Out of memory (allocated 38797312) (tried to allocate 17 bytes) in /home/userID/public_html/wp-includes/widgets.php on line 635
```
Two important things to note.
1. This only happened on one of my accounts.
2. 37 Megs is a real weird amount of memory.
I happen to know I usually allocate 64M for my PHP processes, but even bumping this up to 128 didn’t change the fact that at 37M, everything crapped out. I happen to work with one of the leads on wp-cli, and Mike (aka GetSource) let me bounce ideas off him. He offered to help with any questions, but I learn best by doing, so once I sorted out the basics, and was still stumped, I appealed to his greater familiarity. By the time I logged off to clear my head and get dinner, we decided it had to be user permissions. After all, every account on the box used the same PHP instance. Every account had the same rights, etc. It had to be something funny about the profiles, which I’d buy since this server has some accounts that are 15 years old, and it’s the oldest one having the most issues.

When I picked it back up a day later, I learned something surprising. At first I could get this to run every time on a site that has bbPress, but then I discovered any time I ran a big search (like wp theme status on my multisite, which worked for all other commands), it would also fail. So clearly there’s a memory shenanigan running around here. I tested with and without APC, switched back and forth between PHP handlers (fCGI, suPHP, DSO), and I tried bumping the memory all the way to 128M. Nothing would get me past the weird 37M. In desperation, I changed my php Memory limit to -1. This means no limit. And now it failed on 32M. As I started testing various possibilities, I came across a moment where I set-faulted (this would be from APC cli, don’t use it) and finally grabbed Alex Rabe’s WP Memory Usage, which tells me I was using “Memory : 8.3 of 128 MByte” on the plugins page, so I know WP knows it can have 128M. This lead me down a path of ‘What PHP is CLI using?’ After digging around and verifying it was the same, I started looking at how I’d locked down my server.

This is where I started banging my head on my keyboard.

Shell Fork Bomb Protection is a cool thing, in that it stops people from running rough-shod over your server. Of course they way it does this is by restricting the processes you can run via shell. And wp-cli is, say it with me, shell. Once I turned it off, everything worked. I’m not sure if this is something I’d want to do for every server, but since I can count, on one hand, the number of people with access to mine, and I know their passwords are secure, I’m okay with it.
4 September, 2012
WordPress, DSO and Permissions
I run my server with PHP DSO.(For the differences between DSO and SuPHP, read DSO (mod_php) vs. CGI vs. suPHP vs. FastCGI) It lets me run APC, and I’ve always liked it. It does have some weird problems, mind you, like a tendency to upload files as nobody:nobody, and more importantly it means that you have to set your wp-content/uploads folder permissions to 777. Thankfully there’s a fix!

If you’re not good with command line, scared by shell, and terrified of chmod, you’ll need to find your friendly neighborhood sysadmin to help you out. It’s okay to not feel up to doing this, and it should go without saying that you should make a backup first!

To step back, someone’s going to ask “Why is 777 bad?” Unix permissions are complicated. Every file in UNIX has an owner user and an owner group, and most of the time they’re the same. Mine are ipstenu:ipstenu (which means owner ipstenu, group ipstenu). Now another account on this server, conrel, has conrel:conrel. The groups ipstenu and conrel are both in the same webmaster group, which gives them special permissions. It’s confusing to a lot of people that most webhosts use the same name for the user and the group, but it’s just what we do.

Now for every file, there are three types of ‘ownership’:
1. User ownership – i.e. the user ipstenu
2. Group ownership – i.e. the group ipstenu
3. No ownership – i.e. you who are reading my site
There are also three types of permission levels”
- read (r)
- modify/edit/write (w)
- execute/run (x)
This all works out so when you go in via unix shell and look at your files you see soemthing like this:
-rw-r--r-- 1 ipstenu ipstenu 203789 Oct 5 19:30 stevejobs.png

This means the owner (ipstenu) has rw permissions (which are read-write). The group (ipstenu) has r (read-only), and the world (i.e. everyone else) also has r (read-only). This is an image, no one needs to execute it (which would be an x).(The “1” before ipstenu is for the number of files. “203789” is the size of the file. “Oct 5 19:30” is the day/time I uploaded the file, and “stevejobs.png” is the name of the file.) These rwx letters correspond to numbers. r = 4, w = 2 and x = 1. So when you see ‘rwx’ that equals 7.(There are also options o (other), u (user), g (group) and a (all)… and s … but I’ll spare you that right now. Suffice to say, you can use what you’re comfortable with. I use the numbers most of the time.)

So why is 777 dangerous? 777 means ‘everyone has full access to this file.’ Yeah, that sounds dangerous! I don’t want that! The only person who should have full access is you! But DSO doesn’t like to upload files without 777 permissions. In part, this is WordPress’s fault, but really it’s an unholy combination of things. Alex King explains why it happens, and as of WordPress 2.8, you can fix this yourself.

Just override the default file permissions. It’s genius! I tossed this into my wp-config.php file and I was good to go!
```
define('FS_CHMOD_DIR', (0755 & ~ umask()));
define('FS_CHMOD_FILE', (0644 & ~ umask()));
```
No, the 0 in front is not a typo. 0755 is an octal value. Octal values must be prefixed with a 0 and are not delineated with single quotes (‘). It’s just how it works.

There is a catch, though. My uploads folder had been set to 777, which meant /wp-content/uploads/2011/10 (this month’s folder) was also 777, which totally invalidated my test. That’s easy enough to go back and fix permissions on your folders. I did it this way because I have some caching plugins that I do not want to screw around with:
```
find /home/foobar/public_html/wp-content/uploads -type d -perm 777 -print -exec chmod 755 {} \;

find /home/foobar/public_html/wp-content/themes -type d -perm 777 -print -exec chmod 755 {} \;

find /home/foobar/public_html/wp-content/plugins -type d -perm 777 -print -exec chmod 755 {} \;
```
That code says “Find all folders (-type d) and if they have permissions of 777, change them to 755.” There are more variations on that.(I got the code from NixCraft – Linux / UNIX: Change File Permissions Recursively ( conditional )) If you want to change files, it’s -type f and you’d want something like this:
```
find /home/foobar/public_html/wp-content/uploads -type f -perm 777 -print -exec chmod 644 {} \;
```
That will turn all your images back into permissions 644, presuming they were 777 to begin with. Mine were 755.

The last step I had was chowning the folder for uploads and 2011 to nobody:nobody. That was so on month end, I would be able to create folders (like uploads/2011/11 today) without any issues. The other folders, as they already existed, didn’t need the permissions changed. Honestly, I’m not sure if I needed to set the uploads folder to that. I didn’t set blogs.dir for my MultiSite install, and just did the files folder within, since it had created other folders correctly. It’s a hassle, unraveling years of ‘Did it wrong!’ and when you add in that we’re using different tool sets to upload files versus upgrade and all that … well. It works now.

I also kept the upgrade folder with permissions 777, since that just did not want to work any other way. It flat out refused to upgrade any plugins. I’ve yet to try upgrading WordPress itself with this setup, but I suppose I’ll find out soon.

And that’s it! It’s not 100% painless, and it’s much easier if you start out ‘doin’ it right’, but even after you’ve been doing it wrong for over 5 years, you can fix it.
7 November, 2011
Make An RSS Powered Email List
Sometimes the problems we have are insanely more complicated than they should be, because our heads get trapped in a space they shouldn’t be. For years, I used FeedBurner to manage my RSS feeds. Then I realized I didn’t care that much, I didn’t need to know who was accessing my feeds, and really the only benefit was that I could put ads in my feeds (which … no one clicked on anyway) and 12 people could subscribe via email. Well, with some research I found that I could put ads in my feeds with some WordPress functions (I’ve since removed them) and I could use Subscribe2 as a plugin to email when I had new posts. Don’t get me wrong, I really like Subscribe2 except I didn’t like the interface. It’s on the back end of WordPress. My site is a BuddyPress site. Everything is on the front end for my users, and I like it that way. It all looks ‘branded.’ The plugin dev was, fairly, under the idea of ‘Works how I want it.’ I thought about forking, but as I looked at the code, I thought that I really didn’t need WordPress to handle this. I needed a way to email an RSS feed to a mailing list. A proper, opt-in, stable, mailing list, that wouldn’t affect my blog while processing.

I found an answer that can be applied to any site, WordPress or not.

What?

The problem:
I have an RSS feed I want to be able to email to people who don’t like RSS, and I don’t want to use FeedBurner, MailChimp or any external process.

The solution:
- Setup a MailMan list for your emails and configure as needed
- Install and configure rss2email
- Setup a cron job
Why?

Why not use [this product]? When I presented this to people the first thing they said was ‘Just use FeedBurner!’ or ‘Use MailChimp!’ I get that I can use those third-party vendors, but I don’t want to. I like to self-host because then, if things go wrong, I have the ability to do something about it. This is also how I increase my IT toolkit. I have a need, I find a solution. Sometimes I write the code, and sometimes I just master a new tool.

Why Mailman? Mailman (or properly GNU Mailman) is installed on my server and while it may be old, the current stable version is 2.1.14, and that came out September 2010. It’s still updated, maintained and supported. And it works. I’m familiar with it, I’m comfortable with it, and there’s no reason not to. I did experiment with phpList, which claims to be able to handle RSS feeds as ‘source’ on it’s own. The problem, as my Twitter buddy @JohnPBloch warned me, is it’s not friendly. He said “I don’t care much for phpList. I always felt like the software was working against me instead of with me.” And he’s right. It took 5 minutes of setup for me to gag and delete it.

Why rss2email? I don’t think RSS is dead. In fact, I still prefer it to email (or Twitter). My unread RSS list (currently run via Google Reader) sits, quietly, patiently, waiting my attention. I don’t get spam or junk feeds, and if I decided to mark all my Fail Blog feeds as read without reading them, no one knows but me. I don’t have to reply to anything, and I can go back to using my email for communication. That said, I know a lot of people who like to get updates in their email, so I have to take that into consideration when running a site. Sometimes, when you make a site, you cater to yourself. Sometimes you cater to your audience.

Why cron? I’m on Linux. That’s what you do when you want to schedule things.

How?

Bear in mind that my details are going to be specific to my situation.

Mailman is the easiest. You make a mailing list. I wanted an announcement mailing list, so under Privacy options -> Sender Filters I set up that all users were moderated by default and to discard their emails. Then added my email under “List of non-member addresses whose postings should be automatically accepted.” I knew I was going to have emails sent from a specific address, and I didn’t want that address to GET the emails, so by putting it on that list, I don’t have to worry about approving posts. That’s pretty much all the ‘special’ customization I did. If I’d wanted to put a reject to other people’s emails to the list, instead of a discard, I’d have added this “This is an announcement only list. Your post has been rejected.”

rss2email was the hardest, but only because it was new. The install process is really straightforward. I made very minor tweaks to the config.py file, based on a first run when I realized that my mailing list would strip HTML. I set HTML_EMAIL and USE_CSS_STYLING to 0 to get it all to plain text. I changed my DEFAULT_FROM and OVERRIDE_FROM to ‘pretty’ versions of my domain information. Then I had to customize my SMTP stuff, since it requires authentication and is on a special port (not 25).

cron was the most surprising. Since I have to run rss2email out of the same folder it’s in (Python…) I wrote a quick shell script called rss2email.sh that has two steps. It changes directory to my install of rss2email and then it calls the command ./r2e run. Then I called it with a twice-daily (0 and 12) cron job with /home/USERNAME/rss2email.sh and it’s done. I’m not going to give you a blow by detail on how to do cron stuff. It’s way too complicated to try and overview here.

Satisfied?

Pretty well. I’m still massaging the output a bit. The HTML output of a full RSS entry was weird. After changing my WordPress feed to excerpts, I ended up with some weird lines in my emails:

This was caused by some old functions I had in my theme to insert ads into my feeds (mentioned above). I took that out, called ./r2e reset to clean out the database, and then re-ran the script. Worked fine! I admit, I had some moments where I didn’t like putting the excerpt in. I use a custom crafted excerpt in every single post on this site as part of my layout, and while I prefer to avoid ‘read more!’ type things in my feeds, I realized my custom excerpts would be ‘good enough’ for anyone who cared. I do wish WordPress would make two feeds, one excerpt and one none, but that’s a job for another day. At least I’ve managed to semi-customize my Mailman digest header (via manually editing masthead.txt).

After all my testing, I deleted the mailing list and reset everything, did a clean build, and voila! Works like a champ, without putting extra stress on things!
21 January, 2011
My WordPress Scripts
I actually have a couple little scripts I use to update my site instead of using the WordPress built in tools. Invariably, when someone has problems with the automated upgrade tool I comment that I rarely use it. That means people ask me ‘Well how do you update WordPress?’ and I tell them ‘Manually.’ Which isn’t really true. Sometimes I say ‘I wrote a script.’ So … here’s my scripts for upgrading WordPress. I don’t have one for themes, since I always do that manually and check everything. That’s the bane of having highly customized child themes.

These are both Bash shell scripts and run perfectly happily on my server (Linux running CentOS). They’re GPL2, free, and somewhat use at your own peril.

WordPress Upgrade Script

WordPress Plugin Script

As I went to post these, I took a bit of time cleaning them up, putting in comments (the ‘Blame Nacin’ bit is a joke) and formatting them nicely. When I started to look at the plugin one, I realized how freakin’ crazy it is and how many weird custom things I tucked in there. Also I made it so you always had to put in a version number, which if I wanted to ‘release’ that, is something to do away with. One of the catches with it is that a plugin’s ‘default’ zip file of plugin-name.zip is the trunk build. So you’d always have to know your version to upgrade.

On the WordPress upgrader, I could trick that with a simple “if the version is ‘latest’, then download latest.zip”, because the WordPress most recent release is latest.zip. Now, I never call that. I like being master of my domain (pun? maybe) so I always make the time to know what I’m calling. I could have assumed that if you don’t put a version in, you want to install the latest, which is pretty easy to flip around, but I don’t like to assume like that. Still, you can take the code if you want it and do that.

On the other hand, I think if someone wants a plugin, then they should be able to go ‘Get me the plugin’ and it should default to the latest. Probably this is because I test trunk WordPress a lot, but rarely do I trunk a plugin. Since there’s no easy to gank default like that for plugins, I came up with this really fun bit of code, shoved in an if-then check. I really like awk, by the way. It’s insanely powerful.
```
  # We're getting the readme from the repo and using that to calculate the latest stable release.
  wget -qO $1-readme.txt http://plugins.svn.wordpress.org/$1/trunk/readme.txt

  if ! [ -f $1-readme.txt ]
  then
    echo "FAILURE: The plugin is goobered in the WordPress repository, so we can't determine the latest stable release."
    exit 1
  else
    tr -cd '\11\12\40-\176' < $1-readme.txt > $1-readme-tr.txt
    VERSION=.`awk '/Stable/ {print $3}' $1-readme-tr.txt`
    rm $1-readme.txt $1-readme-tr.txt
  fi
```
All these are free for use, and both are under GPL2. I can offer SOME support, but they’re filed under ‘Works for me!’ in my bin.
30 December, 2010

WordPress Plugin Script

I don’t like the automated plugin installer. I don’t know why, I just don’t. I have this stupid simple script I use instead. I cleaned it up before posting here. It’s a lot more complicated than my WordPress Upgrade Script because it has to check for the latest release of the plugin via the subversion repository and clean up weird characters (because people write code on Windows, Linux and Mac and everything else!). This is one of the few times I assume that if you don’t specify a version, you probably want the latest and greatest.

#!/bin/bash

####################################################################
# WORDPRESS-PLUGIN.SH - WordPress Plugin Script for BASH SHELL     #
#                                                                  #
# This script will download and copy up the specified WordPress    #
# plugin to the account. By default it gets the latest version,    #
# but you CAN specify trunk or whatever version you want.          #
#                                                                  #
# Author: Mika Epstein                                             #
# URL: https://halfelf.org/scripts/wordpress-plugin-script/    #
#                                                                  #
# Usage: ./wordpress-plugin.sh plugin [version]                    #
#                                                                  #
# plugin  == the 'ugly' name of the plugin (i.e. wp-super-cache)   #
# version == the FULL version number (i.e. 0.1.2)                  #
#                                                                  #
# This program is free software; you can redistribute it and/or    #
# modify it under the terms of the GNU General Public License as   #
# published by the Free Software Foundation; either version 2 of   #
# the License, or (at your option) any later version.              #
#                                                                  #
# This program is distributed in the hope that it will be useful,  #
# but WITHOUT ANY WARRANTY; without even the implied warranty of   #
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the    #
# GNU General Public License for more details.                     #
#                                                                  #
####################################################################

if [ "$1" = "" ]
then
  echo "EXIT: FAILURE! You didn't specify a plugin name.  Kinda need that."
  echo "Syntax is ./wordpress-plugin.sh plugin [version] "
  exit
fi

if [ "$2" = "" ]
then
  # We're getting the readme from the repo and using that to calculate the latest stable release.
  wget -qO $1-readme.txt http://plugins.svn.wordpress.org/$1/trunk/readme.txt

  if ! [ -f $1-readme.txt ]
  then
    echo "FAILURE: The plugin is goobered in the WordPress repository, so we can't determine the latest stable release."
	exit 1
  else
    tr -cd '$2' < $1-readme.txt > $1-readme-tr.txt
    VERSION=.`awk '/Stable/ {print $3}' $1-readme-tr.txt`
    rm $1-readme.txt $1-readme-tr.txt
  fi

else
  # Quick check if someone wants the trunk build with a 'You sure?' 
  # double check.
  if [ "$2" = "trunk" ] # start trunk check
  then
    read -p "Are you sure you want to install the TRUNK version? (y/n) " -n 1
    if [[ ! $REPLY =~ ^[Yy]$ ]]
    then
      echo
	  echo "You have opted NOT to install the trunk build of $1."
      exit 1
    else
      echo
      VERSION=
    fi
  else
    VERSION=.$2
  fi # end trunk check
fi

# Download the plugin
wget http://downloads.wordpress.org/plugin/$1$VERSION.zip

# If the file didn't download, then you probably got the URL wrong. Fail.
if ! [ -f $1$VERSION.zip ]
then
  echo "EXIT: FAILURE! Could not download $1$VERSION.zip - Did you get the version and plugin name right?"
  exit
else
  echo
  unzip -q $1$VERSION.zip
fi

# This is ONE LAST CHANCE. If you say anything other than yes, then it cleans up.
read -p "Last chance.  You sure you want to install the plugin $1 v$VERSION for $USER? (y/n) " -n 1
  if [[ ! $REPLY =~ ^[Yy]$ ]]
  then
    rm -rf $1/
    rm $1$VERSION.zip
	echo
	echo "EXIT: You have chosen NOT to install WordPress $1 at this time."
	exit 1
  else
    echo
  fi

# This is a quick check to make the directory if it's not there.
# Change this if you want to install to a subfolder or whatever.
if ! [ -d public_html/wp-content/plugins/$1 ]
then
  mkdir public_html/wp-content/plugins/$1
fi

# Copy the files up to root public_html
# Again! Change this if you want to install to a subfolder or whatever.
cp -r $1/* public_html/wp-content/plugins/$1/

# Post install clean up with a 'I don't know what you did!' error.
if [ -f $1$VERSION.zip ]
then
  rm -rf $1/
  rm $1$VERSION.zip
  echo "SUCCESS! You've downloaded the plugin $1 (version $VERSION). Now go activate it!"
else
  echo "POSSIBLE FAILURE. Could not clean up the files, so there's a chance everything went pear shaped."
  echo "Please review your WordPress plugins and remember: Blame Nacin."
fi

exit

30 December, 2010

WordPress Upgrade Script

I don’t like the automated updater. I don’t know why, I just don’t. I have this stupid simple script I use instead. I cleaned it up before posting here. But this is what I use when I want to upgrade my various installs to the latest version, or the nightly build. I didn’t bother to put the svn stuff in here, since the script I use for that is fairly weird and particular to me.

#!/bin/bash

####################################################################
# WORDPRESS.SH - WordPress Upgrade Script for BASH SHELL           #
#                                                                  #
# This script will download and copy up WordPress to the account.  #
# It's pretty simple, with the bare minimum of error checking. So  #
# be careful.                                                      #
#                                                                  #
# Author: Mika Epstein                                             #
# URL: https://halfelf.org/hacks/wordpress-upgrade-script/     #
#                                                                  #
# Usage: ./wordpress.sh version                                    #
#                                                                  #
#                                                                  #
# This program is free software; you can redistribute it and/or    #
# modify it under the terms of the GNU General Public License as   #
# published by the Free Software Foundation; either version 2 of   #
# the License, or (at your option) any later version.              #
#                                                                  #
# This program is distributed in the hope that it will be useful,  #
# but WITHOUT ANY WARRANTY; without even the implied warranty of   #
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the    #
# GNU General Public License for more details.                     #
#                                                                  #
####################################################################

if [ "$1" = "" ]
then
  echo "EXIT: FAILURE! Call this as './wordpress.sh VERSION', you nut!"
  exit
fi

# Quick check if someone wants the nightly build with a 'You sure?' 
# double check.
# This sets the URL, as it's different for the nightly builds.
if [ "$1" = "nightly" ]
then
  DOMAIN=wordpress.org/nightly-builds
  VERSION=wordpress-latest
 
  read -p "Are you sure you want to install the NIGHTLY build? (y/n) " -n 1
    if [[ ! $REPLY =~ ^[Yy]$ ]]
    then
      echo
	  echo "You have opted NOT to install the nightly build of WordPress."
      exit 1
    else
	  echo
    fi

else
  DOMAIN=wordpress.org
  if [ "$1" = "latest" ]
  then
    VERSION=latest
  else
    VERSION=wordpress-$1
  fi
fi

# Download WordPress
wget -q http://$DOMAIN/$VERSION.zip

# If the file didn't download, then you probably got the URL wrong. Fail.
if ! [ -f $VERSION.zip ]
then
  echo "EXIT: FAILURE! Could not download $VERSION.zip - Did you get the version right?"
  exit
else
  echo
  unzip -q $VERSION.zip
fi

# This is ONE LAST CHANCE. If you say anything other than yes, then it cleans up.
read -p "Last chance.  You sure you want to install WordPress $1 for $USER? (y/n) " -n 1
  if [[ ! $REPLY =~ ^[Yy]$ ]]
  then
    rm -rf wordpress/
    rm $VERSION.zip
	echo
	echo "EXIT: You have chosen NOT to install WordPress $1 at this time."
	exit 1
  else
    echo
  fi

# Get rid of hello dolly and akismet 
rm -rf wordpress/wp-content/plugins/akismet
rm wordpress/wp-content/plugins/hello.php

# Copy the files up to root public_html
# Change this if you want to install to a subfolder or whatever.
cp -r wordpress/* public_html/

# Post install clean up with a 'I don't know what you did!' error.
if [ -f $VERSION.zip ]
then
  rm -rf wordpress/
  rm $VERSION.zip
  echo "SUCCESS! You're on WordPress $1."
else
  echo "POSSIBLE FAILURE. Could not clean up the files, so there's a chance everything went pear shaped."
  echo "Please review your WordPress install and remember: Blame Nacin."
fi

exit

The fix to ‘Oh shit, I installed WordPress 2.1 instead of 3.1!’ is to re-run it correctly, by the way. So long as you haven’t logged in to your site, you won’t update the database, so a backout is always a re-run, even in the real world.

30 December, 2010

Tag: command line

Command Line WP

Installing

WordPress, DSO and Permissions

Make An RSS Powered Email List

What?

Why?

How?

Satisfied?

My WordPress Scripts

WordPress Plugin Script

WordPress Upgrade Script