Half-Elf on Tech

Thoughts From a Professional Lesbian

Author: Ipstenu (Mika Epstein)

  • Internet Anonymity and Impersonation

    If you’ve visited this URL, I know who you are. I know your browser, your IP, your OS, your screen size, how you got here, who your ISP is, what country you’re in, and really, that’s a lot of stuff. It doesn’t matter if you post on this site or not, I have a way to log who you are.

    Did that scare you? Well, it should and it shouldn’t. Every website on the net has this ability, and some are more honest about what they do with that information and some are not. I use it to optimize content for my visitors, and to block my current bevy of South African residents who are harassing me.

    Five years ago, I wrote an essay for my office about how people on the internet know who you are. The intent was to raise awareness in my co-workers as to how people knew who they were, and what actions made them obvious to site-runners that they were who they were.

    Someone asked me once if it was possible to be anonymous on the net, and I told him, seriously, “Sure, don’t log in.” Expecting to be able to be truly, 100%, anonymous is like expecting to be able to come to someone’s house and never tell them your name or show them what you look like. They’d kick you out, have you arrested, or worse. A website is a house, and the same basic rules apply. You’re a guest.

    If you run your own website, be it a small, weird blog about everything, a tech blog, or a fansite, you have people who come by and will eventually be a dick. This is just a constant in life. But that means you have to keep an eye on your site, upgrade it to keep out the ones who want to hack, and find ways to keep out the ones who just want to be trolls. I’ve written a couple plugins (Ban Hammer and Impostercide) to help me with that, but at the end of the day, no plugin can be as smart as your own brain.

    Recently, in the Impostercide comments, someone asked me if Impostercide could stop anonymous users from impersonating each other. And the answer is no, no it cannot. See, Impostercide (and any similar plugin) needs to check against a list, and really, all you have is the list of members. So if someone anonymous tries to use a members email or login handle or URL, well that’s easy to catch! Sure, some people might have the same URL, but that’s pretty unlikely unless they’re running a business together… Like Ron and Andrea. I may want to rethink that part, now…

    Anyway, the point is you have to have something to check against. Anonymous users aren’t registered, so the only ‘check’ you have is IP address. In theory, you could jigger the check to say ‘If the user ID/email has commented before, check to make sure the IP is the same, and if not, flag it as bad!’ Except that wouldn’t work, since, for example, I login with multiple IPs. The world is just too mobile for that to work in any decent automated fashion. Instead, you need to use your brain.

    As a site runner, when I see a questionable comment, I make a note of the IP address first and then the email. If it’s a specialized domain (like ipstenu.org, something personal), I go to the site and check it out. If the site looks legit, I match the IP. Does it come from the same general region as the website? Does it come from the same general region as where the website says the person lives? If it’s someone I’ve seen around my sites before, does it sound like their other posts? Does the language match their website? Do they post on forums I frequent and sound like they normally do? You’d be surprised how easy it is to notice when someone doesn’t sound right. There will be an odd turn of phrase or a strange typo.

    I’ll give you a true example.

    I have a sort of twitter stalker/idiot, who pretends to be a famous person, and kisses up to me and asks I verify her celeb account as legit (this is because I run a fansite for said famous person, and I met her once). Recently she posted on my fansite blog. Her comment immediately was flagged by my moderation filter, because it was a new post from a new email address. I do this for all new comments on all sites I run. And even then, if I approve a post I’m not sure about, I manually put it in the moderation list for a while.

    What my idiot, apparently, did not know, was that when you post to a blog, it records your IP address. I looked up the IP, since someone who’s purportedly a celebrity should come from, oh, perhaps the general Los Angeles area. Or maybe her agency. But no. It’s from South Africa. South Africa happens to be where another twitter account, one that regularly harassed and insulted me, was located. In fact, if I went to that account’s twitter page, right there under location it says ‘South Africa.’

    Armed with that information, I opened up the fake celeb and the troll twitter pages, side by side, and matched time-stamps of tweets. Oh look. All tweets are roughly around the same timeframe (hours that are pre and post school for South Africa, but weird for someone in the USA).

    The lessons to take from this are simple. First is ‘Never piss off the sysadmin’ but only slightly less well known is this: If you’re going to pretend to be someone else, you need to be really good at hacking the internet, in order to hide who you actually are. And if you think someone’s being impersonated, well, it’s pretty easy to double check and follow up. If someone contacts you and says ‘Hey, that’s not me!’ follow up right away and assume they’re them. Kill both comments and email asking ‘which one’s you?’ But err on the side of caution.

    If you’re a commenter, use your brain. Never assume the person running the site doesn’t look at your data and make some snappy deductions from it.

    For a site runner, remember there is no better weapon to fight impersonators on the internet than to use your brain and think things through logically.

  • What is Cloud Hosting?

    This came up because I’m considering moving to cloud hosting. I don’t have to, yet, and since it’d cost me an extra $25 to $30 a month, I’m not planning on it just yet. (Actually, it would be pretty much WHAT I pay now, if I drop cPanel, which is an extra. But for the extra $20 I get ‘cPanel + Fantastico as well complete support of base operating system and all cPanel services. Proactive service restoration is provided.’ I don’t care about Fantastico (and tend to uninstall it), but the base OS support is useful and cPanel just makes life easier for me. Yes, I’m lazy.) But wrapping my head around the ideas behind cloud computing was a weird trip.

    A few years ago, I had a job as a Citrix tech, which meant my job was to take software normally installed on your PC, install it on a server, and somehow trick the PC into thinking ‘When I run Word, it’s actually running on this distant server, and not my desktop, but everything pretends it’s on the desktop.’ This was called a thin-client deployment, because the client (i.e. the PC), only has to have a very little bit of processing power to run things like Adobe Photoshop. By the way, fat-client means ‘everything runs on your desktop.’

    For the really old hands at this, you’ll remember when all PCs were just dumb terminals that connected to the mainframes, and you ran everything off the mainframe. Guess what? Thin-client stuff is kind of the same thing. The programs you run via thin-client basically only exist when you run them. The rest of the time, they’re not available on your PC. This is good and bad. It’s good, because a company can save millions by pushing out low-end, weefy desktops to everyone. It’s bad, because they then have to turn around and spend the millions on the servers and the network. If the server or network goes down, no one gets to work.

    What does that have to do with cloud computing? Cloud computing takes the thin-client idea of ‘on demand’ usage to a new level. Right now, ipstenu.org lives on a server (a VPS to be specific) with four other domains. I pay a flat fee for the server space, a specified amount of bandwidth, a limit of CPU, and some IP addresses. With cloud computing, I would pay a flat rate for hosting, but if I need more CPU, I can easily get more by clicking a button. And when I don’t need more? It goes away.

    Suddenly my server is able to adapt! It scales up and down on an as-need basis. Think of it like your heating bill. In the summer, when you don’t need it, the cost per month goes down. In the winter, it goes up. And unlike the gas company, you don’t pay more during winter because it’s a set, year-round rate. Woo! Or, as the video I’ve linked to below would say, it’s like a Tax. The meter keeps running at stoplights, but it runs slower, so you pay less.

    Now I will say the math for all how much all this costs, sorting out what you need, is a bit heinous. I ended up chatting with my webhost about what I would need, based on my current usage. They have their own traditional webhosting setup as well as a cloud service, and since I adore them to no end, I decided it would be smartest to just ask them about it. Yes, it would be a hassle to move everything, and likely my subversion stuff would break and need to be re-installed, but it’s definitely a better bang for my buck than to use something like a dedicated server.

    There are downsides to all this. The biggest one is security, which panics a lot of people. On cloud computing, you’re back to the same sort of place you were for shared hosting. When you need more CPU, you get another ‘slice’ of the cloud (it’s a mixed metaphor, sorry). The slices still need servers to run on, obviously, and each webhost has the option of slapping together a bunch of servers quickly and poorly, or doing it the right way. And, sadly, a lot of webhosts are leaping into the cloud without looking, shoving servers together, and not thinking about security. To those people who worry, I remind them that cloud or not, your server’s security has always been about your webhost.

    In August of 2010, it was determined that Network Solutions (a big webhost) had over 500,000 compromised websites. Reported on by Armorize Blog, they proved that any time you made a parked domain, Network Solutions put a widget on your site that served up malware and could infect PCs. This was a default widget, something that showed up if you didn’t check any boxes, on newly registered domains.

    From the horses’ mouth, Network Solutions spokeswoman Susan Wade provided this statement when asked for comment: “Regarding the widget incident from the weekend, our security team was alerted this past weekend to a malicious code that was added to a widget housed on our small business blog, growsmartbusiness.com. This widget was used to provide small business tips on Network Solutions’ under construction pages. We have removed the widget from those pages and continue to check and monitor to ensure security. Reports of the number of pages affected are not accurate. We’re still investigating to determine the number impacted.”

    Basically, Network Solutions own website was hacked and shot a ton of other sites.

    You want to complain about cloud being insecure, go ahead, but remember that your security depends on your host being a good soldier, same as always. WHich is why I recommend LiquidWeb and their Storm On Demand Hosting.

    The other thing people complain about with cloud is they can’t touch their physical server. Personally, I don’t care. The virtualization of data is a big thing, and most people actually never see their server. Mine’s somewhere in Michigan I think. Making backups isn’t easier or harder with a cloud, so you can still have a good backup of your data for emergencies. Everyone should have a backup.

    Should you move to cloud? If you’re on a VPS and starting to get too big for it, then yes. The cost is a good reason but also you’re just going to get more flexibility. If my server needs grow (which is to say, if I start crashing the server again), I’ll be moving to cloud for sure.

    Still confused? Watch this video and it will explain it in a very straightforward, amusing, manner:

  • com or org? Which WordPress is Right for Me?

    There are two WordPresses. This confuses lots of people, to the point that Matt Mullenweg has implied he’ll never name something like this again. It’s almost as confusing as pages vs posts, which is a whole different post.

    WordPress.org – The location of the software you can download and install your own WordPress blog on your own server.

    WordPress.com – The often free blogging software anyone can sign up for and have hosted by WordPress.com. It’s like Blogger or LiveJournal, only better because it’s WordPress.

    So which one is better? .com or .org?

    I usually tell people that I can’t answer that question, or to google it, or I ask them what they want to do. It’s not an easy question to answer, but I’m going to try here.

    First, I want to point out that there is no shame in not wanting to host your own blog. Seriously. It’s work, and anyone who says otherwise is an idiot. You have to stay up on your software versions, plugins, themes, etc etc and … Yeah. Work.

    So here it is, in all it’s glory: If all you want is a blog, and you don’t mind a few basic themes? Use WordPress.com. There. Done. If you’re willing to pay, you can even customize your CSS or download other themes, and have your own domain name.

    A friend asked me recently if she should use wordpress.com or self host. My email is verbatim:

    Don’t worry about where you want to be in 10 years, worry about where you want to be in a year, but only in the broad strokes. It’s like learning to paint or draw. You start with the big, simple, concepts, and learn how to do the rest as you go. If you think ‘I want something like Ning’ or ‘And I want forums’ or a wiki or whatever, well, then don’t use .com. But if all you want is a blog? Just use WordPress.com and you’re done.

    Except, see, it’s really not that simple.

    When people on WordPress.org forums ask this question, I usually tell them to read Don Campbell’s post “WordPress.org vs WordPress.com – Which One Should I Use?” It’s pretty straightforward and helpful. Lately, people have followed up that advice with ‘Okay, great. Why is one better than the other?’ Even people who read the official WordPress.com vs. WordPress.org article by WordPress ask that.

    I firmly believe that better is subjective, and it really depends what kind of blogger you want to be. However there are some obvious benefits to self-hosting.

    WordPress.com limits your free themes. If you want some fancy CSS or your own domain name or more storage, you have to pay for it. At a certain point, you will end up paying the same as you would for a hosting plan, and you’re getting ‘less’, in that you still can’t install your own plugins or third-party apps! No Wiki, no gallery. Nada. On the other hand, you pretty much never have to worry about your upgrade going bananas, or hanging .maintenance files that make you think your site is down, or incompatible PHP/SQL versions. You get the most pain-free upgrade possible.

    That said, if your blog grows and becomes popular, you will outgrown the free hosting. You’ll need to pay more for hosting. You may even have to pony up for VIP hosting if you make it big like Cute Overload. Free only takes you so far, and you get what you pay for. Pay nothing, and there’s a limit to what you’re going to get.

    But wait, you don’t pay a thing for WordPress.org! Does that mean you get nothing? No, it means that there is a limit to what you get. Free support, sure, but from people who fill in on our free time. Yes, our. I waste a lot of time helping people with obvious question, pointing out typos, and earning karma credit by trying to be a good person. There are a lot of people with a sense of entitlement, that this software should do everything without needing to know what’s going on. Listen, you weren’t born knowing how to use Microsoft Word. Some people go a lifetime without touching macros, while other people can’t fathom their life without key commands that resize and reformat sections.

    There is no one true way to nerdvana, folks. There’s no one perfect operating system, no one perfect blog software, no perfect phone. It’s all what you want, what you can use, and where your comfort zone is.

    So why would I pick WordPress.org over WordPress.com? Flexibility, growth and options. I want the ability to grow and do everything that might come down the road. Of this, WordPress, my blog, is a small part. I want SubVersion, videos, galleries, you name it.

    Why would I pick WordPress.com over WordPress.org? I wouldn’t. But I do suggest it to people now and then, when I look at their needs and say ‘You know, this is a great place to start.’ If they outgrow the .com, they can export their posts and comments over to a self-hosted install with a bit of effort. And the work required to do that is pretty typical of the savvy you’re going to need to support yourself going forward.

    Which is better? No one can answer that for you, but hopefuly some of the advice here will get you started in answering it for yourself.

  • Hotlink Protection

    Hotlinking is putting a link to someone else’s webpage’s graphic on your site. This is also called bandwidth theft. Directly linking to a website’s files (images, video, etc.) means that when someone accesses your website, they draw bandwidth from another. If you use an IMG tag to show a picture from someone else’s page on your blog, forum post, or website, that’s hotlinking. You’re stealing their bandwidth.

    There is a case in which this sort of ‘theft’ is ethically permissible, though some webhosts don’t like it. If you have multiple Yahoo! sites, and one is low on bandwidth, you can shuttle some of your content to the other site, and thus split up the bandwidth. This isn’t always a good idea, as if it’s against the Terms of Service on your host, they can kill you. Which is why you should always back up your websites on your on computer. If you own your own domains (like I do) and have multiple ‘subdomains,’ then it’s okay to share an image. ipstenu.org is considered a different website that photos.ipstenu.org, so I have to tell my server it’s okay to share between the two. But that’s code geeky.

    What the common websurfer needs to know is this: direct linking to a picture, movie file, or any other content on someone else’s site, unless it’s a simple URL link to that site, is bad form, ethically asinine, and impolite. It’s akin to stealing electricity from your neighbor by plugging into their outlets.

    But what do you do when someone’s hotlinking to your server? Most of us find out about this via a nastygram from our webhost saying we’re using too much bandwidth. Bandwidth controls how fast you can view the net from your home, as well as how much data a website can share with the world each month. Having more bandwidth is better all the time, but forcing users to use more bandwidth with image heavy sites and poorly coded web pages is not cool. Still, sometimes you have a moderate site and one image becomes super popular.

    This is where you need to learn about hotlink protection. The most basic code is this:

     
# Simple Hotlink Protection

RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://(www\.)?yourdomain.com(/)?.*$                   [NC]
RewriteRule \.(gif|jpe?g?|png)$                             - [F,NC,L]

    This basically says ‘If you’re not from yourdomain.com, and you’re trying to see an image, you’re not me, go away. Sometimes I make that last line something like this:

    RewriteRule \.(gif|jpe?g|png)$ http://mydomain.com/hotlink.gif         [NC,L]

    Which shows them a ‘No, don’t do that’ image. If you’re going to do that, use a SMALL image, since that will use up some of your bandwidth.

    For most people, that works just fine, but I’ve run into a couple situations that were weird.

    Multiple Subdomains

    If you’re using a lot of subdomains (like, say, with WordPress MultiSite) you’ll find pretty quickly that the normal hotlink protection rule will block subdomain.yoursite.com from getting images from www.yoursite.com and we don’t want that! For one subdomain, it’s an easy fix:

     
# Simple Hotlink Protection

RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://(www\.)?yourdomain.com(/)?.*$                   [NC]
RewriteCond %{HTTP_REFERER} !^http://(subdomain\.)?yourdomain.net(/)?.*$               [NC]
RewriteRule \.(gif|jpe?g?|png)$                             - [F,NC,L]

    But what about multiple sites? At 12 subdomains, you don’t want to have to add these links in manually every time! Thankfully, the geniuses at Perishable Press have created the Ultimate htaccess Anti-Hotlinking Strategy. You can read the whole post for the details, but here’s the basic code:

     
# ultimate hotlink protection

 RewriteEngine on
 RewriteCond %{HTTP_REFERER}     !^$
 RewriteCond %{REQUEST_FILENAME} -f
 RewriteCond %{REQUEST_FILENAME} \.(gif|jpe?g?|png)$           [NC]
 RewriteCond %{HTTP_REFERER}     !^https?://([^.]+\.)?domain\. [NC]
 RewriteRule \.(gif|jpe?g?|png)$                             - [F,NC,L]

    Simple. Elegant. Genius. All you have to do is change domain to whatever your domain is. Notice there’s no .com or .net in there? There doesn’t need to be. This is the one I use for this site:

     
# ultimate hotlink protection

 RewriteEngine on
 RewriteCond %{HTTP_REFERER}     !^$
 RewriteCond %{REQUEST_FILENAME} -f
 RewriteCond %{REQUEST_FILENAME} \.(gif|jpe?g?|png)$           [NC]
 RewriteCond %{HTTP_REFERER}     !^https?://([^.]+\.)?ipstenu\. [NC]
 RewriteRule \.(gif|jpe?g?|png)$                             - [F,NC,L]

    That’s it. Just change domain to ipstenu and I’m done.

    Letting Other Sites Use Your Images

    The other major gotcha to this is what about other sites where it’s okay if they link to you? For example, I have a livejournal site (I know) that’s a mirror of another blog. To take care of that, I added in this as my last condition:

     RewriteCond %{HTTP_REFERER}     !^http://ipstenu.livejournal\.   [NC]

    Here I specified the URL a little more, since I don’t want all of livejournal nabbing my images. Of course, ironically enough, the line where I call ipstenu has the funny side effect of allowing any URL with the name ‘ipstenu’ in it to access my site. Which is a risk I accept right now.

    If you’re using my first example, the simple protection, then just like you added in a subdomain, you add in your other URLs

     
RewriteCond %{HTTP_REFERER} !^http://ipstenu\.livejournal\.com(/)?.*$               [NC]

    This will save you some headaches down the road, but just remember which one your using. Otherwise, like me when I made a new subdomain, you’ll sit there wondering why the heck the images are broken!

  • Why doesn’t the WordPress auto-upgrade work?

    This came up recently with the WordPress upgrade to 3.0 (and subsequent 3.0.1 bug fix). A lot of people had problems upgrading from WordPress 2.9.2 to 3.0, and for the most part, the fixes were simple.

    There was a known ‘memory bug’, where WordPress didn’t request enough memory from the server when upgrading and, since 3.0 is a bit bigger than 2.9.2, it failed. This was fixed with the plugin Memory Bump. Once you upgraded to 3.0, you could remove this plugin, because the new WordPress version took care of it on it’s own. There were other issues, though most of them seemed to be plugin conflicts or people using weird versions of PHP. I even had a note I kept handy:

    Memory Issues
    Per naicin

    We’re in the process of pushing out a plugin for this: http://wordpress.org/extend/plugins/memory-bump/

    In the meantime, you can also add this to your wp-config.php file:
    define('WP_MEMORY_LIMIT', '256M' );

    The issue is that WP *may* need more than the default 32 MB to upgrade to 3.0, due to the increased package size over 2.9. This is a “known issue”.

    3.0 handles this by always bumping you to a very high memory limit in the admin area, so you won’t see this once you’ve hit 3.0.

    Weird Errors and blank screens
    Rename your plugins folder to plugins-old (via FTP or SSH) and see if that fixes it. If so, name the folder back to plugins and reactivate your plugins, one at a time, testing between each copy.

    Believe it or not, those two answers were probably 90% of what I posted on the WordPress forums for the better part of a week. That and ‘Yes, these plugins don’t work on 3.0 yet’ (and I had a list for that too!).

    Then came Zarathustra — I mean WordPress 3.0.1 — and people began to have new issues. The most common was something like this:

    Downloading update from http://wordpress.org/wordpress-3.0.1.zip…
    Unpacking the update…
    Verifying the unpacked files…
    Installing the latest version…
    Could not copy file.: [some file]
    Installation Failed

    The file would be different for pretty much everyone.

    As far as I know, we’ve not found a fix yet, however I pointed out that when the auto-upgrade fails, you should try installing the update manually. It’s not that hard. It’s basically copying files to a server and if you can’t do that, I don’t think you should be running your own self-hosted site. This is why I run the techside of a site for someone else. Know your limits, I always say (my limits self-tests haven’t always been non-destructive, by the way).

    In this support post for the failed install, riddle said:

    I’d like to get back to the original poster’s point: 3.0.1 automatic upgrades are too unreliable for the very WP admins who most need one-click upgrades.

    ipstenu’s reply (“This is a problem with your server setup, most likely, not WP. The most likely reason would be that your PHP setup doesn’t like the way WP 3.0.1 is unzipping and copying files.”) misses the point. If there are common PHP configurations under which the automatic upgrade won’t work, then at a minimum the upgrade script should test for them before breaking the site.

    And I replied:

    You just hit the nail on the head as to WHY automagic upgrades fail.

    There aren’t config standards for PHP and server software that are across the board on every server known to man. Each company has their own settings and standards, and even then (as I pointed out to a coworker yesterday), unless you clone a machine onto the exact hardware, you’re still going to have an inexact copy.

    Servers are snowflakes, man. It sucks, but that’s it.

    WordPress is able to say ‘Your server must be able to do these things to RUN WordPress’, but even then, someone may have a wildly weird setup where stuff works poorly. It’s the nature of the beast and it’s impossible to test everything.

    If the automatic upgrade fails, do it manually. It’s not that hard (copying files). Heck, it’s easier than installing manually the first time!

    And really this is the problem with all software, web or otherwise. There’s a reason software has ‘minimum requirements.’ It’s the bare minimum someone tested on and the software worked. WordPress says ‘To run this software, you need PHP 5.2 and MySQL 5.0.15’ (as of of 2011, so get on that now!) and that’s pretty much it. That’s all you need to have WordPress run, but that’s not all you need to do everything you could possibly do with WordPress, and this includes those pretty auto-magical upgrades.

    For what it’s worth, I come at my viewpoint from someone who spent 3 years doing application testing. I had to make sure all the apps used together worked together on every computer. Which is impossible. There’s no way I could promise that every app someone might use will always work on a computer with every other app. To make our goal realistic, we ‘certified’ applications, and would list any known conflicts, as well as everything we knew it worked well with or needed tweaks.

    Knowing that, and knowing that servers are setup with just as much variation as desktops, means that when someone says that WordPress should have standards it works on I think they’re just naive. There’s really no such thing as a ‘standard.’ There’s no standard location for temporary files, there’s no standard location for a home folder, and there sure as hell is no standard setup for installing PHP on a Red Hat box. There are variables galore that could cause all sorts of issues. There are application conflicts, configuration miss-matches, setup issues and, of course, the fact that there are so many different types of ‘standard *nix servers’ that are used, with hundreds of patches and tweaks, that the target’s moving so fast, I think it just hit you in the head.

    So why doesn’t your automated upgrade work when you click the button on WordPress? The possibilities aren’t endless, but they’re pretty thick. You’re better off learning how to do the manual upgrade if you have wild errors no one’s seen before.

    And I hold by my belief that if you can’t perform a manual upgrade, you need to rethink your capabilities of running a website on your own. If you’re running MultiSite and you can’t do it, you’re going to be in a world of hurt one day, and I will do the ‘Told you so’ dance.

  • Child Themes – Learn them, love them

    As a general rule, I don’t do much help with themes. Not because I can’t, but because themes are a style and preference issue, which means what I think looks good, you may not. Once I find a theme I like, I prefer to spawn a child there-of to modify and customize. I’m going to step a little outside my comfort zone to discuss child themes.

    The parent/child relationship in code is something that shows up everywhere. A child inherits from a parent, and only the aspects of the child you change will be different. This is most simply understood in the realm of WordPress themes. The official WordPress Codex doc on Child Themes is mostly straight forward for anyone who’s looked at a theme and played around a little. But the novice can get easily overwhelmed.

    The easiest way to get started is to make a new folder in wp-content/themes for your theme. /wp-content/themes/child-of-2010 for example. I like to name my children something that will remind me right away of their parent. For example, on another site, I have a news-style theme, taken from Justin Tadlock’s Hybrid Theme, which I called ‘Hybrid News ala JFO – Blogging’. The folder name is ‘hnj-blog‘ to differentiate it from a very similar, but functionally different ‘hnj-video‘ and ‘hnj-plain‘. Each of the three themes is a small variation on the parent theme, but because of the way I wanted to call things, I decided that it was better to have three themes instead of an extensive functions hack and slash. This was after a lot of testing and tweaking and changing, but in the end, this worked for me.

    For a proper child theme, you only need one file in that folder: style.css

    You heard me right, just one. That Style file will be what tells your code where to look for your parent theme. Here’s what Child looks like:

     
/*
Theme Name: Child of 2010
Theme URI: http://Ipstenu.org
Description: This is a child theme of Twenty Ten (2010), the 'new' default WordPress Theme.
Version: 1.0
Tags: fixed width, widgets, valid CSS, valid XHTML, SEO, SEO friendly, adsense, custom header, three columns, clean,  right sidebar, blue,white, photoblogging, widget ready, simple, gravatars
Author: Mika Epstein
Author URI: https://ipstenu.org/
Template: twentyten
*/

/* Get base CSS */
@import url('../twentyten/style.css');

    There are two really important parts to this. First is the line Template: twentyten — This is what defines the theme as a child theme. Period. Without this, you have nothing. The second is @import url('../twentyten/style.css'); which tells your CSS to pull down all the CSS from Twenty Ten and use it.

    Once you’ve done that, you have a working theme and you can activate it. I know! It’s so easy, a caveman could do it! Any CSS changes you want to make go in your new child theme and, because of how inheritance works in code, they override anything imported from Twenty Ten, so your changes magically take effect, without having to reproduce the whole theme!

    But what if you want to change a template file? I wanted to add one line to my comments.php file to turn on a subscription checkbox. This is done by copying the comments.php file from the twentyten folder into your child-of-2010 folder, and making the edits. It works almost the same way that the style.css. The main difference is that with template files, you can’t just have it contain only your changes, it must be the whole file, with your changes added in. This trips people up sometimes.

    Now that you’ve seen how easy they are to make, you may wonder what the point is? After all, they are easy, but it’s easier still to tweak the parent theme. Yeah, it is. It’s also easy to lose all your changes when you upgrade WordPress.

    For better of for worse, and yes, people argue about this all the time, WordPress upgrades overwrite the Twenty Ten theme, just like they used to overwrite the Default theme. I can’t begin to tell you how many times I’ve see angry posts ‘The upgrade blew away my theme changes!’ And for every one of those, someone’s posted ‘Yeah. It does that. Restore your theme from backup, and by the way, try a Child Theme.’ Now that WordPress lets you upgrade themes from inside the admin screen, you’re going to run into this more and more often. That’s why we’re always saying ‘Don’t change core! Don’t edit themes! Make functions/plugins/children!’ More on the other stuff later.

    A child theme is smaller than a copy, and it’s just as fast. A child theme will never be overwritten when your theme is upgraded. Your child theme is safe even from a manual upgrade. Remember the directions for that? Even when we tell you ‘delete your WordPress folders…’ we always say ‘except for wp-content!’ That’s because your uploads, plugins and themes are in that folder, and you should NEVER delete them for an upgrade. And by making your own theme folder, no one but you will use it and no other theme will overwrite it.

    So yes, use Child Themes. Learn them. Love them. Your life will be better the next time you upgrade WordPress.