Author: Ipstenu (Mika Epstein)

Cheap Is As Cheap Gets
I have nothing against people on a budget. I understand not being creme-de-la-creme and needing to be careful.

I really boggle at people who want to run a company website, but feel $15/month is ‘too much.’

How much do you spend on your car every month? We’re talking gas, insurance, cleaning, maintenance, and so on. You do that for a reason. You need your car to get you places. It’s an investment in your work. You can’t get to your work without a car so you take care of it to keep it secure, you clean it because it smells, and you pay for insurance in case the worst happens.

Your website is running 24/7 and costs you $15/month and that’s too much for your business? You need to rethink your business model. That’s under $200 a year. That amount of money should be affordable for anyone who’s running a business, even on a shoe-string budget. What really gets me, though, is the person who emailed me saying $200 a year was too much did it from an iPhone. They had the ‘Sent from my iPhone’ signature line still on it. While it’s certainly possible they got a cheap pay-as-you-go plan and a used phone, the reality is they look at the cost and don’t see an immediate value.

Let’s turn this around.

$15 a month is about:
- six gallons of gas (from the Arco down the street)
- five fancy cupcakes from Wildflour Cupcakes
- four grande lattes from Starbucks
- three gallons of milk (probably less in some places)
- two craft beers
- one tin of canned unicorn meat
But we get an immediate value in all those things. We can see the gas, the cupcakes, the unicorn meat, and we see the direct application of our money to a ‘thing.’ A website is different. It is a nebulous entity and floats out there in the cloud. When you’re not selling anything on your website, what’s the point?

Lately I’ve taken to asking people “How much are you planning on spending on advertising a month?” If the answer is ‘nothing’ then I tell them they need to consider it for their company if they plan on getting anywhere. If the answer is a realistic amount, I tell them to allocate $15 a month for webhosting. They need to have a web-presence. It’s 2015, people will want to see who they are, so make a good, informational, site. Don’t put a ‘blog’ up unless there’s a plan to publish to it regularly. Don’t use code you can’t support. Don’t use a host where you can’t get your content back easily (which is really my only issue with things like Wix).

But $15 a month is pennies to the traffic a website can bring you. If you sell three gallons of milk a month, you’ve broken even, after all.
11 February, 2015
A Case For Hello Dolly

I like it.

I never use it, but I like it.

I delete it, but I like it.

It’s not professional, it’s not beautiful, and it’s not something that makes WordPress look grown up.

And I think needs to stay in the core download of WordPress.

Let me tell you a story of you. Let me remind you of yourself. Not the you of today who knows all amazing things. Remember the you who was young and inventive but inexperienced. The you who knew how to throw a football but couldn’t throw a spiral. Or you knew how to drive a car and not stick shift. The you who delighted when you learned all those things, like a child with a new toy.

That you was not professional yet. That you needed an example for how to do new things. You had teachers and friends and parents who showed you the ropes.

That’s what “Hello Dolly” is. Hello Dolly is the Hello World of WordPress, and it makes a plugin suddenly seem like a non-insurmountable task. We can all look at that one file and see either inspiration for code we can make, or a sudden lack of terror for what WordPress is. Like I tell people in training classes, WordPress is just files, folks. A plugin can be just that file. And you can take the idea and run with it. More than just a training tool, it’s the epitome of open source. It’s code, freely given, than serves as a first step for people who come to WordPress with no formal education. It’s free. It embraces the goals we want to see in open sourced code.

So it needs to stay in WordPress, because you needed it once. Does it make an annoying extra step for you to delete it when you’re installing WordPress for your clients? Maybe, but for me it makes a moment where I can look back at myself from 2009 and see how far I’ve come from the woman who was too scared to speak at a WordCamp to become a WordPress professional.

I’ll take that one extra step and never forget where I came from.

9 February, 2015
Mailbag: Tools To Keep Consistent

Meg from Ohio (go Ohio!) asks the following:

You blog three times a week about tech. How do you keep doing that?

I schedule posts.

Chris Lema doesn’t, bless him. I started with about 10 posts I had in mind, sat down one day and made myself a buffer, and thought that it would be better to space them out to every other day. It actually started as twice a week, but then I bumped it to M-W-F, and since I’m kind of wordy, I’ve been able to keep up with it. Sometimes I write a post because I solved a problem, which happens pretty much every day, and sometimes I toss out a remark on twitter that people want to hear more about.

Much of it comes from listening and reading a lot. But I don’t just schedule posts. I use the plugin Editorial Calendar to keep tabs on what my schedule is, when things are being posts, and at what time, because I actually really hate the posts lists.

Here’s your default posts list:

It’s pretty bare bones and functional, but one of the things that’s always bothered me about the whole post list is how useless it is. Don’t get me wrong, it’s a list of posts, and it does that really well. But with the moving target that is what we use WordPress for, it’s become rather frustratingly bare bones for me and it really does impact my ability to get work done when I have to bounce back and forth between multiple screens just to see what the status is, verify I updated everything, and by the way, where are all my posts.

So, in the grand WordPress Tradition, I enhance it with plugins.

Admin Featured Image shows the featured image in the posts list, which is really good for one site to make sure I did too set an image and what it is.

UI Labs I’ve actually forked. I need to remember to ping John about this, because I took his (great) plugin and modernized it. If you’re interested, that code is up on my github UI-Labs repo. It’s slowly being improved to make things a little easier for me and to work on WP 4.0 and up.

Editorial Calendar, as mentioned before, gives me a great view for what’s scheduled and when:

The drag and drop interface lets me reschedule on a whim.

Speaking of… Schedule Posts Calendar fills a void that has pissed me off for years. Just look at the comparison:

First, there’s the calendar by the month, then there’s the date, and finally the epic button ‘today’ to let me fast fix posts messed up by the WP iOS app.

So how do I keep posting so often? You ask questions, I answer them, and I have some tools to make it simpler for me.

6 February, 2015
Professional Utility
It’s well known I hate themeing. I can’t really design and I don’t know how to change thoughts to form like that. Words are my gift.

A year back, I changed this site to using the Utility Theme by Carrie Dils. Since then, I’ve moved on with another theme, for various reasons, but I still found Utility to be one of the nicest, cleanest, themes out there.

Recently, Carrie came out with Utility Pro and as she’s one of the nicest people out there, offered me a discount. The new theme costs more, starting at $69 and going up to $199 for a professional version with a Gruntified theme and source files. It’s a lot more than the $45 Utility cost, but I went ahead and bought the theme, not having a home for it quite yet.

After fifteen minutes looking at it and the code, I knew I wanted to use it.

What Carrie did “differently” with this theme is she made it mobile first. That means the entire site is designed to look good on a mobile device and the breakpoints are used make it look better are larger devices. This is the opposite of what many themes do, designing for large screens and adjusting for smaller. Her ‘media’ section is surprisingly small because of that, and the site resizes quickly and properly with no adjustments needed.

The next thing she did, and the thing that really was a selling point to me, was she made it accessible. One of the concerns I’ve been struggling with in the last year has been making my content accessible, and in specific my slides. I want everyone to be able to take my content and learn from it, and a theme that considers that means I have to worry less.

Finally, and here’s where she won my heart, she decoupled code from her theme. This is something that many theme devs and I agree on. A theme should theme, but code should be code. Which means that I don’t want my theme to include custom post types for example. But also she removed Font Awesome. I love it and use it, but by having it in the theme meant that every time the font upgraded, she had to upgrade the theme. We’re all used to upgrading plugins regularly, but themes rarely. By separating the two, she’s able to give the theme stability and the feature flexibility.

Am I using the theme? Today, yes.

Looks just fine in mobile (Google’s POV is jaded since I block them from scanning things).

It was the work of a few hours to convert a site from Going Green Pro over to Utility Pro. The only reason it took hours is that I picked up the non-developer version sans Grunt, which meant I had to split out the CSS into my desired sass files, fold in some of my custom functions, and finally fix the problem that had prompted the following comment:
```
/**
    This file has been modified by Mika to fit the needs of this.
    If you use it somewhere else, expect breakage. I hard coded
    some things in. Shut up, future me.
**/
```
Future me read that and sighed a lot. Finally I removed all the full calls, making everything relative or using the proper functions in order to dynamically add paths. Also I had to merge a Wiki, a Yourls Site, and a gallery into the look, and that meant some serious theme juggling. It didn’t help that with the new layout I decided to tidy up some of the sidebar content and optimize layouts.

I’ve done very little to rejigger the code. What I’ve messed with is unrelated to what Carrie’s design choices were and more with how Genesis approaches the few things I don’t fully agree with. I’m not yet using the welcome splash screen, since this site people come to for news first, but I plan to use it for major announcements.

Now, for $69, it’s a well made theme. Would I spend the $199 for the full version with the development tools and the Grunt files and the use on as many sites as I want? If I wasn’t me who liked to play with code and files, yes. If I needed this for clients, most definitely. StudioPress itself charges $59.95 for Genesis, and $399.95 for all themes in their repertoire, so from that aspect, this may seem expensive.

Chris Lema and I have some strong opinions on the cost of a WordPress theme. When you consider all the things you’re paying for, all the work of testing on mobile devices, accessibility, colors (which are also accessible), compatibility, plus a year of updates and support, that $200 is an amazing price to use on (say) a dozen websites out there.

I think it’s well worth the price to have this handy in my back pocket for anything I might need it for. And it’s a testament to Carrie how rapidly I realized I did need this and didn’t even know yet.

Check out Utility Pro. You won’t regret it.
4 February, 2015
Overreaction to Negative Reviews

I’ve long since held the belief that our reactions to critical judgement of our work hurts so much because it’s so personal.

This has never been more true than on the Internet. In the world of distributed and isolated development, we often end up writing in a sandbox. We sit down and tune out the world and write code. And then we just deploy it to the masses for real-world testing. Many people are unit testing, which helps a lot, but as we’re such a distributed development world now, we rarely get the sit-down feedback we might with a company.

With that in mind, perhaps the over-reaction of people to their bad reviews (codewise) is a function of this distributed environment.

You’ve seen it, I’m sure. You leave a low-star review on someone’s product, annoyed that it doesn’t do something you think it should, and you’re replied to with vitriol. You’re astounded! You know that a one-star review kinda sucks, but you didn’t expect name-calling or, worse, someone to find your personal contact information and tell you that you deserve to die and you’re an idiot for not understand what code is.

I didn’t make that up. That’s happened. And since it happens, the question is why does it happen?

It comes back to the way we both develop code and the way we share it. The easier we make it to share our code in things like Github or official, public, repositories like the WordPress.org plugin repository, the closer the connection we make between developer and user. If you consider how it ‘used to be,’ the person who wrote the code may never meet any of the people who use the code. I’ve used Safari for years, but I have no idea who wrote it. Conversely, I’ve actually communicated with many of the Chrome developers about issues I’ve see and unexpected results. And goodness knows we all just ‘cope’ with how terrible things can be in Microsoft Word.

We’ve made the world more accessible for people to communicate directly the issues they’re having with software. This is a good thing. It allows us to develop faster and iterate code faster. We make things better faster. At the same time, it opens us up to issues like handling negative reviews.

If you’ve seen the movie Office Space, there’s a character whose job it is to take information from the customers to the developers, because developers are bad with people. We all laughed at that because we all saw the grain of truth. That tiny nugget of truth was that people who can bury their heads in the sand for hours to invent things are kind of weird people, and they don’t always communicate the way the ‘rest of the world’ does. Of course, now it’s 2015 and we know that it’s just not so. We all communicate similarly. Some of us just have more patience than others because we’re used to working with people more often.

Sunday is the 17th anniversary of the term “Open Source” in how we use it today. There was a public call to use ‘open source’ instead of ‘free software’, and we heeded the call. But open source has changed a lot from that day. We’re not just talking about free software that anyone can take and develop but the open lines of communication that allow us to develop it by working with the users in a closer relationship.

While many of us develop in isolation, writing and testing code by ourselves, the moment we release it to the masses we’re terrified. What if it breaks? It will. What if it sucks? It does. What if people hate it? They will. But we do it anyway, and when we, the developers, get that one-star review, it hurts. It punches us in the gut and makes us want to walk away.

Except… it shouldn’t. Certainly some reviews are made by absolute prats who demand the unreasonable. We don’t reply to support tickets for our free software fast enough, or maybe we didn’t refund their money when our store clearly says ‘no refunds.’ Maybe they hated it because we declined to add a feature. Maybe they just wanted to rant at us for 500 to 1000 words.

Yes, those reviews that are clearly full of anger should be ignored. And yes, those will make you feel like total shit. But the other ones, the ones where someone says “I wanted to like this, but the developer pushes an update every week and it really isn’t adding anything useful. This plugin has become bloatware and I’m not using it anymore.” Well hey, that’s actually a very nice one-star review. It’s a sucky one to get, but it’s fair and just.

So why do people often demand we delete those one-star reviews, or reply back that the user has no vision and cannot see how the plugin develops, or that the code is the dev’s and you should thank your stars it’s free? It goes right back to how we develop. We’re not used to the feedback and constant communication with others about our code. We don’t present our code to the masses until it’s at a usable or workable stage. And there are practical reasons why, but it means we just don’t know what it will be like to work with others to develop until it happens, and it seems to always happens in bad way.

What should you do? Keep in mind that the people who hate your code may have a point. Try to be objective and see it fairly. But don’t be a pushover and don’t let the people who are legitimate mean people get you down. It’s not easy, though. It helps if you have other people to work with on your code projects. Trusted beta testers, or even developers who are willing to take a look. Get yourself out of your isolation and you’ll find it’s a whole lot easier to deal with the crazy, if only to have someone to laugh with.

2 February, 2015
Mailbag: Trash the Blog Slug

If you only knew how many times I got this one…

When I made my multisite, it changed all the URLs on my main site from example.com/postname to example.com/blog/postname ! How do I change that!?

This is because you picked Subfolders for your network.

Now before you get into this, ranting that it’s wrong, please actually read all of https://core.trac.wordpress.org/ticket/12002 first. The initial ticket was that if you used subdomains, you were also locked into using /blog/. We’ve obviously fixed that, but it brought up a bigger issue.

Why do we keep it? To prevent conflicts. If you use /blog/%postname% and have a post named “humperdink” and another subsite named the same, it would cause a mess of problems. It’s one thing to search all your pages for possible conflicts (remember, your pages will still show up as example.com/pagename), most people only have a few pages. But once you factor in the hundreds of posts, it gets really crazy. If you have an open Multisite, where anyone can register any site, you have no way to doublecheck the URLs.

So we’re making sure we don’t conflict with posts and sites, which is pretty impossible to do without a massive DB query every time you post, as well as pages and sites (less massive). I think that we should have some slug in there for those reasons.

Or as Nacin put it when he detailed out a potential roadmap for Multisite:

Dealing with URL Conflicts

Perhaps the greatest change will be addressing the issue of the main site gaining a /blog prefix. This is ostensibly to avoid top-level pages on the main site from clashing with sub-sites. With arbitrary domain support (via domain mapping primarily, and secondarily via secondary networks), any site with path / can clash with any other site with the same domain but a different path. With multiple path segments (nested sites), any site with path /X/ can have pages that clash with site /X/Y/.

Ultimately, this requires two-way blacklisting. Before a site is created, it must be checked against top-level URLs of the possibly conflicting site. And, before a page is created, it must be checked against sub-sites that already exist. If an /about/ page already exists on example.com/, an /about/ site cannot be created. But if an example.com/blog/ site already exists, a /blog/ page cannot be created on example.com. This gets complicated quickly, and is a very strong argument for only supporting one path segment in core by default, and allowing plugins to handle these potential conflicts on their own. In most cases, simply ignoring the potential conflicts is going to be sufficient.

You see the headache? But hey, if you’re sure it won’t be a problem, you can do this yourself.

Edit the site via network admin -> sites

Click on settings and scroll till you find the permalink settings:

Remove blog and save. Done.

Now bear in mind, should you ever change permalinks on the main site, you will have to go back and do that again. This is because on the permalinks page, it’s hardcoded in:

Also some plugins will refresh permalinks and accidentally put it back in, so you need to be very careful. Someone wrote a cron job to re-write that value every hour in the DB.

30 January, 2015

Author: Ipstenu (Mika Epstein)

Cheap Is As Cheap Gets

A Case For Hello Dolly

Mailbag: Tools To Keep Consistent

Professional Utility

Overreaction to Negative Reviews

Mailbag: Trash the Blog Slug