Author: Ipstenu (Mika Epstein)

Newsletters Are Still Cool

It started with a mention:

Okay, who has tinyletters?

— Mel Choyce-Dwan (@melchoyce) April 7, 2015

And I went and looked up TinyLetter

It’s simple. It’s as easy as writing a blog post and boom, you’ve sent a mail. In so far as that goes, it’s awesome.

It’s too simple. There isn’t a way to really automate it.

It’s really cool. It just works and sends out a nice, easy to read, email.

It’s really annoying. You have to get folks to sign up.

I really want to like it and use it, but I’m not sure I have a use case. Thanks to Jetpack, I push to LinkedIn, Facebook, Twitter, etc, and my family sees the things. They sign up to Jetpack emails for in-boxes.

But if I needed a newsletter, I’d use TinyLetter.

6 May, 2015
Update Fatigue
The week of April 20th saw a lot of WordPress related updates:
1. WordPress 4.1.2
2. WordPress plugins with a major security issue
3. WordPress 4.2 and 4.1.3
4. A bunch of themes fixing the same issue plugins had
5. WordPress 4.2.1 and 4.1.4
I don’t know about you, but even with automated updates, I was tired of all the updates. I was also tired of explaining to people that, yes, those security issues were a massive hole and yes, they did need to be patched. And yes, I know it’s annoying to get all those emails and have to test all the things because not every plugin or theme is created equal.

In the midst of all that, I noticed one of my plugins had updated 6 times in ten days. That’s pretty much an update every other day and you know what? That’s way too much.

If I have to update your plugin every few days for minor releases, I’m going to stop using it. Update when you:
1. have a point release
2. are fixing really important bugs
Other than that, if you update every few days for minor changes, I really am stopping using your plugin because you are making my life annoying. You’re why people hate updating. You’re why they stop.

There are valid reasons for multiple releases in a week, like bug fixes for 0-day security holes that have already been publicly disclosed. But in this case, it was all minor changes, like adding languages and so on.

That was useless and pointless and annoying. Okay, fine. Maybe not useless or pointless. Those are important things to update. But when should you update them? Not every day, certainly, nor even every week. If you look back on my two simple rules for when you should update, consider them seriously.

Is this a bug or a new feature?

New features means new major revision unless there’s a reason not to. My plugin Genericon’d keeps pace with Genericons’ versioning, so while they’re on 3.3, I will update 3.3.1 with a new feature. The majors are at their behest, so I have to take control over minors only. It’s not ideal. I hate it but it’s the best way to make sure people know “Hey, this has version 3.3 of Genericons!”

New languages aren’t bugs nor are they really features, but they should only be added if there’s a major release. Alternately, you can slip them into a bugfix, but they shouldn’t be your only fix. As for the person who really needs the language? Make them available on git or svn and tell them to download and put it in the /wp-content/languages/plugin/name/ folder. Not ideal, I agree, but it’s a majority/minority issue.

How often should you patch bugs?

Is it a zero-day exploit, released in the wild, bug that’s breaking sites right now?

RELEASE THAT SUCKER!

Is it a minor bug that annoys you but doesn’t cripple the site? Make a dev branch, fix it, but don’t push the release just yet. Wait until you have a lot of bugs fixed. Or wait until you have the next major release.

Take a page from how WordPress.org pushes minor releases. Fix the bugs that need fixing. Solve the security problems. But updating every day? Not a great experience for anyone.

Opps! You missed a critical bug!

That happens. Update the plugin right away. Yes it sucks but see the bit I bolded above? That’s your exception. If you break something, fix something. We pushed 4.1.3 because we broke sites with 4.1.2. Period. Fix it.

But you’re sure people really want this new thing!

Maybe, but people also really don’t want to be hassled and you’re hassling them. People have (understandable) concerns about updates. They worry about bug fixes. They worry about how your change will impact all their other plugins and themes. Keep that in mind before you push a change or a fix.

Did you update that changelog?

It’s your code diary. For every good commit message there should be a good changelog entry. Just do it. You’ll be thanked.
4 May, 2015
Mailbag: What’s The Diff?

How do you compare two plugins to see if one’s a fork or stolen? What’s the difference between a fork and a clone?

Sometimes people like to ‘steal’ plugins. This normally happens when someone takes a premium (purchase only behind a firewall) plugin and attempts to give it away for free on WordPress.org. They tend to violate copyright when they do that, but also it’s just not a cool thing to do and I find it distasteful.

Often we catch these since people who steal like that aren’t always very smart and we recognize code that is generally well known and popular. But more often we don’t catch it because CodeCanyon has 3400+ plugins and WordPress.org has 37k+ and that’s a lot to compare and remember. And that’s when we get an email from a plugin developer who says “So and so stole my work!”

What do we do? We ask them for a copy of their code, in a zip, and say we’ll compare. Most developers are happy to do that. We’re a trustworthy lot, otherwise we wouldn’t be on the plugin team (yes, being a good, moral, and ethical person is very important). Once I have the zip, I download the claimed-clone and compare them line by line.

Well. Not really.

My toy is DeltaWalker.

With DeltaWalker I can compare two zip files without having to open the zips and look at each line. In the below example, I’ve got Akismet 3.0 vs 3.1.1 and I can see every single change just by tossing the zips in as files to compare:

DeltaWalker is so good, it helps me compare the readmes so I can easily see that someone has just fiddled with the original and not written their own.

What I look for is code style, formatting, and naming conventions. Rarely do two separate individuals use the same code formatting (tabs vs spaces vs tabs+space etc), so seeing their additions will jump out. Similarly, the code style, their internal logic, is often wildly different. Same with naming conventions.

When you look at it, it will jump out at you that generally all anyone does is rename functions or classes. They remove credit and copyright information too, and sometimes they mess with the help docs. Rarely do they add anything of substance. If they do then it’s a legit fork and we’ll push them to restore credit and copyright information.

But since it’s generally not, we will quickly see that the plugin is a direct, no feature added, copy, and remove it.

If this happens to you, if your plugin is ‘taken’ and duplicated without any code being added, email pluginsATwordpress.org with a copy of your original plugin (and a link to perhaps prove it’s you) and we’ll look at it. If you get an email where we tell you that your plugin is a copy, take a moment to review your code and feel free to talk with us about it. A ‘one line’ change actually MAY be acceptable as a fork, but it’s rare unless it’s adding in a massive feature, or totally changing functionality.

Above all, remember this:

Despite the fact that all plugins in our directory are licensed under the GPL or compatible licenses, we do not allow direct copies of other plugins to be re-listed under somebody else’s name. “Forking” is acceptable only when the resulting fork is of a substantial nature, or when the original plugin is no longer updated or supported.

Always try to contribute back to the original plugin’s authors if you wish to make improvements to the original plugin, instead of creating an entirely new version and thus creating incompatibilities and duplicated code in the repository.

Alternatively, write your own plugin to perform the functionality you want to have, drawing on ideas from the original. Ideas can always be copied.

1 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
Mailbag: Homogenous websites?

I have a site for my business that has multiple physical locations that have online booking for each location. Right now we basically have separate websites that look very similar for each location (except for some content) with separate domains [URLs redacted]. Is this what you meant by homogenous websites? If WPMU ins’t a good option, can you steer me in the right direction for how you would design this type of site?

Yes. That’s pretty much exactly what I mean when I call a site “homogenous.”

You can’t see it, but each URL I removed had identical design. Same layout, pretty much the same splash page.

When I talk about ‘sameness’ with websites, I really do mean exactly this. Each site on the network has the same information, the same about page, and actually pretty much the same everything except for the booking page.

Right now, each site has a locationdomain.com/book-now URL. Without looking at the code, I’m going to guess that the book-now pages are inserts. Either templates or shortcodes, but something that doesn’t need to be on the domain URL to be unique. Just some content in the page.

And I would have maindomain.com/book-location Or better still maindomain.com/location/LOCATION/book

That second example looks weird, I know. You see, I’d do it with Custom Post Types for each location. My CPTs would be pages and their slug would be /location/. Then each page would be LOCATION, giving me URL formats like /location/lexington/ and so on.

My thought process is that if the majority of the content of each site is the same, and the design of all sites are the same, then I don’t need a multisite unless there’s a specific need to silo data.

There are very few cases, in a homogenous network, where you need to silo data. Exceptions are pretty much all based on legal requirements.

And if you have a song in your head, here it is:

24 April, 2015