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.
Thesis creator Chris Pearson was the special guest on last weeks episode of the WordPress Community Podcast with Joost de Valk and Frederick Townes. There is at least one sticking point in the conversation that I can readily agree with Chris Pearson on and that’s the lack of synergy between the front-end and back-end of WordPress. Just about everything requires you to log into the back-end of WordPress to do anything, whether it be editing a post, a comment, a text widget, etc. One of the coolest things that SquareSpace offers over WordPress is the ability to manage most of the site from the front-end. Not only is this a major time saver, but it just makes sense to have certain tasks be accomplished without having to go through an administrative interface.
I know there is a plugin that bridges the gap right now called Front-end Editor by Scribu and I think some themes can accomplish this goal but at some point in the future, this synergy between the front and back-end of WordPress will happen and it will be a big shift in efficiently managing a WordPress site. Going through an administrative interface to accomplish anything is the OLD way of doing things. I’m ready for the NEW way!
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?
Quick update on the menu management progress
WooThemes is currently reconfiguring their menu management system into a patch that can be integrated into the core of WordPress. Once the patch is committed, everyone can try it out and weigh in with their concerns or improvements. The patch may be ready by some time next week. Expect to see a possible case study somewhere down the road on how a wp-based commercial business can work in harmony with core rather than competition.
Quick discussion on the best way for plugins to be explicit about which license they are under
This was quite a discussion but in the end, here is the end result. The Writing A Plugin Codex page has been updated to include a License: Slug as part of the standard plugin information header. The first restriction for getting into the repository has been reworded to say the following: Your plugin must be GPLv2 Compatible. Promotion of best practices which is an ongoing effort.
Now there was extensive talk regarding whether GPLv3 plugins are or are not allowed to be hosted in the repository. Many of the answers I saw said NO because GPLv2 is not compatible with GPLv3. Therefor, I put this information out on Twitter but I was reminded of the fact that this is not set in stone. It’s based on a bunch of assumptions which in my opinion, sums up the GPL pretty good. A bunch of assumptions. But unless I’m told otherwise, which is guaranteed to happen, I wouldn’t try hosting your GPLv3 plugin in the repository.
Update on schedule compliance
There is some UI stuff that needs to be taken care of between the Menu management patch and the WordPress Multi Site stuff. I think feature freeze will happen on Monday as per the dev schedule. You’ll need to review the log file for more details as it was hard to follow the conversation
Update on improvements to Extend for plugins
mdawaffe is currently the lead man implementing improvements for plugin authors. When asked what those improvements are, here is what he told me, expose some of the stuff locked behind the admin tab to everyone, feedback on why plugins were rejected, better tools for our plugin moderators, looking into how to better display multi authors. The feedback mechanism will also help with plugins that get suspended due to a violation. Ptah Dunbar brought up a good question that has been discussed on the hackers mailing list before regarding plugin authors having the ability to remove their plugins from the repo. Right now, their is no good mechanism to accomplish this.
License And Other Stuff
I highly encourage you to read the log file for this meeting, especially all the parts regarding licensing so that you can go as crazy as I did. Also read what happened after the meeting as the conversation is quite good.
How To Participate:
If you want to suggest a topic to be discussed at the next meeting, you can by visiting the WordPress development updates blog. If you would like to participate in the chat next week, install IRC or an IRC compatible client and connect to the following IRC server.
chat.freenode.net or any random server on the Freenode network and then join this channel at 3:30PM Eastern time or 20:30 UTC Thursdays. #wordpress-dev.
One topic that has been discussed a number of times during the development cycle of WordPress 3.0 is how to handle menu management. At first, it looked like the team was going to go with a widget based menu management system but during one of the most recent meetings, that was put on hold to evaluate if that was the right thing to do. Today, we’ve learned that the debate is mostly over and menu management will take the form of the Woo Navigation Menu system. If you’ve never seen it before, watch the video.
Based on what I’ve seen in the video, the menu management system looks like it will be very easy to use. A big kudos goes out to the WooThemes team for allowing their navigation system to be integrated into the core of WordPress for the benefit of all users. A classy move by them. Keep an eye on Woothemes.com as they will be publishing more info about this development on Monday.
Back in episode 82 of WordPress Weekly, a round-table discussion took place centered around the topic of the WordPress Beta testing conundrum. In that conversation, we discussed why critical bugs were found only after the so called stable release was offered to the public. The answer to the problem is more beta testers, but getting those testers is hard. Stephen Cronin of Scratch99.com takes a hard look at the problem and his proposed solution I think has merit and is worthy of more discussion.
Live user testing with staged releases. Companies such as Google use this method to roll out features over time to a select group of users for live testing. This gives them a chance to iron out any kinks in more environments and use cases rather than going through a strict beta testing team. Perhaps the same method could be used on WordPress where 100,000 or so installs receive an upgrade notice that explains that a new feature has been added and then asks if the user wants to participate in the trial of that feature. If any problems are discovered, to report them. Now I don’t think it’s a good idea to put people on Trunk versions of WordPress but the way Stephen explains it, the version of WordPress would be kept the same, only when the feature has been coded into WordPress and is ready for testing would the trial upgrades go out to the public.
There are definitely some logistical issues involved with this entire process but I’d like to see the idea discussed in an upcoming developers chat to see if it has legs. What are your thoughts on this method?
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?
It’s become evident that a large portion of the WPTavern readership is made up of consultants. This next plugin should be right up their alley. It’s called Technical Support and is authored by Konstantin Kovshenin. The plugin provides a dashboard widget that after configuration, gives clients an easy way to contact you for support. After install and activation, you’ll need to configure a couple of fields such as provider name, provider email address (this is where the support queries will go), provider logo and provider URL.
The next step is to customize the technical support widget. From here, you can add or delete topics such as General Support, etc. You can also customize the default E-Mail Subject line which is nice since you can then add that subject line to a filter within your favorite e-mail client. Last but not least is the configuration of the message format. You can reword the default text while also rearranging the shortcodes available.
After I saved the configuration, I added the widget to my dashboard.
The email I received provided all of the necessary information I configured. Worked just as expected. Note that if the site this is installed on can not send email, neither can the plugin. As for the other side of the equation, I don’t know how to respond back to the ticket author. Therefor, this is not a good means of two way communication. However, this is a great way to notify the person in charge of issues that have sprung up such as an error.
Loading ...
