While following the directions on how to set up 10up’s wonderful dev environment for WordPress, I noticed that Vagrant was using a .pkg installer.
Now there’s nothing wrong with installing software that way. Hell, doing things via a graphical installer is easier for most end users. But Vagrant isn’t really something that was made for “end users”. It’s a command line utility to create and manage development environments.
So I did a quick check to see if I could install Vagrant via my favorite package manager, Homebrew. And while there’s nothing in the vanilla install of Homebrew, I stumbled onto an independently maintained add-on called brew-cask that allows you to install Mac applications on your computer via the command line.
Using it is as easy as loading up your terminal and typing:
brew tap phinze/homebrew-cask && brew install brew-cask
Then, to get Vagrant installed, just run this command:
brew cask install vagrant
Hell, you can even install VirtualBox if you’d like:
brew cask install virtualbox
Pretty nice, right?
Oh, and if you’ve been holding out on using Vagrant in your dev environment, consider giving it a try. It’s way more flexible than MAMP and nowhere near as quirky.
Have you guys heard about Instant Server? It’s pretty rad. Basically, you push a button, wait a few seconds and they give you 35 minutes of usage on an SSH-able server. Once the 35 minutes is up, you can either pay to keep it running or they trash the server instance.
Anyhow, after trying to figure out some of the fun things I could do with it, I’ve come up something that security minded WordPress folks might find useful.
There’s this command line security scanner called WPScan that performs a bunch of non-intrusive checks against WordPress installs. Folks with Linux based systems can install and run it easily. It’s also a fairly trivial install for folks who’ve set up Homebrew on their Macs. But if you don’t want to mess with installing Xcode on your MacBook or you have a (gag) Windows machine, try this out…
Run the following command: sudo apt-get install libcurl4-gnutls-dev libopenssl-ruby libxml2 libxml2-dev libxslt1-dev ruby-dev git make && git clone https://github.com/wpscanteam/wpscan.git && cd wpscan && sudo gem install bundler && bundle install --without test development
After that finishes running, you should have roughly 30 minutes left on the server.
Run this command: ruby wpscan.rb --url example.com --enumerate
(Make sure to replace example.com with your own domain.)
Sit back and let WPScan tell you about any security issues you might need to address.
If you stay on top of core, plugin & theme updates, you shouldn’t really see anything surprising. But it’s always better to know your threats and limit your exposure, right?
The WordPress team just dropped what they’re calling their “first draft” of Twenty Thirteen into the wild. And while I know that it’s not a finished product yet, I like it so much that I’ve decided to use it here. At least for a little bit.
Can you blame me? I mean, just look at it…
Sexy, right?
But how did I get my grubby little hands on a copy of the theme before it was even released? Well, if you’ve got Subversion installed on a Mac, it’s as simple as opening your favorite terminal application and running this command:
cd ~/Downloads/ && svn co https://wpcom-themes.svn.automattic.com/twentythirteen/ && zip -rv twentythirteen twentythirteen && rm -rf twentythirteen/
What does that command do? Allow me to give you the step-by-step rundown…
Changes the working directory to your user’s “Downloads” folder.
Performs a SVN checkout of the Twenty Thirteen theme from Automattic’s WordPress.com theme repository.
Creates a zip file called “twentythirteen.zip” in your Downloads folder.
Deletes the “twentythirteen” folder.
Once the command finishes running, log into your WordPress dashboard, go to “Appearance > Themes”, select the “Install Themes” tab and click “Upload”.
All you have to do then is upload the theme from your computer and activate it. Simple!
And by “simple” I mean you have to be comfortable with the command line and hope to God that you have Subversion installed.
Should you not have the SVN binary on your Mac, perhaps the exciting world of pre-release themes isn’t for you. Don’t fret though, I’m sure Twenty Thirteen will find its way to the official theme repository soon enough.
P.S. Since Twenty Thirteen isn’t exactly finished yet, I wouldn’t suggest installing this on your production site. But if you’re borderline crazy — like me — feel free to join me in saying “fuck it”.
Just don’t come crying to me if something goes wrong, okay?
For the folks who haven’t committed to cleaning the unused core files out of their WordPress install, the Old Core Files plugin for WordPress looks like it should be useful. I only say “looks like” and “should” because I’m already tidying my site’s files on the regular. But this’ll definitely save me from having to do my future sweeps manually.
While helping a client come up with an alternative for the somewhat spotty Smush.it plugin for WordPress, I thought I’d do an extremely unscientific test to see what performed better. So I grabbed an image from Kanye Wes Anderson and got to compressing…
Let’s start with the original 221549 byte image. Feel free to grab it (just click on the image) if you want to play along at home.
To start, I tried uploading the file to PunyPNG. But I quickly realized that they cap their free compression tool at 150 KB. And since I didn’t feel like paying to run a one-off test, I gave Kraken a go instead.
Kraken losslessly compresses the image to 214233 bytes. Which gives a 3.3% savings in total size. In a later test, the OS X utility ImageOptim gave the exact same results. That’s not to say that’ll always be the case, but it was definitely interesting to see. Especially when you consider that the command line (see: Linux friendly) alternative image_optim only managed to compress the image to 214746 bytes.
Even though image_optim gave a respectable savings of 3.1%, I was surprised to see that otherwise insignificant variation. At least until the Smush.it web interface returned the “same” 214746 byte file.
So all of them do a respectable job, but it seems as if Kraken & ImageOptim’s lossless compression methods are slightly more aggressive. Since Kraken has an API, it’d be wonderful if someone could whip up a WordPress plugin to leverage it. But until they do, all of this crap needs to be done before the images are uploaded to your site. Which is a total bummer. It’s still better than relying on the really spotty and ridiculously laggy Smush.it API though.
Anyhow, I hope this was helpful to someone.
Oh! And if you want to see the images that each program outputted, feel free to grab them from here.
There’s been a lot of discussion around John O’Nolan’s Ghost today. And there should be. It’s a beautiful, blog focused reimagining of the WordPress dashboard that provides an alternative to what they’ve done with the dashboard on WordPress.com.
A lot of the discussion is about how John would like to do this as a fork of WordPress. And while I think his efforts and ideas might help the WordPress UI Team more than a fork would, I’m really hoping that someone picks up and runs with his editor idea.
Maybe that’s influenced by the fact that I’ve been working in Markdown more and more lately. Still I really like the idea of a quick, split paned writing area with a live preview.
I’ve been looking for a clean, single-column, responsive WordPress theme that supports post formats (or at least asides) for the past few weeks now. And honestly, I was beginning to think I’d have to roll my own. Now, that isn’t really an issue — especially since I’m comfortable with theming — but site design is something that I don’t currently have the bandwidth for.
Then, I saw Jake Caputo’s Memoir. And even though it’s a ThemeForest theme, Jake’s track record (and the demo) immediately made it into a solid candidate. Especially when the other two options involve adding asides to either Anthem or Duet.
While I do get to work on WordPress Multisite issues from time to time, I apparently don’t do it often enough to know about the NOBLOGREDIRECT constant…
Basically, that tells your Multisite install to redirect to an alternate URL of your choosing if either:
Registration is disabled.
There’s no install that corresponds to the domain being visited.
Not too long ago, I helped a friend clear out some malware on their WordPress site. In doing so, we went thru a pretty comprehensive site cleanup checklist:
Deleted unused plugins & themes.
Installed a fresh copy of everything.
WordPress core
Plugins
Themes
Double checked the .htaccess file.
Changed every conceivable password.
WordPress admin users
FTP/SFTP/SSH account
MySQL user
Bought a SSL certificate and forced all wp-admin & wp-login.php traffic to it.
But the malware would keep getting reinserted in the site. Almost like clockwork. So I had them install a logging plugin to see if we could catch what was happening. Sure enough, the lone admin account would log in, upload & activate a plugin — which seems to be how the attacker was delivering their payload — and then remove the plugin from the site before logging out. Running a “stat” (via the shell) on the files we’d cleaned previously all showed that the modify timestamp matched up (roughly) with the plugin activation timestamp.
Because this kept happening, there were some concerns that my friend’s personal Gmail account might be hacked. They enabled 2-step verification as a response and started watching the account activity like a hawk.
Then the malware came back. Again. But nobody had logged in to my friend’s Gmail account. Things were getting to be maddening.
Since we couldn’t spot anyone logging into their email account, I started going over their Apache logs. That’s when I found something interesting…
If you look at things closely, you’ll see that the key value is the same both times. And, upon checking their database, I noticed the key value was still set to HR9qFJ2N6c3XveQY487b. Since WordPress clears out the user_activation_key value from the database after it has been used, the faux plugin the attacker was using must’ve pushed that value back into place to provide them with a backdoor. Pretty sneaky.
So I cleared the malware, locked the site down again and made sure to clear out the user_activation_key. Sure enough, the malware stopped coming back and my friend was happy that they could finally concentrate on blogging again.
Anyhow, ever since then, this little MySQL query has been getting run on every hacked site I’ve worked on…
Yeah, that totally guts all of the user_activation_key values for admin and non-admin users alike — and I’m sure that most attackers aren’t as clever as the one I was dealing with — but it’s always better to be safe than sorry, right?
