Category: How It Is

Making philosophy about the why behind technical things.

To Fork Or Not To Fork

Sometimes the question you have to ask yourself is if you should fork. With a plugin, this is a fairly easy conversation. You want functionality, the original author doesn’t, you fork. But when you look at a theme, you start getting into messier territory.

In many ways, a theme is ‘simpler’ than a plugin. Theme devs, don’t shoot me! What I mean is that a plugin can be or do anything, but a theme is always a theme. While it may change how your site looks in amazing ways (and I am constantly in envy of people who can visualize like that), it really is just a theme. This is why reviewing themes is easier to monitor and manage than plugins. But that’s another conversation. The point here is that when you want to extend a theme, you make a child theme. Done.

What happens when you’re already using a child theme, though? StudioPress, a theme shop I love, makes child themes and sells those. This site is using a child theme, though it’s currently one of my own devising. Previously, it was using a child theme called Streamline, however, and it had a lot of changes.

So when do you make a child theme, and when do you extend it in other ways? It really depends on what you’re doing. While I sat and tried to figure out where my personal breakpoints were, I realized that since the best themes know they are a theme, and not a plugin, it was really easy. A great theme lets you seamlessly use a plugin to add in functionality. They may even tell you what the best ones are. Recently, Coen Jacobs wrote about how good themes never bundle plugins and he’s right. A plugin is a plugin, a theme is a theme. Keep ’em separate, keep ’em safe.

I’ve done it in three different ways for three different sites, and I’ll explain my rational below.

The Simple

One site is simple. Every ounce of functionality I needed, and more, was in the core code of StudioPress, not even a child theme was needed. All I wanted was to change some colors and add in a couple CPTs and shortcodes. That was easily done via Jetpack, which has a CSS editor, and a couple plugins. Actually, 99% was the CSS, once I sat down and looked at it. All the weird stuff was normal plugins.

Sometimes simple is a teeny bit complicated, and when that happens, I may make a custom mu-plugin or two, but in general, not so much needed unless I want a Custom Post Type. And anyway, I never put a CPT in my theme if I can help it.

The Complicated

On the other hand, one site is hella complex. I found a theme I really, really, liked. Almost. And worse, this was a child theme. It was exactly what I was afraid of. There was no way I would get what I wanted out of this theme unless I edited the functions.php file, a lot of the CSS, and a ton of the images. Could I still have done this via CSS and a couple plugins? No. Well, the CSS yes, but not the code. I had need for some crazy functions, a total re-write of comments, and the list went on.

In this case, I forked. I ripped out the small amount I never wanted. I added in the medium amount I did want. I directly edited the theme’s CSS, added in a post template, and changed all the images to my chose color. I even added in a different font. Could I have re-written from scratch? Of course, but the theme had 90% of what I already wanted to do.

There actually is a step before forking, and that would be using plugins. I know I mentioned plugins before, with the simple themes, but actually most theme frameworks are extra special. They often have custom plugins like Simple Hooks, which fundamentally lets me do everything I might do in a functions.php file for that theme. This means most of the time, I don’t fork. But. This theme really was so complex that I needed more than just the simple hooks. Genesis Complex Hooks may have done it, or another plugin to make a transient functions.php (ala CSS editing). And that would have done it except for when I wanted to change a lot of images, add in JS, and then a custom page template …

Well you see how it goes. The point here, however, is that I sat and thought about it, studied my setup, and made a long term decision. Originally I was using the plugin way, but when it stopped being extendable, I decided to do this, and I regret nothing.

The Original

The last option I had was I theme I kind of liked, but it was old. It was pre-HTML5, it didn’t have microformats, but more-over, it wasn’t aging as well as I would have liked. I made a list of what I liked about it, what I didn’t, and what I really wanted. While the list was short, it was also clearly not going to just be CSS. I wanted a custom front page, an extra page template, images, and Genericons built in. In short, I wanted this theme to be something that could carry me onward, regardless of a plugin, even one I wrote.

I have not made my own, 100% from scratch, child-theme in a long while, and this one may not really count since I was designing it to look like something else. This took me an afternoon to bang out the basics, and a couple days of minor fixes here and there to perfect them. Release and iterate, as they say. Certainly, I could have taken someone else’s theme, but it was going to be a surprising amount of work to do that. Instead, I made a list of my needed features and my desired options, and went to town. It’s still a pretty simple child-theme (which speaks well to the inherent extensibility of the parent), but now it’s mine, and it’s easy to extend it and expand it.

The Rest…

What about you? What do you think about when deciding how to handle a theme that needs changing?

17 June, 2013
DreamPress: We Went There
Not the most flattering picture of me…
One of the projects I’ve been involved with since I started here at DreamHost has been a secret. Actually two of them were, but we released one already. Anyway. The one we pushed today is DreamPress!

What is DreamPress? Here’s marketing:

What is DreamPress? That’s a good question! Think of WordPress. You got it? Cool. Now, think of that WordPress install, but on steroids! Picture it running on a specialized, optimized, virtual private server. Yeah, this is far from your average WordPress hosting package, isn’t it? DreamPress comes pre-configured by our in-house WordPress experts for maximum security and performance under traffic load. This is our call-out to all entrepreneurs, website designers, developers, and bloggers to give it a test-drive today!

And here’s me:

If you did your job really well, one day you woke up to a downed website becuase you swamped it with traffic. I’ve been there, you’ve been there. There’s a point where your host reaches out to you and says “Honey, sweetie pie, you’re too big for shared hosting.” And as horrible as this is, it’s a good thing! You’re popular! Of course you’ll try caching and changing themes and plugins, but there’s just that moment when, damn it, you’ve got to step up and go up to a VPS.

And you know what? A VPS is scary. I started this blog when I got my VPS because I wanted to learn how to manage it. But you see, I’m weird. I know it, you know it, that’s okay. I’m strange and I like me, just the way I are, and this works for me. It doesn’t work for everyone, so when you find yourself faced with something new and different, maybe you don’t want to learn it. Maybe it’s not your thing. So looking at that VPS is a great big bag of nope.

This is where managed hosting steps in. Hosts take on the job of managing your server. We handle upgrades (which yes, we do anyway), but we also optimize and customize the server. All the times you hear me talk about ‘Edit your httpd.conf’ or ‘installing PageSpeed…’ is something we’ve already done for you. Need more memory? We’ll take care of it without bothering you. It’s a VPS without the responsibility. PHP memory, server power, even caching is taken care of. Oh yes, you no longer need any caching plugins, because we’ve got Varnish in front for you.

Of course, this isn’t perfect for everyone. Hard-core code jockeys may want that VPS (or dedicated) to play with the nuts and bolts, install extra add-ones, and just go to town. But if that isn’t for you, come check out DreamPress. I promise we’ll have a magic button to migrate things soon!

Nifty articles on DreamPress:
I know there are a lot of hosts out there. I work for one, I use others, and I think the more of us who get into this supporting the app that needs supporting, the better experience for everyone. Bring it on, baby!
4 June, 2013
Not RSS 2 Email
Back in 2011, I made an RSS powered email list using rss2email. The last new version was released that year, and while the last two years have worked perfectly well, there’s one small problem. The developer appears to be done with it. This happens, and the beauty of open source is that people can pick up the code, fork it, and carry on. The annoyance is that sometimes the new coders do things that break it all for you. In this case, the running fork of rss2email uses Python 3.2 or higher.

If you’re using Python 3.2+, grab rss2email the new version and off you go! But if, like me, you’re on a server that doesn’t come with that version of Python, you can start swearing. This is not something you can just upgrade, either as Daniel Eriksson explains how to do this on CentOS 6 (my flavor). Many different flavors of Linux use the old 2.x branch of Python, and there are no plans I’ve seen to upgrade any time soon.

Now I’m faced with a dilema. Do I mess around and upgrade on my own, or do I find another answer. You know I went with option B, right?

I sat and thought really hard about what I, personally, needed this to do. This is a key component to any code you’re going to write. Make sure you know what you need. Let’s break things down:

Needs
- Email to be sent to a specific address automatically when there’s a new post.
- No email sent on pages or CPTs
- Post ‘excerpt’ is message content
Wants
- Change ‘to’ email on the fly.
- Select full post or post excerpt in email
- Customize ‘from’ email address
Dream Future
- Ability to say “no, not this post”
- Customize email message
- Allow options for different post types to get emailed
That’s pretty simple, isn’t it? It’s clear cut what I need, what I want, and what I’d like to have if I have time. Not every project is this simple, but today it is.

I actually knew how to do my ‘needs’ already, but as soon as I tested it I found I had to expand on what I meant by ‘when there’s a new post.’ If I hooked into the publish_post action, the email got sent every time a post was updated too. This lead me down to Notifly, which emails a list of people for every post and comment, but not post updates. That gave me the magic of transition_post_status, which solved that first problem.

At this point, the question became “Why not just use Notifly?” The first problem I had was that it sent out emails for comments too, with no easy way to turn that off. I could have forked, and I started looking into that when I ran into problem two, which was I couldn’t change the ‘from’ email. This was something that became a bigger issue later, when I realized I needed to be able to change the from email to work better with restrictions on certain hosts and with certain mailing lists. I could still edit the plugin, but I looked at what that plugin did and what I needed and wanted. Editing Notifly to do what I wanted would mean overcomplicating it and adding a lot more options. I could fork it, but I’d be stripping everything out and rewriting if I did that, so I decided to carry forward with my own thing. I would say the plugins are similar, cousins, but approach the goal in different ways. Semantics, I know.

Once I mastered only emailing on post publish, I had to tell it not to email on non-posts. No emails being sent on CPTs and pages was easy and I could have used is_post_type() and checked for posts, but I decided to use get_page(), because that let me expand on some other features later. This was new to me, but since I wanted to use the post excerpt, this was going to be, bar none, the fastest way to pull that in.

While I love being able to read whole posts in my RSS reader, I lose a lot with it, in regards to formatting. For the site I desired to run this on, the layout is a huge thing. On top of that, thanks to some idiots, I had to turn on hotlink protection, lest they crash my server again. Also I use a lot of embedded media (HTML5 video, twitter, etc). That means the ‘whole’ post generally looks like crap. So for every single post, I custom craft an excerpt. And this is why get_page() was awesome, because I could use that to pull the excerpt.

The default WordPress emails are sent from ‘wordpress@yourdomain.com’ with the name ‘WordPress’ and while that’s great, I wanted mine to be sent from ‘Blogname’ (the email address was fine, I’ll just add it to the email list as a moderator). That changed my ‘want’ of being able to customize the from info into a ‘need’ but it was also pretty easy to do.

If I was only going to use this code on one site forever and ever, I’d probably leave it at this. But … I know I’ll want to use this around other places. I started by looking at my ‘wants’ and put those in as well.

So what did I end up with?

Post2Email

This is a simple WordPress plugin that lets you set a to email, a from email, and a from ‘name’. It uses the RSS settings to determine if your email body is the full text or the excerpt. It only emails on posts, not pages or CPTs, and not for private posts. You can only set one email because of reasons, first being I only need to send to one address, but second is that I really hate when people send me emails I don’t want or need. Limiting the number of emails you can send to will help that. It also helps you not piss off your webhost by spamming people. Seriously. You use my plugin to spam people, I will hurt you.

What about my dream features? Handling the different post types means using get_post_types(), which isn’t horrible. In theory it’s just a check ‘If the option for that post type isn’t checked, fail out.’ It’s not something I need, and I really don’t feel like auto-emails for everything is a good idea (pages and CPTs are not posts!), so I’m going to wait and see if this is a need for people.

Flagging per post I have no idea how to do, since I don’t yet know how to put a custom post option like that per-post and check it on publish. Yet. Since public posts are public, I think that it’s fine having it email on all public posts. Opting out like that is not for me, but if enough folks come up with it, I’ll consider it because it’s a good excuse to learn something new.

Customizing the message is easy and when I went back in to fiddle with internationalization and proper content serialization, I added it in. I also went and used wp_parse_args to remove setting the defaults in the database, and make it easier for me to add more options in later.
22 May, 2013
Jetpack Koolaid
Credit: Nivole Lorenz 2010. Pencil sketch on copy paper.
Sometimes I draw unicorns. Sometimes they have jetpacks.
WordPress Jetpack gets a lot of grief, and for an understandable reason. From some perspectives, it does everything we hate about plugins. But there are reasons and methods behind the madness. I’m going to hit them from my perspective as best I can, without ever considering the ‘Automattic sucks!’ arguments I’ve heard. I’m reasonably sure Automatic is neither trying to be a dick nor are they evil (egotistical maybe, but not evil). If you go in assuming there has to be a reason for all this, even if you don’t like it, you can understand it a little better.

Why one big plugin and not 20+ separate ones?

Actually I’m going to come back to this one, but there’s a reason, so hang on.

Why do I have to connect to WordPress.com?

This is a better place to start. You have to connect to WordPress.com because they’re providing a service. Not everything runs on your server, so in order for the modules to work, you have to let your server talk to WordPress.com. That one makes sense to just about everyone, I hope.

Less obvious is exactly how this benefits you. I’ll give you a real annoying example: Twitter’s API. You may not know, but Twitter throttles API usage based on IP address. So if you’re on a shared server, and everyone uses Twitter on their blogs, you may get your API cut off and no Twitter updates show on your site. Bummer! On the other hand, WordPress.com has a gimmie from Twitter, letting them post as much as they want.(Probably not unlimited, but enough for us.) This is also true of Highlander (aka the comments plugin), which transmits data between multiple hosts instead of you having to set up OAuth, which if you’ve tried, you’ll see why Jetpack Comments are way easier.

But why do I have to connect to use any of the modules?

This usually comes up when someone only wants to use one feature, let’s pick the contact form, which doesn’t need to communicate with WordPress.com to run. The best reason I had is ‘It’ll make it easier if you later decide to turn on the other features later.’ I tossed this around for a while, considering the users I work with every day, and I’ve finally agreed that for the common user, it’s better to have to do one setup, once, and be done.

After years of free support, and now doing this for a living, the common user doesn’t have the experience to understand that while I may need to connect to WordPress.com for the stats, why do I need it for a mobile theme? The problem comes up when the user wants to start with the items they don’t need to connect. Springing it on them later is an uphill battle I wish I didn’t have to make. So yes, it’s sensible for the average user. As Helen said, Jetpack is for users, not developers.

Anyway, if you know for sure you (or your client) will never want to connect to .com, then you can use the new development mode (as of version 2.2.1) and add define( 'JETPACK_DEV_DEBUG', true); to your wp-config.php file. Done.

If the .org repository doesn’t let people host marketplace plugins, what’s up with VaultPress?

VaultPress is selling a service, not a plugin. It’s hairsplitting, but look at Akismet (which also could be a pay-to-use product). It’s ‘free’ but you’re encouraged to pay. If they went pay-only, which I could easily see them doing if they started over, they would be a perfect candidate for Jetpack. Where VaultPress rubs the ‘Hey wait…’ button is when you remember that there is a separate plugin for it. So this is like if they let you signup for Akismet within Jetpack… Oh, wait, Akismet’s links are in the Jetpack menu now. Still, of all the questionable things Jetpack does, this is actually the only one that really makes me Spock the Eyebrow(Yes, that is what the favicon is.) because it’s just a little off.

Why the auto-activate?

Users won’t know otherwise. If you don’t turn things on, they’ll never see it. I don’t like it, especially when I’m using a plugin that got folded in (see CSS editor or Grunion), but they learned the Grunion lesson! When the CSS editor joined Jetpack and I upgraded, it turned off the old editor. That was smart, and takes away my User-Ipstenu complaint of auto activation. Remember! This is a user plugin. Not a developer one. Calm yourself.

Why is it one big plugin?

This needs some history.

A few years ago, the concept of ‘Canonical Plugins’ (or Core Plugins depending on if you asked a core contributor or anyone else) came up, and it was an idea for stuff that is (or used to be) in core, but wasn’t used all the time. Examples of this would be the content importer plugins which are used once or twice in a site’s lifetime. To quote the original poll and announcement:

Canonical plugins would be plugins that are community developed (multiple developers, not just one person) and address the most popular functionality requests with superlative execution.

That was 2009, and here it’s 2013 and we don’t really have any yet. Jetpack certainly isn’t one, though in many ways it hits those ‘popular functionality’ feelers dead center. In a way it is a canonical plugin, but it also clearly illustrates why some of the most popular plugins would be very difficult to pull off without the infrastructure that Automattic already has. So while I wouldn’t call Jetpack a ‘Core Plugin’ (it’s not community developed), it’s sort of a great example of what a core plugin suite would look like and the issues with it.

Now, why is it a ton of plugins in one? Well why not? A lot of people hate installing six or seven plugins because “it makes their site slower” (not really), and the way Jetpack does it is remarkably elegant, in that you can turn off the parts you don’t use. The problem I have with Jetpack is it’s size. It’s big. It’s almost the size of WordPress and at 4.2 megs, it’s slow to install. I find that it’s way easier for me to run via wp-cli and upgrade, but not everyone has that option.(That said, I don’t have a problem upgrading on my smaller sites when they don’t get a ton of traffic. Upgrading on my busiest site while it’s busy is always stupid and I know it.) The size problem is also a hassle because WordPress doesn’t (yet?) do incremental updates for Plugins. When you have a series of upgrades then security fixes on a large plugin, it’s annoying.

More likely is the idea that these plugins can share APIs and features if you lump them together, making one big plugin smaller than twenty-odd separate ones.

What is this dev mode of which you speak?

Oh it’s neat. Put define( 'JETPACK_DEV_DEBUG', true); into your wp-config.php file and here’s what happens:
1. Everything defaults to OFF
2. You can only activate the following:
  - Carousel
  - Sharing
  - Gravatar Hovercards
  - Contact Form
  - Shortcodes
  - Custom CSS
  - Mobile Theme
  - Extra Sidebar Widgets
  - Infinite Scroll
The only ones missing that surprised me was LaTeX (I guess it phones home to parse…) and the new Tiled Galleries. Why is that cool? Well now you don’t need to connect to WordPress.com to run those things!

Are you drinking the kool-aid?

Oh. Probably. I honestly like Jetpack. I hate having to set it up for clients (I end up in an Incognito Window, creating a new WP.com account for them, and that whole hassle), but once it’s done, it’s really worthwhile. It does everything I need and while there are parts I don’t need, I’ll live with it. That said, having it set up for people like my father means there’s less I have to worry about with finding plugins for him. Most of what he needs is right there in Jetpack.

I hate Jetpack, I’m never going to use it!

Okay. Don’t use it.

I’m not defending it’s uses for all cases. If Jetpack doesn’t fit what you need, don’t use it! That’s totally fine. I just hate reinventing wheels. There are always alternatives to what Jetpack’s got (Contact Form 7, Google Analytics, and so on), so you can use any tool you like. There are pros and cons with everything, and it’s up to you to decide where your own break point is.
7 May, 2013
WordPress False Security
Credit: Grafitti Verite
I wrote this months before the botnet attack of April 2013, but I kept putting off posting it. Clearly now is the time! So since people often ask me if I do certain things to protect my site, here’s what I don’t and do do.

What I don’t do

• Hide the WP version in my HTML
• Remove readme.html
• Hide login error messages
• IP blocking*
• Use a different prefix for your DB
• Move wp-config.php*

I don’t bother with the readme or the WP version because it doesn’t matter. People don’t actually search for ‘Who’s using WP 3.4.2? I’ll attack them!’ They let slip their dogs of kiddie cracker war and bury us in traffic. I learned that lesson with the TimThumb debacle. My server got slaughtered by people not searching for TimThumb, but slinging attacks at me as if I had it installed! Even better? They didn’t bother to differentiate where my install where WP was in a subfolder (domain.com/wp/) and just attacked domain.com/wp-content/themes directly. The same thing happened with the recent botnet attacks. Basically people are going to attack me, assuming I’m vulnerable. It’s only when I’ve pissed someone off directly that I’d worry about having a specific version being an issue. And since I keep up to date with upgrades and patches, I don’t worry so much at all.

The error messages thing stems from people worrying that failed logins to WP will tell you that you got the username or password wrong. So if I login as Lpstenu, it’ll say ‘ERROR: Incorrect username.’ That apparently spooks people, thinking that if you know that you’ve gotten a right username, you’ll hammer that. Do me a favor. Go to yourdomain.com/?author=1 and what happens?(This doesn’t work on this domain because I created it back when WP defaulted your first user to ‘admin.’ I made a second ID and deleted that one.) That’s how much effort it takes to find your username, folks. It’s even easier when you look at this post and see the author name, and a link to it, right there in front of you. Your username isn’t a secret. It’s dead easy to get. I’m not wasting time hiding something that easy to find.

That’s not really a valid “security” improvement, anyway. It’s irrelevant whether the attacker knows what he got wrong, as it provides no extra information that would help him to get in. Furthermore, the usernames are exposed in dozens of other places already as I showed you before. I often argue that you can’t remove doors: everyone has to be able to get into a house, so we put locks on our doors as deterrents, and signs up to say we’re watched by ATD or whomever. All of those can be circumvented, and you still have a door. Most crime is prevented by deterrents, however (a sufficiently motivated and skilled person will work around anything), so really all we do is make things inconvenient enough that they go somewhere else.

Part of security is knowing where to spend your time. Make a better mousetrap and you get smarter mice, true, but if you still want to get rid of the mice where do you start? I start with not hiding the obvious. Here’s my username, here’s my login location. They’re standard on most websites, because people have to be able to log in. Now when I really have a locked down site where I want no one but me to log in, I use .htaccess to limit login to just my IPs. This is a (minor) problem when I’m on the road, but I can always SSH in to fix that. Most of the time, though, I trust in my firewall, my server, and the basic security of WP to be enough.

IP blocking is totally useless to me. With a caveat. I use CSF and ModSecurity on my server which will block by IP if you hit very specific abuse parameters, including my newer ModSec rules for protecting logins. However I don’t pay much attention to it, save to whitelist my commonly used IPs. The point of the firewall is not to stop people I know are bad, but to dynamically catch them in the act, block them on the fly, and then let that IP gracefully expire after a certain amount of time. Years ago I may have had to use .htaccess for that, manually updating it to block specific IPs, but software’s come a long way, and letting the right tool do that job is huge. If you only have .htaccess, well, you can use some .htaccess protection of logins, or you can use Perishable Press’s 5G Blacklist. As I tell people frequently, you never know where legit traffic is coming from, don’t be foolhardy.(True story. A customer at work insisted he did too know better, and blocked China and India traffic. Then he went there on vacation and was pissed he couldn’t log in. Yes, I mentioned I had warned him before.)

Curiously controversially, I don’t mess with the DB prefix. I use wp_ much for the same reason I never move my wp-content folder unless I’m using CDN (and even then…) : Poorly written plugins and themes will kill me, and people can view my source code or use DB insertion calls in their code. They don’t have to know my prefix, and in fact, best coding practices are intended to work no matter where the folder is or what you use as a prefix. The other reason is I’m exceptionally lazy, and the less I have to remember that I did ‘differently’ in case of an emergency, the easier my life is. This is important when I’m ever hacked (yes, when), because I can restore faster from scratch if I didn’t go nuts reinventing the wheels or moving things around. Rebuilding a wp-config.php is very easy if I only have to change passwords and user IDs, after all.

Similarly, I don’t move my wp-config.php in most cases. I do on my localhost instance (so I can wipe the folder and DB and start over easily), but really it’s impractical in other situations for me. I think it would be safer to move it out of a web-accessible folder, and when possible I do that (sometimes I have WP in a subfolder) but I have other things I can do to protect that file.

What I Do

Besides a massive amount of work keeping my server up to date and tuning my firewall, I do some things that anyone using WordPress can do:

• .htaccess protect wp-config.php
• Lock file permissions
• Prevent plugins from writing to wp-config.php and .htaccess
• Prevent folder content browsing (for images mostly, but also plugins)
• Use strong passwords for WP/FTP/SQL accounts
• Use one-time passwords for WP/SQL/FTP/SSH accounts

I protect my wp-config.php from direct access with a really simple .htaccess directive:
```
<files wp-config.php>
order allow,deny
deny from all
</files>
```
I think nginx is this:
```
location ~* wp-config.php { 
    deny all; 
}
```
This means you can’t see https://halfelf.org/wp-config.php in your browser. It’s pretty minor, in so far as things go.

I lock down my file permissions as tight as I possibly can. Nothing is set to 777, and my .htaccess isn’t writable. This means if I use a plugin that wants to edit my .htaccess (or wp-config), I have to do it manually. This is good, in my opinion. I always know exactly what I’m doing. In my .htaccess I also have Options -Indexes, which stops people from being able to browse empty folders (this is important for plugins that don’t have an index.php file). Since I’m using SVN and Git, I also prevent people from seeing those:
```
	RewriteRule ^(.*/)?(\.svn|\.git)/ - [F,L]
	ErrorDocument 403 "Access Forbidden"
```
My passwords are stupid complex. I haven’t the foggiest idea what they are thanks to 1Password. I also don’t reuse passwords. This is very important for how my server is setup, as DSO requires you to enter in passwords to upgrade WordPress. While I can use my main account, I actually created an FTP only account for each and every website on my server, and then I hard coded that (and it’s password) into my wp-config file. So yes, I have a DB password (each account is used once for each DB) and an FTP password (again, one account for each account) in my config. And no, I’m not worried about that. Sometimes I have a generic SQL ID for all DBs under one account, though that’s a tiny bit more risky.

But, most importantly, I try to cure myself of being stupid. I don’t log in to my site via non-secure ways (SSH & SFTP only). The passwords I use for my login (which is not SSL protected on WP) are one-account/one-use. I try never to log in on someone else’s computer. I don’t do admin work on potentially unsafe wifi. You see, the greatest security risk in the world isn’t the software you’re using, it’s you. You do stupid things, like recite your credit card info (or password) over your cellphone while on a train trying to get your host to reboot a server. You use Starbucks’s wifi to pay your bills. You talk about how your mother changed her name.

Social engineering is way more dangerous than any server hack, and when it’s down to the wire, that’s what I’m more worried about. After all, I have good backups of my files.
16 April, 2013
Your Photos, Your Way

I’m funding PressGram on Kickstarter and you should too.

I like Open Source. Surprise!

I don’t mind paying for products (as witnessed by the fact that I have paid for this theme, and even the old DevPress and ThemeHybrid ones I don’t use anymore. I have a slew of plugins I paid for, and all in all, I think every dime was money well spent. Paying for open source makes sense.

So there’s this guy I know from the Internet, John Saddington, who likes taking photos, and he likes social media, but he wonders, like I often do, what happens when those outlets go away? Where are all my photos if TwitPic or YFrog vanishes? Or if Facebook deletes my account?

They’re gone.

John loves WordPress. So do I. John loves photos. Well. I fiddle around with them, but the point is he wants to built something that is way more than ‘just’ a plugin. He wants to make a free iPhone app… look, this is what he wants:

The premise is simple: I wanted to post filtered photos from my iPhone 5 but without worrying about any privacy or licensing issues (and we’re not interested in asking you to upload photo IDs). In other words, I wanted complete and total creative control of my images and content (as well as the pageviews).

And this will post to WordPress, which is so simple, we have a one-click installer at DreamHost for you to use to make it. Imagine that. You could have a photoblog with a couple clicks.

When I read that John was making PressGram, I had to poke at it, even though it’s not Open Source. It’s an Apple iOS app. I’m not shocked that it’s not open source, and after consideration, I don’t mind. It doesn’t have to be. As long as the plugin is open source (and frankly, given WordPress’s API, I can easily envision how it would be without stepping on closed source apps), it’s good to go.

John knows his shit. He shares the same concerns and doubts about social media as I do, he rails on Facebook for the same things I do. He’s a guy whose ethics I can get behind. And he’s a guy whose code I can get behind. Remember I review plugins. I’ve seen his code. It’s good.

So yeah, I’m supporting him so you can have a free app. Go figure. And as with most of the things I kickstart, I get no swag back (I think I get a kudos and a link somewhere), because I like to give for the spirit of giving most of the time. I’ll be getting the Veronica Mars DVD, but I’d be buying that anyway.

Give in. You know you want this. Pay $5 instead of risking your content belonging to someone else.

6 April, 2013