Understanding get_template_part

If you’re creating WordPress themes you surely came across the get_template_part function at one point or another. It’s one of those hidden gems inside of WordPress that don’t get the attention they deserve. Let’s change that.

The get_template_part function is essentially a PHP include or require, on steroids:

  • It already knows where your theme is located and it will look for the requested file in that theme’s directory
  • It doesn’t issue a warning or fatal out if the requested file does not exist
  • It can search for other suitable files, if the requested one is not found
  • It knows about child themes and parent themes

Long story short, the get_template_part function allows you to break your theme down into smaller templates (or template parts), which can be reused across your other templates.

Although get_template_part is similar to a PHP include or require, you should not use it to include things like your theme options code, sidebars registration, custom widgets, etc. The get_template_part function should only be used to get template parts.

Let’s start off with some basic examples.

Continue reading

WordPress Workflow Tips: Using Subversion Externals for Plugins, Themes and Core

Subversion Externals for WordPress Projects

I’m pretty sure most of you are familiar with version control, and that it’s best practice to start each new project in version control, and not “add it sometime later.” Version control will help you manage changes to your code, and have revisions which you can easily roll back to.

Although my favorite version control software is Git, today we’ll talk about Subversion, and WordPress developers know that WordPress itself, as well as the plugins repository and the themes directory, are hosted in public Subversion repos. As you’ll see, this makes it incredibly easy to access core, themes and plugins using external references.

It’s a great idea to keep all of your code under version control, including WordPress core, the themes and plugins that you use. However, themes and plugins, as well as core, are already under version control in a different place, so to avoid redundancy, and extra maintenance work, we can use external references, which are more often referred to as svn:externals in the world of Subversion, or submodules in Git.

In short, an external reference is an entry in your own version control repository, which points to a different place, similar to a symbolic link in your operating system. When running svn update, Subversion will follow these links and grab the source code from those external repositories, without having to keep them under its own version control.

That might sound a little confusing, so let’s take a look at some examples, which will hopefully clear that up.

Plugins as Subversion Externals

Suppose I’m working on a typical WordPress project, and have got some themes and plugins in my Subversion repository, like this:

  - wp-content
    - themes
      - twentyten
      - twentyeleven
    - plugins
      - akismet
      - jetpack
      - bbpress
  - wp-includes
  - wp-admin
  - ...

Note, that the whole public_html directory is under version control.

Let’s say Akismet just shipped a new version, and my WordPress dashboard prompted me to update. When updating the plugin, WordPress will replace the old Akismet plugin files with the new files, thus, my files are now out of sync with my repository. In order to bring them back in sync, I have to SSH onto my server, and commit the new and modified Akismet files back to the repository, which is a pain.

Luckily, we can get rid of such pain by using svn:externals. So lets remove the akismet directory from our repository, and add an external reference to the Akismet plugin, like so:

cd public_html/wp-content/
svn rm plugins/akismet
svn commit -m "Removing Akismet from the repository."
svn propedit svn:externals plugins

Which will launch a text editor (typically nano or vim), where you can add the external reference to the latest version of Akismet from the WordPress.org plugins repository, like this:

akismet http://plugins.svn.wordpress.org/akismet/tags/2.5.6/

Save and quit your text editor, and run svn update. This will update your files from your repository as it usually does, and then update its external references, so you’ll probably see something like this:

Fetching external item into 'akismet'

Followed by the addition of an akismet directory in your plugins folder, with the Akismet plugin source files. These files are not under your version control, they’re just copied over from WordPress.org repository.

Now, when Akismet ships a new version of their plugin, say 2.5.7, you don’t need to update from your WordPress dashboard, you’ll just need to edit your external references, and change that tag to 2.5.7. Then run svn update and Subversion will pull in the new version for you, replacing the old files.

Let’s do the same for the Jetpack and bbPress plugins. Remove them from the repository, and add them as external references instead:

cd public_html/wp-content/
svn rm plugins/bbpress plugins/jetpack
svn commit -m "Removing bbPress and Jetpack from the repository"
svn propedit svn:externals plugins

Akismet is already an external reference, so let’s just add the two new ones:

akismet http://plugins.svn.wordpress.org/akismet/tags/2.5.6/
jetpack http://plugins.svn.wordpress.org/jetpack/tags/1.7/
bbpress http://plugins.svn.wordpress.org/bbpress/tags/2.1.2/

Now run svn update and Subversion will pull in the Jetpack and bbPress plugins for you, directly from the WordPress.org repository. If you’re wondering where I got those URLs, browse to any plugin on WordPress.org and click the Developers tab. You’ll see an svn link to the current version.

Themes as Subversion Externals

You can do the exact same thing with WordPress themes, which are hosted in the WordPress.org repository, such as Twenty Ten and Twenty Eleven:

cd public_html/wp-content
svn rm themes/twentyten themes/twentyeleven
svn commit -m "Removing Twenty Ten and Twenty Eleven from repo."
svn propedit svn:externals themes

Now add the references to Twenty Ten and Twenty Eleven, like so:

twentyten http://themes.svn.wordpress.org/twentyten/1.4/
twentyeleven http://themes.svn.wordpress.org/twentyeleven/1.4/

You’ll find the link to the Subversion repository in the Developers tab of any theme on WordPress.org. Make sure you pick the latest stable version, by comparing the version numbers in the repository, to the version number displayed on the theme page. It is not always the last one, since themes go through a review process, and some versions might not be approved, but still listed in Subversion.

Now, when you run svn update from your wp-content directory, you’ll see that Subversion will pull the external references for your themes and plugins. There! You no longer have to maintain themes and plugins from WordPress.org, in your repository! Just svn update every once in a while ;)

WordPress as a Subversion External

You won’t be surprised that, since WordPress is also hosted in a public Subversion repository, it can be an external too! It’s slightly more tricky than with themes and plugins, but definitely handy. In this particular case, the external reference needs a folder of their own (otherwise you’d have to list all core files as externals), so your working directory has to look somehow like the following:

  - wp
  - wp-content
    - themes
    - plugins

This means that you’ll have to setup WordPress in a subdirectory, and move your wp-content directory outside of WordPress core (though as an external, WordPress will still have one of its own).

Now, let’s remove the wp directory and place it as an external reference to our public_html folder instead:

cd public_html
svn rm wp
svn commit -m "Removing WordPress from repo."
svn propedit svn:externals .

Note the dot at the end of the call to propedit, meaning we want to edit the property for the current directory. Then, in the text editor, let’s add our reference:

wp http://core.svn.wordpress.org/tags/3.4.2/

After saving and quitting your text editor, run svn update from the root of your repository, and you’ll see that Subversion will grab the WordPress core, and your themes and plugins references. Neat!

Whenever you need to upgrade WordPress, you’ll just change the reference to point to the new version, and update again. You don’t need to delete the files every time you update an external reference, Subversion will do it for you. Also, when updating WordPress, don’t forget to visit the admin page, in case there are updates to the WordPress database.

At this point, you should no longer be maintaining WordPress themes, plugins or even WordPress itself in your own Subversion repository. Let WordPress.org do the work for you, while you focus mainly on your own code. I mentioned in an earlier blog post, that you can use GitHub projects as subversion externals too, which is pretty awesome.

If you’d like to learn more about Subversion externals, visit this page.

So what about you? Are you using version control for your WordPress projects? Do you prefer Git or Subversion? Do you currently use, or plan to use external references? Please share your thougts via comments, and thank you so much for stopping by!

Installing WordPress with MAMP on Mac OS X

This is an absolute beginners tutorial on how to get yourself a local WordPress development environment set up on your Mac OS X with MAMP. Step by step (and with screenshots,) we’ll go through each part of the process — downloading and installing MAMP, basic MAMP configuration, creating a MySQL user and database, getting WordPress up and running, and in the end I’ll share some tips you might find useful in your WordPress journey.

Continue reading

How To: Add Taxonomies to Your Custom Post Types in WordPress

Custom Post Types are not new to WordPress, they’ve been around since version 3.0 and have really changed the “WordPress as a CMS” game ever since. Custom taxonomies though, have been around even earlier and are used to group your posts and custom post types.

This post will give you a short insight on taxonomies in WordPress and show you how to add different taxonomies to different post types without having to alter any of the core or third party plugins and themes code.

Continue reading

Generating Easy To Remember Yet Secure Passwords

I had some Twitter conversations about passwords lately, and long and boring discussions with my friends and co-workers. It turns out that no matter how many security articles and books are published about passwords, people tend to follow a very, very insecure method of picking them up and memorizing them. In this post I’ll try to demonstrate a brand new theory (or maybe not so new) of creating and memorizing secure passwords.

There are so many websites out there in the web asking you to provide a password. Some of them follow security conventions, others don’t. If you’re subscribed to at least 30 or 40 resources, social networks and desktop applications, there’s literally no way you could remember all those passwords unless (or the top 5 mistakes while choosing a new password):

  • You’re using a dictionary word
  • You’re using the same password over and over
  • You’re using a sequence of characters (12345, qwerty, abcdef, abc123, etc.)
  • You’re using your own name, your dog’s name or your girlfriend’s name
  • You’re using a password that matches your login

There are many articles out there that help you pick a strong password, but as I said, there’s literally no way of memorizing them all, unless you’re some genius of course. This is why people tend to use good passwords and store them in special applications called password managers, designed to store your passwords like 1Password, Keepass, Lastpass, Google Docs, a text file on your computer, or a sheet of paper on your desk ;)

There are several problems with this approach: you’re storing all your passwords in one place, your passwords are not portable, your passwords are written down! My number one rule is never write down your password, never! No notepads, no software and especially no sheet on your desk — that’s the worst thing you could do.

So how do you keep all those 30, 40 or maybe a hundred passwords in your mind? The simple answer is — you don’t.

The Password Theory

Right. What I’ll be trying to teach you here is how to create a password theory of your own. One that lives in your brain, and one that only you know. Then that theory will become the only thing you have to memorize, and it will create strong, secure and uncrackable passwords.

This may sound a little difficult, but relax. Remembering 40 different passwords is way more difficult than remembering and applying one theory.

I’ll show you how to create a very simple theory in this post, but you shouldn’t use it (obviously) — create your own and stick to it. Besides, a theory created by yourself will be much easier to memorize. So let’s begin, and our brand new theory will be called K3. Try guessing where the name came from.

Example: The K3 Theory

I’ll first give you the theory itself, then explain the details of what each step does and finally give you implementation examples with Twitter and Facebook and Last.fm:

  1. Lowercase the name of the service and remove any symbols
  2. Grab the first two letters and uppercase the second one
  3. Attach a lowercase k and the number of symbols in the service name to the left of the result
  4. Attach an uppercase J and the number of symbols divided by two (with no remainder) to the end
  5. Grab the last two letters of the service name, increase the second one by one and uppercase it, split them with the number 3 in the middle, attach to the end of the result
  6. Add 3, 6, 9, 12 to the end if the password length is too small

Suppose we’re creating a password for MyService, during the first step we’re left with myservice, second step gives us mY and the third step is quite straightforward too: k9mY (there are 9 symbols in the name MyService). During step four you’re grabbing a J together with a 4 (9 divided by 2 will be 4.5, strip the remainder), so you’re now left with k9mYJ4. At step five you’re taking “ce” and increasing the second letter by one, so “e” becomes “f”, then uppercase, so you’ve got “cF” split them with the number 3 — “c3F” and attach to the result: k9mYJ4c3F.

The last step is optional, depending on whether the service you’re subscribing to asks you for a minimum of 7, 8, 10 or maybe 15 symbols in your password. So for instance, if we’re asked for a minimum of 10 symbols, our final password is k9mYJ4c3F3, if we’re asked for 15 — k9mYJ4c3F3691215 (see the sequence of 3, 6, 9, 12, 15).

Let’s assume our original length is fine, our final password is k9mYJ4c3F which gives you an 84% strength on The Password Meter which is quite good. It contains lowercase and uppercase letters, numbers, and is 9 characters long.

After finalizing a theory, you’ll start noticing that some points might be combined, others could be moved around, for instance, it might be easier to start with step number 3 and then continuing with 1 and 2. You’ll get used to it in a couple of months and once you will, believe me — you’ll be the the true password monkey ;)

Practice: Twitter, Facebook & Last.fm

Hope the whole theory made sense to you. To make sure it did, here are three passwords generated for Twitter, Facebook and Last.fm in random order. Try guessing which one belongs to which service: k6lAJ3f3N, k8fAJ4o3L and k7tWJ3e3S — all of them rank 83-84% on the password meter.

For more practice try generating passwords for Delicious, Yahoo, Google, Quora and some service of your own. Try playing around with the password length too and check your results on the meter.

Ideas for Your Own Theory

If you made it until here, great! If not, go ahead and keep using your “qwerty” passwords ;) Anyways, below is a list of my thoughts that can be used in your password theories, but please do keep it simple until you become the guru:

  • Try incrementing a character by two in some spots, i.e. A becomes C, X becomes Z, and Z becomes B
  • Add a few symbols of your choice if the service allows you to
  • Add some extra math, Fibonacci perhaps?
  • Increment the whole word by two at the end, i.e. ABC123 becomes CDE345
  • Spice it up with some non-ASCII characters if the service allows you to (e.g. ©)
  • When incrementing use the ASCII table instead of the alphabet, e.g. uppercase X + 4 becomes a backslash (for gurus only)

Once you create your theory you’ll need time to practice it out, and yes, you can do this on paper, but make sure nobody’s watching, and eat them up once you’re done calculating.

Also, some of you might think that these types of passwords are not that safe, and that passwords should contain some random characters and numbers, but hey, at least this is something memorable and it’s certainly better than dictionary words, same passwords everywhere and “12345” ;)

That’s it! Share your thoughts in the comments, but don’t disclose your theories ;)

Powered by Delicious: Web Design, Coding & HTML5

This is my first “Powered by Delicious” post, but I plan on writing similar posts at least once a month or so, depending how many links I bookmark. Here’s a list of some of my latest delicious bookmarks, with goodies on web design, coding, html5, photoshop, javascript and a bunch of other stuff.

Threaded Comments in WordPress 2.7

This was pretty quick and easy, really, you don’t even have to do much code, it’s more about styling the nested comments. First of all you have to switch them on in Settings – Discussion, then some slight theme modifications in header.php and the comments.php section. I don’t want to write about them here because it’s already written in the WordPress codex over here: Enhanced Comment Display.

Make sure you don’t skip the javascript modifications section, though I managed to get threded comments without it, but javascript makes it alive. It’s the code that is responsible for putting the reply form just below the comment you want to reply to on the fly, i.e. without having to reload and render a new page.

Now use Firebug to create and modify CSS on the comments page – just use your imagination and make it look good. The issues I had are:

  • The textarea box was ~700px wide and it overlayed my sidebar when I tried to reply to someone. Changed that to 100% – looks good now
  • The comments and replies are actually different elements. The comments are OL (ordered list) and the replies are UL (unordered list). The UL with the classname ‘children’ should have the margin-left, don’t mess that up.
  • Threded comments can be lost without borders. I don’t really like how they look in the default theme, but my variant is a little bit of padding-left and border-left for the UL/OL commentlist/children LI elements.
  • The ‘Reply’ anchor is not part of the comment and is not within the P tags, so I had to margin-left that separately.
  • The comment form in a reply needs a margin-left, but doesn’t when you’re starting the thread. You can use something similar to this (.comment indicates that it’s a reply and #respond is the actual form):
    .comment #respond { margin-left: 42px; }

I guess that’s it. Questions and suggestions are welcome in the comments.