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.

#

What happens when publishers put important data in the post format custom fields, then choose to change to a theme that doesn’t support these fields?

It’s a legitimate concern, and (as noted previously) one that I had an interesting discussion with Ian about at WordCamp SF this year. His idea of core functionality that could tack the data on at output seems like a great solution.

In Open Source, code talks.

I’ve put together a proof-of-concept plugin that does exactly this with the data fields supported by our post formats UI plugin.

With this plugin enabled, the information in custom fields is automatically added to the post content. In the event the publisher switches to a theme that either doesn’t support post formats (or doesn’t support the custom fields our admin UI provides for), they could enable this plugin and their posts would have all the information displayed that they expect.

Once WordPress 3.3 is out the door, I’ll submit these plugins for consideration and discussion to be included in core. In the meantime, this should at least minimize data portability concerns for theme developers.

Fellow developers, please help this improve! Fork it on GitHub, provide feedback and enhancements, etc. This was put together in a few hours yesterday afternoon, so it is very lightly tested and should be considered a starting point. There are some simple checks in place to try to avoid situations where the auto-added content would duplicate content manually inserted into the post, but I’m guessing that can be improved a bit (it’s entirely lacking for image formats, for example).

While it is a great framework feature, it only really exists as something developers leverage to extend WordPress. There is no UI that ships with the feature, which limits its accessibility to users.

My team and I have been working on FavePersonal (the theme you see here) for a while, and one of the features we’ve built is an admin interface for post formats.

We have released this code on GitHub (pull requests welcome) and encourage any and all theme developers to use it, add to it and improve it.

Here are some details on how it works.

The plugin is a completely additive solution that leverages the default WordPress functionality, while improving the UI and standardizing the names and presentation of custom fields that support the various post formats.

A set of tabs are added to the post authoring screen that allow users to select the post format they would like to use. The built-in radio button interface is hidden, and the tabs simply control the selected radio button.

Status posts are treated as “content only” – similar to the short form seen in Facebook status updates and Twitter’s tweets. Behind the scenes, a title for the post is set using the first 50 characters of the content.

Link posts have an additional custom field (_format_link_url) for the URL of the website/page being linked to. This URL is then utilized in the theme to implement linking directly to the external site from the title link (if desired).

Image posts utilize the WordPress built-in Featured Image functionality. The Featured Image is treated as the image for the post, and the theme displays it accordingly for this post format.

Gallery posts display the WordPress gallery in the tab so that it’s clear that these items will appear with the post. The theme then implements the gallery view based on the post format.

Video posts have an additional field added for embed code or an oEmbed URL to be added. This information is stored in a custom field (_format_video_embed). Then the theme can use this to display the video in an elegant way.

Quote posts have two additional fields. One for the name of the person being quoted (_format_quote_source_name), and one for an attribution link (_format_quote_source_url). These can be used in the theme to present the quote and attribution in a consistent manner. Similar to status posts, a title for the quote is created behind the scenes from the first 50 characters of the quote.

You’ll notice that we have adopted a consistent naming convention for custom fields used to support post formats. That convention is:

_format_{format type}_{descriptive data name}

The underscore at the beginning of the key prevents the field from showing up in the default Custom Fields interface (since we are managing it behind the scenes) and the rest is set up to logically describe the type of data being stored.

We look forward to releasing our theme in the near future, and hope that this code will be widely used to help bring adoption of post formats in a way that is truely portable between WordPress themes.

Several people I’ve shown this to have asked if I’d like to see this adopted in WordPress core. Yes, of course! I had an interesting conversation with Ian Stewart about this at WordCamp SF this year. He had some reasonable concerns about the data being stored in custom fields not being portable to themes that don’t implement post formats; while acknowledging that having the data in a structured format (separate fields) was very valuable for presentation purposes.

One possible solution we discussed would be the addition of core functionality that would look for these custom fields and post format support, and would auto-prepend/append the custom fields to the content accordingly (add the featured image, gallery, quote attribution, etc.). A solution like this is definitely preferable to requiring all of the data to be present in a single content field.

UPDATE: see my follow-up on this.

Publish a post by transitioning the post status.

and that’s exactly what it does. Moreover, that’s all it does.

If you are creating a draft post via wp_insert_post() (or wp_update_post(), which calls wp_insert_post()), certain defaults will be set for you when the post status is set to publish (or future, etc.). Among these is the automatic creation of the post_name from the post_title (if none has been explicitly provided) and setting post_date_gmt.

I had some code on my site that was hitting a service to get data, creating a draft, adding some meta data and taxonomy information, then publishing it. When I was initially doing this (and using wp_publish_post() instead of wp_update_post()), I was ending up with published, unnamed posts. Not what I had in mind.

There are two ways around this:

1. Use wp_update_post() instead of wp_publish_post(). This works fine, but it’s a little heavier, and conceptually I think the code reads better with the wp_publish_post() call instead.
2. Use wp_publish_post(), but make sure to set the post_name, post_date_gmt, etc. when you create your draft post via wp_insert_post().

For what it’s worth, I was using wp_update_post(), switched to wp_publish_post() because it seemed cleaner, and have since gone back to wp_update_post(). Using less of my own code and letting WordPress core code do more work for me feels more future-proof.

Hopefully this is useful to someone else who starts digging through the code and is having trouble deciding which of the various functions to use.

I actually want it to go a step further. I want each new Incognito window to be a full separate session. The tabs within that window would belong to that session, but I could pop open new Incognito windows as desired and each would be their own session. Using this, you could log into the same website under as many different accounts as you wanted to – a killer feature for developers to be sure.

Sidenote: There doesn’t seem to be an easy way to link to a Twitter conversation (tweet + replies). That’s one area where Google+ currently beats Twitter handily. I see folks throwing around links to Google+ conversations all the time (hmmm, Wave?).

I worked around this by making the check for touch vs. non-touch browsers also test for a BlackBerry user agent string; then lumping all BlackBerry devices into the non-touch bucket (you’ll get “click” and like it). This is a bit broad, but for my simple use case it was a fine trade-off.

Feel free to post other solutions in the comments…

Custom fields are still the right choice for misc. data that is used for display purposes only, or descriptive data about a post that is used by a behind-the-scenes process. You can serialize data here to store the equivalent of cached relational data. You can set flags for various behavior triggers, etc. You can also create a custom user interface for adding and editing the data you need to store.

Where you should use a custom taxonomy instead is for any data that you need to query on. For example, getting all posts that were broadcast to Twitter; all posts that were created by an outside process; all posts that have a certain workflow status.

The reason to favor a custom taxonomy in these situations has to do with the WordPress database structure. Queries by taxonomy are well optimized as this is a primary front-end presentation feature in WordPress core. Conversely, querying by custom field key and value is slow. The value column in the custom field table is not indexed – you are basically doing a search through data that is not intended for that purpose.

(Yes, as a workaround you can create a NoSQL-style composite key that contains both the key and value in the key column (key = ‘featured-yes’ instead of key = ‘featured’ and value = ‘yes’), but there are only a handful of solutions where I’ve thought this is a more elegant solution than using a custom taxonomy.)

Remember, you can still create a custom admin UI for your custom taxonomy (perhaps to enforce single selection, hide certain options in certain situations, etc.). Or you could choose not to expose the data on the front or back end at all and just manage it in code behind the scenes. However, if you do want to expose it, WordPress already has a bunch of tools to let you do this (clean URLs, pagination, feeds, etc.).

I think my previous mindset of being focused primarily on using custom fields is partly because they existed before custom taxonomy support was part of WordPress core. One of the hardest things to do as a developer is realize when things have changed and part of your library of knowledge is no longer accurate/relevant. I know I harbor grudges against various apps, platforms, etc. that are certainly based on outdated information (I just don’t know which ones).

We definitely want to use the SVN repositories on WordPress.org so that released plugins can be easily available to the community, but there is very little developer community there. We’ve also used Google Code hosting in the past. It’s nice to have issue tracking, etc. but again there is not much community there. GitHub has a vibrant developer community and great collaboration tools, but it’s Git and the WordPress developer community infrastructure runs on SVN.

After a good bit of discussion within our team and discussion with other WordPress developers, we’ve decided to move everything to GitHub. We’ll still push the code to the WordPress SVN repos as a packaging step, and will occasionally have to maintain mirrored SVN repositories for specific projects; but the active development will happen in GitHub.

We have a few different projects that I think will really benefit from wider community involvement. In particular, we’ll be moving over our Carrington Core theme platform, our CF Revision Manager plugin, and our CF Post Formats code (which I moved earlier this week). Over time, we’ll get everything moved over – I’m hoping that we’ll start seeing forks and pull requests for these projects on GitHub.

Personally I’m going to be putting more and more code snippets on GitHub so that I can make code more generally available to the community without needing to package it up a plugin.

This works great, but we discovered that moving the URL out of the post body breaks another feature: pingbacks.

Pingbacks currently work in a very specific way. The post content is parsed for external URLs, then a ping is sent for each of these URLs letting them know they were referenced. Unfortunately, in the current version of WordPress there was no way to get any additional URLs into this list (and we aren’t storing the URL in the post content where it would be found automatically).

I created a very small patch to add a filter into the pingback process. With this, I’m able to add a few lines of code that takes the URL from the custom field and add it to the list of URLs that need to be pinged.

View the code on Gist.

I’m adamantly against making changes to WordPress core code in almost all circumstances, but the exception is patches that look like they’re on track for inclusion in the next release. Early indications for this one appear positive (thanks Nacin!). If you need this feature before it makes it into core, you can grab the patch. I’m running it here so that my link posts send pings as I feel is appropriate.