WordPress is an amazingly flexible, powerful content management system – it can do a lot of things for a lot of different people, and can can be contorted to match the requirements of impossibly different businesses. All for free.
Of course. Lets talk about how you can go about making small customizations to your WordPress based site. There are routes to take for people of all ability levels – so don’t be afraid if you’re still not exactly sure what “hosting” means.
I’m going to give 2 paths here, one for people who don’t know html and css from arugula, and one for those who do, even if it’s just barely.
Over the past 12-18 months, the WordPress community has exploded with a new class of themes – heavily customizable and easy to use, even for those with little or no html and css ability. I’m going to talk about 3 themes here – 2 paid, and one free. Feel free to chime in in the comments with your personal favorite.
Headway is my favorite. It’s not free, in fact, it’s not even cheap – but in my opinion, their visual editor is really fantastic – and just what a beginning WordPress user needs to get them up and running with a great looking, customized theme. Click here to visit Headway.
Thesis has been around since the beginning of paid themes. It’s hugely popular and has a rabid following. It’s not my favorite for a number of reasons, but how wrong can 35,000 people be? Click here to visit Thesis
Atahualpa is another tricky one. It’s very popular, and refreshingly, it’s free! However, there is a pretty steep learning curve that comes along with it. If you’ve got the patience to power through the learning stage, you’ll no doubt be very excited with the end product. Click here to visit the Atahualpa homepage
The other option is a little less glamourous, and a lot more migraine inducing, but the possibilities are limitless. WordPress works on a templating system that is both easy to use, and robust enough to let you do anything you want it to. The kicker is: you need to learn how HTML, CSS, and even a little bit of PHP if you’re going to make this work. You don’t exactly need to be an expert in any of them to make small changes to an existing theme though. Here’s the quick overview, and some links to get you pointed in the right direction:
Nearly every WordPress theme consists of the same basic set of files, listed here:
That is, unfortunately, not even close to a complete list. Fortunately, there’s a handy diagram at this page on wordpress.org.
Now, you at least know where to start looking – all that’s left is to figure out what to do once you get there. Here are a couple of great tutorials to get you on your way:
HTML Tutorial
CSS Tutorial
EDIT: The process has changed! You now get your api key straight from akismet. You’re going to have to withstand some awfully guilt inducing text to get it free. Consider yourself warned.
When I was first starting with WordPress, there were a number of things that confused me. The distinction betwen wordpress.COM and wordpress.ORG is not immediately clear, and even if it was, it’s difficult for a beginner to wrap their minds around what the difference actually means to them. I don’t want to derail on this post and talk about that too much, so here’s what you need to know:
Chances are, if you’re reading this blog, you’re using wordpress.org, and you have your own host and domain name.
Right. Back on track. A few plugins and other services require you to have a WordPress API Key – Most notably, Akismet (the comment spam fighting plugin that comes bundled with WordPress). Now, when you hear WordPress API key, you assume you’ll head back to the place you downloaded WordPress from (wordpress.org), and get it there. This is, however, wrong. WordPress.org is a big site, and it’s possible to have an account there, so you can waste a lot of time looking for the mystical API Key.
The API Key you’re after is part of the WordPress.COM ecosystem, and is available once you sign up for a free account there. You don’t even have to set up a blog – just head over, sign up (click here to sign up without setting up a blog), and navigate to your profile page, where you’ll find a link to get your API key. Just like that, you’re all set!
EDIT: The process has changed! You now get your api key straight from akismet. You’re going to have to withstand some awfully guilt inducing text to get it free. Consider yourself warned.
Having just done this to move from apartmentonesix.com to yourcodegarage.com, I figured it would be fitting to write a quick post about how to handle this sort of redirection.
It’s important to know the goal – in this case, we want to move a site from one url to another. For example, from
http://site1.com
to
http://site2.com
However, we’re actually moving all the content and everything over – so we want to redirect the individual urls, like this:
http://site1.com/post-1/
redirects to
http://site2.com/post-1/
That way any bookmarks or incoming links pointing at the old site will redirect properly at the new one.
First things first, you need to duplicate your WordPress installation from the old site onto the new one. Here’s the drive by version of how to do that:
We’ll be back to thsi site in a bit to implement the redirect, but for now, we’ll move to the new site.
$table_prefix =
You need to make one more change, at about id 39 – look for an option with the option name of “home”, and change it appropriately.All we’ve got left to do is redirect your old site to the new one. Unfortunately, this is often the scariest and most difficult part of the entire process. On the bright side, you should be able to just paste this code in and call it done.
To accomplish our redirect, we’re goign to modify the .htaccess file of our old site. .htaccess is a file that you can use to give your server special instructions on how to handle certain requests to your site. Because it starts with a dot, it’s often hidden by FTP clients – so you may have to do some tinkering to have it visible and editable to you.
Here’s the code we’re going to use:
RewriteEngine on RewriteRule ^(.*)$ http://yourcodegarage.com/blog/$1 [R=301,L]
Obviously, you’re going to want to replace “yourcodegarage.com/blog” with your own url. Just put that at the top of your .htaccess file, and you should be all set. Here’s the gist of what’s happening:
RewriteEngine on
Here, we’re just telling the .htaccess file to make sure the rewrite engine that your webserver uses is running, and able to handle the request.
RewriteRule
We start the line with the word “RewriteRule”, because that’s what we’re defining – a rule for the server to use in rewriting the url and sending the user to where we want them.
^(.*)$
I’m not going to get into the nitty gritty of the regular expression being used here, but what you need to know is: This section says “Match the entire url (after the domain name), and store the whole thing for me to use later in this line.”
http://yourcodegarage.com/blog/$1
At this point, we give the url we’d like to send the user to. In my case, I needed to send the user to yourcodegarage.com/blog, because that’s where the blog is now located. The $1 after that is telling the server to append whatever we found before to the end of this. So, if the old url was
http://apartmentonesix.com/my-post/comments
then “my-post/comments” would be grabbed, and appended to the end of “http://yourcodegarage.com/blog”, ensuring that the user gets sent where he needs to go.
We finish up with this:
[R=301,L]
All we’re saying here is use a 301 redirect (permanent), and don’t listen to any redirect rules after this one.
And with that, we’re all set! Make sure you use Google Webmaster Tools to notify google of the change, and get to work blogging at your new url!
I finally took the plunge and redirected apartmentonesix.com here to yourcodegarage.com/blog. This is where I’ll be doing all of my code and tech help related blogging from here on out. Expect much more frequent content over here.
Thanks for visiting!
As I’ve mentioned before, I’m in charge of all things technical over at The Keyword Academy. Last weekend, we had one massive site outage. For nearly 36 hours, the site was COMPLETELY inaccessible. Not responding to pings inaccessible. All of my knowledge about how to run a website comes from experience, so this was a great, and terrible learning experience. I figured it would bea good idea to write down what I learned from the mess – both to clarify it in my own head, and to give anyone else some insight into what they might need to watch out for.
The Keyword Academy is a respectable program – we have somewhere between 1000 and 1500 paying members, many of who are on the site every single day – checking the forum, using our tools, or reading up on content. Going down for any length of time means that we’re not only losing out on potential new members arriving on the site, but we’re also annoying our faithful members a lot, by throwing a wrench in their daily work (or procrastination, depending on what they’re planning on site) habits. Like any other site, we don’t want to be down. Ever.
Just after 1pm on Friday, 10/29, things started getting weird with the server (more on the actual server setup in a minute). Database connection started showing up in some places, but not others. Soon, no connection could be made to the database. After sshing into the server to see if I could figure out why the DB was down, things got weirder. The “top” command wasn’t recognized. Neither was “vi”. I couldn’t even list directory contents with “ls”. Things were going bad, in a hurry. A quick reboot of the server (I’m a terrible nerd – reboot is very high on my “potential solutions” list), the problem remained.
So, I contacted support. We’d been hosting the site (actually the collection of sites – we’ve got a couple of tools on different domains/servers) with MediaTemple, and we’ve been very pleased with them – the pricing is reasonable, the service is predictable, and, while I can count the number of legitimate support tickets I’ve ever opened with them on one hand, support has always been pretty good. Obviously, this was a big deal, so I pinged them on twitter immediately after opening the support request (insider’s tip: pinging @mediatemple after opening a ticket seems to get it looked at much more quickly), and soon after, I had a response: “Not our fault. Try reformatting your server” (more extra info: This site was a VPS, meaning we have full root access to it, but we don’t get the whole machine. MT has a convenient “revert” feature that puts everything back to it’s original state and lets you start over. Also, they used nicer words, but that was the gist of it). Not what I wanted to hear, but at least it meant I could resolve it on my own. A few minutes later, however, another email came in – something to the effect of “Actually, there might be something to this. We’ll look into it”.
Then came the waiting. And waiting. Even if it’s a hardware problem, how long could it take to fix, right? I’m not a sysadmin, and I’ve never worked at a hosting company, so I have no idea if that sentiment is valid or not, but – surely this can’t take more than a few hours? So we kept waiting.
Updates were scarce, and vague. While I was envisioning a tech jumping into action to replace the hardware, and get my service restored, the reality looks to have been a little different. 2+ hours later, I got my first status update (which I expected to be “All good, go nuts!”): “… emergency maintenance for vz439 has been scheduled …”.
Wait, what? 2 hours later, and you’ve managed to schedule maintenance? Surely that’s just some sort of automated message meaning “Our team of ninjas is replacing hard drives at breakneck speed”, or at least “We’re at best buy, reading the back of hard drive boxes. We’ll call you when we’re back”, right? So, I held on. Surely it would be resolved in a few more hours?
I’ll cut the narrative short at this point, because I could rant for 1000 more words about the rest of the ordeal. Suffice it to say, this update came about 1:00 Sunday morning, with 1 update in between. 1 update. In 35 hours of downtime.
To make matters worse, my server was actually still offline. I updated my support ticket to reflect that fact, and got no response. Finally, I reverted the server, and it started working again. At this point, it was midday sunday, a full 48 hours since the site had gone down. Oh – and when I did revert, I managed to get into the data they had worked so diligently to “restore”. It was from July. I can’t imagine any business where 4 month old data would be a good thing, but in ours, I have little doubt that it would have been the end of the business. We can’t lose 4 months of customer data and shrug it off, we would literally be out of business.
Fortunately, I had lost faith in MT’s ability to fix the problem sometime early saturday, and started the arduous process of moving to a new host. Because of DNS resolution, the site was down for anywhere between about 30 hours and 40 hours for our members, so we’ll call it 36. We’ve got the main site on a rackspace cloud server at the moment, while we figure out if that’s where we want to stay. We’re not sure what we’ll do, but we do know what we won’t do: stay with MediaTemple. While their service record has been great for us for over a year, they lost us far too much money (in missed sales, potential cancels, and my time, which is billed hourly to the owners of TKA) to stick with them. On top of that, service was atrocious. If I had been updated hourly, and given a reasonable ETA (even if it was 48 hours) during this ordeal, I might stick with them. As it was, they absolutely hung us out to dry. It’s inexcusable.
Fortunately, there was lots of learning to be done in this experience. Here are the main points:
We’d been with MT in our current setup for over a year, and I’ve had smaller sites hosted with them for much longer. They weren’t always great performance wise, but the control panel was nice, and it worked well enough. What could we have to worry about?
As I mentioned, this was a VPS server with MT, meaning I share it’s resources with at least a few other users. I don’t know how many people were on my particular box, but I know that there was only one other person demanding updates on twitter. If the outage had affected thousands of users, I’m guessing updates would have been flowing a little more reliably.
If we had been on a fully dedicated server (where we were actually the only user on the server), what would the result have been? The level of public outcry is important to getting your problem addressed. Next time, I’ll inform the general membership who to yell at to get things going.
July. MT gave us data from July. That is borderline useless to me. Aside from the months and months of user data that wasn’t there, we’ve also made countless code changes since July. Without a backup, all of that would have been lost. Again – this probably would have been a business ender.
There are a number of “Set and forget” backup solutions out there, even for fairly large servers. We use one of these, because I don’t want to be saddled with the additional worry of knowing whether or not my code is backing us up properly – I want someone else to worry about that. We use Jungle Disk. When it came time to get my backup restored onto the new server, I was terrified. I had messed around with restoring backups to the same server using their handy desktop client before, but moving the data to a new server was a different animal, and significantly harder to do. Documentation was scarce. It all worked out, and we’re staying with JungleDisk – but I’d have felt much more comfortable if I knew what I was doing BEFORE the disaster.
We were backing up the database every 6 hours. That saves you from a real catastrophe, but it doesnt exactly make for a seamless resolution when things go wrong. We now back up hourly, and we’re looking into what we can do to have an up-to-date database ready and waiting for a problem to happen, 24/7.
(sidenote: We use MySQL for everything) I’ll admit: We cheat on our database backups. We don’t run mysqldump, because it’s too slow for the amount of data we’re backing up – so I just backup the database files and hope for the best. This hasn’t bitten us yet, except in one spot: a couple of points in the database use innodb tables instead of MyIsam tables. MyIsam tables are easy to recover from files – you just plop them into your MySQL folder, and they’re good to go. InnoDB tables, however, are messier. Depending on your configuration, they’re probably stored in one big file, and that one big file probably will try to keep MySQL from starting if you don’t get it, and it’s required supporting files into your MySQL directory before trying to recover. Know how to handle this beforehand.
Since we came back online, we’ve been battling countless tiny bugs that pop up because of inconsistencies between the old server and the new server. PHP versions, MySQL versions, installed libraries – all of these things can cause problems. If you’re planning a server switch, you can take your time to iron these out. If you’re suddenly forced to make the switch unexpectedly, your users are going to see, and have to deal with all your dirty laundry as you fix it up.
Email:
The problem (ok, one of the problems) with your average VPS setup is that everything runs on that box – including your mail server. If your server is down for 36 hours, you can’t receive email at your normal @mydomain.com address. Worse – if all your user data is tied up in the server that went down, you don’t know who to email to give them updates, and you can’t send it from whatever mail system you ahve on the server. As it happens, just as the server went down, we were getting set up on a new account with MailChimp. We hadn’t imported our email list yet, but I was able to get that from a db backup, allowing Mark (one of the owners) to import to MailChimp, and send out an email giving everyone an update.
Twitter:
Twitter is a great way to keep up with users in a situation like this. Fortunately, we have a support twitter account. Unfortunately, we hadn’t done a huge amount of promotion to get all our users following it beforehand. Twitter is great for giving out updates. Get an account, and make sure your users know about it.
The real lesson is: stuff breaks. Failures happen. I place a lot of the blame for what happened to us on MediaTemple – but the fact is: I’m the one in charge of keeping our site up and running. I have far more to lose than they do if they lose all data since July. While it feels great to say it’s their fault, it would feel even better to say “I was prepared, so our users barely noticed”. Be ready with a backup plan. Figure out what you’re going to do when you run into a massive failure like this, and do it before you’re forced to, because it’s happening.
I do all of the development work for an SEO/MMO program over at thekeywordacademy.com. As part of the program, we’ve put together a system that facilitates guest posting on other members’ sites easily. That’s all well and good – but one problem we run into fairly often is this: For whatever reason, the posts table on a site goes down, and the owner’s posts are all suddenly gone – without a trace. Naturally, they get pretty worried, and an email shows up in my inbox (or in our forum).
The good news is: it’s almost always just a simple myIsam crash – easy to fix, and no data loss. After going through this a number of times with various members, I decided I really ought to put together a quick tutorial on how to fix it.
First – how do you know this is the issue you’re seeing? The most obvious symptom is this: Your posts have just disappeared. The homepage of your blog is giving a 404 (but a pretty one, with your theme), or just telling you it can’t find any posts. You log into your dashboard, and much to your dismay, the edit posts screen is showing not ONE single post. It’s terrifying, because it’s at exactly this moment that you realize you never installed that backup plugin (or more likely, you started to, but never finished, because it got tricky). Much cursing later, you’ve resigned to the fact that all is lost.
Of course, it’s likely that all is not lost – lets look at how to make sure.
To get this done, you’re going to need to get direct access to your database somehow. There are a number of ways you can do this, ranging from the super nerdy (command line/ssh access), to the moderately nerdy (MySQL gui client like Sequel Pro), to the entirely accessible – the web based interface of phpMyAdmin. I havent run across a host in recent times that doesnt give you access to phpMyAdmin in some form, so that’s what we’ll use here.
First, you’ll need to get into phpMyAdmin. I can’t give you much help there, because it’s a different process with every host. If you’re having trouble, get to your control panel, and just start searching for things – start with “phpMyAdmin”, but if you can’t find that, move on to “MySQL”, “Database” – things of that nature. You’re bound to get on the right track soon enough.
Once you’ve got phpMyAdmin opened up, you’ll end up at a screen that looks vaguely like this:
On this main page, you’ve got a list of databases off to the left, and lots of information and settings you don’t need to worry about in the center. You need to choose the database that is running the WordPress install in question off on that left column, and click to open it up. (If you’ve got a number of WordPress installs on one server, this could be a bit tricky. Check out the settings in your wp-config.php file if random guessing doesn’t do the trick).
Now that you’ve chosen your database, you’ll see the list on the left has changed – now you’re looking at tables inside the chosen database instead of databases. Click on the wp_posts table to open it (note – it’s possible that this is something other than wp_posts, especially if you’ve got multiple installs in one database. The table you want will definitely end in “posts”, and whatever comes before that can be found in your wp-config.php file – look for “$table_prefix = “). Clicking on the posts table will either pull up a page describing the contents of the table, or an error message, that looks something like this:
Surprisingly, this is good news. Your precious posts are just one command away.
Finally, the juicy bits. To repair the table, we’re going to need to run an SQL command on the database – and to do that, we’ll click the “SQL” tab near the top of the page. Doing so should bring up a page with a box that looks something like this:
As shown in the screenshot, you need to enter this:
repair table wp_posts;
In case you hadn’t guessed – if your table didnt start with wp_, you need to adjust that command accordingly.
Double check that you’ve typed the command in properly, and hit “Go” (bottom right of the input box). If all went well, a moment of loading later, you should be presented with this screen:
And with that, you’re back in business. Check your site, and your posts should be back. In some cases, the wp_posts table isnt the only one that goes down, so as long as you’re in phpMyAdmin, you might double check to see if any of your other tables need some TLC from your newfound database administration skills.
On the off chance that none of this worked, the table wasn’t crashed, or repairing it didn’t fix the problem, there’s a fair chance you’re in serious trouble. For problems with that, or any questions along the way, get in touch here, or drop me an email.
Good luck!
Update – All this post disappearing have you hankering for some backup help? Have a look at this post about How to back up your WordPress blog
Here’s a little tidbit I can NEVER find when I need it: If you need to get all the tags that belong to a current post, here’s the function:
$tags = get_the_tags($post_id);
This will return an associative array of tags, with all their relevant info.
BONUS
If you need the same thing with categories, here’s your function:
$args['fields'] = 'all';
$categories = wp_get_post_categories($post_id, $args);
Including the args bit allows you to retrieve all the category info. If you leave that out (and use only the $post_id argument), you’ll get an array of relevant category ids, but no other info.
Big thanks to Clay Lua at hungred.com and his post Get Tag with Post ID in WordPress for pointing me in the right direction.
I’m not going to lie: I’m a javascript hack. I dont know what I’m doing half the time, because I don’t have to use it all that often. jQuery is seriously my saving grace when it comes to appearing to know what I’m doing with javascript.
That said, I’m currently working on a project that requires quite a bit of javascript work – specifically involving some animations – slideUp and slideDown stuff mostly. I put it all together, and it worked beautifully in Firefox and Safari on my mac – smooth animations, perfect transitions. As though I knew what I was doing. I fire it up in IE7 just to be sure, and it’s a nightmare. You can’t really call it “animation”. Slow, choppy, and unpredictable – legitimately unusable.
A bit of googling around revealed that apparently no one else in the world has this problem, and I am an idiot. Then I happened upon a gem at stackoverflow.com which mentioned, in passing, that Internet Explorer does an awful job of caching and displaying background images (specifically repeated background images) during animation – basically, he implied that for each frame of animation, I.E. loads, places, and renders each instance of a repeating background image, just one example of how a browser could have issues with animations. The specific elements I’m working with are 1000 px wide rows, and with each animation, about 10 of them have to move 300 pixels or so. The kicker? Each one is using a 1px wide repeating background. 1000 background images * 10 rows, and it becomes apparent why the animation was so bad. I bit the bullet and tried a single 1000px wide background image, and the difference was night and day.
The moral of the story is this: the css techniques you use on elements that will be animated can have a serious affect on animation performance. If you’re having problems, give some real thought to what the browser will have to do to animate the elements – calculating heights, margins, widths, background images, etc etc. Experiment with different values, with an eye toward explicitly defining any value that the javascript might have to calculate (i.e. define heights instead of just letting the browser do it), and you can probably make a big difference in your javascript animation quality.
Occasionally, I’ll run into a situation where I need to call a post specifically using the get_post() function. get_post() returns a Post object, with a number of member variables – the one that stores the actual content of the post being post_content.
However, if you try just echoing $post->post_content, you’ll get completely unformatted text – which is frustrating, because WordPress uses a great visual text editor on the backend – it’s a shame to not take advantage of it. Fortunately, WordPress provides a filter to display the text just as it would be displayed in the the_content() function inside the loop. Here’s how it works:
To get the content formatted properly, we need to apply a filter (which is different from adding a filter – here, we’re registering it so that other filter functions can modify it before it’s displayed).
apply_filters('the_content', $post->post_content);
So, we’re just applying the the_content filter to the $post->post_content variable. Doing so means that any plugin which adds a filter function to the_content like this:
add_filter('the_content', 'my_content_manipulator');
function my_content_manipulator($content){
//do stuff here
return $content;
}
will be applied to your variable. Fortunately, it also means that the WordPress core functions which format the post content correctly can also work on it.
Need more info about the $post object? Check out this post: .
Here’s something that comes up for me pretty often: depending on what I’m trying to do, I sometimes need plugin functions to run (or not run) simply based on which admin page the user is visiting. Here’s the WordPress function that will give you the title of the currently loaded admin page:
get_admin_page_title()
So, if you only want to run a bit of code on the “Edit Posts” page, you’d put together a conditional statement like this:
if(get_admin_page_title() == 'Edit Posts'){
//do something fancy
}
Recent Comments