Andy Peatling has announced on the official BuddyPress development blog that version 1.2 is now available to the public. This version is a milestone because BuddyPress can now be used on standard WordPress installations whereas before, you needed to have WordPress MU installed. Other goodies that 1.2 offers include:
Simplified Install Process – This version only uses three steps and has done away with the manual installation routine.
New Default Themes – Andy Peatling must have drank the default theme kool-aid as 1.2 sports a new, out of the box look.
Activity Streams – Activity streams have been revamped. Each activity stream item has it’s own permalink making bookmarking or saving the event much easier. Any user can comment on activity across the site with support for threaded conversations. You can also publish events to a group activity stream or site wide while also marking activity items as favorites.
If you don’t want to test BuddyPress by installing it on a live or local site, take a gander at the BuddyPress Test drive website which is using the latest version.
Congratulations to Andy Peatling, John James Jacoby and everyone who contributed to the release. It seems like it was only yesterday when 1.0 was released where the most requested feature was support for standard WordPress installations. Now that BuddyPress can be used on regular WordPress sites, expect to see BuddyPress empowering the social nature of WordPress sites all across the web.
Not only has Michael Torbert taken some heat with the commercial version of All In One SEO Pro but I’ve also taken some myself thanks to the podcast advertisement and the banner in the sidebar. The biggest argument I hear from everyone is that it does exactly the same thing the free version does except it has no ads. So where is the value? Why is it worth paying for? The answer is easy. To remove the ads and donate link, the support is only part of the package. But I’ve been thinking, what is the difference between software that is ad-supported which provides an option to pay to have the ads removed and AIOSEP Pro? I did this with FeedDemon and the program is exactly the same before I paid to have the ads removed. I don’t see anyone lining up with pitchforks to go after them. If what FeedDemon does is acceptable, why is a WordPress plugin so different?
I think that the switch from being free to commercial is what has people in a fit but that’s just the nature of plugins this year. It’s his choice to make as it is for all plugin authors. There are two easy ways of solving this problem. Pay to have the ads removed or use the ad-supported version.
The other complaint I’ve heard is that the $39.00 (sale price) is a monthly fee. I can not verify if this is true but if it is, I would complain as well. I think that has to do with the system WPPlugins.com has setup and hopefully, they build in a way for plugin authors to be more flexible with the types of models/payments that can be received.
Mark Jaquith has published his tongue in cheek version of guidelines that plugin authors should NOT DO or else the plugin would end up being removed. The list is not comprehensive and does not include all situations in which a plugin would be removed but the advice Mark gives at the end of the post should be heeded.
Be cool, think of how your plugin benefits its users, and write awesome plugins.
Also read through the comments, especially for Mark’s take on #5.
While at work the other day, I thought about how I have not added any new plugins for additional functionality to this site for a long time. The most recent ones being After The Deadline and WordPress.com stats. Other than that, I’ve been pretty darn happy with the features I’ve added to this site thanks to the plugins I’ve chosen to use. WPTavern has 31 active plugins in use. Some add functionality such as WP-Polls while others give me something small such as the ability to have post author comments highlighted a different color. Sure, this could be accomplished from within the theme, but I don’t want to.
Matt has stated at numerous WordCamp events that the average number of plugins active on a WordPress site is around five. Considering the breadth of plugins available in the repository, it’s likely that no two WordPress’s are the same. When I stop to think about that, all I can say is awesome! The 31 plugins I have installed make up the total functionality that I want WordPress to have that I don’t have to force down anyone’s throat. The only time I add plugins to WPTavern now is if I need to test a plugin because it won’t work on my local server. Could things be improved in WordPress? Of course. But, WordPress 2.9.1 doesn’t really pose any problems for me in terms of publishing content. I’m pretty happy with how things are right now.
At any rate, this is just a reflection I had the other day. Are you one of those Pressers that continuously add and remove plugins as time progresses or have you stuck with the same core group of plugins you use on all the sites you administer?
Chip Bennett has an interesting post on his site that shows results of an audit he performed on some of the most popular plugin authors to see if they declared what license the plugin is under within the plugin in the form of a license.txt file or from within the plugin header. As we’ve found out recently, due to an event that occurred with a plugin author, plugins that are in the repository MUST include the license declaration or face removal. Let’s take a look at the guidelines as they are written on the repository.
Your plugin must be GPL Compatible.
The plugin must not do anything illegal, or be morally offensive (that’s subjective, we know).
You have to actually use the subversion repository we give you in order for your plugin to show up on this site. The WordPress Plugins Directory is a hosting site, not a listing site.
The plugin must not embed external links on the public site (like a “powered by” link) without explicitly asking the user’s permission.
None of them explicitly state that license declaration has to be included within the plugin. Out of all the stats that Chip published regarding his audit, the most surprising thing of all is that out of 19 plugins written and maintained by Matt Mullenweg, none of them had proper license declaration. The bottom line here is that if you’re going to enforce guidelines, preferably written, you will have to lead by example and follow those guidelines yourself. Not doing so is unacceptable. As it stands, this looks pretty darn bad.
The good news is that the solution to this is simple. The readme.txt text that plugin authors use as a template for the repository is currently silent when it comes to license declaration. All it would take is for someone to add the necessary text to the readme.txt generator. Peter Westood weighed in with a comment that is an even better idea. Using a slug type approach for the License field so that it could easily become part of the automated checks that take place upon submission to the repository.
This specific topic has been added to the WordPress Developer meeting for February 11th, 2010. If you are interested in attending to voice your thoughts, visit the WordPress development prologue site for meeting details and the overall agenda.
While monitoring twitter today, I noticed a few prolific theme designers agree with a point that Chris Pearson made today.
Now that I’ve built the platform, I see why Thesis can do plugins’ jobs more efficiently than the plugins themselves. There’s no comparison. – pearsonified
I think I understand the reasoning behind the statement. Instead of using a plugin that may have more functionality than is needed, ONLY the functionality that is needed can be built into the theme making more efficient use. However, I’ve always been a fan of the idea that themes should be about good design alongside flexibility while leaving anything that can be handled by a plugin, to a plugin. Sure, a theme that provides all sorts of plugin functionality built-in provides a ton of convenience, but the distinct difference between a plugin and a theme is that when the theme disappears, the plugin and it’s options are still there. The same can not be said for a theme. What’s the difference between putting a wall around me, and building in a bunch of functionality that is typically left to plugins? I don’t see much of a difference. If the theme is built in a way that semi-locks in the user, that theme is doing it wrong. But, I’m not the one with a theme business so perhaps I’m wrong.
At the end of the day, the user has to decide on whether they want convenience, or flexibility.
Should Themes Contain Plugin Functionality Built-In?
Carl Hancock who is part of the team behind GravityForms asked an interesting question on Twitter the other day.
What do you prefer for software support? A support forums or a good FAQ and a support ticket system?
I thought it would be nice to expand on the question so that we can answer it with more than 140 characters. In the past, I’ve really enjoyed working with software that has an in-depth FAQ because I enjoy solving my own problems. I think the more avenues for support, the better. However, if you are offering so many ways to receive support to the point where it’s decreasing the overall quality of support, then you introduce a new problem. I’d rather go to one place that I know is going to give great support and not spend time with four or five different methods that are sub par. There is no reason though why a good FAQ can’t compliment either a ticketing system or a forum, although one could argue that a forum fills both needs. I’d to hear what you think is the best method of support based on experience.
Last but not least, do not use the commenting form on a blog post to provide support. Nothing like traversing hundreds of comments to see if one is similar to the problem I’ve having.
Although I’ve thought about this issue endlessly, including most of the issues raised here, there are some things brought up in the comments that I haven’t thought about before. More importantly, you could be right.
That’s why we’re doing this whole thing as an experiment; not the Large Hadron Collider type that could potentially destroy the universe, but more incrementally with just three initial plugins.
Now if in the course of working on these three plugins it looks like we’re going to cause the end of WordPress as we know it, we’ll change course. It’s not that big a deal, and we’ll figure something else out. The only dangerous course of action is doing nothing at all.
That Matt guy. Always showing up in interesting conversations related to something dealing with WordPress with a calm, cool head. How does he do that? It must help when you know for sure what is going on. His comment is the first I’ve heard of Core Plugins being an experiment. It’s also the first time I’ve heard someone clearly spell out three different types of core plugins that will be part of the experiment. An abandoned plugin, a newly created plugin, and functionality taken out of WordPress and put into a plugin.
So far, the discussions surrounding core plugins have been as if everything is set in stone. We now know that is not the case. There is no guarantee that core plugins are going last or if they will prosper. The way Matt presents how core plugins are going to be used brings me back to a calmer state and I think we should watch the experiment take place and see what happens.
Scott Reilly, also known as Coffee2Code has been busy as of late churning out plugin updates. This guy some how continues to find a way to maintain about 60 plugins. Some are simple while others provide awesome functionality. To hear more insight in to how Scott does it, check out this interview I did with him back in August of 2009. Also keep an eye on Coffe2Code.com to see if any of the plugins you use by Scott have been updated.
News is spreading around the community that the plugins created by MaxBlogPress have been removed from the plugin repository. Apparently, his plugins contained a forced opt-in mechanism that is, once you installed the plugin, you had to provide a name and email address in order to activate the plugin. Based on numerous complaints over the span of the last three months on the WordPress.org support forums, the plugins were finally removed. After getting the end users email address, the marketer would send email marketing messages sometimes daily without an easy way to unsubscribe.
Not only is the forced opt-in a terrible way to do anything, but it acts as a usage restriction of the plugin which violates the terms of being hosted on the plugin repository. I think Bobby Ning sums up the reasons for removal quite well as does Otto in the WPTavern forum.
If you take away the marketing and phone home aspects of his plugins, it looks like they provide good functionality. Since the plugins have been taken off of the repository, I wonder how long it will be before someone who really valued the plugin ends up creating a fork, minus the marketing stuff and submits that to the repository as a replacement. So far, it looks like Chip Bennett has done that to at least two of the plugins.
Andy Peatling has announced on the official BuddyPress development blog that version 1.2 is now available to the public. This version is a milestone because BuddyPress can now be used on standard WordPress installations whereas before, you needed to have WordPress MU installed. Other goodies that 1.2 offers include:
Loading ...
Scott Reilly, also known as Coffee2Code has been busy as of late churning out plugin updates. This guy some how continues to find a way to maintain about 60 plugins. Some are simple while others provide awesome functionality. To hear more insight in to how Scott does it, check out 
