Best practices are called that because they’ve first been repeated again and again. In my many years of WordPress work, I’ve picked up a couple best practices that I wish I would’ve found sooner.
None of the following advice is ground breaking, it’s just all stuff that is constantly on a developer’s plate while working on a project. Maybe stuff that hasn’t always been there- stuff that exists outside the normal tutorial and how-to. I’ve written this rambling guide to hopefully help some new developers pick up some skills that might otherwise fall through the cracks.
Use a text editor, source control, etc
This might seem like a pretty simple one, so I won’t spend much time on it, but I thought it might be worth mentioning that a smart developer always uses a proper text editor or IDE, and a developer that doesn’t like to repeat work should be using some sort of source control, be it Git, SVN, or even a simple check in/out.
When you edit inside /wp-admin (or even when freestylin’ in a text editor), it’s really possible that you do something wrong. I do it all the time. When I do, I find great comfort in reverting changes to my last known happy place. Save some stress and hair, keep your code backed up.
Don’t make child themes
This is probably a point that might start some arguments, but I say bring it on. This may sound weird, but best practices for a professional might not be the best for beginners. The way you learn to do things is often not exactly the way you end up implementing things in the final version, but that journey is invaluable, especially for a new developer.
While a lot of developers and consultants will swear by child themes, I’d bet money that most of them didn’t start with child themes. I can admit that once you’re comfortable with PHP and theme structure, child themes are a fine preference, but I think when learning you should stick to tinkering right inside someone else’s code. Why?
Because someone smarter than you has already written a ton of great code. Go ahead and jump right into those template files and get dirty. If you’d like to build on their code with a child theme, you’ll at minimum need to know how to use PHP hooks, filters, and actions. Need another reason?
Automattic doesn’t use child themes on WordPress.com. They’ve built their own starter theme, _s (aka “Underscores”), and it’s meant for hacking, not birthing children themes. Each time they begin a new theme, they directly edit this starter, not hook into it. They even call the theme The 1,000 Hour Head Start. And those are hours from folks soooo much smarter than me.
If _s doesn’t suit your fancy, give Bones a try. Bones comes in multiple flavors: responsive, classic, and Genesis. All are filled with robust documentation and meant for direct editing, a great way to learn how things work. When you’re done, simply wash, rinse, and repeat.
Looking at code written by someone else is the main way I learn. Be it themes, plugins, or tutorials on blogs (like this one!). Once you’ve mastered that, feel free to make a child theme. Hook and filter until you’re blue in the face, just don’t do it before you know the guts like the back of your hand.
Don’t stop at the post and page
When I started with WordPress I spent a lot of time wrestling posts into new things. Portfolio items, events, movies, people. I’d add tags and categories and I’d query and I’d filter and things would eventually look like an interstate overpass exchange.
Custom post types and custom meta data are the secret sauce in all my WordPress work. I’m no longer shackled to the post or page, I can have movies and recipes. I’m no longer stuck adding markup to my post body, I can enter each specific bit of information into its own box.
I won’t explain the whole shebang now, I’ll just say to go get comfortable with custom post types and with custom meta data. I believe in meta data so much I wrote a 45 page ebook about it.
Extending WordPress beyond the post and post body is the main thing people are talking about when they mention doing things like a CMS. It used to be a hassle, now it just takes a few minutes at the top of your project. Do it.
Making a plugin is way easier than you’d think
Speaking of custom functionality, let’s talk about plugins. When I started making custom WordPress sites, I was pretty happy just dipping my toe into the WordPress themes folder. From there it was possible to change the styling, make custom templates, even add custom functionality like fields and post types.
But changing themes was a pain. For years I dealt with it, because I figured writing a plugin was complex. WRONG. Writing a custom plugin is about as difficult as making a custom page template. You include a tiny bit of custom markup near the top of a file (which you can even copy and paste), and WordPress does the rest.
In fact, here is the custom heading you’ll need to create a plugin. Simply create a file called something like my-plugin.php, start it with the following, then drop in your functions, shortcodes, includes, etc.
<?php /* Plugin Name: Name Here Description: Description Here Version: 0.1 Author: ClarkLaB Author URI: http://clarklab.com */ // do something here! make some cool_functions();
Once you're comfortable with making plugins, you can easily hop from theme to theme without losing things like custom post types, meta boxes, and more. And if you need to go the extra mile, perhaps at the fault of a clumsy client, you can load plugins in /mu-plugins/ to make their include mandatory. No way to disable them, nice and dummy-proof.
Bill Erickson uses such a method with his Core Functionality Plugin, which he's of course shared for you here. Following our theme of using code from folks smarter than us, let's follow his lead and make sure to put our must have functionality tucked away somewhere safe.
Get involved in your local WordPress scene
At the risk of revealing my true colors here, I love to get together with folks and talk about nerdy shit. I go to electronics conferences, I speak at WordPress meetups, and I meet a lot of great people while doing so.
Unless you work in a full-time environment surrounded by WP gurus, you deserve a sounding board for your developing skills. Simply finding some like-minded folks to bounce around ideas and best practices and favorite plugins off of will greatly improve your skillset.
For years while writing PHP code I sat alone (well, in a technical sense), reading blogs and posting in forums. In the past year or so, I've started to get involved in the Austin WordPress Meetup Group and I won't be stopping any time soon. There's a place for everyone. If you're learning, there is plenty to soak up there. If you think you are a pro, reciting your reasoning to a group of others will only help sharpen your resolve.
WordPress is calling this the year of the meetup, which should be reason enough to give it a try. Go to a meetup, go to a WordCamp, find your other nerds.
Learn from your mistakes
Aside from the corny title, this might be the most important bit of info here. When you take the time to learn something, the next time you do it you'll only do it better. And with code, you'll have the exact answer you're looking for.
If you're making themes and writing code, consider signing up for a GitHub account to share Gists or writing or blog or running a Tumblr- just do something that allows you to keep track of your past conquests. I often find myself writing blog posts specifically so I will remember it, sharing with you guys is just a bonus. Not only is reusing and expanding on code a great way to get things done, you can usually do so in a fraction of the time.
It's OK to learn on a client's dime, but know your limits
At Dev Day during WordCamp Austin 2012, an interesting topic came up. Someone asked about learning on the clock, and how to bill for that time. The consensus of the room seemed to be that as long as you've got a reasonable amount of skill and speed on your side, learning on the clock is a fine deal for both the developer AND client. How so?
When you tackle a project and run into a problem that needs solving, always remember that someone else has already found and fixed this specific issue. Not only is being able to find and apply that fix a skill worth paying for, you're only able to do so based on the 1,000's of hours of work you've already poured into your skillset. So your current client is getting a benefit that your past client paid for, and your next client will benefit from the time this client paid for. It's the circccle of lifffe! and any good client should realize he's scoring a deal to have custom solutions achieved specifically for his project.
That's not to say that you should take any project willy nilly and figure it out as you go. It means that a skilled developer can plan out 90% of his or her plan and freestyle the rest during the project. It does not mean that you should take a job with little idea how to complete it.
Ask questions but learn to Google
There are a lot of great WordPress forums and places to get your question answered. You can try the official WordPress support forums, StackExchange, Forrst, or the Austin WordPress Google Group. I'm even a paid member on ThemeHybrid, a community run by Justin Tadlock. The answers there are top notch and the members are super talented.
To be honest, though, you can usually find a solution to your problems with some exhaustive googling. Lots of times I'll be in the middle of the hunt, give up, ask a question, only to find a solution minutes later with some further snooping.
I love starting a good discussion and seeing how other developers do things, but never underestimate the power of teaching yourself to do things. The internet is the best text book ever written, especially where WordPress is concerned. There's more documentation and tutorials than you can shake a stick at. Take advantage of it!
I've even gone on job interviews and said "I'm really good at the internet." I explained that hitting walls and finding solutions are major part of my process, part of the process I'm damn good at. I got the job.
You target is always moving
As you continue to learn, your target will always be moving. A triumph one week will be code you're re-writing the next. This constant improvement and growth is one of the most thrilling things about being a developer and I hope this post helps set up some good habits for those of you looking to learn more.