Crimes Against WordPress: How to Be a Real Jerk if You Make WordPress Themes and Plugins

Want to develop a sense of deep contempt for your fellow web developers and designers? Then try managing a multi-site WordPress install that uses SSL.

Some would have you believe that the WordPress ecosystem is a veritable Shangri-La of themes and plugins. I want to destroy this illusion: it’s not. If you’ve had to manage a WordPress site or two, you’ll know what I mean when I say WordPress themes and plugins can be a labyrinth of compatibility problems and a morass of bad programming practices;  full of empty promises. This article is my small contribution to making the world a better place; making my life have meaning; and assuaging the pain.

This is a list of crimes against WordPress. I found all of these questionable practices in themes and plugins that made my life a living hell.

Including Your Own Out-of-date Version of jQuery

I discovered this in a theme:

$my_jquery = get_bloginfo('template_url'). "/js/jquery.old.version.js";
wp_deregister_script( 'jquery' );
wp_register_script( 'jquery', $my_jquery, false, '' );
wp_enqueue_script('jquery');

WordPress comes with jQuery included; please make sure your plugin or theme is compatible with the jQuery version WordPress includes. Never include jQuery with your plugin or theme. What do you think happens when your version of jQuery is a step or two behind the version included by WordPress, hmmm?

Adding code like that above feels like you’re invading my personal space. If your JavaScript code requires jQuery then simply do this:

wp_enqueue_script('jquery');

Uneditable Template Text

Ever known someone who finishes all your sentences for you? Themes and plugins that output page text that you can’t change feel the same way.

Here’s an example:  if you’re a theme maker and you want to show a page submenu in the side column, avoid hard-coding it into your template; make it a widget. Allow the site owner to position it and add a custom title. The site owner may dislike the title “Sub Navigation” and prefer “In This Section.” Why do you assume you have the right to make all the decisions?

At least provide an options panel.

IE=EmulateIE7

This is just plain cruel; you may as well start throwing rusty nails into my eyes, because that’d be more fun than tracking down the cause of the CSS bugs that arise because of this:

<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7">

I found that in a theme I actually paid for. If you’re a theme maker and you’re unable to make your CSS work in IE unless it emulates IE7, you need to go back to the drawing board. Seriously bad form.

Adding Superfluous Theme Features

A WordPress theme is all about presentation. Providing features like Google Analytics support is unnecessary and just adds to the clutter of your theme options page, like a colleague who never shuts up.

If I want to use Analytics, I can get a plugin for that. Besides, what if I want to use a site stats service other than Google Analytics?

Not Cleaning Up After Yourself

If the site owner wants to remove your plugin or theme, don’t begrudge them the option to do so; it’s their site, after all. Leaving all your data lying around is like being a bad tenant who trashes the joint when they leave.

Plugin authors, make sure sure you add actions for the deactivation of your plugin. For example:

register_deactivation_hook(__FILE__,'my_plugin_deactivation');
function my_plugin_deactivation()
{
  //get rid of stored data here
}

It’s simple to add and you can read all about it on the WordPress Codex.

There’s currently no official method for themes to assign actions to a deregistration event,  but here’s an approach that looks promising.

Neglecting to Make a Call to wp_footer in Your Theme

If you’re not going to add a call to wp_footer in your theme you may as well steal my shoes. This is the most basic no-no—so many plugins depend upon this happening—and yet you still find themes, even commercial ones, that fail to call wp_footer.

You need to place <?php wp_footer(); ?> just before the closing </body> tag.

There are no arguments here. Just do it.

Performing Initialization inside wp_head

Comparable to turning up late to your best friend’s wedding, I’ve noticed theme and plugin makers sometimes initialize important global variables or constants inside a function that is bound to wp_head. For example:

function my_init() {
define('REALLY_IMPORTANT_CONSTANT', 'really_important_value');
}
add_action('wp_head', 'my_init');

Simply put, the wp_head action should only be used to output tags into the HTML head. If you ignore this rule you’re binding code logic with HTML output, and that’s generally bad.

Promising Custom Menus without Using WordPress Custom Menus

Would you promise to bring a van to help your friend move house and then turn up on a motorbike? So why would you promise the feature of custom menus, but not use the WordPress custom menu feature? I recently paid for a theme that provided a field into which the site owner is supposed to enter a comma separated list of page IDs:

Enter the query string of the pages you want to display in the main menu (top left corner of the page). Example: include=9,10,20,21,32 (this would display 5 menu items for the pages with the id 9,10,20,21,32).

If you offer custom menus in your theme, define menu positions and allow the site owner to use the WordPress custom menu maker; available in WordPress 3.0. it’s flexible and easy to use for the site owner; and the code to add custom menu slots to your theme is so simple. The Codex has all the code you need.

Thumbnails without Using Post Thumbnails

Here’s a great way to sentence the site owner to a life of hard labor. WordPress has had the post thumbnail feature since version 2.9, but you still find themes and plugins that force site-owners to manually paste image URLs into custom post fields.

Instead create a few custom image sizes an then use the Post thumbnail feature. It turns hard labor into a set-and-forget option:

add_theme_support( 'post-thumbnails');
if ( function_exists( 'add_image_size' ) ) {
  add_image_size( 'frontpage-news-thumb', 75, 45, true );
  add_image_size( 'frontpage-news-large', 570, 300, true );
  add_image_size( 'portfolio-page-thumb', 44, 30, true );
}

With the above code, whenever an editor uploads an image, the additional sizes will be generated automatically. All the editor then needs to do is select the image as the feature image for the post.

In your theme or plugin you can output the appropriate image tag with the the_post_thumbnail function:

<?php the_post_thumbnail( 'frontpage-news-thumb' ); ?>

Read all about it on the Codex. Please.

Inserting Custom Post Boxes without Using add_meta_box

The add_meta_box function has been available since WordPress 2.5, but I still see the following:

add_action('edit_page_form', custom_write_panel);
function custom_write_panel() {
  //echo lots of form HTML
}

The example custom_write_panel function above echos form HTML into the post edit form. This is equivalent to throwing up into the urn your best friend keeps her mother’s ashes in.

The add_meta_box function adds your custom write panel to the global $wp_meta_boxes array. Once there it can be accessed, overridden—generally managed by other code or a plugin. It’s the polite way to do it.

Read the function’s reference on the Codex for details and links to easy tutorials

Failing to Support HTTPS

If you run a WordPress site under HTTPS, constant browser mixed content security warnings are almost inevitable, requiring you to modify the plugins and themes manually. This is because many theme and plugin authors hard-code ‘http’ when they include page resources like JavaScript files and Images. It feels like being conned into buying a brand new suit and realizing only the front half of the mannequin was covered. And now your butt’s hanging out in the breeze while you deliver your big speech to the shareholders.

Since version 2.6 WordPress has had the is_ssl function:

$scheme = ( is_ssl() ? 'https' : 'http' );

Just use it before someone gets hurt.

Hardcoding aside, there are times where you can’t really blame plugin and theme creators. After all many of them have simple copied code from WordPress itself. In WordPress 3.0.4, default-constants.php, line 77, we find:

if ( !defined('WP_CONTENT_URL') )
define( 'WP_CONTENT_URL', get_option('siteurl') . '/wp-content');

Using get_option('siteurl') simply retrieves the value from the database without any SSL check. A better way is to use the site_url / get_site_url functions as these perform the appropriate check.

Alternatively you can do what I did and patch this yourself:

function fix_ssl_siteurl($url) {
  if ( 0 === strpos($url, 'http') && is_ssl() )
    $url = str_replace( 'http://', 'https://', $url );
  return $url;
}

add_filter('option_siteurl', 'fix_ssl_siteurl');
add_filter('option_home', 'fix_ssl_siteurl');
add_filter('option_url', 'fix_ssl_siteurl');
add_filter('option_wpurl', 'fix_ssl_siteurl');
add_filter('option_stylesheet_url', 'fix_ssl_siteurl');
add_filter('option_template_url', 'fix_ssl_siteurl');

You can place the above code in a plugin, in the functions.php file in a theme or, if you run a multi-site installation,  put it in your mu-plugins folder and be done with it. Of course it’d be better if everyone just supported HTTPS properly.

Not Supporting Multi-site WordPress

If you claim to support WordPress 3.0 and up, then you must support multi-site WordPress installations. If you fail to do this you’re a schmuck. From my point of view the experience is like winning a family trip to Sea World, but finding out that only one of us is allowed to swim with the dolphins.

Enabling multi-site on a  WordPress install changes the file upload path, the URL to admin forms, and the database table names are unique for each blog. Also, plugins can be activated for the whole network. Writing about this topic could fill a whole tutorial itself. But here’s a few pointers:

In a multi-site WordPress installation the content file path depends upon a URL redirection. Often theme or plugin makers will include a supporting library, like an image manipulation library for example. If this is the case with your theme or plugin, make sure your library works with URL redirection. So many of them fail at this.

One plugin I used wrote the options form action like this:

<form method="post" action="<?php echo $_SERVER['PHP_SELF'] . '?page='
. basename(__FILE__); ?>&updated=true">

The problem with this is that with multi-site WordPress, the path to the admin forms is different for each blog and not equal to $_SERVER['PHP_SELF']. Here’s the fix I used for that plugin; it basically changes the action from a root-relative path to just a plain relative one:

<form method="post" action="<?php echo 'options-general.php?page=' .
basename(__FILE__); ?>&updated=true">

If your theme or plugin need custom database tables, then don’t forget in a multi-site installation each site has a unique table name prefix. Mostly this means using the global $wpdb object for database access and the $wpdb->prefix property. It’s all explained in the Codex and in this blog post.

The above blog post also has some useful examples for dealing with network activation and deactivation.

Summing Up and Calming Down

I feel a little better now that I’ve gotten that off my chest. It really comes down to this: do as little damage as you can, use existing WordPress features as much as possible, make everything customizable, and recognize that some sites need SSL or are multi-site installations.

If site owners are forced to make edits to your code just to make it work acceptably, then you’ve failed, and the WordPress ecosystem isn’t working as it should.

Free book: Jump Start HTML5 Basics

Grab a free copy of one our latest ebooks! Packed with hints and tips on HTML5's most powerful new features.

  • Antonio C.

    Very Good work, saved to future reference, and shared in Facebook with all my WP “friends”.

  • JR

    I don’t usually point out typos, but since it’s a specific function name, I will. There is no wp_foot function, it’s wp_footer. However, wp_head is correct.

    (I know comments here are moderated, so feel free to fix it and delete the comment, I honestly don’t mind.)

    • Louis Simoneau

      Thanks JR, I’ve just updated the post.

  • Andrea_R

    minor correction: the function above is wp_footer. You were probably thinking fo wp_head (no, they don’t match ;) )

  • Conrad

    Excellent post. I feel your pain. My last WordPress project involved me upgrading a site from wp2.5! I had to individually activate each plugin and test the site for stability before activating the next one. All 21 of them.

    • Dave

      I just went through pretty much the same experience. The cool thing was that so much more functionality has been built into the WordPress core installation between 2.5.2 and 3.0.4 that I was able to delete about half the plugins.

  • JLeuze

    I run into a lot of issues with my slideshow plugin that stem from sites that are loading three or even four copies of jQuery because of themes and plugins that pack their own copy of jQuery.
    Don’t forget to let developers know when you run into conflicts like this, I’ve gotten in touch with several and they have all been more than happy to update their theme or plugins to play nice with others.
    One thing, you mention calling “wp_foot”, the function is actually wp_footer.

    • Andrew

      That’s a great point JLeuze, and for my part I’ve posted to the wordpress.org plugin forums where I can.

  • chp

    Great Article! I have seen these errors a lot, and I’ve to admit – done some for myself! I’ll go through my themes and troubleshoot them.

  • Tom Hermans

    I love good practices lists like these. There were some I didn’t know about (like the SSL one, don’t use that myself), and will surely check this list next time I build a theme/plugin ..

  • Dave Doolin

    These are good recommendations, and many of them I haven’t seen elsewhere.

    I think I’m being a jerk in a couple of places myself. Not a great, big jerk, but maybe a little one. Would have been nice to have a list like this years ago!

    We’re having a big plugin hackfest locally, in April. That will be a great time for me to comb through my main plugin to reduce the crimes against WordPress.

    Thanks for writing.

    • Andrew

      That’s great Dave. I get the feeling some plugin/theme creators release for older versions of WordPress but fail to keep them up to date. Even when some of them are commercial themes!

  • Rick Anderson

    You could include:
    1. Loading javascript in the head of every page, even when your plugin isn’t in use on that page
    2. Not using enqueue script to add javascript to a page
    3. Not using enqueue style to add style sheets to a page
    4. Adding internal styles to the head of every page (or any page for that matter)
    5. Using inline styles
    6. Using tables without adding a class name to the table tag
    7. Using tables for the layout of elements (rather than for tabular data)

    • Andrew

      Good list, Rick. I too could go on and on…. but I had to pick the worst problems for this article. Probably room for a sequel post though :)

  • Sparky Pop

    I’m SORRY! I was just learning! I bow to you and the other WordPress Gods! I promise to use this article as a reference when starting my next project.

  • mizliz

    wow. Great job calling these out!

  • Eric

    Love the article, very good info for fully understanding what’s going on.

    One thing from my experience, though – WordPress is far and away better at this than Joomla. I’ve been through utter hell with Joomla because plugin creators CHANGE THE JOOMLA BASE CODE when they decide to. Try to upgrade then, and the whole site breaks. I had to spend a whole month doing testing and planning to migrate one site for a client because of all the customizations they decided to do. For me, it’s like dealing with a high school coding project as opposed to a professional one like WordPress. When I see all those comments saying how great joomla is I just want to throw up. Doesn’t mean that your observations above aren’t relevant, but you have to take them with a grain of salt :)

  • Lee Alley

    …or you could ditch WordPress and use Drupal. Multiple menu systems, cross-module SSL support and a properly curated API for years, over several versions.

    It’s not as pretty (it can easily be made to be!) but is so much better engineered.

  • Skattabrain

    This is why I hate themes. Goofy markup, crappy plugins… I’ve used them, every time it’s a nightmare. Even if it’s decently coded… it is still not my code, ya know?

    Not enough time in the day to research a $25 theme for hours just to see if it works. I’m am FAR FAR better off to using these themes as inspiration for my own designs.

    I may be off base, because I’m speaking in a context of buying a theme for non-wordpress sites as I’m done with CMS’s like wordpress. Maybe it’s me, but I get asked to often to do out of the box things.

    I can’t deal with busted themes or plugins after a WordPress update. No Thanks!

  • Bob

    RE: IE=EmulateIE7 meta tag. I can’t speak for WordPress, but I will say that I’ve had at least two instances where this tag fixed IE incompatibilities that I simply couldn’t resolve ANY OTHER WAY despite many hours of troubleshooting. What’s the big deal? Other browsers ignore it, and some cases it’s the only way to get IE to behave. Until MS fixes its rendering engine, I’m not going to feel guilty when I have to use it. BTW, it’s “emulate,” not “emuate.”

    • Andrew

      My problem with that Bob, is IE8 has better support for CSS than IE7; IE8 is behaving correctly more often than IE7 is. If your CSS is only behaving correctly in IE7 that might mean your expecting incorrect behaviour from your CSS.

      • Raynaldo

        Would this work?

      • Raynaldo

        Whoops, no html!

        Could you wrap it in an IF IE6 or lower conditional?

      • Andrew

        Except that the meta tag is only supported by IE8+

  • Ozh

    Some good points. A few things to correct:

    - I don’t see anything wrong with providing your own jquery.js for a plugin interface for instance: sometimes things work with the version you developed with and will break next year with a newer library. The only thing important is that your js doesn’t override the shipped version, and only loads on your plugin interface.

    - There are better alternatives to comply to SSL than yours listed. For instance, get_home_url() doesn’t need any funky filter to detect for is_ssl().

    • Ozh

      Yay for crappy comment formatting.

      • Louis Simoneau

        Sorry about that, don’t know what happened to break formatting. I’ve asked the devs to look into it.

      • Louis Simoneau

        All fixed now :)

    • Andrew

      Hi Ozh, I did mention the site_url / get_site_url functions, but get_home_url could be added to that list. It may not have been clear from the article but my fix is for site owners who don’t want to mess around with plugin/theme code. If you have to use a plugin that uses get_option, then my fix is useful.

  • BrenFM

    Hay thanks for this list! I’d throw myself in the “intermediate” developer box, and some of these were a real surprise. Love your writing style too!

    One that SORTA bugs me is inclusion of script tags in the header. I thought it was fairly common practice these days to put your css in the header and your js in the footer?

    And what’s going on with these comments too? What happened to the email field and the “email me when someone replies” option?

  • Tony B

    As a WordPress beginner I’ve probably made a few of these mistakes. Fair enough. But does that really make me a jerk? Why not post the same list if no-nos in a positive way? Why insult, belittle, and patronise people? You’ve never made a mistake I presume Mr Tetlaw?

    I’ve got my own views on who the jerk is here.

    • Andrew

      In a word: yes. Sometimes it’s hard to hear the truth from the other side. I’m standing up for site owners everywhere! And we’re tired of suffering because of bad code!

      • craiger

        No, Andrew… you are wrong. No need to be a troll with this kind of tone. If you pay for a plugin that is badly coded, then you have every right to call the developer a jerk and/or ask for your money back. If you use a free plug that someone has developed, and offered the community for free, then you get what you pay for. Fortunately, many plugs work very well and contribute a great deal to the WP communitly. Everyone is in their own place in their learning curve. No need for name-calling. Now, I want you to apologize to Tony B. or I’m calling your parents. : )

        • Andrew

          :) Just having a little fun.

          “If you use a free plug that someone has developed, and offered the community for free, then you get what you pay for.”

          Except that you need standards as a community. You can’t take the “beggars can’t be choosers” position or else the community dies. No one wants to be treated like that even if they’re geting stuff for free.

      • Tony B

        I can see your point, and as I’m not coding for other people at the moment perhaps I shouldn’t have taken issue with you.

        From a beginner’s perspective it is often hard to tell right from wrong. There are a lot of sites out there giving WordPress advice, and I guess not all of it is good. Even in the codex it is hard to tell good from bad and old from new.

        So maybe you could have posted not only a helpful list of WordPress no-nos (and this list is helpful), but also advice on some sources to trust and not to trust.

        Thanks.

    • BrenFM

      I wasn’t keen on the term “jerk” either… or the tone of the article. But this is a serious message and the shock value tone is almost necessary. Some of these are VERY serious (or at the very least insanely annoying) issues – and if it takes someone calling me a jerk to wake me up to the error in my ways, then that’s all good by me. Or are you perhaps a subscriber to the new-age PC rubbish philosophy of “let’s praise everybody for the tiniest little shows of good behaviour and never speak a harsh word of them when they slip up”? And hey, if you’re really a beginner you’re hardly the target of this name calling, right?

      • Andrew

        Also, please realise that it’s (mostly) tongue-in-cheek.

      • Tony B

        I didn’t notice myself asking for praise there, so cool your boots.

  • David George, TWOP Chairman

    Really glad of this article. I’m just beginning to teach myself how to design WordPress themes, and, being extremely lazy, I don’t want to waste effort: I’d rather do it right first time.
    Having said this, it’s obvious that designing themes is going to be a lot of work. Sigh. But such is my life.
    Seriously: thanks for this.

  • pd1138

    How about an article about jQuery jerks

  • David Cox (digital raindrops)

    I have a theme in WordPress Extend called Atmosphere 2010, I made a few or even a lot of mistakes, but there were tools that helped and a lot of hard work to get it right.

    The realisation that I had been doing it so wrong for so long, using the source code from other online tutorials, also brings to light the amount of bad examples by “WordPress Guru’s”, that new theme and plugin developers may come across.

    We should mention the Theme Check plugin, the default WordPress data theme developers can get from Extend, and in a local wp-config.php to turn on Debug, these are key in bringing a theme or plugin up to the mark.

    The only other thing I would say is that it is easy as an active WordPress user or developer to forget that the largest percentage of WordPress admin users cannot do more than add a post, so theme options are not always a bad thing cutting down support requests when catering for a mass market.

    David

  • Ash

    While I agree with much of what you say here there are 2 points I take issue with

    1) Themes are all about presentation.

    Not true, Themes are about whatever the developer wants to provide for his target audience ie whatever the audience needs. I often include an Analytics option in my themes and my customers love the fact its there so they don’t have to install plugins.

    In your angst you seem to forget the vast majority of WordPress users are NOT developers. I don’t build themes for developers and neither do most theme builders. We build for people who haven’t a clue how to add a line of code to the site, or how to tell a quality plugin from a bad one.

    2) Support for Multisite.

    This is an option and NOT mandatory, Why should I spend loads of extra time on development and testing when most of my target market will never use it?

    If your looking for Multisite support use a theme that explicitly supports that, but don’t insist the rest of the world build to a standard most will never need.

    I have built and released over a dozen themes. Want to know how often multisite supports has been asked for by my users? 0. Yep 0

    On the other hand, SEO, Analytics supports and a dozen other function (not form) features have been requested.

    Themes are only supposed to support the features they require. For one of my themes I have actually disabled posts! Yes, the entire blog related sections of the backend have been hidden and the theme does not have support for blogging.

    Why? because this theme isn’t designed for that. The theme in question has a very specific purpose and that’s all it does. My customers love the fact that they can install this theme to server this one purpose free of distraction and confusion from a plethora of features they wont need or be using.

    You know what drives me crazy? Themes that try to satisfy every segment of the market, that try to do it all and as a result do everything poorly.

    If your building a theme are plugin don’t try to build for everyone. Build what your audience needs and no more.

    WordPress is used by millions, trying to anticipate what every potential user needs is madness. Think of it like restaurants. Would you want to eat at a restaurant that tried to serve every kind, every nationality of food there was? Would you expect them to do a good job at it?

    Or would you rather eat at a restaurant that specializes in one kind of food, for example Italian or Mexican and does it very well.

    Your theme and plugins do NOT have to be all things to all people.

    • Andrew

      “We build for people who haven’t a clue how to add a line of code to the site, or how to tell a quality plugin from a bad one.” I know it’s probably not what you intended to say but that does read like you’re saying it doesn’t matter because they’ll never know.

      Seriously though, even though they’re not developers these bad practices will affect them and cause problems. For example I know that failing to properly support SSL will cause mixed-content warnings. I’m lucky that I know how to fix it. I can’t imagine the anxiety of being a site owner and not understanding why suddenly your site is displaying mixed content warnings to all your visitors. Site owners that are not developers are even more vulnerable to these problems in my opinion.

    • Andrew

      You’ve got me thinking about this “themes are for presentation” issue, Ash. I’m still a strong believer that themes should be all about presentation and plugins for functionality. I’m wondering if the problem is really that it’s hard to bundle plugins with themes. By that I mean to expect people to install your theme and then plugins separately might prevent them from using your theme.

      So, maybe there should be a way to package plugins with themes … ?

  • Fel

    Excellent post. Any existing WordPress themes you can recommend?

  • mercime

    Ok, I admit, the shock value of “WordPress Jerks” in my inbox got me reading your article :-) The actual title of your article was much more to the point, thank you.
    Curious, why didn’t you name the offending themes/plugins, the ones using deprecated/incorrect/harmful codes?

    • Andrew

      I thought about it mercime, but then reached the conclusion that it wasn’t about naming names, just outing bad practices. Besides there are so many why pick on the unlucky few?

  • Mike

    I have been guilty of the jQuery one. The default WordPress one was served uncompressed and I don’t think was being cached. So it added ~70k of extra weight to every page.
    I tried to use the Google hosted URL for jQuery, which mightn’t be a bad idea for WP to adopt. With so many WP blogs it’d probably increase cache hit rates for the library a lot. I reversed my change when it broke the admin area.
    By the way, under Inserting Custom Post Boxes without Using add_meta_box should the code be this? (second argument as a string)

    add_action('edit_page_form', 'custom_write_panel');

    • Andrew

      Thanks for the correction Mike, my bad.

  • Rob

    EXCELLENT analogies!

  • gul

    Creo que es uno de los articulos mas interesantes de wordpress que he leido ultimamente.

    Para cuando una segunda parte, me has dejado con ganas de mas

    Un saludo y muchas gracias

  • that_tim_fella

    I can’t help but agree with some others on here about the negative vibe coming from the newsletter in my inbox this morning.

    What I usually see from Sitepoint newsletters is a negative balanced with a positive – as all good writing often is. And using the word “jerk” is just wrong.

    I think your beef should be with WordPress rather than the developers who are allowed to work sloppily within the framework provided.

  • Guillaume

    Veeeeery interesting post, instantly bookmarked ! And I promise to follow (some of) these good practices in the future ;)

  • Logic

    To be honest, WordPress itself is “a labyrinth of [omited] problems and a morass of bad programming practices; full of empty promises.” and a lot more horrible programming. I would not recommend WordPress to my worst enemy. It is that bad.

  • Yeopedev

    Nice article.
    Agree with almost everything on it.
    My only doubt is about the jquery.
    Some people sugest to use CDN services like google for example:
    wp_deregister_script(‘jquery’);
    wp_register_script(‘jquery’, (“http://ajax.googleapis.com/ajax/libs/jquery/1.4.4/jquery.min.js”), false, ’1.4.4′);
    wp_enqueue_script(‘jquery’);
    So my question is, what’s the best aproach?

  • Mike Little

    Great list Andrew. And I love the tongue-in-cheek outrage! :-)
    I’ve one other huge deal breaker/annoyance -that-makes-me-scream for plugins. If you move your wp-contents folder, and set the defines in wp-config.php of course, a *lot* of plugins break. Especially of you are multi-site too.

    Though to be fair, at least one crucial part of WP-MU didn’t support that before the 3.0 merge.

    Every single plugin I have tested (and I’m talking more than 20) from one supplier of premium (several hundred $US per year) plugins, has broken because of a moved wp-content on a multi site install!!

    I ended up using 2 or 3 plugins with mods, and ripping the useful code out of a couple more to fold into my custom code.

  • Art-multimedia

    Useful article. However, I do not agree that a plugin should be automatically multisite ready. Especially not if they are commercial plugins.
    You can decide to integrate MU support in your plugin, or make a separate plugin for MU and charge extra for it. I don’t feel a jerk for doing that, I prefer todecide my own business model. ;-)
    After all, a MU installation generally means multiple site owners and my plugins are sold per person.
    That said, it is good that you point this out because some of us might forget about this option.

    • Andrew

      “After all, a MU installation generally means multiple site owners and my plugins are sold per person.”

      Art-multimedia, if you don’t support multisite NONE of the site owners will be able to buy your plugin.

      • Art-mulimedia

        You misunderstand; a multisite owner can buy the multisite version of a plugin, enabling them to set it up on a multisite. Such a version is then sold per 10, 20, 50 or 100 sub domains, or whatever plan you have.

      • Andrew

        Art, but what if only one of the site owners wants to install your plugin? They’ll be locked out of installing it on their single site. When I say be compatible with multi site I really mean be able to function within a multi-site install, even if the plugin is only installed on one site.

  • David Cox (digital raindrops)

    Just a footnote to my comment:
    While using the Theme Check plugin, the default Tweny Ten theme came up with a warning for non printable character, I found the offending text in a comment.

    Themes created with the latest Artisteer offering will fail the theme check, redundent or deprecated code and missing standard functions for background and header.

    Plugins are not tested by WordPress unlike themes, so using debug mode has stopped me even looking at some new offerings, all will function but may not do so with a lter release.

    Plugin and theme authors gain knowledge from other peoples code, so a clean up of the WordPres extend directory to remove themes and plugins that are no longer version supported would help.

    A checking system like the themes for plugins added to extend would also be a help and reduce the amount of bad code, enhancing the WordPress brand.

    David

  • Dekmar

    I really loved this article, shared it, and saved it for future reference. Loved your analogies, too!

  • Becs

    Love this post – my boyfriend and I complain all the time about the poor plugin development and the need for a more controlled reign over the plugins and themes.

    I enjoyed the abuse too!

  • Stella

    Thanks for the article, there were several things there I had never even heard of. I’m just a beginner, having designed one WordPress theme so far and about to start another. I have already noticed issues with bad plugins that fight with each other, don’t work, or produce horrible invalid html that is a nightmare to style.

    I’m sure I have made a lot of mistakes but my client seems happy – I was only designing for one specific site, not trying to sell it to other people. I can see where the poster above is coming from when they point out that themes are often designed for a single person and a single purpose, and as long as they work for that there shouldn’t be too much problem. On the other hand, if they sack me tomorrow but still want to use the theme, good practices make it a lot easier for someone else to understand the theme and make changes.

    I will be bookmarking this etc. Thanks again.

  • deathshadow

    Given that wordpress is in itself a crime against the Internet with it’s including that fat bloated train wreck of trash jQuery, endless “scripting for nothing”, default markup that looks like it was coded in 2001, endless idiocy that people go as far as using massive regex to fix (see the recent article here on SP about that)… even just simple statements like:

    “So why would you promise the feature of custom menus, but not use the WordPress custom menu feature?”

    Are a no-brainer since I wouldnt’ trust wordpress to build a menu any more than I would Yugo to build a quality automobile or people with massive shares in insurance companies to be in charge of health care “reform”.

    • Lightshadow

      Let me guess, you are one of those hardcore green-lettering-on-black-screen type developer who hates WordPres without even knowing it properly? Does it ring a bell with you that millions of people use the system successfully ad that it gets listed n Google within 2 days?
      Wake up to the reality, Dinosaur.

  • Ryan Hellyer

    It would pay to point out that the most important problem with using $_SERVER['php_self'] in a form like that is it creates a major security vulnerability.

  • Web Wise Media

    Excellent post, great advice and will use it in the future.