Tag: wordpress

The Responsibility of Freedom

I’m sure you know there are clubs out there that re-sell WordPress products at a far lower cost than their original source. This post is not about that being right or wrong via the GPL, nor is it about the morality.

This post is about responsibility.

In my home office hangs a poster “Flynn Lives” which I have to constantly remind me “I fight for the users.” It’s a nerd level joke most of my fellow developers and support gurus get, but many people I help would not understand the point. My job, as a WordPress Support Guru, is to help people. This is simple, straightforward, and obvious.

My other job, though, is to make their lives easier and better. It’s my responsibility, when I write code, to make it do something to make someone’s life easier. Even if the only person it helps is me, the point is that someone is being helped. If it’s just me, it’s really easy to support myself. “Hey, Ipstenu, you know this broke?” “Yeah, added to my list!” But when it’s someone else, how does that change?

I firmly believe there’s an expectation of support with all plugins and themes hosted in the WordPress.org repository. Period. That means, yes, I have code I don’t put up there because I don’t care to support it. But I know that expectation puts responsibility on me as more than just “Someone who writes code.” I can’t just write code, drop it into the world, and never support it.

“But Ipstenu,” I hear you say. “Isn’t that what WordPress.org does? It just dumps WP into the world. I never see the devs in the forums!”

You’re not WordPress.org. You’re not that big, that complex, and that intricate. Unless you’re BuddyPress-levels of plugins, and you’ll notice they have support forums. Instead of directly supporting WP, the core devs of WordPress who are dedicated to WordPress have people like me, who traipse about the forums and help. And when I see broken things, I either take it to trac or help the person who found it do so. My determining line is “Can I fix it? Okay, I’ll trac it and patch it.” If I can’t, I help them. Low hanging fruit.

The point here is that all this wonderful software came with a responsibility to make it great and help people. What does this have to do with sites like those Justice League Clubs that offer cheap/free versions of pay-wall’d software? They’re not helping you.

Oh, in the short term they’re helping you by giving you something for free. They’re getting you further in your site development than ever before. However that help ends at the provisioning level, because you aren’t paying for support from these resellers, you’re paying for product. That’s okay, so long as you know what you’re paying for, and a lot of people don’t. If people did know what they were paying for, they wouldn’t use nulled themes with base64 backdoors in them.

The ethics and morals of reselling someone else’s work aren’t at play here. Yours are yours, mine are mine, and that’s just fine. What is at play is what are we paying for, what are we providing, and what are we devaluing when we resell someone else’s product?

Devaluing is the easier one. People sell products at cost in order to make money. It’s simple. I work for a company that sells space on a computer and world wide availability from anyone to that space. We sell it at a price that allows us to make money, but also that allows us to hire amazing people like me who work on WordPress, write some of the code, test it, and otherwise spend all this time on WordPress, just because it’s software you use!

The value of the product is, again, not just in the product, but in the service. And the service is more than just access and accessibility, but also in the support you get. No matter what people think, we aren’t just rolling around in money and laughing at you. We reinvest that money in ourselves, our hardware, the software (some of which we give to you). But what we always do is support that. Sometimes the support isn’t what you want to hear, but we do our best to solve problems, or explain why we can’t.

So what are you paying for? Support! In the end, you’re pretty much always paying for support. You buy Microsoft Office and you don’t get the kind of support you get with WordPress, but you pay a lot more money. Where’s the support? When Word crashes, it sends (or asks you if it can send) a report back. That report gets noticed and acted on so that if it’s solvable, it’s solved. The next upgrade you get has a patch, and that crash doesn’t happen again. That’s support!

You can also get actual support from Microsoft (though I know of no one who’s done so). They have people who write fantastic help docs and who monitor their forums and twitter. If you took Word (let’s pretend that was legal) and resold it, would you have all that?

But that’s a quite extreme example. WordPress plugins are significantly smaller in scale than MS Office. So why is Office (and Adobe Photoshop etc) so expensive if they don’t give you half the help that the free WordPress product does? There are a lot of reasons. Patents and copyright are expensive, and frankly we’re all willing to pay for it. When Apple dropped the price of the new OS down from hundreds to $25, we were all suspicious. When it became free, we flipped out.

But Apple wisely noted that making us pay that much money wasn’t helping them as much as it might. Free gives you a certain brand loyalty because we get to try before we buy. And we will buy those apps and those app add-ons (though I don’t fully approve of games that force you to pay to play all the time). We buy them because after we get the base product for free, we see the real value in the cost of the other products and we’ll pay for them willingly. Apple takes responsibility for their free software in interesting ways. We have to pay for assistance (most of us via the Genius Bar). And in the WordPress ecosystem, that too is what you pay for. The help.

So back to this whole “I’ll take your paid software and give it away” thing.

What are we paying for? I’ve heard tell that ‘Paying for support’ is a rip off. So is paying for documentation. I can see why some people balk at paying $25 a year for ‘support’ they may not ever need, and I’ve seen some companies work by letting you pay per-ticket. Though that makes people feel like you’re nickel-and-diming them, and I do agree it can come across that way. And yet that support which they so casually toss aside like an old shoe is where these free-software-clubs fall down.

There is one club that says they will support all the plugins they re-host. Many of us are suspect at the possibility of that actually working well, though given the odds of how small their sales will be to start with, it may end up sustainable. The problem is that they’re not going to be patching upstream. They’ll fix your issue, and then when the real source pushes the next version, they get to reapply their patches. Strikes me as a lot of work.

Is the payment system for some WordPress plugins and themes broken? I don’t think so. I think it’s not optimal for the user nor for the developers just yet, but monetizing these things is still relatively young. There will be mistakes and bad choices along the way. Finding the balance between the freedom of the GPL and the desire to make a living is difficult.

The ultimate responsibility we have with WordPress is to give back. We give back with support and with improving things for everyone. If we’re just doing things for ourselves, after all, we don’t share them. Are these clubs failing in those responsibilities? Not yet. But all eyes will be on them if they do.

12 March, 2014
WordPress’ SEO Sucks

“what to say when someone asks you to suck them off”

Not the sort of term anyone would really associate with this site. So imagine my surprise when I saw my search stats in Jetpack:

That sentence is at the end of my list of Search Engine Terms. I tweeted that I was astounded, and wondered how far down the SEO hole one had to traipse to find my site. As it turns out, not very far at all:

Fourth. That’s it. That’s how high I ranked. So the next logical question would be to ask what I did to make my site rate that high on random searches? Nothing. I don’t have anything ‘special’ on this site. I have a good theme, certainly, but I don’t use any WordPress SEO plugins, and in fact, I’ve never (until now) used “what to say when someone asks you to suck them off” like that, all in a row.

What’s the magic?

It’s not WordPress.

What Makes WordPress so darned Awesome (by Jen Mylo)

That is, it is and it isn’t WordPress. WordPress is SEO optimized out of the box, and your content totally matters. And it’s content that probably landed me so high. You take good content, you add in people linking to your content, you promote yourself with friends who pass it on, and magically your hard work becomes content!

Last week someone told me they wanted to “automate the posting of [original] content” and I was completely bewildered at the concept. The issue, as I understood it, was that posting original content to 100 blogs meant writing original content 100 times. And you can’t automate that. By definition, posting unique posts means … you make unique (aka different) posts. This person went on to say it was time consuming to make 100 posts and create 100 custom links to them. I sat back and blinked a few times, and thought “Well, yeah.”

I say it over and over. A website is work. If people could magically install WordPress and boom, money, then I wouldn’t have a job helping people speed up sites or debug strange conflicts, or a million other weird things I do every day. WordPress can make publishing on the web a heck of a lot easier, but it will never be effortless because effort is what makes your site amazing. Effort and attention are crucial to keeping your site going.

Every time I hear about someone trying to find the quick and easy way around content creation, I shake my head. There isn’t a quick way, there isn’t an easy way, and there isn’t a simple way. Unless you like writing and think that it’s any of those things. But even then, you can’t just write and expect magic to happen. You have to write, and customize, and care, and water, and fertilize your website.

So how did my site get ranked so highly about sex when it’s about tech? If you read the post that got linked, it’s about how you suck. “My question is you suck” is the title, and in there, I talk about what to say when someone says you suck. It’s actually a pretty logical result, when you think about it for a moment. But because enough people link to me, and enough people used the word ‘suck’ in their links, and enough people shared the link, I’m respected by google and score crazy high on a totally non-relevant search.

That’s how you work the system.

Sorry about that, to everyone who is vastly disappointed, having come here via the search result.

10 March, 2014
Great Walls of Fire

If your website is ‘international’, you’ve probably already run into this. If you’ve ever worked for cooperate America, you’ve seen this happen. If you’re on an out of date browser, you’ve definitely seen it.

It’s that horrible day when your site looks like absolute crap because something critical to your site isn’t loading because it cannot be accessed from where you are.

Let’s step back.

Using Google’s Open Sans doesn’t work in China because Google is, generally speaking, blocked in China. What does this mean for people there? Well their WordPress dashboard is going to load slowly, in fact for many it’s so slow as to be unusable. This is because WP 3.8 uses Google fonts on the back-end. Now, you can disable it with the Disable Google Fonts plugin, but many people feel that’s a poor user experience.

I want to take a moment to note that while I, personally, dislike using Google for required fonts on WordPress, there was a discussion on bundling vs linking that took place in November 2013. At that time, everyone agreed bundling (that is including the fonts with WP) would be best, however how to do that was more complicated. In order to provide a good experience for all users and all languages, it got messy and large really fast. You can read up on the history on make/core: Open Sans, bundling vs. linking.

That being said, by remotely calling Google, there are two main issues: privacy (which I’m not getting into) and accessibility (that’s what I want to poke at).

We know that calling Google remotely, for everyone in a country with good internet speeds, is great as it speeds up your site! That’s the premise behind Use Google Libraries after all. If someone’s already downloaded the files in their cache for JS (or fonts), then the next site they visit will load faster if it uses the same ones! It’s a sound, and accurate, theory.

But are you making your site inaccessible with your need for speed?

What happens when someone can’t load Google? In the case of the Use Google Libraries plugin, it falls back to using WP’s standard, which is good, but that initially connection has to fail first! The same happens for WordPress’s back end, which means the time it takes to load your site is longer for those users.

I tell this to people a lot, and generally they reply “Well I don’t have users in China.” or “This doesn’t affect my visitors.” Really? REALLY? Sorry, but that is one of the most shortsighted views I’ve ever heard in the history of ever, and one I tell people “Yeah, that’s an incorrect and rather arrogant conceit.”

Let me tell you a story. I went to Japan for 12 days to hike O’Henro with my Buddhist brother and our agnostic father. We made the “A Jew, a Buddhist, and an Agnostic walk into a temple…” jokes. While there, I checked in on my websites and on my regular sites I visited, only to find out that some were blocked because we were using a net connection that went through a country those sites blocked. Why? Because “no one” who would ever visit their site was from there.

I no longer use those services, I no longer support those sites. My father goes to China regularly (he does risk assessment on the disused weapons caches in China). I turn off Google Fonts on his website in order that he, and his customers, can see the site as intended. You can tell me all you want that ‘no one’ visits from those places, and you’re just wrong, and arrogant, and yes, I strongly disagree with WordPress having made Open Sans via Google a requirement like that.

My personal dislike of Google aside, it’s a reality I look at more than I wish I had to that people and places block third parties. This is why I get on the case of plugin developers who use third-party services when they don’t have to. They’ve created an unnecessary dependency on this other service, which will crazy to debug when someone says their code doesn’t work.

Your code should be as self-sufficient as humanly possible. Offloading for ‘speed’ doesn’t work for all situations, and instead can make things slower by causing more external resources to load. Have you ever looked at those scan reports where they say your site calls too many sites for JS or CSS? This is what you’re doing. Even though it increases the odds that people who can get to these sources will already have the files cached, people who can never access them have a worse time. And then loading them locally will make your site heavier and load slower, unless you use proxy-caching (like Pagespeed or Varnish).

It’s not a perfect solution for everyone. This is why websites are hard.

7 March, 2014
I Hate WP Here

I’m probably going to piss a lot of people off with this longer post, so let me make this clear from the start: the post is long, and any comments I deem inappropriate, overly angry, or totally off the point (like rants about why the 3.8 design sucks or why the updater is evil), will be deleted. This is my website. You can rant on yours, thank you.

So here’s the deal. I get it. I really do. The change in the WordPress.org back end, the new admin dashboard, is dramatic, bold, and not universally embraced.

And I get that the updater isn’t something people love. Though to be honest, the volume of people who did not notice the 3.7 to 3.7.1 update, but are livid over the 3.8 to 3.8.1 update perplex me. Where were you in the end of October when we last had an auto-update?

People have passions and they are general vocal about it. I’ve had so many conversations like this:

Isn’t that beautiful, easier to read, potentially colorful, admin dashboard wonderful? Oh wait, you find it ugly, harder to read, and too colorful? But … the design works so well with a mobile phone! You use the iOS app? The colors man! You don’t like black? That’s okay! Colors! See you just go to your user profile and pick a different one. I like Ecto… what? It’s not the colors? You just hate it?

I’m not putting a picture of Aaron Jorbin up here, but you know the drill. And I get it, I really do. The change was big and it’s never going to be something loved by all. But let me quote something for you:

I agree with a lot of users too that the changes to the admin dash interface are not up to par, like some of the buttons
[…]

The defense is that new users will love it because they don’t know better? That’s rather weak considering the millions of people installed base that still want to work with WordPress.

Also, calling the old UI “insanely stupid” and loving the new one makes me suspect you really don’t know what you are talking about or you are really involved in this. What is it?

[…]

I’m going to stick my neck out on this issue and say that it has ruined the whole blogging experience for me. The UI was the best feature of WordPress, it’s the bit that bloggers know and love for being an ace bit of kit.

Those are all quotes from the topic “2.5 admin backend annoying” posted in 2009. That was when WordPress last had a totally massive, top down overhaul of the back end. And boy howdy did people have a strong reaction to it. The answer we had back then is actually the same as we had five years ago, and it’s not “Tough titties” (as Taffy would say). “Use a plugin to change it.”

Right now the vocal minority of people who hate the new WP dashboard will need to make do with customizing their experience using plugins. Which is a whole ‘nother post in and of itself why plugins are good, and that isn’t the point here.

The point here is that WordPress is probably not going back to the pre-3.8 design, nor will it be dropping the auto-updates. This was not a change made in a vacuum. It was tested by early adopters on WordPress.com (who were actually flipped over to this in June) as well as beta testers of WordPress core. The odds are, while improvements to address some of the visibility issues and functionality problems will be made, the direction of WordPress will remain forward, not backwards.

While people who really hate these changes are pretty vocal about it, it’s actually nothing new if you look back to 2.5 and how it’s redesign was received, or if you look at the failed 2.3 redesign (Shuttle) and how well that went off. And when you consider that in Wordpress 2.7, when we introduced the ‘one click’ updater for core, and how many people hated that, it’s rather astounding we ever get anywhere at all. I hate saying “Just give it a shot!” and “Cope” but that’s really kind of where we are here because of people being irrational about new features in general. And who is being irrational? Two main groups: the people who hate it, and the staunch defenders who did not write it.

The people who hate it, well, I covered that. The people who didn’t write it though, and to some extend these are people who didn’t actively or vocally work on testing and bug catching either, are the people in the support forums who mean really well, but are getting testy and snide and cranky. You know why the haters are upset, they’re having an emotional reaction. The supporters are angry because they get angry haters all the live long day, and snap back. It’s a vicious circle.

With all the new features of WP 3.7 and 3.8, there was a lot of work. Months and months of work, testing, breaking, fixing, testing again, and finally you reach a point where you have to remember this: No matter what you do, your change will break someone’s workflow.

Change happens. We don’t always like it, we don’t always agree with all of it, but change is, inherently, a good thing. Even if everyone hates it, it helps us decide the direction of our passion and where we want it to be aimed. Take all that anger and think about what it actually means and how you can take it to improve things for more people. Because we’re talking about an open source product that you’re using, for free, that makes your life better. It makes it easier to manage websites, it makes it easier to get a job, and it makes it easier to do what you want. That doesn’t mean it will always do it exactly how you want it to, though. Even I have parts of the new features I dislike.

But. What makes me and my dislike different from people who get angry are two things. First and foremost, I can recognize when I am angry, and when I do sense it, I walk away. I don’t reply. I leave the room. Even though it’s my job, to some extent, to talk to people about this stuff, I will hand things over to others, or beseech assistance in wording. The second thing is that I chose to be part of the progress and stick my toe in the water to try and change WordPress in a direction I prefer.

This doesn’t mean I’m better than people who get angry. My lack of fire in some places leads to me not being the sort who champions new directions that often. You’ll notice I’m a community type rep, and not a core-plugin one. That’s why. But what I share with the people who change the world is a desire to funnel our hate into something productive and positive. I see something I dislike and I study it to understand it, why it was done, and since this is open source, suggest changes. I try to back them up with fact when I can, and logic when I can’t find enough fact. I strive to make things improved.

I feel it’s better that way, and I sleep a lot better at night then when I was just angry all the time.

3 March, 2014
Is This Plugin Bad?

I get asked this a lot, in part because of my job (WordPress Support Guru and Manager) but also because I’m a know-it-all busy-body. The problem with the question is that it’s very subjective, and the answer highly depends on why someone’s asking the question.

I’m sure it annoys my co-workers when they ask “Is this plugin bad?” and I ask “What problem is the customer reporting?” If the answer is that the customer has a slow site, then MY reply will be different than if they were hacked. Making matters worse, sometimes the answer depends on what other plugins they’re using, or what their theme is, or how they use everything together! You see, the issue is rarely “This is a horrible, evil, terrible plugin and no one should ever use it!” It’s generally more “Well in this case, I would say this is the best plugin, but you have to take this into consideration…”

As a customer, it’s annoying. I just want a yes or no answer. But this is like that gas milage situation I talked about in my explanation of Shared Hosting. How many tanks of gas does it take to drive from Chicago to Cleveland? For me, it’s one. For my cousin, it was two and some change. Same distance, same day, same weather! What was different? The car and how we drove.

Your site and my site are different. This site and this other site on my network are different. They run different plugins, though the same theme, and sometimes one of those different plugins causes a problem. Like I found out the custom prices plugin caused my background image not to display. Oops. Does that make it bad?

There are a few types of ‘bad’ plugins to consider.

Evil Plugins

This is the easiest to explain. A plugin that is created to do evil things, like leave backdoors into your site, is bad, no matter what. Don’t use it.

Holey Plugins

This plugin has the best intentions in the world, but for whatever reason has a security hole. Maybe they forgot, maybe they missed it, but it happens to everyone. In general, this is not a bad plugin, unless the dev refuses to fix it. Or worse, can’t fix it! Now it’s a bad plugin.

Broken Plugins

Pretty common, this is a plugin that once worked but now, with the new upgrade of your theme/plugin/WordPress it stopped. This one sucks, and not much can be done except try and fix it, unless the developer comes around.

Works For Everyone But You Plugins

This is the brunt of what people mean when they ask me “Is this a bad plugin?” but they just don’t know it yet.

If you haven’t noticed, most of the ‘bad’ plugins are really just unfortunate plugins in bad situations. Determining if a specific plugin is bad for you isn’t as simple as going “Yes, I know that plugin is crap!”

What I do know, but I have to be circumspect in saying, is some plugins are better than others for specific server situations. You’re on shared? You probably don’t want W3 Total Cache right away because the best parts of it (that hooks into server side caching) aren’t available for you. On a VPS? You can probably use that YARPP (yet another related posts…) plugin just fine! Oh, but you’re using it with BuddyPress and bbPress and a whole mess of other plugins with a high degree of interactivity? You may need more memory.

And that’s the real answer. Is any individual plugin I named ‘bad’? No! In fact I’ve used them all and they’re wonderful in their use case. But they also require me to be aware of my whole situation. What kind of server am I using, what kind of environment am I in, what other plugins am I using?

It all comes back to being aware.

28 February, 2014
A Monstrous Regiment of Content
Any similarities to website configurations, current or defunct, is probably somewhat intentional. But I’m not naming names here in this tale of woe.

The situation:

You have your website: domain.com

You have a staging version where you test all your code: stage-domain.com

Your coders edit the theme code, install plugins, configure them, etc. At the same time, your editors edit content, make posts, etc. The code (plugins etc) is managed by Git because you know you should be using versioning. The posts are not because… WordPress.

The Problem:

In order to post content, you have to push code and content up to the production server. This means that if you’re trying to upgrade WordPress, you have to put a hold out on content until the upgrade is done. How do you keep the two in sync, without goobering your content?

An Answer:

Decouple content and code.

First let’s version control the php files. This means your themes and plugins will all be edited on staging, and when you’re done, you check the code in and then check it out on production.

Next we attack the DB. Have a job that, when you check out files in production, it copies up only following tables:
```
_options
_users
_usermeta
```
This means that all your code (plugin settings, theme settings, etc) gets pushed live, and all your content remains isolated. If you have extra tables, you may need to make allowances for them (like, say _podpress or _badbehavior), but you can find them quickly looking at the current DB. You’ll want to add these as necessary, or not. I’d count _podpress as ‘content’ and leave it out (we’ll get to what to do with it in a second), and _badbehavior as transient data.

On production, you have your content makers be Editors. They edit the content live (because you trust them). If you want to be extra secure, lock down the server via IP rules. At the end of every day, run a reverse sync, where the staging DB’s posts and content are replaced by the live site’s, thus ensuring everyone has the ‘live’ data. Obviously you’d want to script in a serialization safe search/replace after every sync (and have an auto-backup taken before any messing about starts).

It’s in the copy back that we decide what to do with the other files. Either make an exclude list or an include list, whichever makes you feel safer.

Includes would be:
```
_commentmeta
_comments
_postmeta
_posts
_terms
_term_relationships
_term_taxonomy
```
And then anything else you want like _podpress (see? I told you I’d get back to this).

Excludes would be anything I have in my push script from before, so _options etc. To this I’d also add _badbehavior or anything transient. I don’t really need it.

Pitfalls:

Content isn’t just posts and pages. What if your ‘editors’ need to edit widgets?

What if they don’t? StudioPress’s Genesis Framework has a totally awesome widget called “Featured Page” which lets you pick a page, check options, and off you go. What if you had a page called ‘Header Widget’ and in your widget area for Header, put that widget, pointed it to that page, and checked ‘Show Page Content’? Now your editors just need to edit that page!

What if they still do? Grab a plugin like Members and make a special role for “Super Editors” to let them make widget changes. Of course, now you have to uncouple _options and you’ve lost some of the magic here. This is a bad idea. You want to decouple content and code. Using Widgets for this is a cool idea, but what if you did it another way entirely. What if instead you used custom post types, and just had it show the most recent in the ‘spot’ for that header? Say you wanted an ad to show at the top of the page. Make your CPT for ‘header ads’ and write a post. Then schedule another for Wednesday at 3pm. Boom, your ad gets replaced! This also makes it easy to go a step further, make a Role for Marketing or Advertising, and now only they (and admins) can mess with ads. Downside there is you may end up with a lot of CPTs.

What about when WordPress updates? Well, that’s something to be careful over. If you update staging to (say) 3.5.1, but production is on 3.5, the tables will get updated. Thankfully, WordPress rarely messes with posts and comment tables. The ones that normally get poked with an update is _options, and we’re syncing that anyway. Still, you should set aside some time to test in staging before you go ahead and push this. Since we’re only posting content on production, this will have no impact on your editors.

Alternatives:

Put the content tables on another database. While WP doesn’t make it as easy as it does for custom user and meta tables, certainly you should be able to fiddle with that. Then just sync the rest of the tables. Code like hyberDB already lets you split the DB for load balancing, so you could fork that.

Or … Sync the whole database. But that defeats the purpose.
12 February, 2014