Category: How It Is

Making philosophy about the why behind technical things.

Catch a Session

When I was at WordCamp Chicago in 2013, Brian Richards asked me if I’d be interested in giving a WordPress ‘Session.’ Since not everyone can make a WordCamp, what if there was a live, online, session they could watch to get the same information? Thus was born WPSessions!

I said yes, and months went by. Then he pinged me again, asking if I was still interested, and would I might talking about eCommerce and Easy Digital Downloads? That was new! Most people want support, community, or multisite. Since I’d recently written a book about running an ecommerce bookstore, I said yes again, and on Thursday gave a session.

If you missed it, and you probably did since I did a terrible job promoting (sorry Brian!), you can check it out at WPSessions – eCommerce for Site Owners. It’s $30 for four sessions (mine is 51 minutes long), and while my slides are online , you never get quite the same impact as seeing me give them, do you?

http://slides.halfelf.org/wpsedd/

11 April, 2014
Whatevergram: The Honeymoon is over
I’m not a photographer. I’m not artistic in that particular way and I don’t want to learn to have to be. The joy of Instagram is I can take a photo, slap a filter on it, put a border, and boom. Done. Share it with friends. The sad part about Instagram is putting that photo on my blog. It’s all machinations and annoyances.

What I wanted:
1. An easy way to take ‘styled’ pictures.
2. An easy way to push those pictures to my blog.
3. An easy way to determine how I want the pictures to post.
That’s all, three things. Now, Instagram wins at #1, and Pressgram wins at #2, and the both suck at #3.

That third one is the hardest, I guess, but what I want is that when I upload a file, it either makes an individual post or makes a gallery post of the whole day. And in both cases, I get the option of making a post publish right away or save it as a draft. I kind of love the idea of ‘This week in [Insta|Press]gram’ as a post for a photo blog. In looking at my options, I determined there’s one Pressgram plugin and a million Instagram, but none really do all of that.

But really … Pressgram 2.0 fixed most of my issues with UI, and for that I’m very happy about the new version. It’s easier to read and use, the layouts make sense. I’m even okay with the in-app purchases for things (though charging for some of the things Instagram offers for free strikes me as a poor call). Lacking the nice, snazzy filter names (imagine naming them after WP Themes) and borders/patterns means that if I want those in a quick way, I use Instagram and the maybe Pressgram to upload.

Except that isn’t what happens. I take a bunch of photos. At the end of the day I manually upload them all to my blog. Manually. What an annoying thing. I can’t do the one thing I want, which is make a gallery post. By default Pressgram 2 publishes my posts, so I have to use a plugin to not do that. Or I can use a plugin to import from Instagram (though again, it’s a single post per image). Of note, people recommended Instagrate to me, but it’s not Multisite compatible (says so on the plugin page) and that means it’s either poorly written or it’s doing something really wrong, since Multisite shouldn’t matter at all for that. Also it’s manual.

The best plugin I found was one that daily pulls in my Instagram pictures and saves them as draft, leaving me to manually merge and make a “This week in Instagram” gallery. There was another that can make a weekly post, but it’s old, out of date, and doesn’t actually save as draft anymore. There’s not really a perfect way to do that, though, as even the ‘import on demand’ plugins seem to have gaffs and time delays. Obviously Pressgram’s ‘Post direct’ method is going to be more precise, but even then it doesn’t have a ‘collect everything from a week’ if it’s going that.

I know I said the Honeymoon is over, but to be honest, I don’t know that it was ever here to begin with.
9 April, 2014
Why Can’t Multisite…

Many times people complain that WordPress isn’t ‘complete’ because it doesn’t have the features they feel are indispensable. While explaining, and educating, to people that they can’t always get what they want out of core is often fruitless, the point remains that WordPress cannot, and should not, do everything. That’s a part of a longer post, but once you are willing to accept the fact that WordPress will never be everything to everyone, we can move forward.

There are practical reasons why Multisite doesn’t do everything people envision, and there are also some weird impractical reasons. Sometimes the answer to this is a very simple one, sometimes it’s confusing, and sometimes it’s technical. But there are reasons, even though we don’t like them, and over time they change or go away as issues are resolved.

Here’s a list of the common questions I get and their answers.

Why can’t I manage everything about all sites from the network admin?

It would slow your site down. You’ve probably heard me say something like “WordPress Multisite was intended to be multiple separate sites managed by one install of the WordPress files.” When I say that, I don’t mean ‘managed’ the way some people envision managed. When I say ‘managed’ what I mean is “You manage your network settings from the network dashboard, and you manage your per-site settings from the per-site dashboard.”

Not every site has the same settings, anyway. The point being, if WP had to query every site for every setting (like all your comments), it would get really really slow when you have 11k comments on your blogs. And you’d be mad.

Why can’t I set all defaults from the network?

Oh you want them to be all the same? I’m not sure you should be using Multisite, but since you are, this one is annoying.

In normal WordPress, you shove everything into wp_options and call it a day. On Multisite you have an options table per site, so wp_2_options and so on, but you also have wp_sitemeta. Some settings and plugins have been coded in a way to fall back, so it grabs defaults from that table. But. Not everything has been, because there’s a tacit assumption they don’t need to be.

Now there are plugins that will let you force in defaults on new site creation, but given that every single site admin can go in and change them, it would defeat the point. They’ll just change them! Thankfully, it’s a growing trend for plugins to include a Network Admin Settings page, where you can determine how to control things for your network. But that’s only going to be for things like caching and probably Jetpack. Not ecommerce. Yet.

Why can’t I share media?

Because media is content and content is per-site.

There’s a plugin called Network Shared Media which purports to being able to do this, but by it’s nature, content is sacrosanct and separate.

Why are usernames using characters like – . _ are not allowed?

Because they’re not permitted in subdomain URLs and since the blog URL is generated from your login name, it’s not allowed. The site admin can do it from the back end, though. This is highly imperfect, and perhaps should be changed (so maybe we could also have less than four characters in a name, which not even an admin can fix). The logic to do the detection would be a pill though, and you’d still want to do it on things like a mapped domain.

Why can’t I just map a domain!?

That’s being worked on. Eventually WP will have that superpower.

Actually that brings me to the biggest reason why Multisite can’t… It’s not that it can’t, it’s that it probably shouldn’t, or it will be able to do so eventually. If you consider what the original intent of Multisite was, much becomes clear. Open Source Development doesn’t move at your pace, not even if you’re Matt Mullenweg. It moves at the pace of everyone involved in the coding and testing, and it moves at the pace of their ability to innovate. That means sometimes what you want isn’t there yet because it’s not easy, or because it’s not ready, or maybe because no one agrees with you right now that it’s a priority.

After all, sometimes we’re wrong about Open Source Developmen.

7 April, 2014
Easier Control

In a WordCamp I heard a developer say something along these lines:

“I include my own jQuery because it’s easier and I can control things.”

The moment he said this, I clamped my mouth shut and bit my tongue. It was not the subject of this presentation, and multiple other people in the room had already pointed out that WordPress has it’s own version. Afterwards, someone remarked she saw steam coming out my ears. All I said in the room was “We reject themes and plugins from the .org repositories for including their own copies of jQuery.” and then shut up. After all, I was in the room because I wanted to learn about something I didn’t know, and that wasn’t jQuery.

It’s sad that my major takeaway from that talk is too many people sacrifice sustainability for ‘ease’ and ‘control.’

You may think that if you force install your own jQuery, you can be sure a random upgrade of WordPress won’t break your theme. You have full control over the theme, after all. And you may think that you can make your theme or plugin faster if you compress all the JS together yourself, rather than having WordPress load a dozen separate files. Those thoughts are both true, but you’re wrong. You’re never ‘master of everything’ unless you only use WordPress core and the themes and plugins that you built. And even then, you’re still not.

While it’s perceived as easier and faster to write code if you assume you know the truths of your website and will always be it’s master, the fact is the assumption is plain ignorant. These days, it’s rare you’re ever the sole developer of a site. You may be hired to make a theme, I’m hired to make a plugin, and someone else is titularly in charge of both of us, but probably doesn’t know a lick of code while still being the driving force behind the website. Not to mention we’re not the webmasters of the site. That may be some intern nephew of the boss, who will take over once we’re done.

And that is exactly where using our own versions of scripts will get us into trouble.

You’re master of your plugin, or your theme, but you’re not master of the rest of the world. Even if you’re making it on spec for someone for a specific purpose to be used on a specific site, there’s no guarantee that it’s the only time and place your code will ever be used. There’s no assurance that then 10 other plugins you tested with today will never upgrade, or that they won’t add more. If you get hit by a bus tomorrow, there’s no promise your code will remain untouched. Basically we’re running on pure arrogance that not only are we crystal clear about the present, but we’re totally perfect about knowing the future. And that just ain’t possible.

So. How do I explain why including your own jQuery in a theme or plugin, instead of enqueuing the one with WP, is bad?

“Picture this. Your theme has jQuery 2.0. So it de-enqueues WPs and re-enqueues yours. My plugin is using version 1.7. I do the same thing. Bob’s plugin uses 1.11, HE does the same thing. Joanne over there properly uses WP’s. Which one of our jQuery files wins?”

The problem is that you’re emphasizing short term gains (speed of development, speed of site) over long term sustainability (regression conflicts, duplicate files). You’re making your life a little easier, and actually harming the website you’re trying to make because tomorrow, you will be gone and they’ll be trying to figure out why the site is so slow. Or why it’s breaking when they upgrade Jetpack. After all, you tested with Jetpack, right? You were selfish, short sighted, and just … wrong.

But it’s okay. You can learn to do things better. You can do it right with your code and fix those mistakes. You can let the wookie win, and let WP control what it’s supposed to control, while only augmenting what you must control. And you can do it all in a friendly, sustainable, updatable, extendable way. Which is how WP wants it.

Oh and how to I handle minification? I have a proxy service do it for me. In my case, Google’s mod_Pagespeed compresses and combines all my JS and CSS to make it one file that loads faster.

2 April, 2014
Category or Tag?
Everyone in WordPress has probably heard the advice of Lorelle VanFossen on the subject of Categories or Tags. I’m sure her 2005 post will remain, forever, one of her most popular posts, much like mine about why you shouldn’t use Multisite will be one of mine. And why is that? Well it’s simple.

She’s right.

She gives information in a clear, direct, concise way, and she’s right. She will always be right. No, sorry, if you disagree, you’re just wrong. Category abuse is like menu abuse in that it confuses your readers. If you’re organizing things in too many directions at once, the sense of location is lost and no one cares anymore.

But still, people ask which do you use and where and why? For me it’s really simple.
- Categories are organized
- Tags are free form
To me that means I need to organize my posts on a site to major topics. This is a tech blog, so I’m probably going to talk about how things are and how they do it, and how you do it. That means I really don’t need much more than three categories. I ended up with five, since I decided a CPT for presentations and another for videos wasn’t really needed. Categories categorize, though. It’s simple and straight forward. A category is a room in my house.

The tags are the items in my house and they can go in any room. They’re the minor topics of my site. Like my iPad can come into my bedroom or bathroom (we all do it), the post about plugins could be philosophical or explanatory. The little things versus the big things, as it were. The tags are all those little things scattered around the site.

But what good are they to anyone? They’re both aspects of organization, and they’re both somewhat useful to find old posts, but do your readers ever use them? It’s funny when you think about how much time we spend trying to make all these aspects of our site ‘perfect’ and how few people actually use them. Like I did a study on this site for related posts. I measured, using my analytics, how many people used them to click through and came out with a resounding “Less than a dozen.”

Same general test on another site? Over a hundred. And on that site, no one clicked on tags. They don’t really here either, but since I use categories to organize ‘sections’ of the site, those get used a lot everywhere. And if you can’t tell, this is all a lot of work. You’ve got to work hard to make the site flow right for your users and visitors. For your product, you have to consider what you’re sharing and selling, and how people logically get around. You need to study, watch, and experiment.

The real answer to category or tag is, of course, what works for you. But when you’re starting out, listen to Auntie Lorelle.
24 March, 2014
You’re Wrong about Open Source Development

We like to say that the ‘customer’ is always right. But when it comes to open-source products, the line between customer and developer is blurred. I joke that I’m not the owner of code, I’m the custodian, and by fielding questions from users and other developers, I turn that into a better product. There’s more and more calls for people like me by the way. A non-insignificant number of companies ask me “Is there someone else like you who would want to work for us?” because giving good support is hard, it’s a weird skill set, and it requires the ability to tell someone “I’m sorry, but that’s just not correct.”

Yes, I tell people they’re wrong a lot. When I say it, I try to couch it in more friendly terms like “I understand why you’d think that, however because of XYZ the product chose to do ABC.” Or maybe even “That would be great, but historical support forces us to do that in a way that would remain backwards compatible. It would suck if we broke everyone going forward, right?” See the point here is that you’re not right but you’re not exactly wrong either, you’re just isolated in view.

Tunnel vision is something that happens to all of us. We look at the world from our perspective (yes, I was Captain Obvious there, I know), which means when most people remark that a project needs something, what they really mean is they need it. This is the part of passion that escalates into angry and vitriol remarkably fast, by the way, so if you’ve ever seen someone go from zero to abusive in three comments, that’s often what’s going on. They really want something to the point that they see red and can’t get out of their tunnel.

Getting back to the rational world is hard, especially if you don’t really understand what it means to develop open source. You may think the developers are ignorant of their users, or out of touch, or don’t care. After all, if open source allows anyone to contribute, why doesn’t a project do everything?

Well besides the fact that it can’t do everything, there are four main reasons a project doesn’t do things the way you it to. This doesn’t mean you’re right or wrong. Being wrong doesn’t mean you are wrong. It’s pretty hard to ever hear ‘wrong’ and not take it a little personally, though. Just keep in mind the reality that most Open Source developers are way more in touch with their users than people behind iOS or Microsoft Word. They just move at a different pace.

Support

The people who write the code have to support the people who don’t (or can’t). If they don’t want to support certain code, they shouldn’t have to. After all, what if they don’t feel confident that they can!? If you ask a developer to put in a feature they don’t use and don’t really understand, what happens when it breaks? I always tell people “You can’t support what you don’t know, and you can’t know what you don’t use.” This is why everyone who’s been through my WordPress training is pushed to actually use WordPress. Supporting something is so much easier if you use it. Thankfully all WordPress developers use the product every single day, so they know what it’s like.

Complications

The code is something everyone wants, but it’s too damn hard to code and remain backwards compatible, which is a huge deal for WordPress. A good example of this kind of thing would be WordPress Multisite’s shift from using /blogs.dir/ to /uploads/ for storing uploads. Doing this allowed us to dump MS Files and speed up WordPress because we’re no longer routing images through PHP (lots of benefits there). It came at the cost of losing the ‘hide’ effect of the /files/ URL, but you weren’t really fooling anyone about that anyway. Point being, we had to do this in a way that didn’t break everyone on an older design of WP! That took a lot of time!

Time

It takes a lot of time to get code right. So maybe they’re actually working on it, but it’s going to take a long time and it’s not done yet. Open Source moves at the speed of imagination and passion, so if a developer has the time and the itch, things get done. Some tasks are pure drudgery, which brings us to …

Feelings

If you’re stuck between writing code you like to do a feature you want and writing code someone else wants and you don’t have an investment in, you’re probably going to do what you want. This is the reason that’s hardest to understand, and it’s the one most people call ‘unprofessional’ because it boils down to “Oh you don’t like something so you’re not doing it?” If this was iOS or MS Word, yeah, you’d get fired. But this is Open Source, and the rules are a little different here. We make what we make out of that same passion you have to see what you want to see.

So … why not what I want?

Because not yet. Maybe never. But WordPress was built to be extendable, not to be everything for everyone all the time. And that’s the beauty of it. But that’s another post altogether.

21 March, 2014