Author: Ipstenu (Mika Epstein)

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
Resilient Responses in Reviews
I review a lot of code. A lot.

On average, I look at around 100 plugins and themes (combined) per day. If I’m not reviewing code for the WPORG plugin repository, I’m debugging sites for customers, writing my own code to make it better, testing patches for WordPress, and pretty much dancing the dance a lot. I like this sort of thing a lot, since I get to see all sorts of different methods to madness, and it improves my abilities to see people doing it right and wrong.

That said, I’m not the best coder in the universe. I don’t claim to be, I don’t plan to be, and I don’t worry that I’m not. We all have our skills and mine is not to be a psycho awesome super coder. Mine is debugging, breaking, helping people debug and break, and writing. We call that support, generally, and it’s a noble profession! But more on that another day. The fact is I don’t know all the code in WordPress. I’m guilty of doing_it_wrong() often enough. And yet, I don’t see my ignorance to be a detriment to what I do.

In an article “Probability and Possibilities”, my father talks about how we react to natural disasters, and how that impacts how we predict them, and their costs. Near the end, he talks about being prepared by having resilient responses, and lists the following traits of those people/groups:
1. Drawing on experience
2. Questioning that experience
3. Intuition
4. Improvisation, or making the most of materials at hand
5. Listening and speaking
6. Examining preconceptions
7. Ignorance + knowledge = wisdom
8. Recognizing and taking advantage of luck
I didn’t realize it at the time, but my dad raised me to be resilient, because those eight traits are ones I apply constantly to my code reviews. It’s because of those that I’m able to do all those plugin reviews, even when I don’t know all the right moves. As a senator once said, I know it when I see it.

Many times, I’ll review a plugin and flag it saying “This is not secure” or “This is not done properly” and sometimes I’ll take a moment to explain exactly why, but given the sheer volume of reviews I need to get through to keep up my end of the review process I will often use some standard ‘predefined’ replies. I don’t review all plugins, nor do I reply to all the emails, though sometimes I know it looks like I do. Still, if one person has to review 25 plugins a day, and craft a reply for half of them (yes, about half the plugins we get need some sort of reply that isn’t ‘approved!’), how am I, a non-uber coder, capable of actually knowing that the code is wrong?

I’m going to tell you the biggest secret of support ever. You ready?

You don’t have to know how to fix what’s wrong to know that it is, in fact, wrong.

That’s it. Not knowing how to fix things was, I admit, one of the leading causes as to the impostor syndrome feelings I had when writing my WordPress Plugin Support ebook. But the thing was, I knew that the code was right or wrong most of the time. Oh, sure, I make a couple mistakes, but if I see someone calling wp-load.php directly in their code, I’ll tell them it’s not permitted and then they get a canned reply as to why, with some general suggestions.

I stopped worrying about not being able to help someone debug their own plugin for a couple reasons, though. It’s (generally) not my job to help you write your own code. If you have a jquery conflict or need help calling WP functions outside of WP (please don’t), I can help you with a search or suggestions where to ask, but just because I don’t know the answer doesn’t make my telling you that you’re not permitted to do something in the WPORG repository invalid.

Ah, there’s the crux isn’t it? Someone was doing code in a totally janky way. It happens. Most of the time, we end up doing this by accident, not knowing there’s already a WP function or action to use for it. We reinvent the wheel by accident. Let’s pretend this guy was using his own copy of jQuery. Now, as we all know, you don’t need to do that! WordPress comes with jQuery and you can just enqueue it. So there’s a canned email we send, explaining you can’t include your own, nor can you call it remotely, please use ours.

The reply comes back “My code won’t work without my own.”

So I reply to the effect of “Please correct your code to work with our version of jQuery. The most common cause of these conflicts is not writing your code to work in no-conflict mode.” And then there was a series of links.

He replied, “Why don’t you just tell me what I did wrong?”

I explained I would if I could. But I don’t know his code, I’m not awesome at jQuery, I don’t care to reverse engineer everything to figure out exactly what’s broken, and it’s not my plugin anyway. So … no. I don’t know how to fix it, but I do know that, having listened to a lot of smart people and having read a lot of code, that the primary cause is an issue with no-conflict mode. So I can Google that and get wp_enqueue_script() – jQuery noConflict Wrappers as a hit (this is the WordPress Codex) and read that this happens if you use the $ shortcut, so I take a second look at his code, determine this is the case (though perhaps not the cause of all issues), and reply back with that info and a link. I’m helpful.

He doesn’t agree. “If you know so much, you should fix it.”

No, sorry. This time I explain I don’t know much more than that as I’m not great with JS yet, and now I expect to get smarmy commentary on how, if I don’t know how to fix it, I don’t have the right to tell him it’s wrong. After all, I’ve heard that a hundred times before. Instead, this guy says “Yeah, I don’t know either, so who am I to judge? Okay, any suggestions where to ask for help?” After picking my jaw off the floor, I sent him to wp-hackers and stack-exchange, after doing a quick search to see what other direct links might help, including one on SE that looked like the absolute answer. He came back, said the SE answer was it, and everyone was happy!

I solved the issue by being resilient, and giving the ultimate support. Also now the guy has the tools to do it himself next time.
31 March, 2014
ZOMG! You Stole My Code!

While the GPL is pretty clear about this, and my personal moral code is as well, the topic today is not about the question of is it right to resell someone else’s work, but what do you do when someone’s reselling yours?

This happened to my friend not too long ago. Someone else took her theme and was reselling it and you either already know who it is or you don’t, it doesn’t matter for the sake of this story. Now, the issue was not if they could resell it, we all agreed they could. The issue was how they resold it. That is, they took her images, much of her ad copy, and resold it, presenting it as if it was their own code. And that was, we all agreed, wrong. That’s fraud, in my eyes. You’re taking someone else’s work and claiming ownership of it. But. That wasn’t my fight, it was my friend’s, and all I could offer was some moral support and connections.

But when this happens to you, what do you do?

First, don’t type angry. It’s okay to type while you’re mad, but if you’re like me, and your skin heats up when you’re angry and you get all green and violent (I type really loudly), it’s probably a good moment to step back and think about why you’re angry. After all, GPL says this is allowed, right? I get mad because of perceived ownership. It’s one of my things. You should never claim to be something you’re not and you shouldn’t sell something that isn’t yours.

And that’s the angle I’d use to approach the situation. I would find the person, ping them privately if possible (almost everyone has a contact page these days) and ask them if they could change the wording to make it clear that this isn’t their code, it’s mine, and they’re using and providing it without the support of the original author. That’s what my friend did, and that’s also what the other people whose themes were being resold did. They pointed out that the reselling was confusing to the customers, and the customers got an unlicensed product.

What if that fails? Well. Now it’s messy. Legally if they’re taking my content and putting it up on their site with verbiage that implies it’s theirs, I have a DMCA takedown right. My content is all under copyright (I have not, nor will I any time soon, chose to go copyless) and I use the CC BY-NC-SA 3.0 license, so if you use my content, wholesale, without attribution, you’re stealing. But this isn’t about my content, it’s my code, and all my code is released GPLv2 (unless otherwise noted). That means in order for me to come up and tap your shoulder, you have to take my code and my content.

Boy this got complicated. But if I ping you and say “Hey, bro, not cool.” and you ignore me, or tell me to sod off, I’ll come back and ping your webhost. “Hi, this guy is stealing my content. I asked him nicely to stop. Here’s a copy of our conversation.” I should note, none of the times I’ve ever had to do this have gotten past this step. The hosts have always stepped in, poked the perpetrator, and that was that. The times I was the bad guy (reprinting news articles), the content owners have only ever had to ask me to take it down. It’s never gotten past me.

Well okay, so what happens if the host says “Tough luck” or “We agree, but we can’t do anything without a takedown notice.” Now you bring in the law and file a DMCA (Digital Millennium Copyright Act) take down. DMCA is a U.S Copyright Law covering intellectual property. Your blog posts and ad-copy are your intellectual property. This went to a pretty dark place, didn’t it? I mean, I hate the DRM with a passion, and I freely give away my stuff, so let’s stop talking about the legal stuff. You can look it up on your own if you really want to know how to file all that.

Most of the ‘handling’ of someone who steals your stuff isn’t even the legal hassle, anyway. It’s just the pain of getting in touch with them, explaining the situation, and getting it sorted. And the headaches come from having to explain over and over that you’re not mad (though you probably are) and you just want them to stop making it look like they’re you, please and thank you.

Okay, so how might I justify selling someone else’s theme or plugin? I would sell a service. It’s really that simple. I would sell the downloading, installing, configuring, and tweaking of the product. I would charge them the raw cost of the product AND give them the license information (it’s their now). I may charge them for some ‘placeholder’ text to import via the WP importer, and to import it. Certainly I would charge for some training on how to do this going forward. But the thing I wouldn’t do is actually say “This is our plugin” or “This is my theme.” Because it’s not.

I’m just making sure you can have the theme better, faster, and easier. Plus now they can upgrade and I can go to Fiji!

28 March, 2014
Migrating A WordPress Site With wp-cli
This is … crazy simple. I wanted to move a site from ipstenu.org to ipstenu.com (yes, I own that too). While ipstenu.org is a Multisite network, ipstenu.com is where I put a ton of add-on domains. I was moving a site over and, as it was WordPress, did it in a matter of minutes.

Add the domain to the … domain

Since I don’t care to have multiple hosting accounts, and I’m the only one with SSH/FTP access, it’s safe enough for me to do this. There is a risk when you share multiple domains in one hosting account, that if one gets hacked they’re all vulnerable, but I consider it low in my situation. Every plugin is vetted, every file is checked, and then I went and gave each add-on it’s own FTP account. Neurotic? Thy name is me.

Anyway, I add the new domain to my hosting where I want it.

Create the new DB

I have to make a new database, and generally a new DB user, on the server too.

Export!

On existing hosting, I do this:
```
wp db export
```
That gives me my SQL file, thanks to WP-CLI. It’ll be named example_com.sql and will sit in my folder with .htaccess and everything else.

Copy!

I do it via SSH. I go to the new location and run this:
```
scp -r olduser@example.com:path/to/files/ .
```
Since I have ssh keys set up, it’s easy. If I don’t, I’ll put in the password, but that’s straightforward.

Edit wp-config.php

Now I have to point to the new DB. Sometimes I name it the same, but usually I don’t, so I’ll edit the DB name, DB user, and password.

Import the old DB

Ready?
```
wp db import example_com.sql
```
Boom. It’s all dumped in! Only two steps left!

Search & Replace

I love this one.
```
wp search-replace example.com newexample.com --dry-run
```
I ALWAYS dryrun test it. This is a serialization safe search, so rarely is it ever going to be an issue to just run, but it lets me make sure I don’t get any wonky results. I never have, so re-run without dry-run.

Cleanup!

Delete the SQL file, delete the old files on the old server.

Drink

I moved code. That’s shipping, right? Or is it margaritas are for migrations?
26 March, 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