We will be meeting Thursday, April 26, 2012 at the Nerdery for our 21st MSP WordPress gathering!  Show up at 6:30 for mingling and pizza and pop.

Plugins In Your Theme

If you customize the functions.php file of your themes, you’re already building plugins! Many tutorials will advise you to take a snippet of code and paste it into your theme’s functions.php, this isn’t really any different than making a plugin, and often times, this code should be a separate plugin.

It’s all too common for themes to try to substitute for plugins and add custom post types, taxonomies, or shortcodes to a site, but what happens when you switch themes? That content disappears.

What’s a theme? What’s a plugin?

A plugin could change the design of a site as easily as a theme, and any plugin could be crammed into a theme. But really a theme should only be managing the presentation of a site’s content, any new types of content or functionality should be enabled using plugins.

What should be in the theme’s functions.php?

Code to enable built-in WordPress functionality, like custom backgrounds and post thumbnails, sidebar registration, or a theme options page. This would be a good place to customize excerpts or enqueue scripts that are needed by the theme.

Don’t ever edit an existing theme, if you edit a theme in the official directory like Twenty Eleven and then update that theme, you will lose your changes. Instead fork the theme by changing the name to make it unique, or create a child theme for it so that you can safely update the parent theme.

What should be in a plugin?

Any functionality that you want to keep around regardless of which theme you are using. Some themes might not support the custom post types and taxonomies you are using without extra templates or styling, but that content should never disappear from the admin, and if you use a plugin it won’t!

Another thing to consider is how modular the functionality is, if you find yourself adding the same widget to themes again and again, it’s a great candidate for a plugin!

Site specific plugins

One good way to transition from using the function.php file to building plugins is a site specific plugin that acts as a standalone functions file you can use to add functionality specific to that site like a custom taxonomy for blog posts.

There’s a great post on WPCandy which explains why you might want a functionality plugin and how to build one.

General purpose plugins

A good place to start learning how to actually make a plugin is the codex article on writing a plugin. It can be a bit overwhelming at first, but don’t get discouraged. A polished plugin you release to the world might have some extra information and comments, but a simple plugin for your own use could be just a few lines.

I’d suggest watching some videos on building basic plugins. After watching a few and learning how different people are making them the learning curve won’t feel so steep!

When you start building plugins, you’ll start running into a few things that don’t come up very often in theme development, like hooks, actions, filters. Learning how these are used in the plugin API is essential and will save you a lot of headaches!

Another important detail is to prefix everything. You want to make sure that the functions, variables, the rest of the code you write is uniquely named so that it doesn’t conflict with code in WordPress, your theme, or other plugins. It also doesn’t hurt to clearly name everything so that you know what it is for, after all, this isn’t Twitter, there’s no character limit!

Translating your plugin

Supporting translations of your plugin is a good way to improve the usability for non-English speakers and build an international audience for your plugin. The documentation has plenty of information on this topic, but it’s not the most user friendly introduction, try using this tutorial instead.

Basically any text you want to translate needs to be wrapped in a function, the two most common ones are “__” and “_e”. Use the “__” function for returning text to be used in PHP, and the “_e” function for echoing text to output in HTML. In the example I showed the strings being translated were labels for a taxonomy, so it was all being returned rather than echoed.

Notice that in the example the functions contain not just the string to be translated, but also the basename of the plugin. This tells WordPress that the translation files for that string is located in that particular plugin after you have loaded that basename as the plugin domain. Just remember, don’t get clever when adding the basename. The PHP files need to be parsed by GNU gettext to generate the translation file, so don’t try to take shortcuts with variables.

You could download GNU gettext and try to generate a translation file on your own, but there are some easier options. If your plugin is in the repository you can generate this file right from the plugin admin. If the plugin isn’t in the repository, you can checkout the tools from SVN or use poEdit to generate this file.

Once your plugin is ready for translation, I recommend making it easy for translators to find the translation files and get their translation back to you. I have a languages page in the documentation of my plugin with translator credits and info for new translators.

Learn!

I forgot to mention my favorite WordPress book during the meeting, Professional WordPress Plugin Development. The first couple of chapters really help build a good foundation for starting a plugin. The rest of the book goes deep into different details of plugin development and I have found it handy to reference specific chapters as I need them.

If you have any questions, leave a comment and I’ll try to point you in the right direction. Now get coding, I’m looking forward to seeing the member plugins list grow!

A couple of snapshots from the meeting

Coda 1.7.5 – Demo by Tom Penney
http://panic.com/coda/
$99 for Mac OS only
* Subversion integration for version control. Git in the next version.
* “Everything you need in one window”
* Neat feature: Invite other Coda users to collaboratively edit files.
* Only works with Safari webkit browser in the one window.

There is a WordPress plug-in available…
http://hitchhackerguide.com/2011/02/18/wordpress-syntax-mode-for-panic-coda/
1. Download the packed mode file and unpack it.
2. Copy the PHP-HTML-WP.mode the Coda Modes folder. ~/Library/Application Support/Coda/Modes/
3. Open a WordPress or PHP file and load the syntax mode in Coda by visiting Text -> Syntax Mode -> PHP-HTML-WP in the toolbar.
4. Optional: To make this mode the default visit the Editor pane in the Preferences window and select the ‘PHP-HTML-WP’ mode as default file type

Aptana Studio 3 – Demo by John Havlik
http://aptana.com/
* FREE, Open Source IDE based on Eclipse for Mac or Windows
* Git integration for version control githubfirst
* More web focused than Eclipse. Built for Javascript, CSS, php, and html.
* Plugins available for jQuery, WordPress, and CSS tool tips.

Guest Author:
Tim Cimbura, www.cimbura.com
Helping businesses become more effective, productive, and profitable through custom iPad/iPhone applications, FileMaker app solutions, and web site design.

There has been a lot of discussion on the group recently about what software and workflows WordPress pros are using to build sites these days.

Two of our pros-in-residence, John Havlik and Tom Penney, will show us how they use Coda and Aptana, respectively to rock their workflow.  …And I’ll just address the elephant in the room right now – Doesn’t anyone use Dreamweaver anymore???  ;)

We will also continue our discussion on Trackbacks & Pingbacks and close out the evening with an info-session about the Overnight Website Challenge.

We will follow that up with a Tech Shoppe and a discussion of our soon-to-be announced (and planned) WINTER EXTRAVAGANZA!!!

What: Minneapolis-St. Paul WordPress User Group Meeting
When: Thursday, September 21, 2011 at 7 p.m. (Doors and pizza at 6:30)
Session Topic: WordPress Multi-Site, Tech Shoppe, Winter Event Discussion
Where: The Nerdery, 9555 James Ave S Suite 245 Bloomington, MN 55431
Cost: Free! (Please bring a friend!)

See you tomorrow!
Toby

We will follow up Dave’s session with a roundtable on fun and useful plugins we all use (thanks, Susie!).

Finally, we will have a short organizing meeting for the yet-to-be-named local WordPress event this winter. Who knows, maybe we will call it “WordCamp”.

What: Minneapolis-St. Paul WordPress User Group Meeting
When: Thursday, September 21, 2011 at 7 p.m. (Doors and pizza at 6:30)
Session Topic: The Current State of SEO; Fun with Plugins
Where: The Nerdery, 9555 James Ave S Suite 245 Bloomington, MN 55431
Cost: Free! (Please bring a friend!)

See you tomorrow!
Toby

We will be holding our 17th WordPress gathering tomorrow night at The Nerdery.

The first part of the show will be Matt Mullenweg’s “State of the Word” address from WordCamp San Francisco.  We will follow that up with a discussion about the current state of the WordPress community locally as well where you think WordPress is heading.

What else is on your mind?

What: Minneapolis-St. Paul WordPress User Group Meeting
When: Thursday, August 25, 2011 at 7 p.m. (Doors and pizza at 6:30)
Session Topic: 2011 “State of the Word” Address
Where:  The Nerdery, 9555 James Ave S Suite 245 Bloomington, MN 55431
Cost: Free! (Please bring a friend!)

See you tomorrow!
Toby

Click here to see the agenda.