One of the biggest changes we made was an overhaul of the Broadcasting screen. Here is the “before” version:

This worked OK, but you can see a few problems:

• You can’t send different messages to different accounts on the same service. This was something I wanted to be able to do, to have different voicing on @alexkingorg and @crowdfavorite.
• Facebook pages aren’t visible by default.
• The character counter limit indicator is too far away from the textarea it is reflecting.

So we worked on some different approaches. These are pretty close to what we shipped in version 2.5:

And here is the version that shipped:

We also made some significant UI changes to the way accounts are managed on the admin side. Here is the “before” version.

Again, functional but can be improved. In particular I wanted to consolidate this into a single list rather than having one place to add/remove accounts and a separate place to indicate the default accounts. Also, you can see the problem (again) of pages not being shown by default.

This concept allowed the two lists to be combined into one:

And what we shipped was pretty darn close to that:

In addition to making the admin screens more compact, this design also makes it easier to support more services in the future (Google+, etc.).

So there you have it, a little “behind the scenes” fun. I definitely recommend incorporating sketching and wireframing into your design process, it’s been a huge help for us as we brainstorm, discuss ideas, etc.

Here are the high level bullet points:

• easily connect your Twitter and Facebook accounts (no need to create apps through their developer sites and copy keys around – this feature enabled directly by MailChimp)
• allow any other authors on your site to broadcast their own accounts, as well as to any global accounts for the site
• broadcast your posts to Twitter and Facebook (with customized messages for each account)
• pull social reactions on Twitter and Facebook back in to your site as comments (this could be liking or retweeting your broadcast, replying with a comment, or just tweeting a link to your post)
• ability to reply to these social reactions from your WordPress site and send them back to the appropriate social network (keep the conversation going)
• your site visitors can authenticate with their Twitter or Facebook accounts when commenting (and they can optionally post their comment back to their social networks)

Pretty good feature list, right? Social also has a couple of great collateral features. When used in conjunction with the “users must be logged in to comment” feature of WordPress, you can choose to require your commentors to attach a more meaningful (and verified) identity with their comments. Removing anonymous noise from the mix always raises the level of debate.

Social also allows your site to be the place for your content. You can bring in conversations from both Facebook and Twitter back to your site, while still participating in the conversations on those social networks. Engage with people where they want to engage, but do so while providing a richer cross-network experience on your own site.

That’s Social in a nutshell. Which brings us to the “what’s new in this version” list. I did most of the coding on this release so I’m hardly unbiased, but I’m pretty darn pleased with the way this version has shaped up. I’ve been using development builds on this site for a bit now, and I really like the way the new features have removed that last little bit of friction from some of my more common interactions.

Before we launch into what’s new, I’d like to take a moment to point out that Social is built entirely in the open on GitHub. Developers, please send us awesome pull requests.

Facebook Improvements

I think some of the best changes in this version are in the improvements to interactions with Facebook. By default, when a post is broadcast it is sent as a link rather than a status post; regardless of if it has a featured image or not. The obvious exception here is for posts that have a status post format – those are still sent as status posts. To try to make this interaction clear, we show a nice preview of how the post will look on Facebook on the broadcast screen.

When comments are broadcast to Facebook, we try to do the Right Thing with it. There are two options:

1. The comment is replying to an existing comment thread and we should post it back to the same thread in Facebook. If this is the case, we try to do so. If for some reason (permissions, etc.) we aren’t able to do so, then we fall back on option 2…
2. Post the comment with a link to the post to the commentor’s timeline. It makes more sense. Their comment is on the link, and the link is posted right along with it. This should make the posts going back to Facebook more meaningful.

We also take the step of auto-selecting the “Post to Facebook” checkbox under the following conditions:

• The (admin/author) user has a Facebook profile attached to their account.
• The comment they have clicked “reply” was imported from (or was broadcast to) Facebook.

Social does this all for you – just hit reply, type your message and send. This feature is important to keep the conversation running easily on both Facebook and your WordPress site.

Twitter Improvements

Twitter integration got some nice improvements in this version as well. You were previously able to import tweets as comment directly by URL, but now you can do this from the front-end as well. Use the menu we add in the admin bar under the Comments item to bring in tweets directly (and look for social comments). This is really useful for bringing in replies to replies or other tweets that are part of the conversation, but not something that Social will pick up by default. Note that you have to be on a single post (permalink) view for this to be available.

One of the use cases that I think makes Social really interesting is the way it allows your WordPress site to interact with real-time happenings on Twitter. Did someone tweet something that prompted you to write a blog post? You can send your broadcast tweet as a reply to that user.

Tip: Make sure to include their @username in the tweet so that they see it as you expect.

We also improved the Twitter comment detection to auto-select the account that a tweet was directed to when replying to an imported comment. Huh? Basically, if @someoneelse sends a tweet to @yourusername and Social brings that in as a comment, Social will also select your @yourusername and check the “post to Twitter” box when you hit the Reply link for that comment. It also inserts @someoneelse into the comment box so that you can start writing your reply.

The last significant change we made is to widen the net a little and catch specific types of Twitter replies, then import them as comments. The scenario is basically this:

1. You broadcast a post.
2. Someone replies to your post, this is imported as a comment on your site.
3. You reply to that comment on your site, and broadcast it back to Twitter.
4. The other person (or multiple people) reply to that comment.

Previously we would have missed automatically importing the replies in step 4 above. Now we catch them.

We walk a fine line with the amount of content we try to find and import. In particular we want to make sure we don’t set up rules that allow Social to use up all of your API requests checking for comments on your broadcasts. However, we do want to bring in as many relevant reactions as we can. We were able to make this change without requiring an additional API hit. We are able to look for additional data in the API requests we were already making.

General Improvements

You can now send customized broadcasts to each account in a single action – each account has its own form that you can edit. By default, the first broadcast message for each service (Facebook, Twitter) is editable while any others are in “copycat” mode. They will all be updated along with the edits to the first message unless you click the Edit link for the ones you want to customize. We think this is a good compromise between convenience and control, and hope you like how it works.

The account management forms have been streamlined and cleaned up, on both the main Social settings screen and the user profile screen. For example, Facebook pages are always displayed so they can be selected, etc. We also consolidated the selection of “default” accounts into the main accounts list. We hope this makes these pages easier to understand and use.

Some of you have post broadcasts that get a ton of Likes and Retweets. These are cool to see in the (condensed view in the) comments list, but not as meaningful in the comments RSS/Atom feeds that WordPress generates. We’ve added some code to suppress these types of “meta” comments in the feeds.

When you have lots of comments, they come with a lot of in-page image requests. This can cause your site to load more slowly than you’d like, so we implemented support for the Lazy Load plugin. Install and enable this plugin, and the avatars for your Social comments only load when scrolled into view.

Social now functions as a platform for other social WordPress plugins. You can choose to disable any features that you don’t want on your site and just use the connections to social networks. Expect a new release of Twitter Tools, built on Social, very soon.

Of course we also fixed all of the bugs we were able to reproduce. This includes making Facebook comment importing more consistent, along with a number of other fixes and improvements.

A quick word about Google+ integration (by far the most requested feature – tracked here). It’s something we want to do and plan to do, but until Google+ has a write API we can’t attain feature parity with our Facebook and Twitter integrations. My guess? We’ll see a Google+ API featured next month at Google I/O.

Want to build cool WordPress integrations like this? We’re hiring.

Social is a plugin that allows you to maintain a centralized conversation on your site, while also participating in conversations on Facebook and Twitter.

Congratulations to Brad on today’s launch of WP App Store. I’m very pleased to see this come to life. It’s an idea we toyed around with several years ago, but decided not to pull the trigger on – I hope it’s a huge success.

We’ve put our FavePersonal and FaveBusiness themes along with our RAMP plugin into the app store. If you’d like to check it out, download the plugin and start browsing. There is a great group of companies represented already and I’m sure we’ll see more additions as the project grows.

As the version number indicates, this release is primarily to deliver a few bug fixes. Here is a quick overview of the significant changes:

• improved compatibility with changes introduced in WordPress 3.3
• properly handle entirely numeric category and tags names
• improved support for hierarchical taxonomies
• misc. cleanup of PHP notices (when the WordPress DEBUG setting is enabled)
• minimum required WordPress version is now 3.3

For a little more detail about just what this product is all about, check out my original post announcing RAMP.

While I’m glad a new version is out to address the vulnerability, I think it was a mistake to release any information about the nature of the exploit today (the same day that the fix is available). I would have favored:

1. Release the new version with the explanation that this fixes a security vulnerability and everyone should upgrade right away.
2. Wait for a week to allow your customers time to upgrade.
3. Then release the details of the exploit.

As a customer, I’m surprised I haven’t (as of this writing) received a notification warning me of the vulnerability and urging me to upgrade.¹ I believe it’s the responsibility of a software provider to reach out to their customers to warn them about security issues before disclosing the details of them publicly.

Cart66 has already generally disclosed what the vulnerability is, but they didn’t go into much detail about how it could be exploited. The “black hat” folks will likely figure it out anyway, but I’m going to hold off sharing any details of it until next week. I think it is appropriate to outline how this can be exploited to help provide some context to Cart66 customers, but I don’t want to be the one making it more likely that people will exploit the vulnerability on their sites.

While I am generally willing to take the explanation of how this vulnerability was allowed to remain unaddressed for such a long time at face value, I also believe this shows a fundamental lack of emphasis on security throughout the Cart66 organization. Someone received my email, replied that this was already a known problem, then nothing happend. Who knows, perhaps the people involved with that response aren’t even with the company anymore, but I’m pretty darn sure that this wouldn’t happen in my shop. A security vulnerability is a “Drop everything, get it patched and get a new release out. NOW!” situation. I will take them at their word that they are working to address this internally, but I’m still not comfortable with what their response (or lack thereof) says about their culture.

If I were advising the Cart66 team, I would tell them they need to take additional steps to make it clear to their customers that they are taking security seriously. I would recommend hiring Mark Jaquith (or another reputable consultant or firm) to do a full security audit of their code and product architecture.

I would also create and publish a process by which developers can responsibly submit security concerns, patches, etc. This should be easy to find on the Cart66 website.

Lastly, I would establish the process by which security issues are communicated to customers (a mailing list, or similar). In the case of responsibly disclosed vulnerabilities, this should include giving customers reasonable time to upgrade before publishing any details of an exploit.

All software has bugs, and some of these bugs have security ramifications. How you deal with them (and how you work with your customers when they are found) is what builds or destroys your reputation.

Last summer we were working on an e-commerce site that integrated Cart66 with WordPress. As part of the development effort there, my team at Crowd Favorite discovered a vulnerability in Cart66.

We reported this to the Cart 66 team on July 11, 2011 and received the following response on July 12, 2011:

Alex,
We are aware of this issue and are working on a solution. I dont have a date for the fix but we’ll keep you posted.

Last week (on April 10, 2012) I received the following email:

Hello Alex,

We haven’t heard from you in 3 or more weeks so we are going to go ahead and solve this ticket. Do not hesitate to reply if you have any further questions.

My guess is that this is an automated email generated by their ticket system, but it reminded me I’d never properly followed up on the issue. We tested the current version of Cart66 (version 1.4.5) and the vulnerability is still present.

At WordCamp San Francisco last summer I posed a question during the Q&A session to get input from others on the best way to handle this situation. The agreed on course of action was to:

1. Responsibly disclose the issue privately to the developer.
2. Give the developer time to address the issue.
3. Go public with the information if the issue is not addressed (it’s more important to let the users of the software know about the issue than it is to extend any “security by obscurity”).

As such, we plan to release the details of this vulnerability in two weeks (on April 30th).

We sincerely hope that the Cart66 team will address the vulnerability with a release that fixes the issue before this time (and responsibly notify their customers of the issue and the importance of upgrading). However, given the overall lack of response we’ve seen from the Cart66 team on this issue, my recommendation would be to evaluate other e-commerce solutions.

While I’m mainly using the “out of the box” features of FavePersonal, I have applied a number of customizations to this site. A child theme is a great way to customize a theme and still be able to upgrade without losing your changes. For the customizations I’ll be sharing about FavePersonal, we need a very simple child theme – just a style.css file and a functions.php file.¹

One of the things I’m using my child theme for is to streamline the HTML I deliver for my pages. I haven’t changed the colors for this site in nearly 10 years, so it’s safe to say I’m not planning to tinker with them much going forward. Since I don’t need the flexibility of being able to swap out the colors, I moved the CSS rules for the colors out of the HTML and into my child theme.

The first thing you’ll want to do is download the style.css file from your Theme Settings page. (Don’t have FavePersonal yet? Check out the online demo.) This gives us our colors, so now we just need to remove the CSS from the HTML.

In the functions.php file in your child theme, you’ll want to add the following code to remove the output of the CSS rules from being added to your HTML.

View the code on Gist.

Now you can activate your child theme and your site should look just the same, but load a touch faster (and give you a nice place to make future customizations).

Another little change I made in my child theme is to add actual underlines (gasp) to links. I don’t think I’ve met a designer in the last five years who still uses underlines in their designs, but I’m old school , I like underlines on my links. I think it helps them stand out better. However I do agree that underlines clutter up areas where things are expected to be clickable (navigation menus, lists, etc.), so I’m just adding the underlines to links in the content area of the site.

Want to underline the links in your FavePersonal site as well? Grab this CSS snippet and paste it into the style.css for your child theme.

View the code on Gist.

And there you go – a few simple customizations for your FavePersonal child theme.

We’ve made it easy to experiment with different colors and find a set that makes your site feel like it’s your own. No need to fiddle through dozens of color pickers, you can choose from full color palettes, preview them, and instantly apply them to your site.

You can browse through existing color combinations to find some initial inspiration. Use the tabs at the top (and the pagination links at the bottom) to navigate through the most popular, highest rated and newest palettes, or just look at a random set. Not seeing anything that grabs you? Try a search. For example, “desert rose” will bring back just what you might expect.

Whenever you see a palette you think looks interesting, just click the Preview button to see how it might look applied to FavePersonal. If you like what you see, you can Select it to move that palette to the selected colors area at the top of the screen. From there, just hit Save Changes, and the color palette will be applied to your site.

But maybe you’ve found a color palette that is almost right, but you want to tweak it a little bit. No problem. Once the palette is selected (shown at the top of the colors screen) you can customize it however you like.

The first thing you may want to experiment with is how the colors are applied to different areas of the FavePersonal theme. FavePersonal takes the color from each of the five positions and puts it into a specific areas in the site. This is done in a way that should provide an appropriate amount of contrast between different elements on the site (but you’ll see that some themes work better than others). By clicking and dragging on the colors to re-order them, you can have them applied to different areas of your site. Click the Preview button to see how things look after moving them around.

When you have the colors applied to the areas of the site in a way that you like, you might want to apply a few tweaks (or maybe you have an explicit color scheme you want to enter). No problem. Click on each of the colors to reveal a full color picker where you can make minor adjustments (I want a darker or lighter share of blue here) or just choose another color altogether. Then click Preview to get an idea how it might look, and Save Changes to apply it to your site.

Have you come up with an original color combination that you love? Add it to Adobe Kuler and you’ll be able to re-apply it to your site easily by using the search feature (you can search for your username or the name of your palette).

I think we’ve succeeded in providing a good way for folks to choose good looking color schemes without “needing to be a designer”, while also providing the fine grain control that other folks (like me) want for their site.

While we were creating FavePersonal it was fun to see our team experimenting with the Colors feature and really getting sucked in to it – it’s a great way to lose spend a few hours.

Don’t take my word for it though, go try it out for yourself with our online demo (click the Theme Admin button to log in).

I think it was two or three years ago that I first had the idea for using color palettes with a theme in this way. I was pretty sure it would work, but hadn’t really seen it done in the manner I was imagining. I started doing some prototyping and ran into a snag.

In order to apply a color palette to a design with (generally) positive results, you need to be able to reasonably predict the colors that will have contrast between them. When looking at color palettes from a number of sources, I found that they came through without any particular ordering of the colors.

Step one became coming up with an algorithm that would work to get the colors sorted in a reasonable fashion. This is not a trivial problem, but interestingly the more complex we attempted to make the solution, the worse things got. Eventually, after running a few different approaches against a test set of color palettes, the most simple and naive approach seemed to yield the best results.

Basically I took the numeric value of the first digit of the RGB values from the hex color, add them together to get a total numeric value for each color, then sort the colors by that value.

View the code on Gist.

I think this could be refined a little further, perhaps adding a slight bias towards blue or green over red in order to better handle cases where you might prefer certain colors that are close in “brightness” to be considered “darker” than others.¹ For FavePersonal I decided that it was better to handle this by allowing people to drag and drop to re-arrange the colors in the palette instead.

We’ve released the colors feature we created for FavePersonal on Github. It’s a designer/developer tool as it’s not something that works as a stand-alone plugin, but it works quite nicely when integrated as a feature of a theme.

The features for FavePersonal were driven by my goals for version three of this site. I wanted the site to be personal, be a great showcase for my content and to integrate with my other social interactions online.

Personal

One of the features I know people will enjoy playing with is the Colors feature. Instead of fiddling with lots of different color pickers, you can select from thousands of existing color palettes (via Adobe Kuler integration) and instantly preview and apply the scheme to your site.

The header options and bio widget features were created to help tell the “this is who I am, and what this site is” story. Most visitors arrive on an internal site page via search engine or direct link. These features serve to provide some context about both you, and your site.

All Kinds of Post Content

With FavePersonal we have integrated our post formats admin UI functionality to make it easy to post photos, galleries, videos, etc. Each of these types of content is elegantly managed and delivered, from the back-end admin interface all the way through to customized layouts appropriate for each type of content, and formatted elegantly for mobile devices (even extending to your RSS feeds).

See some examples on this site:

• Status posts
• Link posts
• Photo posts
• Gallery posts (be sure to check out a gallery post)
• Video posts

Social

If my site is going to represent me on the web, it’s not telling a complete story if it ignores my participation on other social networks. FavePersonal tightly integrates with (and includes) the Social plugin to create a two way integration between your website, Twitter and Facebook. You can post status updates on your site then pass them on to your Twitter and Facebook accounts. Social will bring retweets, likes and reactions from those sites back to your site as comments.

Additionally, your visitors can log in with their social profiles when they comment directly on your site.

Mobile-Friendly

FavePersonal was designed from the ground up to be responsive. Not only does it look great on your computer, but also on your phone and tablet device.

Are you on a mobile browser now? Check out the online demo and see how it works. Be sure to rotate and see how it adapts to portait and landscape orientations.

Of course it is optimized for fast page loads and also features clean HTML5 markup that is both human and machine (SEO) friendly.

This is just a very brief sampling of what we’ve put into FavePersonal. We’ve been working on this theme for over a year.¹ We’ve given every feature a ton of thought, debate, tweaking, building, throwing away, re-building and testing to get things the way we want them. I’ve been told I can be a bit particular , which is a kind way of saying I’m a pain in the arse and we’ll re-design things as many times as it takes to get it right. My team has been very patient with me, coming up with great ideas and solutions and building them in elegant ways. We’ve built deep features on solid foundations that won’t break or surprise you as you lean on them and come to rely on them.

I’m going to be following up with a series of posts that go into more detail about the various features of FavePersonal, discussing some of the design decisions we made, and sharing customizations I’ve put into my own child theme. I’ll also point to some of the code we’ve released on our GitHub account for anyone who would be interested. I’ve got a pretty good sized list.

When I started using FavePersonal in August of last year (2011) it became the third version of this site since it launched in 2002 (check out original version from 2002 and the previous version from 2006). With each iteration I always received a number of “is your theme available?” inquiries. In the past, my themes have always been built with too many content assumptions, etc. for me to effectively share it, but I made sure we didn’t do that with FavePersonal.

Check out the FavePersonal page on the Crowd Favorite website to see our feature videos, try out online demo and purchase (our new store² supports PayPal as well as credit cards).

I hope you like it as much as I do!

So when I saw chatter about it last night, I went ahead and purchased right away. I don’t use GMail, but that shouldn’t be a problem since it has:

Full IMAP support:
Use your Gmail, Google Apps, iCloud, Yahoo, AOL, Mobile Me and custom IMAP accounts.

When I launched the app, this is what I saw:

Ok, that’s not what I need. I need a way to enter in my IMAP server and account details. But this isn’t too uncommon with a mail app. I’ll just enter in my details and wait for it to fail, then it will show me an “advanced” button or something to let me enter the server settings directly.

Hmm, that’s not helpful. I’m not even trying to connect to Gmail.

I tried adding a Gmail account and going into the settings to see if I could adjust the mail server addresses manually from the account settings screen – no can do.

It appears that Sparrow’s only set-up path is to be clever and try to guess at what I need. Like most software with this approach, it fails in real world situations. It may be a great mobile mail app, but if I can’t get it to connect to my account it’s completely useless to me.

Sparrow isn’t the only app that fails like this. The WordPress for iOS app fails in the same way. I believe the WordPress app tries to load an HTML page and look for some specific information (the XMLRPC URL) that it needs for communication (perhaps with a few guesses as well).

If you have a WordPress site that requires a login, your results to add that site to the WordPress iOS app will likely look something like this:

“Need Help?”

No, I need a damn text field!

I’m quite capable of typing in the XMLRPC URL myself (like I’ve done for other apps that post to my WordPress site) and I have no problem with that being an extra, manual step since my WordPress site is a little non-standard. However, that’s not an option.

I grow weary of people holding up Apple as an ideal of simplicity, trying to follow that model, but failing to properly account for real world usage in their clever user friendly designs. When you place “simple” ahead of “functional”, you’ve failed.

The themes are being renamed:

• Carrington Blog is becoming FaveBlog
• Carrington Text is becoming FaveText
• Carrington Mobile is becoming, you guessed it, FaveMobile

We caused a bunch of confusion around the name “Carrington” when we attached it to everything. I’m hoping that removing it from the themes and having the “Carrington” name reserved for our underlying theme features (Carrington Core and Carrington Build) will help make it more clear that Carrington refers to our collection of developer and designer tools that make it easier to create great websites with WordPress. We’ve also initiated an internal project to create better designer/developer documentation for Carrington Core.

Updating the themes to the latest and greatest WordPress features and best practices is on the list for our intern projects and should be getting some attention in the immediate future. I’m optimistic we’ll have updated versions of these themes to release soon. I’m proud of our dedication to releasing code to the community, but once you hit a certain volume it becomes a real challenge to keep everything up to date.

At Crowd Favorite we write modular code (for example: lots of lean, targeted WordPress plugins instead of few complex plugins) for a number of reasons:

• it enables code reuse (DRY)
• smaller bits of code are easier to maintain, update, debug, etc.
• it’s easier to test smaller sets of features/functions

To support this approach we previously made extensive use of SVN externals in our projects. Often times active development would be happening on a specific project and within one or more of the externals within the project (to support a new feature, etc.).

With SVN externals, the included externals are automatically updated to the latest version on every update (unless you –exclude-submodules). If you follow a good trunk/branches/tags model within your externals, you can get away with this without too much trouble; you primarily point the external to the latest stable tag, but switch the pointer to trunk when active development is needed.

Like I said, it’s something you can get away with. That doesn’t mean there aren’t some challenges there. Primarily you can run into multiple people updating or needing to work on an external at the same time (and SVN doesn’t well support a branch-driven development model). You might be pulling in changes on each “svn up” that you don’t want.

With Git’s submodules, you can still bring in another codebase into your project but the mechanics of it are a bit different.

The submodule will be the entire Git repo

With SVN you can make your external point to a subdirectory of a project (this is how you’d choose trunk vs tags/1.0.2, etc.), with Git the submodule will always be the entire project. This means you’ll want to keep your code repositories lean and mean – you don’t want deep URL paths or a bunch of historical design documents and other things in there that would be considered cruft when the repo is used as a library for another project.

Because of this, we’re often maintaining two Git repos for each project. One has just the code, README, CHANGELOG, etc. while the other includes design docs, mockups, etc.

Submodules require extra steps when cloning

With a standard SVN checkout, all of your externals get populated and are ready to go right away. With Git submodules, an additional step is required after a git clone. From inside the newly cloned repo (at the top level), you have to initialize and update the submodules:

git submodule update --init --recursive

This step will get all if your submodules setup, pointing to the proper refs, etc.

UPDATE: or clone with --recursive. (thanks Shawn)

Submodules require extra steps when committing

After initialization, your submodule will initially be in a “detached head” state. This means that even though the submodule is pointing to the correct ref/code revision, but it isn’t setup to update from or commit to a specific head (branch). If you’re not used to this (or are used to how SVN externals work), it’s easy to accidentally start editing code in the submodule code while you’re on a detached head. Recovering from this isn’t particularly hard (I’ll do a follow up post with details on this), it’s just another step in learning how Git wants you to work with submodules.

When I was doing active development on a project that had SVN externals, I’d often end up making changes to the externals as well as the current project. When I did this, I’d need to commit to the external separately from the parent project. Git submodules work in a somewhat similar fashion in that you need to commit the changes to the submodule first; but there are also some additional steps involved.

Like SVN externals, you need to cd into the submodule to commit any changes you’ve made. When you’ve committed your changes to the submodule and have it in the state you want for its inclusion in the parent project, you then need to cd back up to the parent project and commit the “change” of the state of the submodule. Make sense? Basically, you commit to the Git submodule separately just like you used to commit to your SVN external. The additional step is checking out a tag, branch or specific revision that you want the submodule to “stick” at; then committing that change to the parent repository.

Submodules don’t update on their own

Recapping the previous point: submodules are stuck to the revision/tag/branch they are set up on. You have to explicitly update them, then commit the “change” of having the submodule point to a different revision to the parent repository. This is useful for situations where multiple people are updating a project that is being used as a submodule by multiple parent projects. Changes to the submodule won’t automatically be pulled into a parent project that doesn’t expect it (they have to be explicitly pulled in, committed, etc.).

Once you’re out of active development, I consider it a best practice to make sure your submodules are pointed at a tag for the purposes of tagging the parent project. That way when bugs or issues are found they are logged against the proper version of the package in question. When questions about a submodule version arise (does it include feature X?), you can answer them pretty easily by checking the CHANGELOG.

Hopefully this helps you get your head around the differences between SVN externals and Git submodules. Overall I like the implementation of Git submodules better now that I understand what they are trying to do. We’ve found that this development approach compliments the core extensibility features of WordPress very nicely. In fact, many of our plugins interoperate by implementing hooks and filters in the same manner WordPress core does.

Does building modular code (WordPress or for other PHP projects) sound like something you’d like to be doing more of? We’re hiring. As previously noted here, our careers page is a little different, and we believe in a healthy work-life balance.

The main reason for the change is to be able to support a branch driven development workflow (using Git Flow). We were already using this for newer projects (including some of our Open Source WordPress plugins that we host on GitHub), and we were seeing lots of areas where this approach would be a big improvement to our SVN workflows. We think it will especially pay dividends for our ongoing retainer clients.

With our ongoing clients we are commonly engaged in building new features and functionality while also needing to be able to make smaller changes (hotfixes) that are pushed up immediately. With Git it is easy for us to maintain development of more involved functionality in feature branches and still being able to push up quick changes as needed.

We’ve been following a modular development methodology for years, so we have a large number of libraries, plugins, etc. that are shared across various projects. Converting these from SVN externals to Git submodules was a good bit of busy work, but more importantly it required everyone to get comfortable with the difference between SVN externals and Git submodules. The biggest changes are that the submodules default to a detached head and don’t auto-update to the latest code in a branch. These are generally positives, but require changes to how you think about things. More on this in a future post.

We are using GitHub to host our Open Source projects, but we choose to host our own Git server for our private repositories. We are using Gitolite for repository management, GitPHP to provide a hackable web interface and we’re planning to use Gerrit for code reviews.

One of the other challenges was setting up a repository structure that we were happy with for our WordPress sites. We settled on the following:

/index.php
/local-config.php (unversioned – has machine specific settings)
/wp-config.php (define WP_CONTENT_DIR and WP_CONTENT_URL here)
/wp/ (WordPress core as a shallow Git submodule or SVN checkout)
/wp-content/ (plugins, themes, etc.)

This works quite nicely for simple and painless WordPress core upgrades, local development environments, and scriptable deployments. With a standardized structure, we’re also able to create scripts to automate the creation and data seeding of local development environments. We’re still working on the local dev set-up script, but I’m really excited about it. It should make it much easier for any developer on our team to quickly spin up a project and be able to contribute to it.

Does this sound like fun? We’re hiring! Come help us define and implement best practices that make developers effective; and work on interesting and challenging projects.

You’ll find this is particularly important if you’re making requests for remote data from within WordPress via wp_remote_get() or similar technique. If you are working on something that is run within WordPress, you can look at using add_query_arg() as an alternative to this as well.