Half-Elf on Tech

Thoughts From a Professional Lesbian

Year: 2012

  • Speed Up Your Site

    Speed Up Your Site

    FasterThe majority of what I do to speed up my website is on the server level. In 2009 I moved to a VPS, and just last year I switched to a Smart Server. I have access to install APC, to tune MaxClients, and to upgrade my PHP whenever I darn well want to. And I regularly use these tools to fine tune my server so it’s lean, fast, and efficient. 75% of why my domains run this fast under this much stress (I have two fan sites, they get hammered), is that I’ve done all this work, including some of the stuff I did on DDOS prevention.(My CT_LIMIT is set to 75 right now, and that seems to be the perfect balance. The only people hurt are some silly people in Brazil who like to open 100 pictures all at once. I’ve explained why this is bad.)

    However, not all of you have access to the server to make all those cool tweaks and changes to speed up your website. If you’re on shared hosting (and there’s nothing wrong with that), you can’t edit httpd.conf, you can’t always edit php.ini, and you sure can’t upgrade PHP on your own. Don’t worry, there are still things that you can do!

    The first thing you should do is understand that the more complicated your site is, the slower it’s going to be. So if you want a site with all those bells and whistles, you have a lot more work to do than a simple, plain, site. These are the tradeoffs we must accept in all things.(The exception being, perhaps, cookware. I have some awesome Lodge cast-iron pots and pans, and they’re pretty expensive for their simplicity. Then again, they’re made with such amazing skill and precision, they’re not ‘simple’ to make. So YMMV.) Reduce the complications and things run faster. You have to have a balance between ‘everything’ and usability. If your site is sexy as all get out, but slower than a truculent five year-old on a family walk, then you’re doing it wrong. That doesn’t mean you need to have the world’s most boring site, it just means you have to start learning what it is that makes your site slow. When you look at themes and plugins for a site, remember the more you have, the slower things may become, so use them wisely.

    My favorite tools to show why a site is slow are YSlow and PageSpeed. YSlow is a browser add-on you can use with Chrome, Firefox, and every other commonly used browser. Except for IE. Once installed, you simply go to the webpage and run the tool to get a scan of your site. You get ‘graded’ on an A through F scale, with F being the worst, and the grades are computed based on a fairly understandable methodology.(See FAQ: Grading) Page Speed is Google’s version, and I prefer it, but only because I don’t have to install anything to do it, and it gives really good explanations of what’s wrong. There’s also Web Page Test, which is great to find out if your site flails on different browsers, as well as giving you accurate speed breakdowns.

    Here are three of my sites, all installed on this server, scanned by YSlow:

    And here are the same three as SiteSpeed:

    I’m not going to go through every option, most of them are self explanatory (put the CSS at the top and JS at the bottom). Instead, I’ll explain the weirder ones that you can tweak yourself, and some that you can ignore. If you’re using a tool like W3 Total Cache, you actually can configure most of this directly in the tool instead. For what it’s worth, I did ‘fix’ my scores with both sites and I’m now in the 90s from Page Speed and .. Well not so much with YSlow. The two disagree on how much ‘weight’ to give various errors. Page Speed thinks minification is low priority, and doesn’t judge you about a CDN. It also understands that you can’t gzip what you don’t own. If you use YSlow, make note of what you score poorly in, and fix those as best you can.

    Things I Ignore

    When I get complaints of too many HTTP requests, that just means I’m calling ‘too many’ JS scripts and stylesheets. YSlow doesn’t say which ones those are, which isn’t actually helpful to the novice. If you click on ‘Read More’ it just explains why this is bad. The idea here is that you should have one CSS file, but realistically, any dynamically generated site is going to have more that one. Especially when you consider I’m calling some from Google, Facebook and Twitter for my sharing buttons. While this does slow your site down, unless you have 20 stylesheets on your own site (again, I’m not counting the ones on other domains), it’s not that big of an issue. If you minimize what you have, and combine as much as you can, you’re going to be okay.

    I also totally ignore any scores related to my CDN, or rather the fact that I’m not using one. Yes, a CDN will make your site much faster, but I don’t think this is applicable for everyone, and I generally ignore that value.

    Finally I ignore suggestions to use cookie-free domains, but that’s because I’m running WordPress, and it needs cookies.

    Things I Fix in .htaccess

    You can fix most expires headers errors, but only the ones that relate to your site. When I look at a scan for one of my domains, I see that the items my site loads that don’t have Expires headers are a flash module from PayPal, Google’s +1 javascript, a banner, and two gravatars. Those are all items that, yes, can slow my site down, but they’re outside my ability to fix! And in the case of gravatars, I don’t want them to Expire too soon, since they may change. I’m going to, again, ignore this.
    YSlow - Add Expires headers (F)

    Why wasn’t my server listed? It’s because I added Expires headers to my site. Obviously. The easiest way to do this for your site is to put the following in your .htaccess file(If you’re using WordPress, Drupal, or any web app that has it’s own .htaccess rules, remember to put these above the section for them! It’s important.):

    <ifmodule mod_expires.c>
      <filesmatch "\.(jpe?g|gif|png|css|js)$">
           ExpiresActive on
           ExpiresDefault "access plus 1 year"
       </filesmatch>
    </ifmodule>
    

    What this will do is turn on Expires and set to to today plus one year. Now this isn’t actually the best way to do it, as it leaves out a lot of variables, but for most people, it’s good. Keep in mind, the further you set out this expires, the harder it is to change any files! For example, if I upload a PNG with a 1 year expiration, and then upload a new version, no one will see it (unless they flush their browser cache). Don’t set this further than a year, and only set it for things you know aren’t changing often.(You’ll notice WordPress sourcecode has your JS and CSS files saved with ?ver=x.x at the end. This lets you work around the expires, as when you change your CSS, it changes the version, and thus, pushes the changes down to your users.)

    Cache-Control is the half-sibling of Expires, and lets you specify what files should be cached and for how long. The Ask Apache site has some great examples, as this is what I generally use:

    # 480 weeks
    <filesMatch "\.(ico|pdf|flv|jpg|jpeg|png|gif|js|css|swf)$">
    Header set Cache-Control "max-age=290304000, public"
    </filesMatch>
     
    # 2 DAYS
    <filesMatch "\.(xml|txt)$">
    Header set Cache-Control "max-age=172800, public, must-revalidate"
    </filesMatch>
     
    # 2 HOURS
    <filesMatch "\.(html|htm)$">
    Header set Cache-Control "max-age=7200, must-revalidate"
    </filesMatch>
    

    The ‘must-revalidate’ tag is what makes sure your webpages changes actually get picked up quickly. Nothing’s worse than editing a typo, and not having it fixed for your readers!

    Related to that is ETags, which is a bit weird, but this too is something you can tweak. If you disable ETags, everyone has to trust your cache and that gives you a lot of control. It sounds easy, but there’s a reason we should be using ETags for some situations. My sites are using a pretty complex rule that was set by W3TC for me. It sets my Cache Control and ETag, generating the rules I need. If you just want the basics, though, AskApache’s Speed Tips: Turn Off ETags will get you there. For what it’s worth, a small site doesn’t need to worry about this too much.

    If you want to grab my default .htaccess starter, here you go!

    download TXT file

    Things I Fix via CPanel

    You can also speed up your site by enabling gzip. I’d say I left it off on purpose to show you the error, but the fact is I forgot to turn it on when I moved to a new server. If you have cPanel, this is stupid easy. Log in, go to ‘Optomize Website’ and turn it on.

    gzip

    Doing improved a lot of results on my site, though it didn’t want to consider three of my .js files gzipped for some reason, though it did on other domains on the same server when I changed it. I’m not terribly concerned at this point, since I used the HTTP Compression Test (from What’s My IP?) and it says I’m compressed.

    Things I Fix with Elbow Grease (or Plugins)

    Minification. If you view the source of this site, it’s ugly. Everything’s all crammed up without line breaks, and finding anything is a hassle. That’s because I minified my content. If you don’t have a plugin or add-on for your site that can do that for you, you’ll need to do this manually, via Minify CSS and Minify JS. It’s more of a hassle to do that manually, since it’s hard for you to edit later. After-the-fact compression can slow your site a little, but it’s easier to maintain and still faster than non-minified code. Now I use W3TC, which has a minification tool built in, but there are other WordPress plugins that do the same thing.

    The Rest

    There are a lot more tips and tricks to getting your site running faster. I mention W3 Total Cache (W3TC) multiple times because it works great. There’s also WP Super Cache, which I prefer for smaller hosts and shared servers. W3TC is very, very, very complicated, so be warned. WP Super Cache isn’t a ‘lesser’ tool, it’s just different, and I advocate using either one if your site is moderate to large.

    If your site is small, you really can get by with just minifying. There are a lot of minification plugins out there. Images can be reduced in size by compressing them more via Smush.it (there’s a plugin called WP Smushit for WordPress). Many people have also suggested using a Lazy Load plugin, like jQuery Image Lazy Loading, which loads images on demand. I like it, but it slows my site down, and doesn’t work well at all on ones with a lot of dynamic images. I may be using it wrong.

    Anyone can take advantage of a free CDN, Cloudflare has a free plan.(Caveat: I don’t use CDN, nor have I looked at Cloudflare in depth.) They claim to protect you as well as speed things up, and I’ve heard interesting (good) reports on it.

    Many people advocate using plugins to tune your database, but I really don’t like using a plugin for that. You can optimize your database with a cron job instead, or even just do it manually now and again, if you think your site is sluggish. For WordPress I limit my revisions and empty my trash more often with two lines in my wp-config.php:

    define('WP_POST_REVISIONS', 5);
    define('EMPTY_TRASH_DAYS', 5 );
    

    When all else fails and nothing you can do speeds up your site, take a look at your server. If the server itself is really slow, all the time, and I mean you can hardly get your email, ask your host if you can be put on another cluster. A lot of shared hosts are oversold, since not everyone needs all the space and power. It makes sense, but some hosts monitor the status of these servers and move people around if they become bad neighbors, while others wait for you to notice. Opening up a line of communication with your host is always a good thing. Remember, you’re paying these guys! They should be willing to help you out, or you should leave and get a new host.

    At a certain point, you’ll notice that the only ‘fixes’ are to throw more money at it, buying a better host, better themes, better tools, and so on. And that’s simply a fact of life. You can’t live forever on ramen and hot dogs.

  • 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.

  • I Make Plugins CPT

    I Make Plugins CPT

    Mark Jaquith makes plugins. He also makes a plugin about making plugins, called I Make Plugins, which auto-formats your ‘local’ plugin pages, so you don’t have to write anything, and just pull in the WordPress repository readme for your plugin. It’s almost like the Victor/Victoria of plugins. Anyway, my issue was I don’t use pages for my plugin listing, I use CPTs. And in order to use Mark’s plugin, I had to hack it.

    How-to-install-Wordpress-Plugins

    So I did the smart thing, and emailed him with an “I love your plugin! Here’s what I had to change to make it work with a CPT, though.” A couple days later, Mark replied with “Use these filters instead. Untested!” He also bailed me out when I screwed it up, so he gets an Internet today.

    Even though I’ve never actually messed with filters in this way (actions yes, filters I’m still learning), I sat down with my coffee and started reading. Yes, I actually read things before I jump in, contrary to what my friends think.

    This turned out to be pretty simple, when you got around to it. Since Mark called apply_filters(NAME,PARAMS), all I had to do was add_filter(NAME,MYFUNCTION) and then make a function, passing the PARAMS and parsing as I needed. Mark fixed my original code (which was hellishly not optimized) and fixed my weird preview issue by returning an option I forgot.

    Post Type
    First I had to set the post type. In this case, Mark defaults to pages, I default to plugins. Yes, I named a post type ‘plugins.’ It works.

    add_filter( 'i-make-plugins__post_type', 'halfelf_imp_posttype' );
    function halfelf_imp_posttype() {
    	return 'plugins';
    }
    

    This takes in the arguments as $args, resets it to plugins, and returns the new value.

    Get Plugins
    Mark also has a ‘post parent’ so where I just use the CPT’s archive page for https://halfelf.org/plugins, he has an actual page with sub-pages. I don’t need post parent, so per Mark’s suggestion, I need to remove it from ‘get plugins.’

    add_filter( 'i-make-plugins__get_plugins', 'halfelf_imp_getplugins' );
    function halfelf_imp_getplugins( $options ) {
    	unset( $options['post_parent'] );
    	return $options;
    }
    
    

    Since the parameters I’m pulling in are an array, I have to use unset instead of making it a null value.

    Is Plugin
    The last check is to verify this is a plugin, and we can return the content. The normal string for this checks if the parent of the page is the ‘page parent’ (set earlier normally, unset by me). I just swapped it for a ‘is this a plugin?’ There are two parameters in this one, and the second is the post ID, which I need to check post type.

    add_filter ('i-make-plugins__is_plugin', 'halfelf_imp_isplugin', 10, 2);
    function halfelf_imp_isplugin( $is_plugin, $post ) {
    	$post = get_post( $post );
    	return $post->post_type === 'plugins';
    }
    

    Originally I had a call to is_preview() because, for some reason, it was overwriting all my post previews. While that only annoys me, it really annoys me! Thankfully once Mark fixed my ‘Get Plugins’ call, it all started working.

  • Lesson #1373 – Learning

    Lesson #1373 – Learning

    All the help I give on all the forums and various places works using this maze. I can tell you, but then you won’t learn anything.

    Lesson #1373 - Learning (Surviving The World)

    There’s more than one path to knowledge; it’s not always the same knowledge once you get there, either. But if you think it was easy to get there, you’re not at the destination you think you’re at.

    Credit: Surviving the World

  • Making a Stand Alone SQL Account

    Making a Stand Alone SQL Account

    One of the ways to secure your web apps is to limit the damage they can cause. When you create a database for a webapp, you have to provide a user ID and password to connect to the database, logically enough. Illogically, most people just use the same username and password they use to SSH into their server. After all, it works.

    The obvious problem with this is that if someone gets access to your files (via a security hole in your webapp or your webhost), they now know your server password and ID, and can get in and cause serious damage.

    But what if instead of using that normal ID and password, you made a special one that only was used for SQL. You couldn’t log in with it, you couldn’t FTP or anything except play with SQL. Then, even if they got in, they couldn’t delete your files! That’s really simple.

    cPanel

    If you’re using cPanel, just go in to the MySQL Databases screen and add a new user. I like to use something totally obvious, so I can remember it, like ipstenu_sql.

    MySQL - Add New User

    For those passwords, I tend to use the generator to make something like m}+akwQN=&)!, not because I feel they’re more secure (I prefer pass-phrases, like ‘donkeyvanillatapdance’), but as a reminder for me not to use it for anything but SQL. Hang on to the password right now, though, you’ll want it in a minute.

    Then you add the user to the databases. Back on the main MySQL page, there’s a little selection to Add User to Database which is really obvious to use. Pick your user and your database.

    Clicking Add will take you to the privileges screen:

    Manage User Privileges

    Give the user ALL privileges, as you may need this later on.

    Plesk

    It’s just as easy in Plesk. Once your new database was created you, were automatically brought to the area to create the New Database User. If you didn’t do that, it’s okay, just go back the main database page and find the datase you want to add the user to (in this case, it’s LovePlesk_NewDatabase).  Click on the Add New Database User icon, fill in the information (remember to save your password!), and click okay.

    Plesk should automatically grant the user ALL privileges.

    Updating Your WebApp

    Once you have the new user made, all you have to do is edit your config file (i.e. wp-config.php for WordPress) to use the user and password, and hit save.

    Now you’ve made your install a little more secure.

  • You Don’t Need Any Plugins

    You Don’t Need Any Plugins

    I Want to BelieveLorelle said it right when she said there were no plugins she couldn’t live without (except Akismet), and you could even do without Akismet if you turn off comments. She hit the nail right on the head as to why I step out of any ‘What plugin/theme should I use?’ discussions, except when someone asks a specific ‘What plugin should I use to do this…’ version there of.

    Out of the box, WordPress has all the major tools you need to start publishing. Turn on Akismet and you are good to go. What happens next is up to the needs and goals of your site.

    Out of the box, WordPress needs nothing. It works just fine as is, and you don’t need to do a blessed thing to it. But you want to. And that’s where it all gets messy.

    Needs and wants are different things, and few of us need everything we have installed on our sites. I have 27 plugins currently installed on my network. Of those, three are ‘mu-plugins’ that aren’t so much plugins but sitewide functions, nine are network activated, and one is Hello Dolly. I average about 10 of the others per site, and I know that at least Hello Dolly is actually not used at all. Some sites are the only one to use a certain plugin (like the ‘Downloads’ plugin I use here), and others aren’t network activated but are used on many sites (like WordPress SEO and W3TC).

    Even here on my network, I have different tools for different sites. Heck, one site has only one additional plugin activated on it!

    What Do You Want?So when you look at all that, you may wonder if there’s a plugin I can’t live without. The answer is a flat out no, but you’re not asking the right question.

    What you need to ask is What features are required for my site?

    When someone tells me they want help with their site and what plugins should they use, I tell them “You need to make a list of what features you need. Not want. Need.” There’s a huge difference between the stuff you want, to make your site look cool and neat, and the ones you require for the desired functionality. What a website needs is a way to display content in an easily absorbed way.

    People forget the purpose of a website is for people to find your stuff, read it, and help spread the word. Now, if your ‘word’ is videos, then yes, you totally should consider a video plugin. But that’s a need, not a want. A ‘want’ for a video site is a fancy slideshow of New Videos. Look at YouTube, though. They don’t do that. YouTube knows they’re going to get a lot of traffic, so they pull things back to their purpose. They want to show videos, that’s all they do. Obviously they added in a couple wants, which are the ability to comment, vote, favorite etc. Those are pretty minor when you get around to it, in so far as they don’t affect site speed as much as the actual videos do.

    For most blogs, you really don’t need plugins. If you pull your site back to the things you must have, you get a better understanding of what your site is. Once you look at your site ‘naked,’ with no plugins at all, you can start to add plugins back in.

    Each and every plugin I add has to serve a purpose. Even my RickRoll plugin has a purpose (though its not something that would be on every site I make). The point of a plugin is not ‘Oh look, this is cool!’ but ‘How can it serve me best?’ If I can’t come up with a reason this makes my site better, and I am brutal with myself, I don’t use it.

    Queen: I Want It AllIf you’re going to have a website, it’s incumbent on you that you’re mean to yourself. You hear the horror stories of clients who want all sorts of crazy things on their sites, and there’s a reason a lot of us sit and laugh (and cry) when we read the Oatmeal’s How a Web Design Goes Straight to Hell. I push developers to fight back against the crazy, but you clients need to step up and understand that ‘more’ isn’t ‘better,’ and if you’re hiring someone to make a site, you really should listen to their suggestions and recommendations.

    But the point in the end is that, to make a website, with WordPress, you need no plugins. What you want is another matter.