Category: How To

Mailbag: Getting Started as a Freelancer
Neil asks:

I am a web technician and proficient in Wordpress. I’ve worked on a number of WP sites, as well as other types of scripts/sites. Some of my work has been volunteer, and assisted by Dreamhost’s non-profit hosting. Would you have any suggestions as to how or where one might be able to start in obtaining freelance work? I know it’s a bit presumptuous but I thought I’d ask- I’ve seen many of your posts in the Dreamhost forums helping out. Kindest Regards, Neil

I should preface this with a reminder that I’m not a freelancer for a reason. I hate the constant hustle of it.

I don’t think I’m really qualified to answer this one. But you know who is? Chris Lema. And you know who talked on the Matt Report about how to become a great freelancer?

But that doesn’t answer where one gets freelance work.
If I had to start from zero, I’d pick the WordPress Jobs Board and snag a couple people there. Chris Lema supports Codeable, though, so that’s also a really good pick.

Hey readers, who do you use?
5 June, 2015
Design for Multisite or DIE

I don’t mean you need to design all your code to have special Multisite features. I mean that if you’re not writing code to work on multisite, you’re probably doing a lot of things non-optimally and not fully WordPressy. When you write your code with Multisite in mind, you’re actually writing it with the basic tenants of WordPress itself. It forces you to think about how WordPress is used, how it might be used, and how you can be flexible and extendable.

Let’s throw out the idea of network options and activation for a moment and consider the ways we can write our code to make it work for Multisite and the world. The truth is that if you’re coding ‘for Multisite’ in many ways your coding for WordPress in the best way possible.

Calling Files

There’s a time and a place for ABSPATH but it’s as a last resort. There’s a time and a place for get_bloginfo('url') but it’s not to call .'/wp-admin/admin.php either. Did you know admin_url() will get the url to the admin area using the right protocol (http or https) for you? And it works for Multisite. Instead of hardcoding your paths or assuming everyone has WordPress installed in the root of their website (they don’t), use the functions and template calls WordPress has created.

Oh and stop supporting the old WordPress 2.x ways of determining folders. It’s 2015. We’re good.

Saving Files

Saving data to the disk means everyone can read it. Duh, right? Well, where do you save uploaded files? You use wp_upload_dir of course. That works on Multisite just fine. Instead, if you hardcode in /wp-content/uploads/myplugin/ then you’re saving things for everyone. If you’re not using the WordPress options to grab the upload directory, then your code won’t work on Multisite and everyone will be sad.

This extends to where you save your cache files. Did you know there’s a plugin that saves the cache to the plugin folder itself? Besides the fact that the cache didn’t have a way to flush and grew to 700megs over the year the person used it, that cache was for all the sites in the network. All. Saving the cache to a unique location (I suggest /wp-content/pluginname-cache/siteID) prevents cross contamination of cache.

Saving Options

If you write a plugin that, to save its data, it creates a new DB table and saves it there, that can be okay. But if your plugin on update then drops that table and recreates it… That was not pulled at random, by the way, I was reviewing a plugin that did that. Instead he should have been using the function update_option() to create (and update) the options. And yes, it knows.

But that’s an extreme, I admit. What isn’t an extreme is people creating their own tables. It happens a lot. And when they do, they often forget that we have $wpdb->prefix which means they force create wp_mypluginname instead of $wpdb->prefix . "mypluginname" … guess which one’s smart enough to know it’s on Multisite?

(If you want to make a network table use $wpdb->base_prefix and use update site option for network wide options, yes, we know the naming conventions are weird.)

Theme Customizer

Not everyone can edit theme files. Not everyone can make child themes. On a Multisite, the only person who can do that is the Super Admin. Site Admins have no access to edit files or upload themes. Worse, if you make a change to a theme, everyone who uses that theme gets the change. What happens when a site wants a special header and your theme doesn’t allow those to be edited via the customizer? The customizer is there for a reason. Use it. At the very least make things hookable to allow plugins to do simple things like change footers. Please. Please. That’s one of the things that themes get wrong constantly.

What Else?

What do you think would be improved if people ‘coded for Multisite’?

1 June, 2015
Self Ghosted
I had to restart everything.

You see, getting Node.js and apache to work together wasn’t going to fly, so I went and built a new VPS with Ubuntu over on DreamHost. Obviously not everyone has this luxury, but since I do, and since DreamHost made this as easy as clicking on a box, I thought it would be perfect.

Requirements

You have to be shell savvy for this. Sorry. There’s no other way. Just accept that and move on.

You need a VPS. The new Ubuntu SSD VPSes all have a one-click ability for Node.js which makes life easier.

You should use nginx and not apache.

Ghost requires Node.js 0.10.x (not 0.12.x). They recommend Node.js 0.10.36 & npm 2.5.0. Of course, DreamHost installs node 0.12.x and npm 2.5.x. You can check by typing node -v and npm -v to see what versions you have. Does this mean you can’t run Ghost? No, it’ll work, but it’s not what they like.

You’ll also need an ‘admin’ account on your server. From panel, click on “VPS” and then “Manage Admin Users” to add a new user to that box.

Get Node.js on your VPS

This is quite simple. First, get an Ubuntu VPS. All the new boxes on DreamHost are Ubuntu, so this is the easy part. Once you have the VPS on DreamHost, make a new domain. I made ghost.elftest.net and in the settings, I checked a box to use node.js:

That will force my file path to be ~/ghost.elftest.net/public (normally on DreamHost it’s ~/domain.com you see) but that’s not an issue since this is a new box. That path will be my ‘home’ folder for the domain and where I install everything (if someone asks you ‘where is X installed on your server?’ you tell them that path). That path also means that had I already been using that domain, it would mess up my folders and paths. If you’re doing this on an existing domain, keep that in mind.

Install Ghost

Like I said before, you have to install on your server, not your desktop. Every single doc I read told me I HAD to do this as the server admin, someone with sudo access. I really, really, really did not like that. I mean, epic levels of hate for the idea that I couldn’t have my user account own things, and have the code in my darn web folder.

Me being me, I hatched a plan. I was just going to do it. I was just going to install it in my webfolder and see how it goes. I came up with this theory because when I read How To Install Ghost on DreamHost I noticed it wanted me to have a specific user chown the folders. Not the admin user, but a special ghost user. So what if I just made ‘elftestghost’ the ghost user, and what if I just used ~/ghost.elftest.net/public/ghost/ as my install directory instead of /var/www/ghost/? And this way, I’d be able to pop in and edit things as my normal user.

So here’s what I did.
```
$ curl  -L https://ghost.org/zip/ghost-latest.zip -o ghost.zip
$ unzip -uo ghost.zip -d ghost
$ cd ghost/
$ npm install --production
```
That’s it. Ghost is installed. I expected that last step to fail and I’m still a little surprised it didn’t. If it does fail for you, run it as your admin account with sudo, and then chown it over to your ‘owner.’

Configure Ghost

Now that Ghost is installed, you may wonder where it is. We haven’t finished the install yet as it happens. We need to configure it and to do that, we copy the file config.example.js to config.js and open it up.

Once you look at it you see that there are multiple ‘config’ options. Since we called --production in our start command, logically we’re going to edit that section. And lo, there’s the bad URL:
```
config = {
    // ### Production
    // When running Ghost in the wild, use the production environment
    // Configure your URL and mail settings here
    production: {
        url: 'http://my-ghost-blog.com',
        mail: {},
```
Change that to the right URL. Mine is http://ghost.elftest.net

Also look for this:
```
        server: {
            // Host to be passed to node's `net.Server#listen()`
            host: '127.0.0.1',
            // Port to be passed to node's `net.Server#listen()`, for iisnode set this to `process.env.PORT`
            port: '2368'
        }
```
Change the host to 0.0.0.0 and save the file. You can also set it to the IP of your server, but as that might change, it’s not required.

Finally you’ll want to set up mail which can be complex. I set up a special account on my own server.

Setup Ghost

Seriously this is not a five minute install. Your site starts with a Hello World type post which tells you all about the glory of Markdown. If you go to your admin page (http://ghost.elftest.net/ghost/) it sends you to http://ghost.elftest.net/ghost/setup/ where you get this:

This actually makes more sense than it did on the Ghost Pro site, where I was wondering why I had to make a user and then a user. Here I’m clearly making a user for the site. There I was making a user for their network (Ghost Pro) and then one for my site.

Setup Nginx Proxy

Will it never end? The reason we want to do this, and this is why we’re on nginx and not apache, is in order to have a pretty URL without the port number.

Log in to your server as your ‘normal’ account (the one who owns the domain, not the admin) and make an nginx folder for config:
```
cd ~
mkdir -p nginx/ghost.elftest.net
```
Then make a file called ghost.conf with the following:
```
location / {
    proxy_set_header   X-Real-IP $remote_addr;
    proxy_set_header   Host      $http_host;
    proxy_pass         http://localhost:2368;
}
```
Restart nginx (which yes, you need the sudo power for so yes, you need an admin account) and it’ll magically work. If you get a “502 Bad Gateway” error, it’s because Ghost isn’t running. Speaking of…

Make Ghost Always Start

Okay so I actually do need my admin account. I went with the init script approach to keeping the Ghost always on.
```
$ sudo curl https://raw.githubusercontent.com/TryGhost/Ghost-Config/master/init.d/ghost \
  -o /etc/init.d/ghost-elftest
```
Then I edited the ghost-elftest file:
```
GHOST_ROOT=/var/www/ghost
GHOST_GROUP=ghost
GHOST_USER=ghost
```
I changed that to where ghost was really installed, but it brings up an interesting thought. What if I wanted multiple ghost instances? Well that’s actually why I named the file ‘ghost-elftest’ instead of ‘ghost’ (which they recommend). With this setup, I can name an init file for each instance and run the commands as sudo ghost-elftest start and so on. Keep in mind, you also have to pick a custom port for each instance.

There are three final commands to run in order to force Ghost to start up on reboot:
```
$ sudo chmod 755 /etc/init.d/ghost-elftest
$ sudo update-rc.d ghost-elftest defaults
$ sudo update-rc.d ghost-elftest enable
```
Now I can use Ghost to my heart’s content.

Conclusion?

A WordPress killer this is not. It’s just not. If they can make it run without the need for admin/root/sudo access, it has a chance. Once it’s set up, it’s quite nice, but the 5 minute install this is not, and it’s going to need that to beat the beast.
11 May, 2015
Mailbag: Ghost Image Errors
Once I got Ghost up and running, I got some errors and there was venting around the usual places. Image uploads were failing. I cried. Then I solved it. Then someone asked a logical question.

How did you fix the image upload issue?

What happened was that I found I was getting a Wiggly Cat whenever I uploaded an image. Eventually the upload failed.

The cat bounced up and down. My wife eyed it and said “That’s not much of a chuffing SOS now, is it?” (no, she’s not British, but what else can you say about that?). Thankfully, after years of WordPress support I went right into the file system and checked if the images were being uploaded at all. Answer? Sort of.
```
$ ls -lah
total 0
drwxr-xr-x 2 elfghost elfgroup 131 Apr 15 17:22 .
drwxr-xr-x 3 elfghost elfgroup  23 Apr 15 17:12 ..
-rw-r--r-- 1 elfghost elfgroup   0 Apr 15 17:13 f4c134eb021e026414a1bd23d3c5c927-1.jpeg
-rw-r--r-- 1 elfghost elfgroup   0 Apr 15 17:12 f4c134eb021e026414a1bd23d3c5c927.jpeg
-rw-r--r-- 1 elfghost elfgroup   0 Apr 15 17:22 unicorn.jpeg
```
0 bytes isn’t right. But again, WordPress support history to the rescue. I checked my /tmp folder, saw it was full, turfed the entire thing, and the upload worked. Rather fast, too, since it’s not making an image resizes. I will note, had that fix failed, I’d have started playing with folder permissions, but since I got the 0-byte version, I was reasonably sure that wasn’t my issue.

Two humor tidbits for you.

Bing thinks I write in Turkish:

Here’s a cute bouncing cat:

Pusheen The Cat
8 May, 2015
NUX: Setting Up Ghost (Self Hosted)
Once I used Ghost Pro, I thought about self hosting. I have a WP site that’s basically wasted as a WP site. It’s small, it’s static, and it rarely changes. I thought it would be perfect for Node. There are also a couple of small, basically HTML, sites I run in the back of things. This would be fine to manage that.

But first I had to address a major misconception.

You Install Ghost on Your Server

For some reason in my head I had this working like Jekyll, which I would install on my computer and push up to my server. No, I’m not so much installing Ghost as Deploying Ghost.

But I Installed Ghost On Your Computer

I decided to do this anyway, just to see what I was getting into.

To install Ghost you must install Node.js first. Since I have Homebrew, this is two commands:
```
$ brew unlink node
$ brew install node
```
I had an older version of Node.js installed for whatever reason.

Sadly I can’t install Ghost this way.

Next you download Ghost (I was download 564,730) and at this point I hesitated. The directions don’t tell you where to put the files. It just says this:

Next, grab the newly extracted ‘ghost-#.#.#’ folder and drag it onto the tab bar of your open terminal window, this will make a new terminal tab which is open at the correct location.

Since I know that upgrading involves replacing the files, I’m no fool, and I made a new folder setup: ~/Sites/ghost/sitename.com/ That’s where I ran node commands:
```
$ npm install --production
$ npm start
```
Done. Now I have Ghost up and running locally.

Install Ghost on My Server

In a word? Ow.

The main issue is Node.js and Apache both want to use the same ports. That’s impossible. And I want to keep Apache running port 80 because this VPS runs… well… WordPress. This is where I stopped the first time I tried to do all this and tossed this post into a long draft.

There are directions on How to Host Ghost on an Apache Subdomain, which luckily is what I wanted to do. Except it was complicated and messy and required root.

So the NUX here? Absolute crap. It’s just not something a new user would want to do, be able to do, or be able to maintain.

And that sucks.

Ghost’s got a great interface, one that I like better than WordPress for blogs and simple sites. It’s nailed simple in a way we crave. But it came at a cost. WordPress’s simple to install is fraught by it’s IDIC complex. Infinite diversity in infinite combinations, with the themes and plugins, lends WordPress amazing abilities but a pretty insane learning curve. Ghost I could sort out in a couple hours but you really can’t do too much with. I wouldn’t use it for a store. I might use it for a blog if I had to start over.

Except I can’t (easily) self host it because of stupid Node.js.

If they can sort that out, make it so I can easily, without root, install and manage Ghost, I’ll be back.

Until then, Managed Ghost Hosting is the way to go. Or WordPress. Take your pick.
29 April, 2015
Detoxify Your Website
The following are my speaker notes for WordCamp Minneapolis 2015. The slides are up at https://helf.us/wcmsp2015/:

There Are Many Kinds of Toxic People
- The hater
- The know-it-all
- The concern troll
- The Pilkunnussija
When your site gets popular, you get a diverse group of regulars. Not all are created equal. There’s the hater who hates you all, the one who knows everything, the one who CLAIMS to want to help but really derails you on small things, and then… Well you can google that last one, but the short version is the one who says “you spelled it T E H” in the middle of a passionate discussion about the next season of Sherlock, and Oh my GOD did that really matter?

You Dread Your Own Site

Where Did The Fun Go?

You used to love your site, seeing the comments, checking out what the new people had to say. And now, thanks to those other people, those toxic people, you hate your own site and you’re pretty sure the community is going dark and twisted and you know what it’s time for?

Cleanse Your Colon

Keep your Community Healthy

It’s time to give things a scrub. There are only four steps to being able to survive a successful blog cleanse. If you’ve ever tried those cleanse drinks, you’ll know that it’s not easy to make it through, but you can do this. Just … don’t Google Image search ‘colon cleanse’ please. I regret that.

Step One

Forget the First Amendment

You know the one. The one people always throw out at you, that they have the “right” to say what they want? They don’t. They just don’t. They can shut up now. The site is yours, you bought the domain, you pay for the hosting. The First Amendment has never had any bearing on our blogs so don’t be afraid to delete comments.

Step Two

Be Consistent

If you’re going to clean your site and make sure it’s what you want to be and do and work on, then you need to make your rules and stick by them. If a rule is “no talking about George Clooney’s personal life” then you have to be strict. Keep it solid and don’t waver, not even for yourself.

Step Three

Arm Yourself

WordPress has some built in tools that most people use when thinking about spam, but what if I told you to use Comment Moderation on their key phrases. What if you took the people who slammed you and attacked you and put their emails in the block list? Done. Get them out of your life.

Step Four

Trust Yourself

If you get that feeling, that gut feeling that says “This is about to go wrong” then you need to believe yourself. Trust yourself. Have faith that you know the vibe of the site you’ve been working on all this time.

WordPress Tips
- Use the Comment Moderation and Comment Blacklist
- Use plugins like Comment Probation to monitor new people
- Watch their IPs
Outside WordPress
- Block them from your email
- Use Twitter and Facebook’s block functions
Don’t Give Up

I’ve been wrangling communities online for a long time. I’ve faced burnout and exhaustion and pain. But I’m not alone. I have the other communities like mine to lean on. I have fellow forum mods to ask for backup. I have friends who tell me I’m going too far.

Don’t give up. You’re not alone.
27 April, 2015