Half-Elf on Tech

Thoughts From a Professional Lesbian

Tag: design

  • How To Submit a WordPress Plugin

    How To Submit a WordPress Plugin

    Submit to WordPressI’m not a super-psycho coder. But between being a busybody and being a volunteer plugin referee, I do spend a disproportionate amount of time looking at the code people put in for plugins, which means I actually see a lot more code, and a lot more submissions, than you might expect. This puts me in a place where I actually can offer some of the world’s most basic advice ever, that a surprising number of people seem to miss, about how to submit your plugins, what will get them downcheked, and what you really just shouldn’t do.

    This list is not all encompassing, but touches on the issues I see the most often.

    What You Must Do

    Failing to do the following will likely end up in your plugin being yanked (or not approved at all).

    Read The Guidelines

    We are not pirates. These are not wishy-washy rules, though they are intentionally kept as light as possible. You see, the more you make a rule “You can’t do this!” then the more you get “Well, you said I couldn’t dig to China, not Australia!”(That’s a true story on my part. I once got my kindergarten school class to dig to China. After being told not to, I got them to dig to Australia. At this point, they said ‘No digging tunnels at school.’ My parents explained in more detail why this was dangerous, and we watched The Great Escape to understand tunnel collapse. I forget how Dad explained the distance, but I remember a long explanation about the earth’s core being molten, and no, you can’t dig under the ocean. I was bummed. I was also 4.) The basic guidelines are on the front page of the Developer Center, but it’s the expanded guidelines you really need to read. I helped write those guidelines (over beery emails with Otto) and he and I both hate that we have to spell certain things out, but apparently they’re unclear. Just read them. If you think you’re doing something that might be on the far side of okay, ask around. Tweet, post in the forums, or find a plugin dev you respect and ask them directly.

    Check Licences

    All plugins must be GPL2 (or later) compatible. This is pretty basic, but a lot of people don’t realize what that means. First, there’s the issue of GPL2 versus GPL3. While the WordPress repository accepts GPL3 plugins, it’s still not compatible with everything, so make sure the code you fold into the plugin will work with which ever license you chose. If you don’t want to use GPL, you don’t have to! Remember, there are a lot of GPL Compatible Licences. At the same time, there are a lot of incompatible licences as well. And there are the Non-free Software licenses. When you’re only releasing your own code, this is pretty easy. You pick a compatible license and move on. When you’re incorporating other people’s code, however you have to study their license carefully.

    Generally I’ve seen people get dinged for using the Creative Commons license, and in most cases this is because they’re not using the CC0 license. That is the only CC license that really works with GPL (except for CC BY ND). Your code really shouldn’t be CC licensed, anyway, though. Just don’t use it.

    Provide the code

    World Wide DownloadsWhen you submit your plugin, put in a link to the code so it can be downloaded and checked. (See Expanded Guidelines, Rule #16) If, for some reason, you can’t because the code is behind a paywall, or you don’t want it in the wild, don’t worry! The only people who see that link are the plugin review team, and they’re trustworthy. They don’t need an API key, either, they just want to make sure you’re not breaking the repo guidelines. If you don’t provide a link to the code, you don’t get in. It’s really that simple.

    Don’t break the other WP rules

    Did you know you can’t use ‘wordpress’ in your domain name without permission? If your author or plugin URL is http://mycoolwordpressplugins.com then your plugin will be rejected. (See Expanded Guidelines, Rule #17) In addition, you’re still going to be held subject to the forum rules with your account. I mention this because if you get blocked on the forums for rampant asshattery, you won’t be able to check new code in. Basically remember that it’s the internet, and we can see your behavior on Twitter, Forums, Faceybooky, etc. Don’t be an idiot.

    What You Should Do

    Not doing the following won’t get you punted from the repo, but they’re still good to do, in order to provide the best support possible.

    Write a good readme

    A good readme file is going to tell the person everything they need to know before they download the plugin. This means:

    1. Describe what the plugin does
    2. Explicitly state any and all requirements
    3. Be upfront about any external accounts required (for APIs or what have you)
    4. Inform users if their information is being sent to another site, where, and why (not necessarily technical explanations, just ‘Your IP, browser specs, etc will be sent to Google for Analytics purposes. This is required if you want to use Google Analytics.’)
    5. Include screenshots of the options
    6. Include a screenshot of what the plugin looks like on the unmodified default theme
    7. Document if no support is provided (or if support is handled somewhere other than the WordPress forums)

    Credit Appropriately

    Thank YouA subset of that is that if your plugin is a fork of someone else’s, be the good person and credit them! It’s not required all the time, but take a look at the copyright information on a plugin. Sometimes they say they require credit in the code. If so, you’ve got to do it. Even just a line that says “Copyright 2009-2011 Some Other Dude” and then “Copyright 2011 Me” below it. That’s a nice CYA. If you want to be really nice, put their userID under ‘contributors’ in the readme file, and they’ll have their pretty face on your plugin.

    Write Good Code

    Using good code is complicated. I don’t pretend to be the best at it myself (seriously, the level of shenanigans I went through over nonces cannot be measured on a human scale). But I know that good code is secure code. I know I should use nonces in certain situations, I know to protect against SQL injections, and I know to not let total strangers upload executable files (so they can’t upload a PHP file that wipes my DB, for example). And I know when to go find Otto, WePay him a beer, and say “So what the hell did I do wrong, here?”

    Writing good code is exceptionally complicated, which is why, if you’re going to write a large plugin, you need to know what you’re getting into. The problem a lot of people get into is the classic ‘Your eyes are bigger than your stomach.’ When you write a plugin, keep it simple. Start with the code you know, slowly fold in the new stuff. Try to test as many different ways as you can think of, but know that you’re going to miss something.

    What To Do If Your Plugin Is Yanked?

    Every plugin developer’s worst nightmare is waking up to find that their plugin was yanked from the WordPress repository.

    Don’t panic!

    Don't Panic This happens when your plugin has been reported as possibly being in conflict with the developer guidelines, or it has a security hole. Many times you will not be notified when this happens. Sometimes you’re not notified because the report is found to be incorrect, and sometimes it’s because you’ve been warned before. And, once in a while, it’s because the person who closed your plugin doesn’t have the ability to email you. Surprise! There are some people on the plugin repository team who don’t have the access to the plugins email system, so when they close your plugin, they’ll ask someone else to email you. If that person is busy, it might take a while.

    When a plugin is closed, the rest of your plugins are usually checked over to make sure they’re not also having an issue. For example, if you have one plugin with a front facing link that’s turned on by default, all your plugins will be checked for that and, if they all have the same problem, they will all be yanked. This is why you need to keep up to date on the plugin guidelines, and follow the WordPress Development Blog.

    As soon as you find out your plugin is closed, email plugins@wordpress.org and ask what you can do to restore it. Posting in the forums won’t help much.

  • Giving WordPress That New Car Smell (Part 2)

    Giving WordPress That New Car Smell (Part 2)

    Simplicity is the ultimate sophistication.

    In Part One I talked around what I did. Here are the themes I picked, what I feel about them, and what I loved and hated.

    All three themes are frameworks, and I’m using children there of. Unlike just making a child theme from TwentyEleven, these are true, robust, themes, designed by artists. This took me maybe 10 hours of work, total, to do everything on all three sites, and as most of that wasn’t me sitting down and concentrating, but multitasking and bouncing around, so it may have been 4 hours serious work.

    Oh and all these themes are ‘premium.’ And worth it.

    Origin – In use on Half-Elf On Tech

    Origin Theme

    Origin was the first theme I picked, from DevPress, and I decided on it after playing with a bunch of different DevPress themes. I’m partial to them (and ThemeHybrid) because I’ve been using Hybrid Core since before it was released, and I know it. I’ve memorized the hooks, and I like being able to quickly spin up my functions.php for it. All the serious changes are done in a pretty small file, actually, and mostly have to do with inserting FaceBook and Google into the header and footer, my comments ‘rules’ and that cool clickable (and hoverable) asterisks in my site description. I also really like the ‘full page’ view, and used it on some of my content-only-no-comments pages like Licensing.

    Since I have a mini rant later on about favicons, Origin lets you update the favicon right there in the theme settings.
    Origin Favicon

    This is especially important for Multisite installs, where each site will want their own favicon. Now I don’t need a plugin. And if anyone can think of a cooler favicon for this site than the Spock Eye, let me know.

    Balance – In use on Ipstenu.org

    Balance Theme

    Balance, from StudioPress, was next. This was a huge departure for me, and oddly it’s the theme I love the most and have the most issues with. Let me explain.

    While I’m perfectly comfortable bashing away at a functions.php file, unlike Origin, Balance is a child theme. See, HybridCore is a ‘starter’ parent theme, where you make your own child off it. Balance is a true child theme. When I got it, it came with a copy of Genesis, which is the parent. So while with Origin I made ‘HalfElf Origin’, I couldn’t do that here. I would have to edit the Balance theme directly, which goes against my nature.

    Back in the day when I used Hybrid News, Justin made a massive upgrade. I hated it, as I’d made all sorts of tweaks to the theme, and it was a bitch to fix. Now, I happened to agree 100% with the choice to make those changes, you had to upgrade the menus for WordPress 3.0, but it was painful. This sort of hassle scarred me for life. I don’t like to edit themes directly. So I pinged Andrea and asked her ‘How often do these themes update? She said ‘rarely’ which isn’t the same as ‘never’ and, while calming, wasn’t the best thing in the world for my neuroses.(Nacin makes ‘tin foil hat’ jokes about me for a reason. I don’t trust anything.) Personally I’d love to see Genesis go the same way that Hybrid did, and to make a ‘core’ that is included in all their themes. Then Balance would include all the files for Genesis and Balance, and people could happily make their own children.

    With that in mind, I did a smart thing. Instead of editing the child theme, I made two files: ipstenu.css and ipstenu.php (I told you I’d get back to why there was no style.css(Actually, there is a style.css in the folder, but only to stop WordPress from throwing silly errors. It does nothing.)) and put them in a fake theme folder called ipstenubalance. Those I included into the style.css and functions.php of the actual child theme.

    Calling the CSS was easy:

    @import url("../ipstenubalance/ipstenu.css");

    And the special functions is just this:

    require_once( get_theme_root() . '/ipstenubalance/ipstenu.php' );

    Now all I have to remember is that if the default style or functions gets edited in Balance, to re-add those calls in.

    The reason I dislike Balance, however, is not my own personal issues (and I’m well aware they’re just mine). It’s that there was a favicon forced on me. I hate that with a passion. You see, everything else is really a small change. I want a larger font, a darker blue, a bigger curve. But a favicon is … your site is naked without it. And it should resemble who you are. That’s why I have my ‘me’ image as my favicon most of the time.

    But at the same time I love Balance, because I was able to overwrite the favicon with this:

    remove_action( 'genesis_meta', 'genesis_load_favicon' );
    add_action( 'genesis_meta', 'ipstenu_load_favicon' );
    function ipstenu_load_favicon() {
    	echo '<link rel="shortcut icon" href="https://ipstenu.org/favicon.ico" />';
    }
    

    Other than that, Balance is my first go-at with a ‘managed’ theme, and I have to say I’m really astounded. If you didn’t know anything about functions and hooks, you could still make this site (in fact, I did, via a Genesis Hooks plugin). It’s crazy customizable, without feeling clunky. And yes, some of the other ‘pro’ themes I looked at felt that way. StudioPress impressed the hell out of me. If you need a ready-to-go theme and don’t want to mess around with code, StudioPress is the way to go. They set the bar for parent themes. And like Origin, they too have a full-screen template, which I used on my terms of use. I suppose this is why the don’t go the route of Hybrid Core. Most of their users aren’t going to play with child themes, and instead will use the built in features, or the Genesis Plugins to customize things from the WordPress admin dashboard.(This morning it occurred to me that having ‘hybrid core’ as a non-parent theme means that if Hybrid updated, Origin would need to be, and now someone has to edit that. The difference is I’m only editing my child theme. When Origin gets updated, it doesn’t impact my child, and a trained theme guru will make the edits, not a newb. On the other hand, if Balance is updated… Yeah. I suspect at this point it’s too much work to say ‘Make a child theme!’ for the Genesis users, but I’d love to be a fly on the wall for that conversation!)

    It’s a step ‘back,’ in terms of me being a developer, but at the same time I feel a burden lifted when it comes to managing things. A strange balance.(The pun was totally intended.)

    Dotos- In use on Ipstenu.Photos

    Dotos Theme

    The last one was for my Photo site, Ipstenu.Photos, and I wanted it to look like a photoblog. This was really easy, since as Dotos is also from DevPress, I could cheat and make a child theme called photodotos and copy my Origin functions over, renaming halfelf for photos. I did one minor css tweak on Dotos, and that was to hide the ability to comment on photos. Didn’t want it or need it. I have a lot less to say about it, since everything I said in Origin applies here, and I did less tweaking.


    So there you have it. My sites got a facelift, and I’m so happy, I load them up just to smile at how sexy they look. My site feels bright and new, and I want to blog more. And that is a win, no matter how you look at it.

  • Giving WordPress That New Car Smell (Part 1)

    Giving WordPress That New Car Smell (Part 1)

    It’s been a while since I redesigned my sites, and this isn’t something I do very often. I also have a tendency to stick to a ‘theme.’ For the longest time, I was really homogeneous with the sites on this server. All my Ipstenu sites ran Retro Fitted and then Twenty Eleven. As we got near 3.4 I was all set to shift to Twenty Twelve, but when that was kiboshed, I sat and thought “Well, what do I want?”

    Redesigning a site is not to be taken lightly. As I mentioned before, too many changes confuse your visitors. For the last few years, I’ve kept my sites pretty much the same, and this is normal for me. I mean, look at the designs for JFO! Clearly I find a style and stick by it. I don’t consider myself a ‘theme designer’ person, either. I can tweak the hell out of a theme, but inventing them? No way. I’ve never been very good at the part of art where I’m supposed to take an idea and make it visual. Oddly, I can do it with words and ‘people’ (think directing a play), but while I can see these things in my head, putting it down on paper fails me.

    So why the dramatic change from everything the same to everything different?

    Everything should be made as simple as possible, but not simpler. There’s a theme through these themes, actually. They’re all simplistic, focusing on the content in a way that I can, easily, shove the sidebars out of the way when needed, and showing you what’s important. I didn’t want to get distracted by bells and whistles, but I also wanted a theme that was easy to tweak. Ipstenu.org I wanted to look a little more grown up, Half-Elf needed to be more professional (but still as irreverent as I am (In talking to Dana Severance, she asked what my ‘voice’ was for my ebooks. I said ‘Ms. Frizzle, after 10 years in corporate America.’ And it’s true.)), and my photos needed to be about photos and nothing more. I also didn’t want to fuss with colors too much, they can be a big distraction, and just putting up a black/white with accents felt ‘right.’

    Once I committed to simplification, I cut down my menus while keeping them similar to what they were, and I kept my favicons as they were (though Half Elf has been sporting a Spock eye for a week now). Menus are tricky. You want people to find what they want, quickly, but you also want to guide them to where you want them to be. By cutting down the clutter, and having a little down-arrow on menus with drop-downs, I can gently nudge people around.

    Buzz-words annoy me, and I try to avoid terms like ‘call to action’ whenever possible. Instead I thought of as the purpose. I like using ‘static’ content on front pages for that, as they can explain why you’re here, show you what’s new, and grabs you. The new Half-Elf page really does that, with the big honking ‘ad’ for the book. The haiku keeps you thinking ‘This is Mika,’ and the rest confirms that. On Ipstenu.org, the sales pitch is smaller, but you still have a little ‘who am I?’ blurb to get you started. While I wanted it to look grown up, I really felt the ‘feel’ of me had to stay. That’s the only site where you’ll see my Twitter stream, for example. As for the photos, well, they were simple.

    I drew out what I saw in my head on paper a few times. A header, a menu, a ‘grab you’ blurb, and the content. It’s a good layout for me, I felt the eyes naturally flowed. Sorting out where on Half-Elf to put that ‘recent post’ inset was tricky, as I wanted it to be ‘above the fold,’ if you’ll pardon the archaic reference. Speaking of, all these themes are ‘responsive’ so if you shrink your browser, they adjust. Except for the leaderboard ad in the footer. I need to sort that out.(What I want is for if your screen is less than X wide, it vanishes. Maybe I’ll play with hiding the overflow.) This does not contradict my drawing deficiencies I mentioned before, by the way. When I ‘drew’ my layout, what I did was grid it out. That part wasn’t ‘art’ and I didn’t try to make anything pretty. I just made a list of what the themes needed in black, what I wanted in blue, and what I knew would be custom work in red.

    I ended up with three premium themes that I’ve added functions and style to, but that’s it. While I may have made child themes, there’s no duplication of code. That is, my child themes have two files (functions.php and style.css) and possibly some images. That’s. It. halfelforigin is the child for Half-Elf, ipstenubalance is for Ipstenu.org, and photodotos is for the Photo site. The first half of the name is the site, the second half is the theme. I’ve always done it this way, which is why I also have an ipstenu2011 folder in there.

    Oh, and why does the ipstenubalance not have a style.css? We’ll get to that.

    But that will have to wait for the next post, where I break down each theme, what I liked and disliked, and what code I wrestled with. It’s a little longer than this post, which is why it’s split up.

    By the way, the title is thanks to Ryan, who took my joke seriously.

    http://twitter.com/Ipstenu/status/193061445762691072

    http://twitter.com/ryangiglio/status/193061904686649344

  • Pretty URLs Matter

    Pretty URLs Matter

    Just over a year ago, Lifehacker changed their site and we all learned about the hashbang. I believed that pretty URLs mattered:

    I would posit that, since the web is based on look and feel, the design of your site still relies, in part, on the ease of someone in understanding the URL.

    Well Dan Webb agrees with me: (It’s About The Hashbangs)

    After quite a lot of thought and some attention to some of the issues that surround web apps that use hashbang URLs I’ve come to conclusion that it most definitely is about the hashbangs. This technique, on its own, is destructive to the web. The implementation is inappropriate, even as a temporary measure or as a downgrade experience.

    This Dan guy happens to be in charge of switching Twitter from the #! back into nice, normal, readbale URLs:

    You can read the whole Twitter convo on Storify. But the take-away is, I admit, a little dance from me of ‘I told you so.’

    In the comments of my previous post, someone pointed out that Google uses Hashbangs in a search. I have not seem them in my searches (here’s an example of what I do see on page 3 of a search for ‘sadasdas’):

    https://www.google.com/search?sourceid=chrome&ie=UTF-8&
    q=sadasdas#q=sadasdas&hl=en&prmd=imvns&ei=8CthT86EEoWDgwerpqDwDA&
    start=20&sa=N&bav=on.2,or.r_gc.r_pw.r_cp.r_qf.,cf.osb&fp=6b8f6c2ef22f8dde&
    biw=1324&bih=879

    The thing is, Google doesn’t matter in this instance. Actually, none of Googles URLs ever really matter when it comes to the reasons we want Pretty URLs. Remember our credos?

    URLs are important. Yes, they are, but they’re important when you’re looking for something. They should be important on, say, YouTube, and they certainly are important on Google Code pages. But for a normal Google search? You don’t type in google.com/ipstenu or even google.com/search/ipstenu to find pages about ipstenu (Though, really, that would be really awesome if you could! At the very least, the 404 should have a ‘Do you want to search for that?’ options. Get on it, Google Monkeys!) Which is the point I was trying to make. When you go to a site for specific content, you want people to say ‘Go to ipstenu.org/about’ and be done with it.

    URLs are forever. Again, yes they are, except when they’re not. For Google? This doesn’t matter. They don’t search themselves, and rarely do I know people who bookmark a Google search. But… Did you know Googles search URL formats are backwards compatible? That’s right. If you had an old URL saved, it would still be usable.

    Cool URLs don’t change. Except for search URLs. But Google knows if you’ve gotta change ’em, make ’em backwards compatible. Ben Cherry has a nice article on why it’s good, too, which I found enlightening. I still don’t like them on the front end of websites, mind you, for a reason Ben points out:

    The hashbang also brings a tangible benefit. Someday, we will hopefully be rid of the thing, when HTML5 History (or something like it) is standard in all browsers. The Web application is not going anywhere, and the hash is a fact of life.

    That’s the problem right there. We’re building something we know is going to go away! We just broke a credo!

    Are there ever reasons for using Hashbangs? Sure, but most of us will never need them. They’re great for loading AJAX which is awesome because you can load new parts of your site faster. Heck, WordPress has some AJAXification, but it’s primarily on the backend. They’re fantastic for web apps and they have some attractive functionality. But they don’t work for everyone, and they never will.

    The ‘replacement’ is HTML5, which introduces pushState, which lets you use a JavaScript library with HTML5 history.pushState and … well basically you write an app with that instead of AJAX and the Hashbang, your URLs stay pretty and your page can still have that nice ‘click to add the new tweets’ functionality that we’ve all seen on the new-new-new-Twitter. And Facebook.

    See, pushState is giving us these three things (among others):

    • better looking urls: A ‘real’, bookmarkable, ‘server-reachable’ url.
    • graceful degradation: Render correct pages when you don’t have JS enabled.
    • faster loading: By only loading parts of the page, slow-net users can get the content faster.

    The downside? It doesn’t work on IE right now. That’s okay, though, since it’s got graceful degradation, IE users will just have to manually refresh things. Which sucks for IE users, but perhaps will be the fire under Microsoft’s feet to get on that one.

    Keep an eye out in your webapps. They’ll be moving over to this sooner than you think.

  • Why You Shouldn’t Use Plugins

    Why You Shouldn’t Use Plugins

    These are words I never like hearing: “I want to change WordPress functionality, without a plugin.”

    At first, when I started using WordPress, I would say that myself sometimes. WordPress should have everything! Why do I have to use a plugin to use footnotes? Why do I need a plugin for fighting spam!? Why can’t I have everything I want and need all in one!

    Flash forward many years and my answer is “Because the world’s largest Swiss Army Knife is unusable.”

    85 options and when I look at it, I can’t fathom how I’d use it to do the things I need a Swiss Army Knife for. I do own one (two actually) and they’re both the perfect, simple, classic models. Heck, the one I pulled a picture of here has more gizmos! Mine has two knife blades, two screwdrivers, a toothpick and tweezers. That’s it. No extra bells and whistles, and I don’t need them. That little tool is 100% what I need for the moments I need a Swiss Army Knife, and has gotten me into locked buildings, fixed a car, pulled a thorn from my dog’s paw, and a hundred other little things.

    So when I hear people say “I want to do XYZ without a plugin…” I can’t help but think they’re looking at the whole process wrong, and I ask them “Why?” People have some pretty amazing excuses for why they can’t use a plugin, but I stick with my beliefs that no tool is all-in-one, and the more I hard code customizations, the harder it will be for me to upgrade them later.


    A plugin isn’t ‘core’ so it’s less reliable.

    People have this odd idea that ‘core’ makes something better. It’s actually not true. A good part of the design in WordPress was done so people could hook and action into it, making changes and tweaking things. So if you trust that core is ‘reliable’ then you trust those hooks are as well. And if you’re trusting the hook, you’re trusting the plugin. I think what the real fear is, is this:

    A plugin author might vanish.

    There are a lot of WordPress devs who vanish. Some even work on core. But yes, a plugin author could take a walk and you’d never see them again. This is ‘dangerous’ if you think of WordPress plugins like you think of, say, software vendors. You shouldn’t. Let’s look at HP’s tablets. No one has any idea what’s going to happen with them, if there will be more software, hardware or any support at all in the future. But HP is a proven, reliable company! And what about the Zune? Every vendor makes mistakes with products, and a freelance plugin dev is no better or worse than a major company at the end of the day. A real company might close it’s doors without warning, too! Maybe what people are saying is this:

    There’s no one to sue.

    Why this is a sticking point… The non corporate version of this is actually “For my protection!” But much like the point above, having someone to sue isn’t a magic solution. It’s not a promise that your vendor won’t wander off into Chapter 11, and leave you hanging. Go ask around, everyone’s had that problem with a pay-for program, and worse, one that left you with no one to sue. People are too sue-happy in my opinion, but I can’t fight that one. I do ask why they think they’d need to sue, and I get told this:

    A plugin is less secure.

    I’d like to know when the last time was you did a security audit on WordPress. Look, I’m not saying plugins don’t have the potential to be insecure, but if you’re performing your own due-diligence, and security is your bugaboo, then you should be testing WordPress core, your theme and all plugins with equal scrutiny! We perform audits on all vended software. Every year we have ‘hack it day!’ where we actively try to break into our products (in a non-live environment) to verify it’s as secure as we can make it.

    So if you have a plugin you really want, you should be reviewing the source code. And that’s where open-source code takes the prize. I can open up a plugin, and if I see base64(), or get() calls to things I don’t recognize, I know the plugin’s possibly insecure. I may even email plugins@wordpress.org and let them know about the bad behavior (base64() isn’t allowed at all). But none of that gives me a feeling, like so many other people, of this:

    A plugin is less reliable.

    Than… what? Seriously, I’ve heard this a hundred times. You’re saying “Someone else’s code isn’t as reliable!” but I’ve never had anyone explain how the code total strangers wrote in core is more or less reliable than the code in a plugin. And what about the plugins written by core devs? Are they incapable of problems? Tell that to the bugs that slipped into Jetpack. Nothing is perfect.

    Now, there are checks and balances on core that don’t exist on a plugin. Core changes are tested by hundreds of people (you’re testing it right now, visiting this site, which runs on the latest bleeding edge).  With all those testers, it’s still possible for major bugs to slip through (like json conflicts, sorry, Nacin). Which is probably why people say things like this:

    If I edit my site myself, the code will be there forever.

    Don't Edit CoreThat one amuses me a lot, actually. A friend of mine blogged about this recently and pointed out that life ‘without a plugin’ is dangerous. If you edit your site yourself, you have two places to do this.

    1. You edit core
    2. You edit your functions.php

    If you edit core, after you’ve killed a kitten, you’ve locked yourself into manually updating WordPress forever and ever. You can’t use the auto-upgrade, you have to read and re-read every code change to make sure it’s not on your file, and you have to pray nothing else was changed to make your hack invalid. How is that different from a plugin? Even a deprecated function used in a plugin will still work.

    As for your functions.php … maybe you don’t know this, but the difference between a functions.php change and a plugin is where you put it. Put it in functions.php and now you’re locked into that theme. Which is actually a problem I have with Custom Post-Types right now. If I want to switch themes, there are things I have to remember to bring with me. Hassle. There are plugins, thankfully, that can cover that for me, and I’m glad for them.


    Just use the damn plugin!

    Well okay, then. Are there reasons when a plugin’s a bad idea? Sure! Brian nailed it in one:

    If the plugin is making it snow on your site, I’d consider it unneeded. But I don’t advocate the use of fewer plugins just to use fewer. I do it because I think everything should have a purpose. If there’s no good reason to use a plugin, don’t use it. If it’s redundant, don’t use it.

    What else? Oh, Joey says:

    And that’s another excellent reason. If you want to learn to code, you don’t use a plugin. Or if you’re like me, you ‘fix’ it.


    Excuses, excuses

    What are the best ‘worst’ reasons you’ve heard for why a plugin shouldn’t be used? Here’s what my tweeple said (and my slightly sarcastic replies):

    Clearly they’re unclear on the concept. Functions are great for small, quick changes, but they’re tied to your theme! A plugin is forever.

    https://twitter.com/#!/TJList/status/153654497380540416

    So will adding the code manually.

    https://twitter.com/#!/sabreuse/status/153664752810336256

    I couldn’t even dignify that with an answer.

    http://twitter.com/sabreuse/status/153664914278453248

    If everything was ‘in core’ it would be 600megs and no one would use it.

    Let’s hear your best ones!

  • Speaking of Redesign Thoughts…

    Speaking of Redesign Thoughts…

    I caught this one on Twitter (and promptly forgot to blog about it in the 3.3 support craze).

    Thibaut Ninove, a Web & UI designer from Belgium, talks about pixels, web, design, standards and other topics on his blog, Dots & Thoughts.  He’s got a good one I know I’ve groused about before.  Why not put the ‘add media’ icon on the post edit bar?

    It’s there if you go into the fullscreen view after all:

    Add Media, full screen, GUI

    Add Media, full screen, HTML

    So clearly the hard work with the graphic is already done, and this would just be a case of moving it down a bit. The only reason I can think of to leave it one-out is that, pre 3.3, there were multiple buttons depending on the type of media, and that would have been kludgy. Now that the uploader is ‘fixed’ (it’s my favorite thing about 3.3), maybe 3.4 should move that in?

    Credit: My 2 cents about the WordPress 3.3 post editor | Dots & Thoughts.