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.

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.

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 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.

This version fixes several bugs that were found in our QA process, as well as a few enhancements and initial integration points. The changes since beta 1:

• fix several taxonomy reference bugs that were causing shortcodes and widgets to fail to show tweets
• fix logical flaws that were causing the “include RTs/replies” settings in widgets to behave inconsistently
• disconnect Twitter accounts when they are deleted from Social only when they are shared accounts
• manual tweet download is now an AJAX call instead of a full page refresh
• cleaner failures if Social plugin is not active
• add integration points so that other plugins can extend Twitter Tools

Due to some of these taxonomy issues, you may need to delete your existing Tweets and allow them to be recreated so that tweets appear in the widget and shortcodes as expected (any newly imported tweets should be fine with this version).

Still no README file (contributions from testers are welcome), but I expect to get started on that along with final tweaks and packaging for a full release in the near future.

Developers, please feel free to open issues and submit pull requests in GitHub.

http://example.com/type/standard/

quite nicely. However the code in that patch doesn’t (yet) handle direct WP_Query calls.

I was hacking on this a bit on my own before finding the (much more elegant and complete) code that Nacin contributed. I came up with some working code that does work with WP_Query calls, which I posted in this Gist:

View the code on Gist.

Note that this doesn’t create the taxonomy term and do some of the other nice set-up that Nacin’s code does. It could use a bit of cleanup – improvements are very welcome. This isn’t going to be at the top of my list for a while, so I wanted to make sure I published the code so anyone else who is interested can take a stab at merging the two approaches.

For my own usage, I wanted to have the list of recent “standard” posts that you see in my sidebar. To create this, I enabled the code in the Gist above, then made a slight mod to the Recent Posts widget that is included in core. If you’ve wanted the same, please grab the code and enjoy.

Note for future visitors: this code is working as desired with WordPress 3.3.x, but will hopefully not be needed in some future version.

Why? It does too much, and too little at the same time.

It does too much. Popularity Contest tracks each page load. In order to make this compatible with caching plugins, this functionality was abstracted to be done via a second AJAX call (or tracker image in feeds) that bypasses your site’s caching system.

In other words, with Popularity Contest enabled and a caching plugin installed, each visit to one of your pages still generates an additional dynamic page load request to your server. This is how it has to work, but it’s too much for most commodity hosting environments.

It does too little. While Popularity Contest is tracking each page load and updating aggregate numbers relating to your site’s activity, there is a significant diminishing of returns as you use the plugin over time.

There is no granular data tracked, meaning you cannot plot trends or view popularity in specific time slices. In fact, what I saw on this site was that the most popular posts became simply a list of what ranks highest for popular searches in Google.

With all of the free and low-cost analytics solutions out there, you’re better off using a service to get this sort of information rather than doing it yourself. I’d recommend Google Analytics, WP.com stats or more advanced solutions like KISSmetrics, Reinvigorate, etc.

While I don’t recommend reviving Popularity Contest for the reasons listed above, but if you’re interested in forking or looking at the code you are welcome to do so. I pulled a copy of the code from the WP.og SVN repository and put it up on GitHub. The wp30 branch probably works with the latest version of WordPress with few needed revisions.

However, there are some headaches with symlinks – particularly with common methods of including files:

include(dirname(__FILE__).'/my-include-file.php');

and related permissions issues if the files live outside the web root, etc.

Trying to figure out the symlink path to the file from within PHP is decidedly non-trivial, so a different approach may work best:

View the code on Gist.

Here you can see we are maintaining the location of the file and path that WordPress used to include the file. This has worked well in my experience, perhaps it will be a good solution for you as well.

As always, improvements or suggestions are welcome.

As a few of our projects have enjoyed exactly the sort of developer community engagement I was hoping for (pull requests, issues, discussion), I discovered that my team was getting email notifications for these events but I was not. Instead, I would hear a comment from a colleague or get an email from someone every few weeks asking why I hadn’t responded to their issue.

Once you get past a few repositories, it’s not realistic to click through them all and see if there are new issues that need attention – the notifications are quite necessary.

After confirming that all notifications were enabled in my account settings, I eventually sent a note into GitHub support. I quickly got a response with the solution:

Users in the Owners group don’t receive notifications. You need to create a normal team and add yourself to it to get notifications for that team’s repos.

This was indeed the case. If you aren’t getting notifications for your organizations GitHub repositories and you are in the Owners group, add yourself to another group that has access to the repositories – that should do the trick.

#