A few days ago, Sucuri mentioned that the Absolute Privacy plugin for WordPress contained a security vulnerability that would allow the ability to bypass the authentication mechanism and gain admin access to the application, that being WordPress. The plugin was subsequently pulled from the repository as there had not been any updates to fix the security issue for well over a year. Today however, the plugin can be found within the repository again as the security issue has now been fixed.
500 Plugins To Possibly Be Purged From The Repository
It’s been awhile since we’ve had a discussion revolving around those three magic letters GPL. It looks like we’ll be talking about it again considering that somewhere around 500 plugins run the risk of being purged due to their incompatibility with GPLv2. There has been an ongoing discussion within the past 11 months regarding various licenses and what is and is not compatible with what WordPress uses. It looks like the core team has been monitoring the discussion considering Andrew Nacins comment:
The core team plans to discuss plugin directory licensing once none of us are sick or traveling. So, expect an update here in the next week or so.
The arguments have been laid out, so no need to continue to do so. Not trying to stifle discussion, but, you have all made your points.
Jane Wells also participated in the tract ticket discussion:
I would think we would want everything on wordpress.org to have consistent and compatible licensing. If we’ve moved away from that, is Matt aware of it? (I wasn’t.) He’s always said in the past that anything promoted (including being hosted) on wordpress.org needs to be 100% GPL, and said that no one should ever have to wonder what they can/can’t do with something we host, because the license would be the same/compatible.
I also think the end goal for WordPress.org would be for consistency across the site with regards to licensing. No one should have to guess or worry about which license a particular piece of code is using if it’s being hosted by WordPress.org. At the end of the day though, it looks like license consistency is easier said than done.
*Update*
Until the guidelines have been thoroughly reviewed and discussed amongst the core team, Plugins that violate the current guideline but are compatible with GPLv3 will not be de-listed.
Congrats To Emil Uzelac
For recently joining the 700 club. That number represents the amount of themes he has reviewed since joining the WordPress theme review team! Thanks goes out to Emil for volunteering his time to make the theme repository a better place. Out of curiosity, after reviewing 700 themes, I wonder what sort of patterns or similarities exist between them all that Emil could share.
If you’re interested in joining the theme review team, read the following guide to get started.
Plugin Repository Should Have A Favorites Button
@WraithKenny – #WordPress plugin repo should have a favorites button. – via Twitter
Now THAT’S a good idea! Stretch it further by giving us the option decision to make our favorite lists private or public on WordPress.org. There are all sorts of things you can do from there on in.
Tips On Creating A Good Plugin Readme.txt File
SmashingMagazine has a great article that covers some tips on how WordPress plugin authors can create better readme.txt files. While the code within the plugin is important, the readme.txt file is what users are going to encounter first. It’s the means by which we discover plugins within the repository so it’s important that relevant information be written within the file or else you’ll end up with no one using the plugin. I’m happy to see that amongst their tutorial, they included how to add a changelog which is still something many plugin authors are failing to do. Speaking of changelogs, plugin authors should write them in such a way that the latest version appears at the top of the file and not at the bottom. Too much scrolling is a bad thing! ∞
Naughty Plugins Caught And Removed From Repository
Siobhan McKeown has published a disturbing yet not out of the ordinary article that explains how a couple of plugins were recently added to the plugin repository that were using a version of J-Query from J-Query.org which after investigation proved to be a fake website. The purported J-Query file was actually propagating sites with CPA Infinity Affiliate Links. After the article was published, Otto responded in the comments to make note that the plugins were removed and the user who uploaded them has been banned. This is yet another reminder that the WordPress plugin repository is a powerful place to do naughty business for those that can get past a couple pair of eyeballs and not get noticed right away.
For the future, Otto recommends doing the following if you spot something malicious within a plugin on the repository:
Obviously malicious code doesn’t last long before somebody spots it (this one only lasted a week before somebody noticed, and it would have been removed that same day if anybody had reported it to us at plugins@wordpress.org), but unintended security holes can become widely propagated for a longer period of time, leading to issues when hackers find and exploit them. So they are of a somewhat higher priority to find.
Apparently, reporting offending plugins to that email address gets swifter action than anything else. Although not related specifically to this story, I think it’s good to be reminded of June 21, 2011 when a number of suspicious commits were made to popular plugins after hackers gained access to the plugin repository. Thankfully, those commits were caught in a short period of time but there is no guarantee that they would catch them in time again.
Video: Developing/Submitting Themes To The Repository
The following is a presentation by Chip Bennett at WordCamp Kansas City 2011. In this video, Chip Bennett explains the entire process of what it takes to get a theme hosted on the WordPress.org Theme Repository. Pretty awesome to see Chip go from being a vocal member on WPTavern within the past year or so to really getting involved with the WordPress community overall. Not only has he stepped up and has volunteered his time for the WordPress Theme Review Team but now he has a couple of WordCamp visits/Presentations under his belt. The only thing missing from Chip now is some sort of book!
Here are the slides that go with this presentation via Slideshare.
Revamping The 404 Page For The Plugin Repository
WPBeginner has laid out an interesting question. Do we need a better 404 page for WordPress plugins repository? They think so and I do to. I’ve experienced the issue of clicking a plugin link only to be redirected magically to the plugin repository page without any explanation as to why. From here, I perform a search to find the plugin that I was linked to only to come up empty. In my opinion, the 404 page on the plugin repository should give a few explanations as to why the plugin was not found. It could have been its removal, its suspension, or a bad link but at least give a little explanation. I especially like the idea presented by GraphicsCove in providing a list of 3 or 5 similar plugins. I’d also like to see a little bit of Matt’s witty humor. What better place to put it than on a 404 page.
If you had the opportunity to create the 404 page, what information would you present on it?
Plugin Quality Not Plugin Quantity
Ryan Imel of WPCandy.com has published an editorial that has sparked yet another good discussion. This time, the focus is on the misnomer that it’s better to keep your active plugin count as low as possible to avoid problems.
I’ve been down this road before. In at least a couple of the WordCamps I’ve attended where we discussed plugins, I would tell folks that I had almost 30 active plugins running on WPTavern.com. Judging by their reaction, you’d think I just dropped a bomb on them. In my defense, those 30 or so plugins enabled me to have the functionality I wanted within a WordPress installation. For the most part, these plugins have caused me 0 problems. The total number of active plugins has varied between more than 30 and less than 25 over the past four years but I’ve never had more than 35 activated at one time. After 4 years of using WordPress, my activated plugin count has remained nearly the same for two reasons. The first is that I’m pretty content with the functionality I have. The second is that I’m not the adventurous type who likes to try every plugin known to man.
The funny thing about this discussion is that, you could have 3 plugins activated with one of those causing your site to hang. Or, you could have 25 and your site loads in less than 3 seconds. As Ryan mentions, the number of activated plugins doesn’t matter so much as the quality of the code within them. This conclusion leads us into an entirely different subset of circumstances. For instance, how do you judge the quality of a plugin before installation? How does one know if a particular plugin doesn’t play nice with some other plugin? Are we to sit here and expect end users to know good code from bad? From my perspective, if I activate a plugin and it provides the functionality it says it does, I generally don’t go under the hood to see how it’s done, just as long as it’s done without any apparent issues.
In a perfect world, we should be able to activate 100 different plugins from a variety of different authors and have them all work seamlessly without any problems. But this isn’t a perfect world. It’s open source. It’s the wild wild west of coding. Sure, there are coding standards for WordPress, but not everyone is going to follow them. Not everyone is going to do things the way they should be done because it’s an open world. A plugin review team that works similarly to the theme review team is non-existent allowing plugins that don’t have malicious code into the repository regardless of their code quality. So how does this problem end up getting solved for everyone involved? It doesn’t. We can continue to educate both users and developers until the cows come home but the very nature of how things work in this open source environment allows for bad code quality to happen. It’s the nature of the beast. I think that over time, the problem can become less of an issue but it will never go away. Not unless some major crackdown starts happening on the plugin repository. Educating plugin authors is a good way to treat one of the symptoms of the overall problem but screening code before it gets past the pearly gates of the repository into the hands of users is the only way to truly solve the problem. Just like the theme review team, until a plugin reaches certain quality criteria, it can not be allowed to be hosted on the repository. It may sound bad, but the repository gate keepers would be the ones educating plugin authors before their code is accepted so in the end, it would be win-win situation.
This could cause some plugin fragmentation in terms of where people go to get their plugins but that has existed for years. It might even cause a backlash similar if not, worse than the one generated from implementing the theme review team. But at the end of the day, something like this is good for end users all around. There certainly would be no guarantees that everything will work seamlessly after the team is put together but what it would be doing is increasing the odds of that happening in the future. It would also increase the number of plugins hosted on the repository that can be used as examples of plugins that did things the right way.
However, a plugin review team introduces it’s own complexities such as how many people will be on the team, will only new plugins be screened or all plugins pushing updates to the repository, will these volunteers be paid etc. The funny thing is, if only new plugins were screened on the repository, it would mean that potentially down the road, an update to that plugin would introduce shoddy code which in turn would break someones site.
After thinking about all of this, I start to wonder if it’s a case of “just can’t win“. Perhaps it’s best to educate users and developers as best we can and hope for the best?
Related But Not Required Reading:
Validating Plugins
Quality Check Your WordPress Plugins
Finding Quality WordPress Plugins
WordPress Plugins: How To Know If You Have Too Many
ThemeForest And The Theme Repository
Earlier this week, Jason Pelker wrote an excellent post for WPCandy.com entitled, How did ThemeForest become the red headed stepchild of the WordPress community? Jason takes a look at the various reasons for how this could have happened. However, the conversation turns pretty interesting in the comments when the discussion of quality control at ThemeForest takes precedence over the original question.
Personally, I have not mentioned ThemeForest on WPTavern because of the licensing issues. However, that is now not a problem as the PHP of themes on ThemeForest are GPL while the other components don’t have to be. I don’t do any business with the company as well which is another reason why I don’t mention them much.
The conversation in the comments was interesting because most of the complaints regarding ThemeForest were among some of the same complaints that are always mentioned when discussing the WordPress.org Theme Repository. The biggest issue it seems is that ThemeForest lacks quality control. With a repository containing a ton of themes written by various people, you’re going to run into problems, especially if there is not some sort of gatekeeper. Speaking of gatekeepers, that’s exactly what the WordPress.org Theme Repository has now in the Theme Reviewer team. Unfortunately, the theme reviewer team has taken some heat.
I’ve been in favor of establishing a plugin and theme review team since I became involved in the WordPress community. I saw the success such an idea had within the phpBB community and thought it wouldn’t be a problem for WordPress to do the same thing. Recently though, I’ve started to see a couple of theme authors pull their themes off of the repository or announce that future updates of the theme would discontinue because of the theme reviewing process. Without panicking, this is only a sign that the process is broken somewhat as the goal should not be to stifle development but create a learning process for theme authors. To the theme review teams credit, they are constantly refining the process as situations or ideas merit.
To bring this back full circle, we have ThemeForest which lacks quality control while at the same time, the theme repository on WordPress.org is complained about for having quality control. How do you solve the problem so that both parties can benefit? With regards to the WordPress.org Theme Repository, I think that the review process should be as automated as possible. At the very least, provide a Theme Validation tool where theme authors could upload their theme and the files along with the code structure can be analyzed for inconsistencies or the use of deprecated functions. As far as I know, something like this was already occurring before a theme was allowed on the repository but a tool like this would be more advanced and cover more code/functions. If the theme fails the validation, there are clear instructions on how to fix that with links to documentation if necessary. Once the theme passes validation, they are encouraged to submit their theme to go through the formal review process. Since the reviewers will most likely put the theme through the validation tool themselves to check the results, having the theme pass the validation on the first try during the review process is key to a speedy submission process for theme authors. At least this way, the reviewer just has to look at various bits of code just to see if there is any hanky panky that the tool missed.
The solution I propose is much harder than it seems since who gets to decide what a theme should have or it shouldn’t? Who decides on what basis the validation tool will accept or deny a specific function? At the end of the day though, I think the review process will be a win-win situation for WordPress users that depend on the repository for themes. As for theme design, well, that’s a different story.
To those on the theme review team, I thank you for volunteering your time and effort to help make things better for all of us, despite the rough edges the process currently has.