Half-Elf on Tech

Thoughts From a Professional Lesbian

Author: Ipstenu (Mika Epstein)

  • Amazoned

    Amazoned

    Amazon.com IconI don’t actually like Amazon. However the Kindle people spoke and I listened. After checking that, yes, I can release my ebook for sale on the Kindle legally (that was a weird conversation), I sat about doing it. I really wanted to self-publish on lulu, but … well, Amazon was easier. There. I said it. They actually know what they’re doing, and made it surprisingly painless! Of course, that they want you to write it in .docx, export to html, then upload a zip, was a little nuts. They also let you upload ePubs, which I have, so that was a lot easier.

    I am now a Amazon Author or publisher. Whatever. And I have two books up on Amazon:

    There’s no DRM on these puppies, and while, yes, it costs $7.99 to download, that’s because Amazon takes a really hefty chunk of change. See for every $5 you donated to me, I got $4.50 from Paypal and WePay. Amazon takes 30% or 65% of your money for every sale. Now I know, you’re thinking ‘Why would anyone pick the 35% option!?’ In the ‘real world,’ publishers give writers around 15% in royalties. Seems like a rip off at first, but look at what goes into all this. Writing, editing, typesetting, printing, binding, shipping, advertising, etc. And I’m skipping all that to go at it alone.

    So why would I pick 35% for epublishing, when all they’re doing is webhost plus bandwidth? If you pick 70% royalties, then you get 70% of the cost, minus ‘shipping.’ Shipping, by the way, is electronic delivery. You’re paying for the bandwidth. Fair enough, works out to about $0.05 for every country. But also with 70%, I can only charge between $2.99 and $9.99 US for my book. So the max I can charge is $9.99, which will ‘net’ me $6.96. With 35% I can charge up to a couple hundred ($299.99). Now here’s the dillema. How much to charge. If I max out and go to $9.99 (damn it, I wish they’d just say $10!), I may look greedy. Then again, I did all the work here, do I not deserve my $7 per book? To get the $4.50 I was getting via donations, I’d have to charge about $6.75 for the book, at which point I may as well charge $7. Then again, the average donation I got was actually closer to $8.

    Which is how I ended up at charging $7.99 you see. I don’t expect to break the bank. Hell, I don’t expect lightning to hit like that again. But it was kinda cool. By the way, you don’t get 70% for all countries, just the ones that allow it. The rest get you 35% instead.

    The biggest hassle, other than price, was sorting out the various fields, which in and of themselves, weren’t that hard. Took me an afternoon, and I had the books approved by later that day. I found an error (I’d uploaded the wrong cover, go me) and made a fix, for that I waited a day for the republish and the image to show up. Weird, but not complicated.

    I have to say, Amazon is a hassle, but far less than other places that say ‘You need to make an ISBN’ and ‘You must follow these formatting guidelines.’ which are cryptic and … You know, if they really wanted to make things easy, someone would make a nice form where you could upload your book, sans cover and author pages and copyright. Just the book content, right? Then once it’s uploaded, from epub or docx, you create your author ‘page’ and place it where you want (front of TOC or behind) and then copyright page ditto. Finally you upload your cover. If an ISBN is required, you make it for them. Remember, self publishing is something that you should be helping people do! Otherwise what’s the point?

    Amazon (mostly) hits that one on all the marks. Why not iBooks, you may ask? The tool sucked. No, really. I wrote a doc in pages (Apple’s version of Word) and you’d think I could upload to iBooks and it would auto-format. Nope. Also there was the restrictive bit. Apple’s terms say that any content produced with iBooks Author that is for sale is to only be available on the iBookstore. Free ones can be distributed anywhere you like, but iBooks Author only exports to the .ibook format (and PDFs) so if you want to free-distribute (which technically is what I do here), you have to use a flat PDF. Okay, that isn’t really terrible, the epub to pdf ratio is 1:70. But then I can’t ‘sell’ on Amazon! Amazon, by the way, only locks me down if I’m using the KDP Select program. At least I think so. I read the legalese a few times.

    Fairness to be had, I don’t feel that it’s ‘wrong’ for Amazon or Apple to restrict what you can do when selling your books. It’s free, you get what you pay for, as it were. Both Amazon and Apple take a 30% cut, and all things being equal, Amazon is a better choice. Of course you can still download them ‘for free’ if you want to from my ebooks page. Donations, as always, are welcome.

  • Penguins Just Gotta Be Me

    Penguins Just Gotta Be Me

    One penguin in a crowd singing
    Credit – Gary Larson

    Google’s Penguin came out and a lot of people got hammered, hard, by the changes. Penguin is the name of their new/updated algorithm, and it seems to have a lot to do with backlinks.

    Backlinks are when other people link to you. Pretty straightforward, but now it appears that people are being penalized for backlinks. Is this true? Yes and no. Google used to credit you for all sites that linked back to you, so the more popular you were, the more referral credit you got, the higher you were ranked, and that seems fair. Now, Google’s no longer passing through backlinks from spammers, so your referrals are dropping and people are being ‘penalized.’ But not really. That’s almost like saying you’re getting fewer phone calls after all the telemarketers stopped calling. Yes, you are, but you’re now not getting junk calls, and the ones you are getting are higher quality. The theory here is that everyone is now being judged fairly again, and by omitting the bad people from giving credit, you’ve leveled the playing field. Nice theory. It still feels pretty horrible to find your rankings dropped.

    How do you find what happened to your rankings? Search Engine Journal has a lengthy explanation, but it boils down to looking at your Google Organic traffic and see if you have noticable drops on April 19th, 25th and 27th. That covers both Panda and Penguin.

    But what caused it? Is it legit drops or unfair ones? That’s really something easily argued in multiple directions. The basic reason is something in your site, or in your site’s backlinks, has been determined to be spam. It sure feels unfair, because how can you be expected to do anything about what other people are doing! They’re the spammers, not you, why are you punished? Again, tis the great equalizer. If you remove all the bad links, what you’re left with may be a lower ranking, but it’s possibly a more honest and accurate one. I say possibly because I’m not able to see behind the Google curtain.

    Few of my sites were impacted, though I generally get traffic from Twitter and Google Plus, because that’s where I advertise. Once in a while, a post gets picked up by another WordPress blog or email list like WP Mail or Matt Mullenweg, and I get 600% traffic. But most of the time I’m pretty steady, increasing slowly and naturally. In part this is because this is my hobby. Certainly I take pride in what I do, but this is not going to make or break me. That’s lent itself to a very odd thing. I’ve managed to follow every single one of Google’s ‘do this!’ suggestions, without ever thinking about it.

    What are these rules? They’re obvious and I’ve touted them many times before.

    1. Write good content.
    2. Don’t spam.
    3. Link naturally.

    The first two are easy, the last one is a bit weird.

    Natural linking is like what I did when linking to Search Engine Journal. I saw a URL, I copied it in, and I put my own description. In addition, I don’t have a massive collection of links anywhere. I link to people and posts in-line, when they come up, and send you around to them in a way like I would if we were talking. In that way, I’m always making backlinks that are valuable for the next guy.

    But like I mentioned before, you can’t control other people’s backlinks to you. If you write WordPress themes and plugins, you maybe getting hit by this, and there is something you can do. It’s just that you won’t like it. See one of the things spammers do is use the same link, with the same URL and href attributes, over and over. What happens when you have an attribution link in your theme or plugin? It’s the same link. Over and over. At first glance, that seems horrible, because a theme would be penalized for having a link credit (like I have here) back to their sites. Some people seem to feel this is exactly what’s happening and the current feeling is that putting in the link as nofollow would be a solution.

    Sidebar: Yes, I’m aware of the debacle with WPMUDev getting hammered by Google Penguin. Of interest to me was that once they removed EduBlogs (a site they run) from having links back to them, the issue seemed to be resolved. A working theory of mine is that Google saw the hundreds of thousands of ‘self’ backlinks from these sites to the parent and it was felt to be gaming the system. This would explain why WordPress, who runs a gazillion number of sites, didn’t get hit, and why not all themes are getting slaughtered. Personally a better move would have been for Google to just throw those results out the window, but…

    Emperor PenguinPlugins, on the other hand, run by different rules. One of the plugin guidelines is no powered by links at all unless the user actively opts-in.(Themes are permitted one in the footer, or an optional one. In part this is because you only ever have one theme at a time, but you can have multiple plugins.) Having too many links out to the same place would be a problem for your SEO, and a plugin that linked multiple times would hurt you. We already know that Google knows how to check your js for hidden links. Back in 2007/2008 they added in the ability to pase onClick events, and it’s only improved since then. So while in 2008 Matt Cuts said it was safe to put a link in your JavaScript if you didn’t want it searched, that seems to no longer be the case. I’ve spot-checked on a couple sites, comparing them before and after, and studying their configurations, and many that have JS controlled ‘powered by’ links are being hurt.

    One major takeaway here is that Google screwed some things up, big time. A day-zero search on Viagra was buck wild and all wrong. It’s fine now, but there’s no way a spammer should have been ranked first on a Viagra search. I’ve complained about how Google prioritizes before, and back in 2009 I declared that Google’s Blog Search was Irrelevant. You couldn’t get a single decent result on anything. With Penguin and Panda, they’ve decided to treat everyone the same, and if a lot of terrible people are using your products, and you have a backlink, you’ll get dinged.

    What does all this mean? Well go Google for ‘panda google wordpress’ and you’ll see a lot of people shouting that they’re being penalized, and the ‘nofollow’ fix is hardly a fix at all. More are shouting that those ‘share this’ plugins, which show up multiple times on one page, are causing rankings to drop because the exact same link shows up multiple times. And right now, we don’t know. Like the Viagra problem, Google is fixing a lot of this on the fly. Google says ‘No algorithm is perfect!’ and that is certainly true, but if Google really is just equalizing things, then why were these bad sites so highly ranked to begin with?

    If you’re a plugin/theme/designer, I’d put in nofollow to my works for now. First, the link-juice didn’t matter anyway if it was in javascript, and second, what you want is people coming to your site and downloading the perfect theme or plugin. They’re going to shop around, and that will, eventually, lead to more sales. Pushing people is a sales technique that falls flat. There are so many options for themes and plugins, a hard-sell will lose you people. So will stuffing your plugin with every SEO trick you know.

    There’s no great answer, and screaming at Google (or WordPress) isn’t going to help. They’re going to do what they want. The best you can do right now is weigh your options between attribution and abuse. Are you really making things better for the users, or are you just doing this for yourself?

  • ZenPhoto and ColorBox

    ZenPhoto and ColorBox

    A color boxI use ZenPhoto for a gallery on a site that has a pretty hefty (gigs) gallery with many albums and subalbums. It’s too big for WordPress, in my experience, and so I picked up ZenPhoto as sort of the WP of the gallery world. Not knocking WP, it’s great for text, but sorting and organizing images are a hassle. The flip side to this is that getting straight directions on how to do anything in ZenPhoto makes me bang my head on the wall.

    See, WordPress has a lot of people involved, so the forums are filled with people who’ve been there before. And these people come from a varied array of talents, so some are designers, some programers, and some users. This means the documentation, while lacking in many respects, is actually a pretty awesome display of crowd-sourcing when you compare it to other web apps. The worst part is there’s no perfect way to replicate this dynamic. ZenPhoto is still relatively young, even though it’s only a year younger than nine year old WordPress! MediaWiki (at 11) is older than both, but ‘behaves’ more like the middle child, if you really want to break your head on things.

    It’s a lot to do with goals, and you can’t knock any one tool for the other. They have their places. I would never try to blog on MediaWiki, nor would I put a seriously hard-core gallery on WordPress. ZenPhoto has branched out into ZenPage, a simple CMS, but personally I’d rather see them optimize the hell out of their back end, which could use some UI love. Still, a lot of its simplicity is why I chose to use it instead of, say, Gallery or Coppermine.

    But the help is still lacking, so today was a bit of a wrangling and head bashing.

    What I want is, you’d think, straightforward: How do I edit the default theme of ZenPhoto to include ColorBox? If you ask this on the ZenPhoto forums, you get an understandably annoyed mod saying ‘This has been asked before.’ I feel for them, but as a mod and a user, I look at that and think ‘If people keep asking and you can’t give them a link to how to do it, something’s not right.’

    The directions I found in the forums never worked, but it wasn’t long before I realized why. There were simple typos. So here’s how you can turn on ColorBox for ZenPhoto.

    ZenPhoto

    1. Activate the Plugin

    This is a duh moment, but go Admin -> Plugins and check ColorBox. You do not need slideshow.

    2. Make sure ColorBox is on for your theme

    Go to Admin -> Options -> Plugins and click on ColorBox. Then find your theme and make sure that the pages you want to run ColorBox on are checked. I only wanted it to run on albums, so that’s all I checked.

    3. Edit your theme

    This is where everyone’s directions fell apart for me. Since I only want it on albums, I went to my default theme copy and set my image section to look like this:

            <div id="images">
            <?php while (next_image()): ?>
    		<div class="image"><div class="imagethumb">
    		<a href="<?php echo html_encode(getDefaultSizedImage());?>" rel="showcase" title="<?php echo getBareImageTitle();?>"><?php printImageThumb(getAnnotatedImageTitle()); ?></a>
    		</div></div>
    		<?php endwhile; ?>
    

    Make special note of your classes and rel here! In specific, notice how that I have two divs for image and then imagethumb? While either one will work, I made a note of imagethumb, since it was a little more specific. Also I made a note of the rel in my image itself, in this case rel=”showcase”

    Then back up before I close my head section, I added this:

    	<script type="text/javascript">
    	// <!-- <!&#91;CDATA&#91;
    	$(document).ready(function(){
    	$(".colorbox").colorbox({inline:true, href:"#imagethumb"});
    	$("a&#91;rel='showcase'&#93;").colorbox({transition:"none", height:700, width:"75%" });});
    	// &#93;&#93;&gt; -->
    	</script>
    

    See how I’m using the showcase and the imagethumb? That’s why I needed those.

    4. Customize

    Everyone says ‘Read the directions!‘ but when you look at them, they’re written for people who know jQuery. I don’t. So when I don’t know what I’m doing, I make a list of what I want. By the way, yes, it irritates me when directions are ‘too techy.’ You can’t know where people are in their understanding of things, and you can’t expect everyone to be amazing at everything. I was very close to appealing to anyone who owed me a favor for help before the end of this.

    No set height

    That’s as easy as removing height:700 from my js.

    Force colorbox to treat my cached image as an image

    Just add photo:true to the js. I had to do this because my server renders the images via a php file (to redirect to cache) and this was causing funny problems. It’s a known issue, though, so one I figured out how to search for ‘ColorBox is making my images show up as gibberish!’ I found the answer.

    Put a link to the full sized image

    And here began my headache. If I put in this (where I used to have the height code):

    title:function () { return "To view full size, " + "click here!".link(this.href);}

    … then my link goes to the getDefaultSizedImage() size (which is a max width of 540px for my theme) and that isn’t what I want. I could change it to getFullImageURL(), but then colorbox loads the fullsized image, and that’s just a little silly and bad for bandwidth. I spent the next hour reading up on jQuery to understand that I really wanted to pass data through. Finally I struck about the notion that I could make a new variable in my href.

    full=<?php echo html_encode(getFullImageURL()); ?>

    This makes a link to the full-sized image. And then I changed this.href to $(this).attr('full')

    In the end, it really wasn’t hard, but nowhere were all the pieces laid out in a way I understood. I’m happy with how it all turned out and the site now behaves like it’s 2012.

  • On The Segregation of Code

    On The Segregation of Code

    WordPress stores your URLs in the database as the full URL. That is to say all the links to other pages on your site, all the images, use the full path.

    When I changed this site from tech.ipstenu.org to halfelf.org, I knew that meant I’d need to do a quick search/replace in the database. That meant first I searched wp_2_posts for everything saying tech.ipstenu and replaced it with halfelf. Then I did the same in wp_posts (since I knew I’d done some of that). I did this directly in SQL because I can, and I believe in using the right tool for the job. To whit:

    UPDATE wp_2_posts SET post_content = REPLACE (
    post_content,
    'tech.ipstenu',
    'halfelf');
    

    That code searched all my posts and changed the URLs so my images looked right. Now, since I’m using a domain mapping plugin, I don’t need to go in and change wp_blogs, which I would be very hesitant to do anyway. I’d sooner make a new site with the same name (either manually or via a replicator), delete the old one, and use .htaccess to redirect.

    Why would I do all this? Well, because WordPress stores URLs in a non-relative way. The link to my about page is https://halfelf.org/about, not just /about, and that screams in the face of what I learned back when we all agreed that paying for Netscape as a browser wasn’t a terrible idea.

    The real question people are asking is why are we this way?

    There are a lot of arguments, one is that you shouldn’t change your URLs. Another is that WP is written for the user, not the developer. A third is that you’re trying to force your process on a tool, when you should really develop the process for the tool. That third argument is where I live. I believe in being adaptable, while I want all my code to be flexible, adaptable and fluid, there’s a time and place for the flexibility being the code, and the flexibility being me. In the case of URLs, I think the flexibility must be mine.

    In the ‘real’ world, you should never change your URLs, and if you do you always have the old ones forwarding to the new ones. Go on, go to http://tech.ipstenu.org/about/ and where do you end up? That’s because the plugin works. Go to http://code.ipstenu.org/about/ or even http://ebooks.ipstenu.org/ and see what happens. That’s because I forward those (obvious) URLs to where they should be. I know that people can adapt to change, but I can help with them a well crafted .htaccess rule. That’s flexibility in my code.

    When we take another step back and consider the flexibility of code, we muddle that up quite nicely with the flexibility of content. These are different things. Code should be flexible and adapt to any situation you put it in, but you need to be flexible to adapt your content to the situation. Content cannot be considered in the same breath as code, because they are segregated by their very nature. We should be able to pick up our content and plunk it down in any code, and have it work equally well. This argument was fought, and won, by CSS back in the day. So how does this work with URLs? They’re in my content as links, and if I change them, I have to change my content.

    Let’s take the example of building a site locally. Personally, I use a hosts file to make halfelf.loc so that when I’m done building it all out, I export the DB, replace halfelf.loc with halfelf.org, and I’m done. Why do I pick halfelf.loc? If you’ve been here before, you may remember I wrote about Moving Multisite. In there I mention serialization. That’s why. Searching for domain.loc and replacing with domain.org will not break serialization! This is, some claim, a ‘bush league’ maneuver (yes, zamoose, I heard you), but have you ever tried to move an application on your desktop to a new location? You have something installed in Program Files, let’s say, and you want to move that to Program Files/Half Elf? Congratulations, you get to search the whole registry!

    See, it’s not just WordPress. This isn’t an excuse, but a statement of fact. Many applications on the web don’t use relative paths, and they do force you to search/replace things to move to a new location. This is especially the case when you think about how we write links. Some people use the link interface, which if used, could insert variables for ‘base path.’ But some of us use the old fashioned manual way, and now you have to code a really fancy bit to check “Did Ipstenu post a link to myself? If so, I need to change halfelf.org/foobar into [basepath]/foobar so I can update it later if I move.” Certainly it can be done, but it’s actually going to be easier to just search/replace. The ‘more’ you search for, the easier it gets. I actually know someone who did this. He says it was more trouble that it’s worth.

    That really doesn’t surprise me. What all the proposed fixes to this try to do is to force WordPress into working a certain way, rather than customizing a solution. That probably sounded the same to a lot of people, but it’s not. The method by which you move static HTML files around servers is, for lack of a better term, a migration method. When you migrate an application from sys to test to production, you do so because there are a lot of moving parts to test. It’s in these moves that we face headaches with the relative path locations. When we hard code locations into our content, like in a URL, we lock ourselves into that URL, now and forever. But does the content actually matter?

    For me, the real question is ‘What moving parts of WordPress might I be testing that I would need to ‘push’ to my production site?’ I came up with three things:

    • Themes
    • Plugins
    • Content

    I ‘push’ themes and plugins out to a test server and then my production server all the time. I do it for hundreds of different applications a day, and it’s all automated. We never have a problem (unless the code is bad) because we perfected our migration method, and let go of the idea of pushing our content. Our content is not our code.

    Initially, we didn’t replicate content for legal reasons. We have sample data to test with when we’re checking out theme and plugin changes, but we don’t bother with data replication. Realistically we can’t, since the people who are testing things out don’t have the security clearance to look at the content. Because of that, we have to trust that the live data is the live data, and that it’s good. Instead of sweating over the content, we concentrate on copying up, in this case, themes and plugins. Since those may have customizations, we take a snapshot of the database, install the theme, make our changes, and take a snapshot after. Get the diff, and now we know what needs to be applied up. Then we script it. The job will FTP up the files, run the SQL diff (which we’ve already edited for the new domain name if needed, but rarely since we use hosts to point at our dev server instead), and off we go. Same thing for plugins.

    If I apply this to WordPress, suddenly I have but one, minor, headache in moving my code, and that’s the wp_options table, and it’s serialization which includes the URL. I agree, that’s a headache and if I was going to put paid effort to fixing anything about relative URLs, that would be it.

    But I don’t think that URLs for WordPress should be non-relative. Given the alternatives and the possibilities, right now the issue isn’t that WordPress stores the like that, but that we don’t have a migration ‘process’ defined yet. We should stop getting hung up on ‘fixing’ what isn’t broke, and instead start looking at the best ways to move what needs moving. See, once we found we couldn’t replicate our content, we started looking into what needed to be done to protect it, outside of ‘migrations.’ In WordPress, today, the best way is to have your writers submit their posts, and your editors review and publish. You may want to look into groupflow plugins, or do what the Bangor Daily News did.

    The right tool for the write job.(Pun intended.) Moving your content between testing and live servers isn’t needed. Just concentrate on moving the ‘app’ as it were. It’ll work better.

  • WordPress Multisite 110 – Electric Boogaloo

    Multisite 110

    Introducing WordPress Multisite 110

    I promised a sequel and I delivered. I hope you guys find it helpful. The sequel is out, and it’s longer than the original. Weighing in at over 80 pages, WordPress Multisite 110 has even more information about WordPress Multisite!

    Why a sequel and not a second edition? There were more things to add than a few extra plugins. Branching into a little more philosophy and explanations to the whys, Multisite 110 hopes to be the second handbook you’ll need. The funny thing is most people who read my site regularly don’t need this at all. But your clients might. Imagine being able to hand that off to them saying ‘I’ve got you started, here’s how you can make it epic.’

    Oh yes, with a Creative Commons release, you can pass this on to your clients as you like. I won’t stop you, just don’t sell it to them. If you want to get into the shenanigans, you can bill them for it, but not sell it. Yeah, licenses will kill us all one day. Speaking of licenses, there’s code in this one, and it’s all under GPL2 (most of it’s also on this site already).

    What’s not in it? Deep diving into the database. Fixing everything… There’s no way to cover everything. This one gets into the machinations of how you make a multisite where everything looks the same, or where your admins aren’t admins at all. Favicons? Got that covered too! The White Page of Death? How to figure out what plugin you want? Man, you know I got your back! Backups, control, security, uploads… the list isn’t endless, but there’s a lot going on.

    Check out WordPress Multisite 110

    The post title of ‘Electric Boogaloo’ comes from a movie that came out in 1984: Breakin’ Two: Electric Boogaloo. All sequels should have that sub-title

  • You Can’t Be Everything

    You Can’t Be Everything

    There’s no app out there that does everything.

    A lot of you just said ‘I know.’ but did you ever stop to think about why that’s the case? After all, some applications do everything you need them to do, and some you don’t, so who gets to decide what is and isn’t needed? When I talked about how WordPress was just fine on it’s own, without any plugins, people stepped up and said “But Ipstenu, I really need XYZ.” Heck, Lorelle said she needed Akismet.

    Learning how to separate your personal needs from the needs of the masses, when writing software, is a full-time job, and many of us come at it from a slant-wise point of view. In fact, writing core code for WordPress is in diametric opposition to why we write plugins! While I’m going to talk about it from a WordPress point of view, the concept holds true to any application that has ‘add ons.’

    Plugins are written, by in large, to solve a specific problem. They’re not ‘fixing’ WordPress, they’re expanding. Remember, your iPhone wasn’t broken until it had Angry Birds, nor was your iPad incomplete without Twitter. Those are things you wanted, and solved a problem for you. The base tools, in and of themselves, address a broader group of people, with a diverse set of needs, and have the option of being everything or nothing.

    The best tool, WordPress, your computer, etc, are built to be extendable. They’re built with the innate knowledge that the users may want things they can’t forsee. Five years ago, how many of you thought Google+ or Twitter would be a ‘thing’?  Let’s take that further. You know how when a new video game comes out, sometimes you can’t play it on your older computer? That’s because it wasn’t built with the new game in mind, so it’s just not capable. And that’s why computers generally let you upgrade memory, CPU, and hard drives. They are built to be extendable becuase they know they can’t know the future.

    Bringing it back to WordPress, it was built to meet a need. People wanted to blog, they wanted it to be easy and they wanted it to just bloody work! So the Matts said ‘This is what we want’ and built it. Thankfully, they understood that people wanted to extend WordPress. But not at first. Oh you didn’t know? Back in December 2003, a ‘new feature’ was introduced called my-hacks.php, which let you put a file by that name in the root of WP, and it would treat it like a functions file. In fact, that’s why I call my non-plugin code ‘hacks.’ Heck, we didn’t get pretty permalinks until January 2004 (then called ‘cruft free’ URLs).

    The point of this is not to expose the funny looking beginnings, but to demonstrate the nature of the software. As it grew, people had needs, and instead of writing everything into core, they cleverly changed WordPress so it was extendable and let people grow as they needed. So when we talk about things like needs and wants, we do it in the understanding that we write our software to fill a need, and we make add-ons to fill wants. Sounds like double speak, I know, but that’s why I said plugins and core development are in direct opposition.

    When I want to add things to core, I want them to be useful to everyone, so I’m forced to remove my ego from the equation. Looking at the (few) core submissions I’ve made, I carefully thought them out beforehand. I looked at places were the user experience was inconsistent or diminished. When I make suggestions or offer commentary to what I think could be better, I try to show my passion without acting like a teenager’s first big crush, or a screaming fangirl meeting her heroes.

    This isn’t to say I don’t think passion is a part of the driving force of any product, but that it must be tempered and controlled in things like WordPress core. We know that we can’t make WordPress core do everything, and we know we shouldn’t. When things are extendable, we utilize that and demonstrate our fire. When they’re difficult to extend, or kludgy to implement, we come back and say ‘You know, it would be nice if we could…’ But at the end of the day, when WordPress tags your trac ticket ‘wontfix,’ it’s because they know, being unable to be all things, that they must limit the things they are.

    If you haven’t yet, take the time to read WordPress’s Philosophy.

    Aaron Jorbin - Haters Gonna HateWhen I usually talk about divorcing my ego from a project, what I mean is that I don’t let my passion cloud my better judgement. One of the lessons I’ve learned in nearly 20 years of active fandom is that when you love something, you get fired up about it, and you tend to view peoples opinions and actions as a personal attack when, in fact, they often aren’t. Yes, there are idiots and trolls and people who hate-monger, but in general, people actually aren’t dicks. They’re selfish and self-centered, but that’s just human nature. Part of designing a project means you have to let go of your personal attachment to your baby, and understand that haters are just gonna hate, and there’s nothing you can do about it.

    This also applies to using a tool, though. People mock the evangelists, and we all hate the extremists, and certainly no one actually supports those who are outright malicious. But all those archtypes come part and parcel with a system, and are all aspects of the simple problem that no one product can do all the things. We want things to be a silver bullet, to fix everything we, personally, have a problem with, and we’re totally unrealistic in wanting that.

    Mark and I were talking recently, and he pointed out that WordPress was once 230kb. It’s now 3.8megs, even zipped up. Part of this is because it all grew and became more, but if you ask the old-timers, some will complain that around the 1.5 days, WordPress just became too big. It does too much! And those people say we should pull things like the importer out of WordPress. After all, you’re going to use it once, if at all. Core plugins would get pretty big too. Jetpack is 2.4megs on its own, zipped up. By trying to be everything, maybe we’re making things a little worse.

    So the next time someone gets their panties in a bunch at you for not doing everything, tell that it’s by design. Do what you want with your code, make it easily extendable for the next guy (or forkable), and carry on. They’re not getting that unicorn.