The WordPress Planet is a collection of WordPress centric websites that aggregate their content into one stream of information. In 2009, I proposed the idea of refocusing the dashboard so that it presented more WordPress Centric content. While some sites have been added and removed from the official Planet WordPress feed over the years, the core issue remains. It’s not as great of a source of WordPress information as it could be. I always thought that instead of having all the content from an individuals site published to the planet feed, it would have made much more sense to only subscribe to their WordPress category.
Disappointed in the official planet feed, I searched for other resources of information and one day, came across a site called PlanetOzh. PlanetOzh is just like Planet WordPress except it has more sites to aggregate content from and is maintained by Ozh. Sites are added and removed on a somewhat routine basis. However, I remember sending an email to Ozh one day after I went through each site he was aggregating content from and told him which ones I thought needed to be removed due to their lack of WordPress specific content or that the site appeared dead. It was a substantial list. From my observation, it looks like he has cleaned up the site so it’s much more relevant than it was a few years ago.
Recently, the topic of the WordPress Planet was brought up again by James Farmer of WPMU where he does bring up some valid points. I’m of the opinion that the more people who see great WordPress centric information, the better off everyone in the WordPress ecosystem will be. So I’m all for making the WordPress Planet a better place. However, the official Planet WordPress feed is maintained by one person, Matt Mullenweg. Considering just how busy he is, I can understand how maintaining the list of sites on the planet feed would be one of the last priorities on his list. I think some would agree that there are far more important things to be spending time and energy on with WordPress.org versus the planet feed.
If you’re looking for more variety of content from different WordPress centric websites in your dashboard, you should try the brand new plugin called A Better Planet by WPLIft. In a nutshell, this plugin is a more up-to-date and relevant version of the official planet WordPress feed. While the master list is controlled by one person, it looks like it’s a lot easier to have a WordPress site added to their list than the official feed.
While I wouldn’t mind seeing other WordPress centric sites in the dashboard supplying great information to users all across the world, I also wouldn’t want to see those same sites treating the dashboard as an enormous, untapped customer base. Being in the WordPress dashboard comes with great responsibility. For example, you have to be on-board with the 100% GPL philosophy. Sites can not link to other sites that promote non-GPL products. Sites can not advertise non-GPL products through display ads or otherwise. It really boils down to being an excellent steward in the community. There are WordPress centric sites that meet that criteria but I don’t make the decision on who is added to the feed and who is not.
So considering we’ve been having this conversation for a few years now, has anything really changed? Do you even use the news widgets in the dashboard or do you hide them as soon as you can?
In my journey of locating a better WordPress search alternative, it was suggested that I give Swiftype a try. Swiftype is another search service that offloads the searching process to their servers instead of having to rely on the database to give results. Unlike my struggles with the ElasticSearch Plugin, the folks over at Swiftype couldn’t have made it any easier to get their plugin up and running.
After signing up, I viewed their demo video which does a great job of explaining how to install and configure their WordPress plugin.
Their plans range from Hobbyist at $19.00 per month to a Custom Enterprise solution. They don’t list what comes with the free account but you can find out that information after you sign up. The free account is perfect for small websites that have less than 2,000 articles. As I’ve learned in this process of reviewing search services, an article, post, or page is called a document.
One search engine, 2 domains, 2,000 documents, and 50 query customizations. Recrawl once a week. Your search results must display Swiftype branding.
Swiftype doesn’t enable users to search by categories or dates. However, I’m beginning to think that if the search results are relevant enough, there isn’t a need to include those search queries. One of the cool things about Swiftype is that they give you access to manipulate the search results so that if they are not relevant enough, you can take a result and place it higher on the list.
One of my favorite features is the drop-down suggested search results. In my experimental use, I’ve noticed that most of the time, the results of what I’m searching for end up in the suggested results drop down box.
There are a few instances where the result I’m looking for is nowhere to be found. For example, if I search for WPWeekly Episode 10 I see most of the episodes in the 100-110 range when I’m really looking for episode 10. When disabling the plugin, the search results are roughly equal. Both end up not returning the WPWeekly Episode 10 post as the first result. Using the search built into WordPress, I end up having to browse to the last page of search results to find the post I was looking for. With Swiftype, there is a huge improvement as the post shows up as the 13th result. It’s not number 1 but it’s not the last page of results either.
If I wanted to, I could navigate to the Swiftype dashboard and manually move the results around so that episode 10 IS the first result. But, what I don’t understand is why episode 100-110 were displaying if my search string only contained two numbers? I love the ability to rearrange results but if I have to spend a lot of my time rearranging things, then Swiftype is not doing its job.
There is one last small issue I had. For some reason, the drop down suggestion box didn’t work for every search query. For example, if I searched for the term jeopardy which I already know exist within the post content of an article, the suggestion box doesn’t show up but the article that contained the word jeopardy within the content ends up being the first result. I reached out to Swiftype to see if they could explain this behaviour to me and this is what they had to say:
Autocomplete suggestions are based on the post title, author name, and tags. Longer text fields like the post body and excerpt are used for full-text searches only (i.e., when the user submits a search). We have implemented it this way because the large volume of text in posts would make the autocomplete results less useful.
You can read more about the fields we index in this tutorial: https://swiftype.com/documentation/tutorials/customizing_wordpress_search
Makes sense to me. I also discovered that I misspelled jeopardy when I added it as a tag to the post. Once I fixed the tag, everything worked as it should.
Swiftype was a breeze to set up and within 10 minutes, I was able to improve the search results on my site. It only took that long because of the synchronization process. I’m going to stick with this plugin/service until I find something better but I come away from this experience being able to recommend Swiftype to those who want to substantially improve the built-in search functionality of WordPress. It’s also encouraging to know that on this journey I’ve been on, I’ve discovered that you don’t have to pay any money to improve the WordPress search.
As we inch closer towards the 10 year anniversary of WordPress, I’ve been browsing through a few different time capsule posts. Some of them really tap into my nostalgic center while others have me asking questions such as, what ever happened to the Flock browser that WordPress was excited about in 2005? It was described as being just like FireFox but with goodies. If memory serves me right, it was supposed to be a social browser. At any rate, here is a collection of memory lane posts related to WordPress.
Down Memory Lane With WordPress.com – Although this was published in 2009, it gives a great overview of the history of the WordPress.com front page over the years. It’s filled with interesting tidbits such as when the WordPress.com website promoted the Flock browser.
Then & Now: How WordPress Companies Have Looked Over the Years – Published at the end of 2012, not only does this article chronicle the WordPress.org website but a handful of other notable sites as well such as Woothemes, StudioPress and ColorLabs.
A 10 Year Visual History of WordPress.org – While I created a comprehensive history of the WordPress.com domain, Joe Foley of WPMU.org published a visual history of the WordPress.org website which covers all 10 years the website has been around.
A Journey Through Five Years of WordPress Interface. – Published in 2008, Ozh compiled a number of screenshots together showcasing the changes that the WordPress interface has gone through since 0.7.1 to 2.7. Take note of WordPress 2.5 as many consider it one of the worst interface redesigns WordPress has been put through.
A History of Default WordPress Themes – WPLift also published a history of the default themes that have shipped with WordPress. Although these were far and few between, starting with TwentyTen, we can expect to see a new default theme every year.
Brief History Of The Theme Repository – These slides are from Chip Bennett’s presentation at WordCamp Kansas City that delves into the brief history of the WordPress theme repository.
While compiling this list of posts, I had a conversation on Twitter with a number of folks discussing the history of WordPress and how it would be cool if we could take various elements of WordPress and create a visual history such as the Login screen or the Post Writing interface. I was told by Siobhan McKeown that she is sort of working on a project like this. She currently has every version of WordPress installed on a local machine in order to create screenshots from one version to the next. It will be interesting to see where this goes.
Bryan Witherwax or @Tweeterwax notified me that their WordPress 10 year anniversary party in Seattle, WA will have a local host setup with every version of WordPress installed so that attendees can see for themselves just how far WordPress has progressed.
@wptavern We have some guys setting up all of the versions of WP on a local host for people to play with for our WP 10yr party in Seattle.
— Bryan Witherwax (@tweeterwax) May 22, 2013
Ryan Hellyer has put together a section of his website that shows off the WordPress 1.0 Post Writing screen as well as the index page right after WordPress 1.0 is installed. In the coming days/weeks, Ryan will be adding different versions of WordPress with static Administration and index pages so we can at least get an idea of what the workflow is like. If you don’t see anything, it’s because the changes have yet to propagate to your DNS server.
I’m also going working on a post that explains what steps to go through to install each WordPress version onto a local host. It’s actually more difficult than you would think, especially for WordPress 0.7.1 which requires it’s own unique PHP.ini file.
iThemes, the company behind products such as BackupBuddy and the Builder theme are reporting that their headquarters as well as all of their staff are ok following the Tornadoes that ripped Moore, Oklahoma apart on May 20th. Not only has their company donated $2,000.00 to the Red Cross for relief efforts, but they are asking everyone to consider texting REDCROSS to 90999 which will donate $10.00 to the Red Cross to help support tornado relief efforts in Oklahoma.
One of the best things about WordPress is its third-party ecosystem of themes and plugins. If WordPress doesn’t have the feature set you need out of the box, chances are very good that with just a few plugins, you can make the WordPress of your dreams. However, to new and veteran users alike, choosing which plugins to install is not always an easy task. Using this guide as a checklist ought to remove some of the challenges associated with choosing plugins. I’m not guaranteeing that you’ll be able to pick the right plugins 100% of the time but by taking these factors into account before making a decision, your chances of success will substantially increase.
Starting Point – On the left hand side of the Plugin repository are a series of links for extending WordPress. I highly suggest starting off with browsing through the Most Popular and Highest Rated plugins first, then move on to other options. The plugins within those two categories have stood the test of time and generally, have earned those positions.
Requirements – The minimum requirements information is supplied directly from the plugin author and is generally used as the first factor in determining whether or not a plugin will work with a specific site. The number of downloads can be used to determine the age of a plugin as well as it’s popularity.
Ratings – Ratings are based on 5 stars where the average rating is shown at the top. Plugins can only be rated by logged in users. One of the recent changes to the plugin repository are plugin reviews. If you click on each star link, you can read all the reviews that go with that rating, very similar to Amazon.com. When choosing a plugin, don’t just read the 5 star reviews, also read the 1 and 2 star reviews to get a balanced perspective.
Plugin Author – Sometimes, the plugin authors name will show up as a link. This link will take you to their WordPress.org profile that displays an overview of their earlier works in the plugin repository as well as a stream of their recent activity. This information can be used as an indicator on their recent development activity around their plugins.
Plugin Support – This area of the page shows you how many support questions have been asked in the forum specifically for that plugin. When viewing the plugin support forum, look for the number of threads that have [resolved] in the title, the plugin authors name as being the last poster and threads that have answers by someone other than the plugin author which is a sign of a healthy community surrounding the plugin.
Compatibility – This area of a plugin page describes whether or not a specific version of a plugin works with the current, or earlier versions of WordPress. Using the drop down boxes, you can select an earlier version of WordPress as well as an earlier version of the plugin to see if enough people in the community have reported on whether they work together or not. This information is based on community feedback, not by the plugin author.
Trustworthiness – Although this is not a consideration you can search for, downloading a plugin from the WordPress plugin repository does have its benefits. Before each plugin is allowed to be hosted on the repository, it must go through a manual screening process that checks things like obfuscated code, malware, spam links, and security. This is also the same process a plugin update must go through before it’s also published to the repository to make sure nothing malicious is added after the first screening. For these reasons, I can’t stress enough how important it is to download from the official repository versus somewhere else. That’s not to say that plugins hosted elsewhere are not equally or more thoroughly screened, but with WordPress.org, you know what you’re getting.
With over 25,000 plugins in the repository, it’s becoming increasingly difficult to wade through them all to find the one that perfectly matches functionality with security, support, and reliability. For example, if you were to do a search for Backup or SEO, you’ll be greeted with a ton of different options. Using the factors I’ve listed is this guide can substantially increase the odds that a plugin will work out of the box with little hassle. WPTavern.com uses about 25-29 plugins and most of them have been in use for over 4 years, with little to no trouble.
I reached out to a couple of people in the WordPress community that deal with the plugin repository on a routine basis either for their own interest or because they are in the business of working with clients. Here is their advice.
Al Davis of WPTeach.com – Check what version the plugin is compatible to, as this is a great indicator as to whether the plugin is still being actively developed. If you are unsure how the plugin is going to work on your site, browse through the support forums, see what kinds of issues others may be having and see if those issues are being addressed. Finally, have a look at the screenshots and FAQ if they are available and make sure the plugin actually does what you are looking for.
Angie Meeker, Organizer Of WordCamp Columbus and WordPress Consultant – My first piece of advice is to ask yourself (and your trusted WordPress adviser or the WP Support Forums), “Do I really need a plugin for this?” Many new users to WP are unfamiliar with some of its simplest built-in functions (ones you don’t even need to know how to code to use). They go searching for a simple gallery plugin, not knowing there’s one built into the Media Uploader. They search for a plugin to schedule posts, to password protect pages, or to post by email.
On finding what you want in the first place:
1. Search with as specific of terms as you can think of. “Rotating Image Galleries” is a better search than just “Image Galleries.” Of course, this is true with all search.
2. Google “what you want to do + plugin + wordpress“, and look only at search results in the repository (those with wordpress.org/extend/plugins/ in the url). I find that sometimes searching the repository from within is limiting.
Once you’ve found one:
1. Read the entire description, Installation, FAQ, and Other Notes (ALL of them). If there are Screenshots, look at them to get a hint of what the plugin does. Not all plugins have all of these areas completed, though.
2. Look at the “Requires Version X.X” and Compatible to X.X” If your installation is WordPress 3.1, and the plugin requires 3.5, then it’s NOT the plugin author’s fault when you install it and it doesn’t work. Either upgrade your WP install, or don’t use the plugin. If you’re using 3.5 but the plugin says it’s only compatible to 3.1, then there’s no guarantee it will work with that forward version. It MIGHT, but there’s no guarantee.
Sometimes, a plugin author knows for CERTAIN a plugin DOESN’T work with a newer version, and they’ll make a note of it in the description. Remember, the authors of these plugins are not paid to create and update these, so if a plugin is not up-to-date, don’t go berserk on the plugin author. Be polite and ask if/when there might be an update.
3. Perhaps one of the most useful things you can check out: the Support Forums for a plugin. Plugin authors don’t HAVE to give support for plugins in the repository, but many do. Look at the support threads submitted. How many people submitted the same questions? Does it seem like those questions are simply user error (like maybe they didn’t read the instructions?) or are they asking about a bug or a problem with the plugin? If there are bugs, is the author responsive to correcting them or providing hints at how users can make corrections? Does the author respond to questions? In my opinion, these point to a plugin author who is vested in the success of his/her plugin, and that usually equals success for you when using it.
4. Reviews: These are a recent addition to the WP Plugin Repository, so don’t be surprised if many plugins don’t have many or any.
5. Lastly, clicking on the plugin author’s name will take you to a list of all the plugins that author has submitted to the repo. It stands to reason that a plugin author whose overall portfolio has quality ratings, good reviews, maintains the support forums for his/her plugins and keeps the plugins up-to-date probably creates plugins the community can trust.
Marcus Couch co-host of the WordPress Plugins A-Z Podcast also has some bullet points worth checking
1) How long has the plugin been around? What is the update cycle?
Nothing is worse than committing to a particular plugin and having the developer drop support after just a few version revisions. An active developer assures you that the plugin will receive update attention throughout the various WordPress Core updates that come along several times a year. A developer that frequently updates along with WordPress versions is a quality to look for when choosing between plugins to install on your live sites.
2) Does this plugin play well with the rest of my plugins?
If you’ve ever owned an aquarium, you know that some fish don’t play well with others, often leading to complete breakdown of the natural order and balance of the tank. Plugins are the same way! Make sure that the plugin you are going to install does not “overlap” functionality and cause issues in the performance of others.
3) Plugin vs Plugin Race
If two plugins exist that perform essentially the same function, install them both but activate only one. Run a site load comparison with sites like Pingdom.com and other data load measurement tools. Find out which plugin is more efficient with loading time and use the results to make a determination if one of the plugins takes too long to load or drains too much system memory.
4) Shortcode Dependency
When deciding to use a plugin that relies on shortcodes, understand that somewhere down the line you might want to remove that plugin. This means that there could potentially be thousands of instances of [shortcode] throughout your page and post content.
5) Community
Is there a great community behind the plugin? There are so few plugins with thriving, rabid communities, but it’s always a huge bonus when a large base of plugin fans can gather with the developer and help to improve a plugin and it’s core functionality. Once you start using a plugin on a regular basis and find that there is an active community associated with it, PARTICIPATE! I’ve had many plugins programmed with exactly the functions that I needed simply because I asked the developer to include them in future revisions.
I realize that some of the information in this post is redundant but Angie provides real-world expectations and views. Scott Reilly clearly sums everything up into one paragraph.
When choosing an appropriate plugin from the Plugins Directory it’s often best to take various factors into consideration rather than just any single factor. The plugin author, the number of support threads replied to in the past two months, the nature of the types of support threads being created (and the nature of the author’s responses, if any), the number and nature of the reviews being given (or lack thereof), the last update date, and the rating can all play a factor in making a decision.
If you can contribute anything else to this guide for choosing which plugins to install, please do so in the comments.
In an effort to figure out where resources should be applied to improve the documentation efforts of the WordPress project, there is an open survey that will be ongoing for the next few weeks. The survey is composed of 12, easy to answer questions which shouldn’t take longer than 5 minutes to answer. Along with this survey, there have been renewed efforts by a handful of people to get the various documentation projects up to date. To keep tabs on everything going on documentation wise for the WordPress project, you should subscribe to the Make WordPress Documentation website.
Speaking of documentation, how many of you have actually changed something on the Codex whether it be a typo, a bad link, or corrected information? I’ve made at least a few changes, such as typos and fixed a couple of broken links but nothing major. Just like many other aspects of the project, documentation is one of those thankless jobs. You can log into the Codex, make some changes and unless you brag about them, no one will ever know. However, documentation is one aspect of the project that impacts users for generations. While correcting a link or adding a paragraph of information is not critical to the Codex, it does provide a warm fuzzy feeling when you think about how many people may come across a page that you fixed so that instead of loading a 404 page which doesn’t help anyone, they get the information they were looking for.
Just for fun, I asked my twitter followers to tell me in 140 characters or less, why documentation is important to WordPress. This was one of their responses.
@wptavern Same reason documentation is important to anything: so people will know how to use it.
— Sallie Goetsch (@salliegoetsch) May 20, 2013

A picture I took at WordCamp Dallas 2008.
There has been a lot of speculation on the “shady mystery buyer” of Weblogs Tools Collection and WPTavern (here), which has been funny to watch. It’s me.
Why on earth? Well, it’s the same and different for each one. Jeff wanted to step back from WPTavern and had an offer but I thought it wasn’t really fair given the years and effort he had put into the blog. Even if he wasn’t going to be part of the WordPress world anymore I wanted him to go out of it with the best deal possible. For Mark, the context was similar except I don’t think he talked to any other buyers because his priority was having it in good hands – someone who would keep it around. I have a high regard for the great historical context WLTC provided, being there with WordPress from pretty much day one. So each was purchased by Audrey and went into hibernation.
Neither was done to be a business or make any money and there are no plans for ads or sponsors on either site.

In 2008 when I also first met Mark.
Why haven’t I posted anything until now? Well, I’ve been very busy — Automattic, WordPress, et al. Also the original plan was to just archive them both.
Convinced by Scott, I reached out to see if Jeff would be interested at taking another crack at making a first rough draft of history for the WordPress world. I recall fondly the days when I used to be more nervous about doing an interview with Jeff than the NY Times because I knew he’d have much more in-depth and nuanced questions given his deep understanding of WP. I’m looking forward to seeing that again in the WP blogosphere.
What’s the plan? Currently: put WLTC into archive mode, and reboot Tavern to be a “third place” for the WP community. We’ll show off the latest and greatest with bbPress and some newer WP features like post formats. Longer term it might make sense to roll Jeff’s (and anyone else who is interested) work into some official news resource WP.org, but haven’t really decided anything there yet. Consider this a grand experiment which I’m as interested to see the results of as I’m sure you guys are.
Any questions I could answer?
I have a suggestion for WordPress 3.7 that I believe is a UI element to the media library. I have a number of images within the media library. When I do a search for a specific image e.g. Codex which I know is the exact file name, the search is performed with no sign that anything is actually happening. Sometimes, it takes so long for any images to show up that I start running scenarios through my mind such as I broke the site or it can’t find any images. Then, suddenly, the search results pop up. So I’m requesting that a spinning circle or other visual cue be displayed when a media search is taking place. It’s better to know that something is happening versus looking at a blank page that gives the user no clue as to what’s going on.
I was pointed in the direction of Ticket 22754 as being related but I don’t think so. If anyone comes across a ticket where this is already being addressed, please share it in the comments. I searched through Trac myself and came up empty.
If you live in the Northern Ohio area, make plans to stop by Water Street Tavern in Kent, OH Saturday, May 25th from 7PM-10PM to help us celebrate the 10th anniversary of WordPress. There will be a cash bar, good food and from what I’ve read, there might actually be some WordPress swag. This event is an excellent opportunity to wear the special 10th anniversary t-shirt.
If you don’t live in Northern Ohio, check out the following list of WordPress parties taking place this weekend to see if one is happening near you.
It now looks pretty certain that Yahoo has pulled off a deal to buy Tumblr for 1.1B. The relationship between WordPress and Tumblr has always been pretty friendly: Tumblr’s own blog used to be on WP, WordPress.com supports Tumblr as a Publicize option alongside Twitter and Facebook, our Akismet team sends them daily emails of splogs on the service, and there’s healthy import and export traffic both ways. (Imports have actually spiked on the rumors even though it’s Sunday: normally we import 400-600 posts an hour from Tumblr, last hour it was over 72,000.)
News like this, whether from a friend or a competitor, is always bittersweet: I’m curious to see what the creative folks behind Tumblr do with their new resources, both personal and corporate, but I’m more interested to know what they would have done over the next 5-10 years as an independent company. I think we’re at the cusp of understanding the ultimate value of web publishing platforms, particularly ones that work cross-domain, and while Yahoo’s all-cash deal by some metrics, like revenue, is very generous, I think it’s a tenth of the value that will be created in these platforms over the coming years.
Update: Some people are reading too much into the import numbers — I don’t think there will be an exodus from Tumblr. For more color read the comments on this post.
The Wall Street Journal interviews Annise Parker on Houston and calls it “The Modern American Boomtown”. I think Houston is the most under-appreciated city in North America, as anyone who’s hung out with me for more than a few hours has heard me preach.
Wired has a great cover story on Audrey portfolio company SmartThings: In the Programmable World, All Our Objects Will Act as One.
In late 2012, VaultPress announced that they had acquired security company Code Garage. At the time, the acquisition seemed like a talent grab more than anything else. Even though VaultPress stated that they would continue to work on the Code Garage product, it didn’t make much sense to have both services. When I initially reported on the acquisition, I told Code Garage customers to watch the situation closely because at some point, Code Garage was going to close up shop in favor of VaultPress.
VaultPress has now confirmed that they will be shutting down Code Garage after July 1st.
Today we’re happy to announce a migration plan that provides Code Garage users with the protection they’re used to — while letting us improve security and backup services for everyone by focusing our resources on VaultPress. Through July 1, all Code Garage customers are invited to migrate to VaultPress. To sweeten the deal, your first two months are on us — you won’t see a charge from Code Garage or VaultPress for two months after the migration. After those 2 months, your Code Garage bill will remain unchanged – you’ll keep paying what you’ve been paying as a Code Garage customer.
If you’re not interested in migrating, we’ll maintain your service at Code Garage through July 1, and give you your last month free.
Any Code Garage customer that migrates to VaultPress will automatically be placed on the VaultPress Lite plan with the addition of daily security scans. For a detailed look at how Code Garage was founded and how Timthumb played a role in the company’s success, read this blog post by founder Peter Butler.
As long as I’ve been involved, I’ve seen countless numbers of companies misspelling WordPress. Despite the fact that WordPress added a filter to automatically correct the word, it still happens and when it does, the results are not pretty. Members of the community point out their mistake and while generally it’s enough to get a good laugh, it’s usually followed up with “can’t trust or work with a company that can’t even spell the name of the software correctly“. So after you vote in the poll, let me know in the comments if the spelling of WordPress is an indicator as to whether a company is worth doing business with or not.
BuddyPress 1.7.2 was released a little while ago. It contains some bug fixes but the most notable items include several MySQL Injection possibilities that have been patched. 1.7.2 is being classified as a recommended upgrade for anyone using BuddyPress 1.5 or above.
I’m keeping tabs on BuddyPress because at some point in the future, this site will be utilizing it combination with bbPress.
WordPress.com users now have a feature available to them that should have been in the core of WordPress a long time ago. They call it, Widget Visibility. Users can either hide or show widgets based on category, author, tag, date, or page. This covers the most common use cases without having a need to use conditional tags.
The interface is surprisingly simple. In fact, I prefer what WordPress.com is using versus Widget Logic which requires me to know conditional tags. I’m wondering how did WordPress.com get this feature before stand-alone WordPress? When I asked this question on Twitter, Ian Stewart responded with:
@wptavern I’d look for it here http://jetpack.me/ :)
This makes sense and in fact would allow the Jetpack team to get valuable feedback before ever considering putting it into core. If you can’t wait that long, try out the Widget Context plugin. Widget Context provides a similar interface with a few more bells and whistles that the WordPress.com variety doesn’t have.
BuddyPress 1.7.2 is now available. This maintenance and security release fixes several MySQL injection possibilities reported by Glyn Wintle from dxw.com, and a few other issues we caught after 1.7.1 was released last month. 1.7.2 is a recommended upgrade for all installations running BP 1.5+.
For complete details on what’s changed in BP 1.7.2, see the Trac milestone or the 1.7.2 changelog in the BuddyPress Codex.
Download it today from the wordpress.org plugin repository, or from the Plugins page in your WordPress Dashboard. Questions or comments about the release? Visit our support forums or our bugtracker.
While WordPress 3.6 is almost ready for release, one of the features that is already generating a love/hate relationship is the new Post Formats UI. This new UI exposes the Post Format functionality that is now relegated to a radio button post meta box. While researching this feature, I came across a discussion on the Make.WordPress.org site where it almost didn’t make it. If you use Post Formats now, the new UI is actually much nicer to use than the simple radio selection box. With each Post Format, the Post Screen changes to accommodate specific items. For example, when the Quote format is chosen, a quote source and quote link area is displayed above the post title. However, if you don’t use Post Formats, this new UI becomes yet another distraction into your publishing routine. Thankfully, the standard format is selected by default which is just a normal post.
If you would like to hide the new UI from showing up, there is an option within the screen options drop down tab where you can un-check the Post Formats box.
This only hides the UI from an individual. For multi-author sites, you’ll need to install a plugin such as the one Justin Tadlock created. If you’re curious to see an idea of a post format UI before WordPress 3.6, read Alex Kings post on a plugin he released called Post Formats Admin UI.
Post formats is a feature introduced in WordPress 3.1 as a way for themes to visually differentiate between types of content. Before the addition of post formats, users had to rely on CSS tricks to create specific styles for different kinds of content. A great example, is this post written by Lorelle Van Fossen from 2007 that explains how to use WordPress Categories combined with assigned CSS classes to style posts. Coincidentally, Tumblr launched in February 2007 and introduced a beautiful new way to publish content. This review by LifeHacker shows the layout for creating different types of content. I was part of the mob that hopped onto the Tumblr bandwagon coming away from that experience very impressed with how easy it was to publish content. I didn’t have to worry about tags, categories or any of that meta stuff. It was simply pick a type of content, provide content, publish. What a joy that was. The best feature of Tumblr was their bookmarklet. This bookmarklet I feel is one of the biggest reasons for Tumblrs success.
WordPress on the other hand has this bookmarklet called PressThis. It works in a similar fashion to the Tumblr bookmarklet but because of the publishing process on WordPress, it was never as elegant or convenient to use. Using PressThis, you have to select a category for the post, usually have to edit the title and most of the time had to edit the link text not to mention the addition of tags. In May of 2010, Mashable conducted an interview with Matt where one of the topics discussed was the PressThis bookmarklet. Around the 2:06 mark in that interview, Matt says that Tumblr did a beautiful job of removing that little bit of friction to publishing content which he hoped would be similarly achieved with PressThis.
Once post formats reached the masses with WordPress 3.1, the general community had the task of explaining what post formats were and to this day, it’s still a struggle without being able to visually show someone. People were so confused with the terminology, Mark Jaquith and Otto both published posts with explanations. At the time, I thought post formats would be awesome because of the Tumblr like inspiration but as users, we had to rely on Themes for how the formats were used and displayed.
I used post formats for a few months on WPTavern.com and I’ve made a few conclusions. The first is that post formats encourage short form content. Not only is short form content easy to do, it also promotes creating a fire hose of content. The second, the majority of people were reading WPTavern.com via their favorite feedreader. Feedreaders don’t display content the same as a website. Third, some of the formats I selected displayed on the home page without a post title or an ability to comment. I think this had more to do with how my theme was displaying the formats more than anything else. Last but not least, I started treating post formats as categories.
Some of my frustrations with post formats came at the cost of not fully understanding the when and why of the feature. I’ve also discovered that depending upon how the formats are displayed, it’s very difficult to determine what’s content and what’s something else. I’m so used to seeing the Post Title, content, post meta layout on websites that when I see a posts that are quotes with little text, it sometimes becomes difficult to navigate. A good example of this is the 2013 Theme.
I no longer use post formats. Instead, I just write a normal (standard) blog post containing a quote, video, image or anything else I want. Creating different styles for different types of content was cool but now, it’s not a big deal anymore. I’d rather see a consistent style for the content I consume and create versus wildly different layouts, colors, and expectations.
I want to hear from developers and consultants on how they teach post formats to clients. How do you make the distinction between the different kinds of posts that can be created? What do you think of the revamped UI for post formats in WordPress 3.6, will it get more people to use this feature?
You might have heard about WordPress turning 10 years old on May 27th. To celebrate local WordPress communities around the world are having anniversary parties on May 27th, 2013. This includes the greater Salt Lake City, Utah area. The details are at http://www.meetup.com/WordPress/Salt-Lake-City-UT/930892/:
When: Monday, May 27, 2013, 7:00 PM
Where: Sonny Brian’s; 33 East 11400 South in Sandy
If you are coming be sure to RSVP so that we have an idea of how many people to expect. Bluehost is also giving away the 10th Anniversary WordPress t-shirts to the first 30 people who fill out this form on wpslc.com.

It will be a fun time to hang out and chat with other local WordPress fans/users/designers/developers.
On my recent article discussing the search functionality within WordPress, a few folks in the comments suggested alternatives to try. One of those was the ElasticSearch plugin. My main complaint in that article was that there was not an easy way to tap into the Elastic Search service without having access to a dedicated server or VPS. This is where SearchBox.IO comes in handy. SearchBox.IO is a cloud based search platform powered by the Elastic Search technology. While there is no mention of a WordPress plugin on their site, one does exist.
Installing the plugin from the repository was easy, once I found it. After installation, you’ll need to connect the plugin to the Searchbox API server. On the configuration screen, it’s not obvious as to where you would get the API key. However, the installation instructions on the WordPress.org plugin page tell you where to go. Once you sign up for a free account, you’ll need to copy and paste the Connection URL: provided into the Elastic Server url box.
Once a connection is established, you’ll see a green server status indicator. The next step is indexing posts. Before you click the Index button, you’ll need to make sure that the Default Post Index Name within the Indexing Configurations matches the index name on your Searchbox.IO account. By default, it’s WordPress but I changed mine to WPTavern. It’s worth noting that the free account only allows one Index, 3,000 documents, 10 MB of storage and something called a sleepy index. After the site is indexed, you’ll want to visit the widgets section and place the Elasticsearch Facet Widget at the top of the sidebar. It will only be displayed when someone searches your site.
The widget adds the ability to narrow down a search via Tags, Categories, or Author. At this point, it’s difficult to tell when your site is using Searchbox.IO for the search query or if it’s using the local database. I have not found an easy way of figuring this out. I did send in a support query asking for some clarification, here was the response:
Q: I’ve installed and configured the WP-Elastic search plugin. However, I am having a hard time figuring out when searches are offloaded to the Searchbox.io service versus when my local database is polled. Could you please clarify this for me?
A: Plugin simply searches at searchbox and executes get requests to mysql with returned ids. Hope it is clear, let me know if you have more questions.
I have no idea what that means so if you do, please tell me in the comments.
After everything was said and done, I couldn’t tell whether the searches I performed were any more relevant than the default search in WordPress. However, this plugin tied into Searchbox.IO does add the features I’m looking for in a more advanced WordPress search. One thing I really didn’t like is that each time a check box is selected for a tag, category, or author, it generated another search query. This doesn’t make any sense to me. I’d much rather see an implementation where I can configure those parameters then click on a search button or hit enter. This plugin along with the Searchbox.IO website could use more polish. It would be nice to see an entire page on their website dedicated to WordPress that explains what the plugin does, how to set it up and ultimately, how to know if it’s working.

Today VaultPress announced the Code Garage migration details. We really wanted to make sure that we had the details and options on this right. I know that migrations like this can often be annoying, so we went out of our way to make the process smooth and inviting.
Code Garage users that migrate to VaultPress will get their first two months on VaultPress free. For those who don’t want to migrate, we’ll refund your last payment.
Even if you aren’t a Code Garage customer, you should go read Peter’s CodeGarage Locker is Migrating to VaultPress post. He gives a personal history of how Code Garage came to be, how it grew, and how it ultimately was sold to Automattic.
This is an aggregation of blogs talking about WordPress from around the world. If you think your blog should be part of this send an email to Matt.
For official WP news, check out the WordPress Dev Blog.
May 24, 2013 02:45 AM
All times are UTC.