16 Comments


  1. It would make sense, if a new repository was started under new policies and validation. Then, once a significant amount of plugin authors had migrated, the old one be shut down.

    To go through the current repo and all the plugins would take a considerable amount of time. Maybe plugins that have been checked could just get a “Verified” logo in the listings, or something of that nature?

    Tons of ideas floating around, hopefully we can get some answers in today’s dev meeting.


  2. Other than the time factor for volunteers, probably one of the reasons that something more formal hasn’t been implemented is that some plugin developers would be more inclined to host the plugin themselves.

    We host some of our own. For example, I have a login widget which I’ve maintained since WPMU 1.2. When I wrote it there wasn’t a repository. Now there are 3 or 4 other slightly different login widgets in the repository. So, I haven’t rushed to add it.


  3. For now, many security consultants offer code-reviews and fixes for problems like these. If the WordPress community does make it too restrictive, it will have the same image as the Linux kernel development community – a place where you can try and try harder but can’t get your plugin out there unless you’re lucky. That’s what has been happening with the Apple iPhone AppStore.

  4. trent

    there also needs to be a way to search through plugins that are compatible with the current version of WP. I’ve been looking for different things, and you always have to look under the junk that piles on top. By junk, I mean plugins that don’t even work with 2.8.4


  5. I’d say this would be on the Important but not Urgent list. They’d definitely have to pay someone to keep up with it though. Possibly going back to the older, less popular plugins and do them first. Maybe even cut off access temporarily. That way they can clean up plugins not in active use to disturb the least amount of people at a time.

    Ron & I were just discussing about maybe even better idea is to have approved plugin frameworks for plugin devs to learn from properly the first time around. many of us got our feet wet by example code. If you start from a bad or unsecure example, you’ll just write more.


  6. @Ron – I didn’t mention it but that is probably the largest deterrent for this idea. However, why does phpBB3 have a group of people dedicated to performing these roles for free on their time. I think WordPress could do the same. Don’t know who would want to do it though.

    @Nitin Reddy Katkam – I wouldn’t want that to happen and if handled correctly, it wouldn’t happen. But I see where you’re coming from.

    @Andrea_R – The only reason it is not urgent right now is because none of the worst case scenario has happened yet. I think for it to work and to get a team together, money would have to be involved but I’m not sure Automattic and its investors would like to put money down that hole.

    Approved plugin frameworks is something I haven’t heard of. But I think that is a large part of the problem. Crappy coded plugins in the repository which work but don’t work in the way that they should and then others coming along using those as examples to build on. This is a bad domino effect where at some point, those dominoes will fall.


  7. @Scott I agree with the secondary repository that would have enhanced features like searching on additional fields like version, author, update date range, screenshots available and better categorization than the current tags. WordPress.org could link to this additional site with enhanced features/security/testing which would encourage developers to submit their plugins (for more targeted exposure). They might even have a section for non-GPL and search on that field as well.

    @trent I thought of creating a page on my site just with Google custom searches for the repository because I’ve had to build these searches to ensure I was getting the best plugin for the task. I saw one site that had done this with their own collection of plugins, but not linked to the repository (so the data was old). This seems like a simple interim fix that I’ll get around to at some point. I’m just getting started. Maybe Jeff wants to do it.

  8. Andrew

    I seem to recall a discussion a little while back abut optional standards which authors could build to which would given them the right to state they develop according to that standard.

    It is self-certification, but, as with web standards, these sorts of standards would be a good first step to letting users know that the developer cared to meet those standards.


  9. I think leaving the repository open with some behind the scenes code validation makes the most sense. I haven’t seen a deliberately malicious plugin yet, and I have a feeling if it existed it would get pulled down pretty quickly.

    I think the fundamental reason why WordPress has gained the popularity that it has, is because even a novice can join in and learn with the pros. Everyone is at a different stage of experience and knowledge, and there are bound to be flaws and bugs in just about every plugin out there when someone higher up the ladder looks down at it.

    I agree that the “just because it works doesn’t mean it’s right” philosophy is one that as a developer you have to adopt fairly quickly, but not everyone has the resources to have their plugin combed through.

    What I would hate to see is for the repo to follow the iPhone Store way of life and start rejecting or removing plugins. WordPress has always respected its legacy and the code it left behind, so if a stagnant plugin is sitting there and maybe needs some TLC, in our GPL open source world someone is free to pick up that lost code and give it a new home. If plugins were removed or rejected, that option disappears.

    Imagine the kid that’s submitting their first plugin to the repo, waiting anxiously to show their friends what they did, only they get an email two days later saying it was rejected. With that kind of setup, it breaks their spirits and maybe makes them stop trying. With the current setup, they submit their code to the repo and if people download it they can give feedback to the developer via the wp.org forums, so that kid can learn from their peers and grow to be a better developer.

    If there’s going to be a community of developers combing through plugin code looking for vulnerabilities or exploits, I hope it’s a positive experience for everyone and it’s treated like the customer service/public relations interaction that it is and that it happens pretty transparently.


  10. Interesting thought Jeff. The time is naturally going to make this hard to implement, but from an end user standpoint it makes a lot of sense.

    @Ron – think of extensions for Firefox. Some host extensions on their own sites instead of through the addons at Mozilla. As an end user I feel a little more secure installing them from Mozilla, but I’ll still install directly from developer sites.

    The majority will probably get plugins directly from WordPress, certainly those who would most likely benefit from having the plugin code go through some kind of validation.

    Perhaps WordPress could give more guidance as to a set of standards for developing plugins and only those plugins adhering to the standards could be accepted into the repository. It doesn’t solve the problem, but it could be a step in the right direction.


  11. Why not learn from how projects are handled on github. That way everyone can check the code while it is in the repository and can easily fork etc and everyone is in the open.


  12. The main issue with reviewing is, obviously, time. I don’t know if I’m slow or if there are tools to automate parts of what I did but it took me 30 to 60 minutes to review a plugin. That’s more than 1 year, doing this 9 hours a day, if you want to review the 6500+ plugins for the repository. Not counting the countless plugin upgrades of course.

    (Also, don’t assume that if trivial coding errors were spotted in the competition, things would be worse in the repository. It would be the same proportions I think, some contestant were obviously novice coders, some were skilled guys, just like the people who submit to the repo.)

    I’m often a guy who sees the “that’s not possible” part of thing, but I don’t believe a validation team is possible, I mean volunteers who would check for vulnerabilities and other potential nightmares. This idea has been thrown a couple of times in the wp-hackers mailing list over the last few years, without gaining any real traction. There’s just too much time needed for such a task.

    Now, there might be a team of, say, accredited consultants who could be hired to review plugins and give an official badge stating that the code looks good, but who would pay for this? Who to chose for such a reviewing task? Who to sue if you install a validated plugin that eventually contains a security hole and get your blog hacked?

    This said, I’ve had a couple request for code review since the plugin comp. I’ll let the idea bounce into my mind for one or two days and maybe post something about it :)


  13. This is something I have been musing for a while and don’t think it is something that should necessarily be a centralised thing which is done by a team.

    I think we need to build into the work-flow more social/community features so that:

    It is really easy to report an issue to the person that can fix it – i.e. the plugin author
    It is really easy to keep track of the developments on a plugin – there are feeds etc which can be leveraged (http://blog.ftwr.co.uk/archives/2009/09/10/feeding-on-feedback-and-progress/) but it would be nice for this to be even easier.

    I would like to have the time to review more plugin code as I think the best way the community of developers can learn and the code quality can improve is constructive feedback and best practise documentation.

    In my wildest dreams I would like to dedicate as much of my time as possible on making plugins better – but some things, like $dayjob and earning money, get in the way!


  14. @Ozh – good point about the potential liability held by a reviewer.


Comments are closed.