Category: How It Is

Making philosophy about the why behind technical things.

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
I Don’t Care If You Use Multisite

I love Multisite. I think it’s awesome. It makes my personal life way easier, it helped me write a book and get a job, and it’s a totally cool aspect of WordPress that is still underdeveloped but a very hard worker. Multisite could be so much more, and it’s still that new kid on the block, but it’s growing every day.

When I tell people over and over again that they shouldn’t use WordPress Multisite, I do so knowing there’s a good time to break every reason I said not to use it. After all, why not use it?

But there’s one big question I don’t answer in the WordPress forums anymore, and that is “Should I use WordPress Multisite?” Oh I may clarify specific moments in what I said in other places (like you can duplicate content, but I don’t believe you should), but I won’t get into conversations of “Is this a good use case?” The reason why is that I cannot tell you, quickly, if you’re a good candidate for being a WP Multisite Admin, nor can I glance and say that your situation and environment is perfect for multisite. And the reason for this is that Multisite is complicated.

Actually that’s wrong. The reason is I don’t know, and neither do you.

Do you remember, way back when you started with websites, and you first looked at WordPress and asked yourself “Is WordPress right for me?” Someone probably said “It can be.” or “Maybe.” Oh I’m sure someone said “Of course!” And another person said “No way!” But the point of all of those answers is that it depends.

When you consider using Multisite, or WordPress (or anything) for that matter, you should take stock of what you want to do. Does the product, natively, support those things out of the box? Do people complain that doing something is really hard? Do people say it’s weird, but works? Do people suggest plugins? None of those things are reasons to not use the product, whatever it is, but it’s getting an understanding as to what world you’re stepping into that is important.

But I know, I just know, one of you will post a comment here “Mika, I just want to know if I should use Multisite! Please tell me!”

No.

It takes me about an hour to determine if you and your current site are a candidate for Multisite (and yes, I have rules). Then there’s another two to three hours going over your specs (and probably pushing to get more details) and making sure this can’t be done easily with a standard WordPress install, that it can be done with WordPress, if there are extant plugins, and if there’s custom work that’s going to be needed.

Basically it’ll be about half a day spent to give you the answer you deserve, and even then, it’s not going to be the full answer because you’ve probably forgotten to tell me something like “I need non-logged in users to be able to upload files.” or “This will be on Windows IIS.”

Hopefully at this point you’re thinking that’s fair of me. Four hours of my time is worth around $1000 USD (my going rate is $250/hour when I’m available, which is rare), and while I’d be happy to do a flat-fee for that sort of thing, no one in the history of ever has come to me with a clean and precise list of what they need and why and how they plan to grow.

Which brings me back to why I just can’t do this anymore. I just don’t know. I don’t know you, I don’t know your skills. I don’t know the skills of your users and I don’t know your future plans. I don’t know if you’ve compared the options yet. I don’t know your feelings about custom code and a lot of plugins. I don’t know your requirements. I don’t know if you want to have multiple sites with no admins, or a network with a hundred super admins (please don’t do either of those things). I don’t know your SSL requirements, your domain mappings, your servers, or your host. And because I don’t know those, I can’t answer the question fairly.

I don’t care if you use it or if you use multiple separate sites. I do care that you understand that multisite is complex and I care a great deal that you’ve researched your options. I care that you ask questions like “If my database gets too big, can I split it with Multisite?” (Yes, use HyperDB or SharDB.) I care that you consider “Is a custom post type slower or faster than a separate site on a network?” (Neither, as it happens. They’re about the same.) I get really happy if you ask specific questions, actually. You know, the ones that tell us you’ve looked into this and thought about it.

The answer to “Should I use Multisite is?” is a question.

“Are you prepared to use Multisite?”

19 March, 2014