[rant-o-meter mood="Happy" align="right"] I’ve thought about making one for a while, and just never get around to it. So, today I decided to take advantage of the Google Chart Tools and create a quick and dirty WordPress plugin called Rant-o-Meter.

Rant-o-Meter simply takes the shortcode rant-o-meter and replaces it with a Google-o-Meter.¹

[rant–o–meter]

[rant–o–meter level=80 mood="Pissed off" align="left"]

It has a variety of options for formatting the resulting Google-o-Meter, such as the level of rant-i-ness, the mood, the top and bottom of your rant-i-ness scale².

The full list of options is available on The Rant-o-Meter Github site, so I won’t go into them here. I will say that this whole thing comprised about 45 minutes of work, so I know that there are various ways that it could be improved. I haven’t bothered to list it in the WordPress plugin directory because of that. Eventually, I may do that, but for now, it’s just a gimmick.

1. It’s really something of a “Google-o-Meter” plugin rather than a specific Rant-o-Meter, but that doesn’t matter to me so much.
2. I chose “Buffalo” and “Hood River” as the defaults because that’s sort of my “Rant-level baseline indicator”

Validation error using the CPanel Advanced DNS editor

If you, as the documentation and the support ticket staff both told me, go to the Advanced DNS Editor to enter a wildcard DNS record, you get an error. As you can see in the image, the validation states that the

Name must be a domain with an optional period at the end.

Of course, this is probably a CPanel issue, and not the fault of the good people at A Small Orange. It’s obvious their JavaScript validation doesn’t account for a single asterisk¹ Still, it causes problems because we are told to use this panel.

Maybe it’s something I was doing wrong, but I got it to work by actually going to the Subdomains panel instead. There’s no such validation when you add a single subdomain with the name “*” (without quotes, obviously) and point it directly at /public_html/. After you do that, you can actually head back to the Advanced DNS editor and see that your new wildcard DNS record is actually registered.

Hope this helps someone.

1. I’m looking at their bug system now

Firstly, let me say this: I’m not making a statement on Git vs. Subversion vs. Source Safe vs. CVS vs. the weird text-based logging system you developed 10 years ago and haven’t ever changed. I’m making a statement about using source control period, and using Git as an example because that’s what I use.¹

The Whys of Source Control

Why? Because you’re going to wish you had in about 3… 2…

Seriously, things happen, you break stuff, you need to look at an older version, you want to try something and are not sure whether it’s going to break, you want to share your code with others, or take advantage of the code of others, you want to share code with yourself, etc. Source control is part of a broader development strategy that is valid whether you are a serious programmer or just modifying themes for yourself or clients. There are dozens of reasons why source control is A Good Thing™.

The main one is that catastrophe is going to happen, and it’s going to happen in 3… 2…

Source Control for Smarties

Enough of the whys. Let’s get to some hows.

I won’t insult you by telling you this is Source Control for Dummies, but I don’t want you thinking that you can’t learn how to use it if you don’t want to. Like anything, it takes some getting used to.²

Git vs. Github

Right off the bat let’s clear up Git vs. Github.

• Git is source control management software (the way that WordPress.org is blogging software)
• Github hosts Git repositories (the way that WordPress.com hosts blogs)
• Git is software that allows you to track the changes that you make to individual files
• Github is a company providing a nice looking website to help do that, well as other neat things

If you haven’t already done it, go to Github right now and sign up for an account. It’s free, they are full of awesome sauce, and you can then fork some of the examples I’m going to give you.

Oh, and you will want to install Git too.

The Fast Install Guide

• If you’re on a Mac, use Homebrew (i.e. “brew install git”)
• If you’re on Linux, use the package manager (e.g. “apt-get install git”)
• If you’re on Windows, buy a Mac (i.e. “ba dum CHING!”)

Okay, seriously, Here are the Github help pages for installing Git on Windows, Linux and Mac. It’s really beyond the scope of this post to detail exactly how that’s done. If enough people get lost, I’ll write a detailed post on just that. For now here are some guidelines:

1. Install Git
2. Create an SSH key
   1. Go to a terminal window and type “ssh-keygen”
   2. In Windows, don’t use the normal “Command” window, use Start->Programs->Git->Git Bash and type that. If you installed Git using the directions above, it should work.
3. Create your Github account if you haven’t, then go ahead and set your username and email on your local system according to these instructions.
4. 

   Sample SSH key public file

   Copy the SSH public key

   1. Copy the contents of the file ~/.ssh/id_rsa.pub (or id_dsa.pub) to the clipboard
   2. In Windows, this file is in C:Documents and Settings{User Name}.ssh
   3. This file’s contents look something like the file to the right
   4. Important! Don’t copy the id_rsa file, copy the id_rsa.pub file (the .pub ending means it’s a public file- never ever give out the other one)
5. Go your SSH key settings in Github and paste the public key

Now you have Git installed, and have a Github account that you can access directly from your computer.

Fork it!!

Okay, now that we’re all set up with our source control system, let’s take a really quick tour. As a note: I’m going to do this with the command line, not with any graphical system. I’m doing this both because it’s how I do it, and because it will help illustrate what the commands actually do. Feel free to get a graphical Git program if you’d like, the commands should be the same.

First, we’re going to give you a functional repository, so go to my Github repository of the WordPress TwentyTen theme. In the upper right, under the User/Account/etc menu and under the Search menu are some buttons, hit the one that says “Fork.” Now, head over to my thirty ten repository and fork that. Thirty Ten is the child theme developed by Aaron Jorbin and he graciously offered the code as well as an excellent blog post describing its development. I’m going to use Aaron’s child theme a lot in this series.

Snapshot of a repository on Github

What forking does is copy the repository to your account, but does so in such a way that it “knows” that it came from somewhere else. That way if I change my repository, you can pull the changes, and if you change yours, I can pull those changes if I want. Head over to your account and look at the Thirty Ten repository now. You’ll notice that it shows a list of files and directories showing a message next to each of them. You’ll also see that I am the user listed at the top. That means that I was the last person to “commit” my changes. Committing means making changes to files and telling Git that you want those changes, well, committed to the repository. Lastly, scroll to the bottom of the page and notice that Github is telling us that we have no README file. If there was a README file in this directory, the contents of that file would be displayed here.

Now, go to a command line and type:

$ mkdir themes
$ cd themes
$ git clone git@github.com:USERNAME/twentyten.git
$ git clone git@github.com:USERNAME/thirtyten.git

These commands make a “themes” directory on your local system, and then inside that theme directory they clone the TwentyTen and ThirtyTen. Cloning means making a copy of the repository that’s on Github (Replace USERNAME with your Github username, obviously). Now, all of the files that are in the Thirty Ten repository on Github are also on your local system. You have two identical copies of the Thirty Ten repository.

Modifying code in a repository

Now let’s go into the Thirty Ten repository and make a small change by creating a README file (feel free to do this using a graphical file manager and/or text editor):

$ cd thirtyten
$ echo "This is a child theme based on TwentyTen, the default WordPress 3.x theme." > README

That creates the file README and puts some basic text in it. Next, we’re going to play with some Git commands. Type the command git status and you’ll see:

$ git status

# On branch master
# Untracked files:
#   (use "git add ..." to include in what will be committed)
#
#	README
nothing added to commit but untracked files present (use "git add" to track)

This is telling us that you have one “untracked” file- a file that you haven’t told Git about. We’re going to “add” that file to our repository:

$ git add README

This command tells Git to add the file README to the repository. As a shortcut, if you have all files and want to add them all, you can use something like:

$ git add .

The dot tells Git to add “the current directory.” Since README is the only file that hasn’t already been added, it’ll only add that file. Let’s look at the status again:

$ git status

# On branch master
# Changes to be committed:
#   (use "git reset HEAD ..." to unstage)
#
#	new file:   README
#

Notice that “Untracked files” became “Changes to be committed.” This is the only thing we’re doing right now, so we’re going to commit this change (i.e. tell Git that you’re sure, and want this change save, tracked, and logged.)

$ git commit -m "Add a readme file"

The “-m” switch tells Git that we want to add a message on the commandline, instead of adding it separately. Now our changes are committed to our repository and logged and we can make more changes:

$ git status
# On branch master
nothing to commit (working directory clean)

Let’s go and make another change. Let’s add a special css file that we can play around with later. We’ll go ahead and add this directly to the repo.

$ touch special.css
$ git add special.css
$ git commit -m "Add a blank special.css file to play with"

Now we have two changes committed to our repository. They are saved, tracked, and logged. But our laptop might be stolen, so let’s “push” them to a “remote” repository for safe keeping. A remote repository is a mirror of the repository you’re using. The repository on Github is a remote repository with the name “origin.”

$ git remote
origin

Pushing means “Take the changes that have been committed to this repository and commit those same changes to a remote repository.” Since you only have one remote repository, you don’t even have to tell it which one:

$ git push

will push the changes to Github. Now go ahead and browse to your Thirty Ten repository on Github and look at it. You’ll notice that the user is now listed as you, with your last commit message. Scrolling down to the file list, you’ll see that your commit messages are listed next to the files that you changed.

Coda

There it is, the bare minimum you need to get started with Github, and some sample repositories to boot. In the next post, we’ll create a child theme from scratch, and use the great FTP software Filezilla to copy our changes to our WordPress server after we check them into source control.

1. Flame war: The un-winnable situation in which everything I do is amazing and everything you do sucks. I don’t care what source control system you use- and think that it’s a bad idea to use Git if another one is better suited to your needs. Still, if you’re not using any system, you may as well choose Git because then this article will be easier to follow. Yes, I could give examples in Subversion and Mercurial, but this is not a book, it’s a blog post.
2. Also, sometimes it seems like setting something up and learning how to use it is more trouble than just dealing with the problem when it comes up all the time. Only you can make that decision, but I guarantee that the amount of time you spend learning this will offset the amount of time you spend working (and recovering from failure) if you don’t.

I love WordPress.

WordPress is a dream come true. It’s a great writer’s platform, it’s a great programmer’s platform, it’s a great tinker’s platform…

It’s also a total and complete pain in the ass.

Like many great things, it’s virtually perfect. And, like many great things, it can be finicky, sometimes contemptible, and often frustrating as hell.

Why?

Because it attracts tinkerers, and tinkerers break things, and breaking things is frustrating.

Honestly, not all the frustration that people have with WordPress is the WordPress team’s fault. It’s the fault of the system. It’s a function of a system and philosophy that allows people to have as many options as they can.

That’s a problem.

WordPress is almost infinitely customizable, totally hackable and utterly configurable. That’s the beauty and the curse. Whenever something has that many buttons to press and levers to pull, something is always going to break… eventually

I’m Speaking at WordCamp Portland

This year, I have been honored by being invited to speak at WordCampPDX. Actually, “honored” is a bit of an understatement. I’m overjoyed. Getting up in a room full of people who love WordPress in order to talk about WordPress is pretty damn exciting. It might even be the most exciting speaking engagement I’ve ever had, and I’ve spoken a lot.

What will I talk about?

Well, there’s that whole “double-edged” sword aspect of WordPress that I’ve just been describing. How you can do anything you want to with it, but how that means that it will always break. That’s really the most interesting thing to me. But, that’s just a description of a problem. That’s a complaint.

So, I’m talking about a solution.

WordPress & Source Control

Source control management (SCM) is a concept that is as natural as breathing to most developers. But it’s not something that WordPress users often think of.¹ Hovever, anyone who has ever modified a theme, fiddled with a plugin, or wanted to change the way WordPress works for them in any way could find it valuable.

It’s strange to me that more WordPress users don’t actually use an SCM system, but then again, I’m a programmer. SCM may be as natural as breathing to a developer, but it’s about as natural as breathing underwater to a non-programmer.

But it doesn’t have to be like breathing underwater.

So I’m speaking on ways to integrate Source Control and WordPress, to make your life easier and make it much safer to play around and tinker. Hopefully, after my talk, even non-programmers who want to tinker in the WordPress code will feel confident that they won’t break things.

Or, rather, that they will break things, but that breaking things is okay and a good way to learn– assuming you can fix them.

Getting Excited

Today I created an outline.

It’s day zero of the first of my three WordPressPDX countdown timers. Today was “outline” day.

15 days from now is “Presentation” day- the day I need to be done with my presentation (so that I have enough time to test it, tweak it, and maybe break it)

30 days from now is WordCampPDX!

Today I created an outline, and it’s a pretty good one. We’ll look at messing about with WordPress themes and plugins, we’ll create Github repositories, and we’ll break things.

We’ll even– crazy thought– hack the WordPress core!!

But it’ll all be okay, because we’ll have a safety net.

You don’t need to know PHP, you don’t need to know about source control. All you need is the desire to fiddle with stuff and see if it breaks.

And you need a love of WordPress, but if you’re coming to WordCampPDX, you already have that base covered.

Yay for WordCampPDX!!

1. despite the fact that there is a revision control system built into the WordPress editor

For me, this tagline has become something of a… well… tagline. Many people use the default “Share and enjoy” tagline.¹ This is probably because most people see the tagline as an introduction to the “link to social media” function of Sociable. Me? I actually like the semi-Shakespearian “ending of a chapter” feeling that the tagline gives. It’s like a way to tell the reader that we’re at the end of this post, this thought, this… chapter.

When I started using Sociable, I periodically changed the tagline from “Whaddaya think, sirs?” to “Push the button, Frank.” and back again. These are two good “ending taglines” from that greatest of all shows: Mystery Science Theater 3000. Eventually, I got sick of the tagline being the same thing for all posts, and of having to manually change the tagline. So, I thought I’d hack the plugin source to allow for random taglines.

Random Taglines Rule!

Sociable-random's admin page

Thus, I give you the sociable-random plugin. It’s exactly the same as the sociable plugin, except that it allows for multiple taglines and it automatically uses the <strong> tag for those taglines.

At the bottom of this post, you see a tag that has been randomly chosen from about 7 MST3K quotes. You also see the way I formatted the tagline to separate it a bit from the post, while still connecting it to the sociable links. The CSS for this is:

.sociable_tagline {
            padding-bottom: 5px;
            margin-bottom: 3px;
            margin-top: 5px;
            line-height: 1.5em;
}
.sociable_tagline strong {
           border-top: #444 1px solid;
}

Download

Download sociable-random from its archives link on Github. Feel free to let me know what you think, and if something’s broken, either fire a message along on of the various channels you see on the right edge of your screen, or using the Github Issues page.

1. which is something I’d expect to hear from a space ship’s computer that’s trying to recreate tea, not something I want on my blog.

It’s like camping with a Therm-a-Rest. They tell you not to blow into it. They say it’s important to just let it sit and it will self-inflate. Don’t blow it up. That’s bad.

But everyone does it.

It’s the same with the WordPress core. They say “Don’t hack core,” but everyone does it.

Well, almost everyone.

Actually, maybe just one or two of us.

Anyway, I’d never hack the WordPress core if I were working on something for someone else. I’ve had to clean up that mess after an update to the WordPress software completely wrecked the website (I wanted to kill that person).

I am a little bit more likely to hack the core code on my personal site, however. Just as I’m allowed to do anything I want to my house, but would probably bitch-slap someone if they came over and started drilling random holes in the walls.

It’s mine, I’ll accept responsibility for screwing it up. I’m alright making that choice.

So, recently, I moved to a WordPressµ installation at The MettaSite, and placed Positively Glorious! and a few other gems under it’s control. It’s been great so far, but I missed the ability to edit my theme and individual plugins from within the dashboard. For most installations of WordPressµ, disabling this ability is A Good Thing™, because modifying a theme is pretty dangerous if more than one person has access to that theme. It’ll work on one site, but break on others. That’s bad.

But at The MettaSite, there’s just me, and at most 2 or 3 other people that I might host sites for. In this case, it’s easy enough for me to activate a theme on one blog only. It’s a very small, controlled space, so the problems of theme modification are virtually nil.

So, I decided to reactivate my theme and plugin editors in WordPressµ, which involves hacking the core. This is problematic because there are updates to the core code, and every update breaks any hacks you have (as well it should). I might take some time to figure out how to add this functionality to the backend more cleanly and submit an options patch, but until then, I needed a quick reminder about how to fix it– because WordPress will update, and I won’t be able to edit because I was stupid and hacked the core.

The Instructions

It’s pretty simple, actually. In WPMU V.2.8.x, look in the file wp-admin/includes/mu.php and around line 539 find the function wpmu_menu() in it, you’ll find an if statement:

552
553
554
555
556
557

…
    if( !is_site_admin() )
        unset( $submenu['plugins.php'][10] ); // always remove the plugin installer for regular users
    unset( $submenu['plugins.php'][15] ); // always remove the plugin editor
    unset( $submenu['themes.php'][10] ); // always remove the themes editor
…

Change this so that all three of these unset() statements are contained in the if statement. What we’re doing is turning off those editors only if the user is not a site administrator in the database, rather than always.

552
553
554
555
556
557
558
559
560

function wpmu_menu() {
    global $menu, $submenu, $current_user;
…
    if( !is_site_admin() ) {
        unset( $submenu['plugins.php'][10] ); // always remove the plugin installer for regular users
        unset( $submenu['plugins.php'][15] ); // always remove the plugin editor
        unset( $submenu['themes.php'][10] ); // always remove the themes editor
    }
…

Next, scroll down to And around Line 1116 or so to find function disable_some_pages():

1126
1127
1128
1129
1130
1131
1132
1133

…
    $pages = array( 'theme-editor.php', 'plugin-editor.php' );
    foreach( $pages as $page ) {
        if ( strpos( $_SERVER['PHP_SELF'], $page ) ) {
            wp_die( __('Page disabled by the administrator') );
        }
    }
…

Change that if statement to this:

1126
1127
1128
1129
1130
1131
1132
1133

…
    $pages = array( 'theme-editor.php', 'plugin-editor.php' );
    foreach( $pages as $page ) {
        if ( strpos( $_SERVER['PHP_SELF'], $page ) && !is_site_admin() ) {
            wp_die( __('Page disabled by the administrator') );
        }
    }
…

Again, what we’re doing is changing from a policy of disabling the editor pages always, to only disabling them if the current user is not a site admin.

Coda

That should do it. Once you make these two changes (test them out, of course) you should be able to use the built-in editors for both themes and plugins. Of course, what we’d all rather have is a better system for editing them, but unless you want to set up your IDE of choice with an FTP link, or maybe even a continuous integration server, this is a pretty good choice.

Have fun, Morgan