As recently as this year, I was developing WordPress sites in Adobe Dreamweaver. I say that without shame because the tool was actually pretty good. I found myself defending it every few months, but it got the job done and I didn’t feel like learning anything new.
Enter Sublime Text 2, which recently stormed into my life and made a damn fool of me. This little editor is easily one of the biggest improvements I’ve made to my workflow, ever. Not just recently or just with regards to WordPress, but ever.
If you makes websites at a serious level, you should give Sublime Text 2 a chance.
This post is my quick (well, somewhat) explanation at why I’ve so fallen for the editor and what customizations I’ve made to make Sublime Text 2 even better, specifically for creating WordPress sites. If you’re familiar with the editor itself, feel free to skip to the meat (list of my favorite packages) down below…
Arguably the best feature of Sublime Text is the use of packages, an easy (and often free) way to extend functionality of your editor. With a few clicks, you can add new features like full SFTP support, linting for errors, function autocompletes, snippets galore, even a lightweight Twitter client.
Packages makes it possible to turn Sublime into exactly the editor you want it to be. And what’s best? All your packages and settings are simple files and folders which are totally portable, making your perfected dev environment super portable. We’ll get to that later. First, we need some packages!
First, we’ll look at a tool that helps install and manage your packages, then I’ll include a full list of my favorite packages and why I can’t live without them.
Most popular packages are available through an ultra-handy system called Package Control. If you’re running Sublime Text 2, you should be running Package Control. It makes installing, updating, and removing packages a total breeze. Package Control is available free from Will Bond, or wbond, who you’ll see mentioned again later in the countdown.
To install Package Control, you’ll need to run the following command in the Sublime Text 2 console. The console is opened via the Ctrl + ` shortcut, then just paste in the following text (I know it’s long and weird looking- you don’t need to understand it, just paste it):
Once that’s done, restart Sublime Text, and you’ll find the goods under Preferences > Package Control. From there, click Install Packages and you’re on your way to a magical land.
My favorite packages
All the packages I use are available through Package Control, so feel free to just search there to install them yourself. I’ve included plenty of links below for reference, just don’t forget that most of the action is inside Package Control. Here we go:
A full-featured SFTP client from wbond, Sublime SFTP makes working on a remote server almost as easy as editing locally. With full support for FTP, SFTP, SSH, etc, I’ve found this package gets me access to just about any server I’m working on.
To make the most of Sublime SFTP, make sure you’ve opened a folder (usually my root /wp-content folder) and have your Side Bar turned on (View > Side Bar > Show Side Bar). From there, you can right click on your wp-content folder and choose SFTP > Map to remote, which will give you a simple settings file like this one. Fill it out with your credentials, remote path, etc and you’ve just made Sublime Text into a full-featured SFTP client.
One tip: in the settings file, I love to enable Upload on save, which puts my files onto the server the second I save them. It makes working remotely a breeze. Of course, this isn’t the best idea for a full-scale production server, but during development I absolutely love it.
PS: Sublime SFTP is a paid package, but I find it worth every penny. Plus, the license is per user, not per machine, so the package can travel with you just fine. There’s also a free trial if you don’t mind a nag screen, but I recommend just buying the license. wbond rules.
This package is a collection of functions and WordPress snippets that make writing template PHP a great bit quicker. Not only will Sublime Text start auto-completing WordPress function names, the package includes all the default arguments of the function, which is great in times when your memory might otherwise need a trip to the Codex.
Aside from core functions, it’s got complete functionality snippets, like custom post type templates and plugin starter templates. It’s a great tool for anyone still learning the deeper corners of the Codex and a great way to make sure you’re not making up function names (like get_the_permalink()).
When an auto-complete just won’t cut it, this package makes hopping into the Codex a snap. Simply highlight a function, right click, and you’ll find two new options: WordPress Codex Search and WordPress Function Reference. The first will perform a search on your selected text, the second will straight open a function reference URL with your selected text, like so: http://codex.wordpress.org/Function_Reference/get_template_part. It only saves a couple seconds, but when you’re in and out of the Codex all damn day, it starts to add up.
This is a fun one. The package allows you to highlight a class in a source file (like single.php and the like), and with the press of a key shortcut, you’ll be jumped to the CSS declaration in an open CSS file. For instance, say you’re in header.php and need to edit the main navigation, or .main-nav. Simply highlight the class, fire your shortcut (mine is CTRL + .), and you’ll be jumped into the open style.css to the exact line you’re hunting for. Another shortcut press, another jump. It’s a totally handy way to jump through your files without searching or remembering line numbers- things that are totally annoying in my book.
To lint is to check code for errors, and if you’re writing tons of code, it’s nice to have some form of linting built into your editor. Enter SublimeLinter, which adds error detection for just about any language you throw at it (including of course all the WordPress mainstays, like PHP, CSS, JS, etc).
Even better, each language and ruleset is completely customizable, making for insanely tweakable results. For instance, I don’t even use the CSS linter, because I’m fairly confident there. I always check when I go to production so I don’t usually feel a need to check live as I type.
ZenCoding is an easy and automated way to write HTML. If you’re not familiar with the practice, check out this intro post on Smashing Magazine. It’s a simple enough idea: use shorthand and auto-expand it into clean, quick markup. For instance, check out this example.
I don’t usually go writing whole pages with this method, but it makes shorthanding some chunks of code soooo much faster. Which is perfect for a lazy lump like me.
This offers a quick and easy way to submit public and private Gist snippets to your GitHub account. Simply highlight text, right click, and select Create Public Gist. The package will even let you enter a description and filename (defaulting from the file you’re currently inside). Go forth and share code.
I’ll admit this one is pure silliness, but I’ve found it charming and continue to have fun using it. Sublime Tweet is a package that adds full Twitter capability to Sublime Text. Send tweets, view your timeline, reply to users- all from within Sublime Text.
It’s useless, it wastes time, and I love it. There’s something satisfying about quickly checking updates in a text-only format without leaving your text-only environment. Sublime, even.
Make it portable with Dropbox
Because all your packages and settings are just plain ol’ files, it’s pretty easy to take everything into the cloud with a service like Dropbox. I’m primarily a Windows user, so the following steps will be from a PC-viewpoint, but most of this should be easily translatable to OSX, Linux, etc.
Moving your settings and packages
All your personal settings, snippets, etc are stored in your user folder, located at C:\Users\[username]\AppData\Roaming\Sublime Text 2\Packages\User. Our gameplan will be to copy those files into our Dropbox, storing them in the cloud, then pointing the original folder to our newly cloud-hosted files. The result will be instances of Sublime Text on multiple machines that all function exactly the same.
Make a Sublime Text 2 folder in the root of your Dropbox. Inside, make a Packages folder. Inside that, make Users. Once we’ve replicated the tree, simply copy in all the files you found in the original User folder. Once everything is uploaded and safe, clear out your local User folder (and make sure Sublime is closed when you do so).
Our next step will be making a symlink (symbolic link) between the old User folder and our fancy new cloud-based User folder. You do this in the Windows Command Prompt (which you’ll need to launch as Admin), using the command mklink. It’s a pretty simple idea: we’re going to symbolically link these folders together, so that our old folder behaves exactly as if the files were still present there. The command looks like this:
Once completed, the files hosted in Dropbox will be automagically present inside the local User folder. Any time you make a change in the folder (like settings, snippets, new packages), it’ll be automatically mirrored into Dropbox and thus into your other local User folders.
Astute users might notice that the actual packages themselves aren’t stored in the User folder, and that’s just fine. Package Control is smart enough to catch the packages present in the settings and automatically fetch any that aren’t present locally. Doing it this way means fewer files we need to load into Dropbox and manage ourself, and that sounds pretty good to me.
(Props to jdc0589 from Stack Exchange for this information).
Moving your WordPress build files
Something I usually do when working with WordPress files on a server is make sure to keep a complete local copy for myself. Using the SFTP module makes that amazingly easy. If I’ve started locally, I use the module to upload my entire folder tree when I’m ready to move to a server. If the build was started remotely, I use the module to grab an entire copy for myself so I can edit files locally. Any time I edit a local file, it’s automatically uploaded when I save.
Keeping two complete sets of files has saved my hide more times than I care to count. Now that I’m moving between multiple computers, I’ve moved my local files under Dropbox control, keeping that same safe set of templates even safer.
If you want to move your actual template files into the cloud, you can mostly repeat the process above (with the exception of the symlink, which you can actually skip if you’re cool with working directly out of your Dropbox folder).
This post started out as a quick list of my favorite packages and quickly grew into the monster you just scrolled past. It’s a nice parallel for the editor itself: it looks simple and is easy to get started with, but the customization rabbit hole goes as deep as you’re willing to dig.
Next up, I’ll probably write a how-to post featuring some of my favorite snippets. Snippets are an awesomely easy way to store bits of code you find yourself using often, and with some rich snippets in place, you’ll find yourself using them even more often.
What are some of your favorite packages? Have I missed any must-haves with this list? How has Sublime Text changed the way you develop WordPress sites?
Trying something new: the following slides are from my #wpatx presentation on September 25, 2012. I’ve created a way to show them directly in a blog post, so hopefully this will let me ditch Google Docs Presentations. The following slides are plain text, with links inside, so feel free to get to copyin’ and pastin’ and a clickin’.
Two things: If you’re not familiar with WP101, shame on you. They offer an ever-growing library of WordPress tutorial videos geared and the beginning (and learning) user. Second, I recently released an ebook called Meta Valuables. These two things have now collided in the following video, which does a great job of quickly explaining meta data and how it works. Check it out:
If you liked that taste, make sure to check out WP101. If you’re already a total WordPress boss, don’t forget about the WP101 Plugin, which allows you to insert these handy videos directly into your client’s dashboard. Both services are run by a dude that’s totally active in the WordPress community and we can never go wrong supporting our own!
This is a quick one, but file it away in your brain and some day you’ll thank me. Have you noticed that when you create a new custom post type that you’ve gotta hit the admin settings and re-save your permalink structure? You don’t have to change anything, just saving it again will do the trick, but it’s an annoying little step.
If you’re creating post types programmatically (inside your plugin, whatever), you might need a way to automatically flush your rewrite rules. Enter the simple function flush_rewrite_rules().
flush_rewrite_rules( $hard );
The function only accepts one parameter, a boolean true/false for $hard, which will decide whether to actually update the rules in the .htaccess file or just soft flush the rewrite_rules transient. The default is true, meaning you’ll get a full flush.
Even if you’re not working with post types, you’ll sometimes run into scenarios when you need to flush. I’ve got a project going right now where I’ve dropped the author prefix in the URL, giving each user a top level page (domain.com/user). I noticed that these rules weren’t being created upon registration and a simple flush_rewrite_rules() in my registration hook fixed things up.
It’s worth noting that this is an “expensive” process, meaning you shouldn’t just run it all willy nilly. Only call this when you absolutely need it. If you’re not sure if you need it, you probably don’t. But six months from now when you can’t figure out why some users are hitting 404s, come back for a high five.
Recently while working on a WordPress project, I decided to start a new theme from scratch. This, of course, meant taking a couple minutes porting some of my functionality from my old theme to my new theme. While it wasn’t back-breaking work, a lot of it can be avoided with some proper setup at the start of a project.
Custom post types were the best example of custom functionality I could think of that might disappear when changing themes. Lots of folks, when not using a plugin, declare their custom post types in functions.php, or somewhere similar. When you change themes, these inits are lost and some things will go wonky.
If you’ve got functionality you want to keep regardless of theme, consider throwing it inside a plugin, then throwing that plugin inside a /wp-content/mu-plugins/ folder. Files placed in the Must Use Plugins folder will automatically be used and never be able to be turned off. For things like custom post types or shortcodes, they’re perfect for making sure our functionality stays in place as we change themes.
Creating the plugin is dang easy. Simply create a new file and declare a new plugin like so:
<?php /* Plugin Name: Must-use Loader Plugin URI: http://clarklab.com Description: A must-use plugin that initiates all our goodies. Version: 1.0 Author: ClarkLab Author URI: http://clarklab.com */ require_once(dirname(__FILE__)."/inc/post-types.php"); // include the rest of your neatly sorted functionality here
Save the above file as something like must-use-loader.php and place it inside the /wp-content/mu-plugins/ folder. If this folder doesn't exist, create it. Once you've place the above file, your new functionality will immediately activate and will stay active until the file is removed. Nothing inside /wp-admin can change that. Only the file being physically removed will stop these functions.
In my sample above, once I've established the plugin, I simply include the PHP file containing my custom post type code, just like I used to in functions.php. The only difference is the next time I change themes I won't have to worry about any of this mess.
When working with WordPress, I often need to reference specific columns in the database. I’ve got most of them memorized (ID, post_author, post_date, post_content, etc, etc) but every now and then I’ll need to get at some data and can’t recall where it’s stored. Enter the handy WP DB schema chart!
This is accurate as of WP 3.0, which isn’t exactly cutting edge, but the schema isn’t something they change very often and I’ve yet to find any errors in it. If charts ain’t your thing, check our a full description of the database in the WP Codex.
Learning the columns and tables and the relationships between everything is a great way to pick up speed as a WP developer. Bookmark that chart (or the WP codex page) and check it often. You’ll find yourself making more advanced queries in no time.
I’m happy to announce the release of my first ebook, Meta Valuables.
Meta Valuables is a 45 page look into the world of meta data, the extra bits of information that WordPress let’s us tack onto posts, pages, and users. The book is filled with code samples and real-world examples which will leave you with a better understanding of how to manipulate meta data in every WordPress project you tackle.
The ebook is available for as little as $2, with name your pricing for anyone feeling generous. For your donation, you’ll get a DRM-free PDF file (both at the time of purchase and emailed to you as a backup), along with a TXT file for good measure.
These lessons are meant for the learning WordPress developer, someone familiar with editing template files, basic PHP functions, the template hierarchy, etc. You’ll need a test or local install to follow along in code, but don’t let that scare you. Getting dirty with your WordPress templates is something every developer should look forward to.
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.
This Sunday, I’ll be teaching the class Meta Valuables, Unleash the hidden power of WordPress meta data. It’s happening at Cospace, from 3-6PM, we’re going to be coding live in class, and your attendance scores you a free copy of my awesome new ebook.
The course is being offered through SkillShare, a new startup for organizing local learning sessions taught by hobbyists and professionals (like me!). Tickets are $25, but at the time of publishing, I’m a featured class, so you can score a $5 off scholarship from Appssavvy (details on the Skillshare page).
Because we’ll be doing lots of hands-on coding, this class is limited to just 20 students (a third the spots of which are already taken). I anticipate this class filling up, so if you’d like to join us, head on over to Skillshare and claim yourself a ticket.
The ebook: 45 pages of awesome
Included with your attendance is a free, printed copy of my new ebook, written specifically for this course. Meta Valuables is a 45 page ebook that takes a revealing look into the world of WordPress meta data. Jam packed with code samples and quick tips, these lessons will have you developing more dynamic templates in no time!
Aside from the paper version for reference during class, you’ll also get access to free downloads of DRM-free PDF and TXT versions, perfect for throwing on your smart devices, emailing to yourself, etc.
Free hosting for all students from WP Engine
In addition to the ebook, all students will also get a FREE personal hosting plan from WP Engine, the finest damn host WordPress could ever ask for. They’re based here in Ausin and have a habit of swooping in and supporting events like this, so you’ll definitely want to keep an eye on @WPengine.
To claim your free hosting (for life!), simply join us on June 10 and I’ll give you the secret URL to access the offer. And while we’re talking about awesome folks sponsoring the event, I’d like to give a shout out to Cospace, who hooked me up with the class space. If you’re in Austin looking for a coworking space, come give Cospace a look.
What to expect
The full details are available on the Skillshare page, but students should come to class with a computer and test install of WordPress ready to work. We’re going to code PHP live in class, and having your own set of tools is definitely the way to get the most out of this course.
We’re going to look at functions like get_post_meta, add_post_meta, get_user_meta, update_user_meta, it’s going to be madness! Even if you’ve never touched custom fields or meta data before, you’ll leave this class with an solid understand of how all this junk works. See you there!