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.

At today’s team meeting, the Crowd Favorite folks who contributed to the WordPress 3.3 release (including me!) received goodies. I hope to dole out a few more for the 3.4 release.

Related:

If one of your 2012 resolutions is to contribute to core WordPress code development, please read this post: wp.me/pbNCB-ui

— WordPress(@WordPress) January 5, 2012

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.

1. Improved admin UI for Post Formats, with fallbacks (as previously discussed)
2. A post stack switch/restore implementation (useful for developers)

Already some good feedback on the latter.

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.

Note that this is lightly tested and there is absolutely no information in the README yet. Please contribute via pull requests in GitHub to help write the README with the information you would find useful.

I’m excited about the move to using Social as the platform for Twitter Tools because it fixes the user experience issues that have plagued Twitter Tools since Twitter’s move to OAuth. Read more of my bitching about this here:

• Twitter Tools OAuth Update – June 10, 2010
• Twitter Tools and OAuth Continued – June 13, 2010
• Twitter Tools OAuth Update – August 13, 2010
• Twitter Tools 2.4 (OAuth Support) – August 15, 2010

Please open issues on GitHub for any bugs you find.

I’m probably most pleased that my media size patch was accepted; I think that’s a great addition for those of us that love to develop on WordPress as a platform.

I’ve got a few things to test and update to make sure they are working on the new trunk, then submit as patches for WordPress 3.4 – our post formats and fallbacks enhancements being the most notable. Hopefully that will see acceptance for core inclusion.

As far as I can tell, things are working smoothly. Of course, we’d already been testing Social and FavePersonal on pre-release versions WordPress 3.3 for a bit, so we’d already fixed up a few things. If you see anything around here that looks broken, do let me know. Thanks!

Social has a couple of high level features:

1. It enables broadcasting your WordPress content to social networks.
2. It brings back reactions from those social networks to your own site.
3. It lets people log in through social networks to comment – identity generally leads to better conversations.
4. It allows the sharing of comments on your site to social networks.
5. It does all of this without requiring you to register as a developer with the social networks and create your own apps.

This sort of integration is fraught with edge cases and little gotchas. For version 2.0 we looked at what we had with 1.x, looked at our road map for Social, bit down hard and decided to do a full rewrite for 2.0.

The downside of the rewrite was how long it took to get 2.0 released, but by doing it now we have a much more extensible platform on which to add connections to other services (Google+, for example) and we had less to refactor than we would have had we waited.

Along with the full rewrite, there are a bunch of new features in 2.0. Here are a few of them:

• Changed the way authentication works, to improve security.
• Added support for posting to Facebook Pages as well as profiles.
• When someone Likes one of your broadcasts on Facebook, that is pulled in to your site.
• New visual presentation of Retweets and Likes, so that the activity is visible but the discussion is less cluttered. We also have a smart algorithm for trying to match retweets that are not marked as such by Twitter’s API.
• If you respond to a comment imported from Twitter on your site and broadcasting that back to Twitter, the “in reply to” thread is correctly maintained.
• Where possible, comments on your WordPress site are threaded to match discussions that happened on social sites.
• A new queuing system for the checking of for social reactions, along with features that should reduce (hopefully eliminate) reactions from creating duplicate comments.
• Delayed broadcasting for future posts and comments that are held for moderation.
• The ability to enable broadcasting by default on new posts (please use this judiciously) to selected globally authenticated accounts as well as selected personal accounts.
• Convenience links in the admin bar and on the post list page to allow you to manually check for social reactions on a post.
• A ton of edge case handling for things like changing from bit.ly to wp.me URLs after publishing a post, respecting private tweets, etc.

I have a few good examples to demonstrate how Social brings in comments and displays them. Unfortunately some of these were pulled in before I started running the Social 2.0 codeline so not all of the retweets, etc. are displayed as cleanly as they will be in the future.

Big thanks to MailChimp for their support of Social. They are not only the primary benefactor of the plugin, but they also run the service that allows WordPress to connect to Twitter and Facebook without the pain and hassle of registering as a developer and creating apps for each platform.

Social’s source code is hosted on GitHub and built in the open in the best tradition of Open Source. Pull requests, enhancements and feedback are welcome.

I’ll be helping out at the Happiness Bar at 9:30am if anyone wants to say hello or chat about Carrington Build, RAMP or some of the techniques used in the upcoming (complete rewrite) releases of Social and Twitter Tools.

#

Download from GitHub

We are hoping for a general release of version 2.0 on Monday, so please report any issues you find in the WordPress.org support forums. Thanks!

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.