WordPress.org

Make WordPress Plugins

Recent Updates Page 2 Toggle Comment Threads | Keyboard Shortcuts

  • Ipstenu (Mika Epstein) 1:41 am on February 26, 2016 Permalink |
    Tags: , notice,   

    There’s a Revamp Coming 

    We’re overhauling and upgrading the repo. Interested? You can harass @obenland and team about it:

    Plugin Directory v3

    See you there

     
  • Samuel Sidler 8:33 pm on February 25, 2016 Permalink |
    Tags:   

    Re-thinking “Tags” in the Plugin Directory 

    Howdy all you wonderful plugin authors!

    As you may have read, the meta team is kicking off a rewrite and redesign of the plugin directory. As part of our work, we’re considering every aspect of the plugin directory, thinking through ways we can improve the experience for WordPress users everywhere. If you’re interested in following our work, follow make/meta.

    In considering tags, we looked at a few things that seem to make the experience less-than-ideal for users.

    1. Tags are freeform with a recommended maximum of 12. This leads to plugins “duplicating” tags in the hopes of moving to the top of search results. For example, “anti-spam” and “antispam” exist for Akismet. Freeform tags also mean that misspellings can occur.
    2. Tags are not localizable. If you’ve used the plugin directory in another language, you’ll note that tags are translated into those language. For example, the Japanese plugin directory has English tags. Users who attempt to find “スパム” instead of “spam” will have a hard time finding relevant plugins.
    3. Tags are inconsistent. Finding the best anti-spam plugins using tags requires looking at the “anti-spam,” “anti spam,” “antispam,” “spam,” “comment spam,” etc tags. This makes it considerably harder for users to find what they’re looking for.

    These issues have built over time. They’re not new, but they weren’t inherent issues when the plugin directory was first developed. Looking at a new plugin directory, we’d like to change things up a bit and do the following:

    1. Create a common set of tags. We’ll create this set by crawling all tags in the plugin directory and finding the most popular ones. From there, we’ll search for duplicates (e.g., spam vs anti-spam) and merge them together too.
    2. Allow plugin authors to set a maximum of three (3) tags for their plugins. While this may seem limiting, because we’re working from a common set, there’s very little reason to have a large amount of tags and no need to worry about duplicating tags.
    3. “Match” tags when importing into the new plugin directory. When we’re ready to launch the new plugin directory, we’ll do a final import from the current bbPress database into WordPress. During this import, we’ll do our best to match tags from one to the other. For example, if we have a “Spam Protection” tag, we’ll match “spam” and “anti-spam” and Akismet the “Spam Protection” tag.
    4. Move tags from the readme into the plugin admin. As part of our work, we’re building an admin interface for plugin authors to manage certain aspects of their plugin. We’ll add tags to this interface so you no longer have to commit to SVN to update your plugin’s tags.
    5. Make these tags available for translation. Just as the rest of the plugin directory interface will be translatable, tags will be fully translatable too.

    If tags now sound a lot like categories, well, that’s intentional. 🙂 At the moment, we’re thinking it makes sense to keep calling them tags, keeping consistent with the previous and current iterations of the plugin directory.

    Requesting new tags would happen on meta trac, working closely with the plugin review team.

    To be clear: This is a proposal and we want your input!

    So, what do you think? Leave your feedback here!

     
    • niknetniko 5:05 pm on February 26, 2016 Permalink | Log in to Reply

      While I applaud this very much, I have one remark/use case you might not have thought of.

      Larger plugins typically provide their own hooks and actions for integration. This means there can be other plugins for those larger plugins.

      An example of this is NextGEN (a gallery plugin) that has a bunch of extensions (other plugins designed to work with it).

      Currently, ‘NextGEN’ is used as tag to indicate support/requirement of NextGEN. It has been a long time so I don’t know if they still do it, but they even used to filter plugins with the NextGEN tag and display them inside NextGEN itself.

      Personally I think this isn’t really what tags are meant for, but then I would request another way to indicate support for other plugins. Or even better, requirements for other plugins, but that’s a new feature, so I don’t know if that is possible with the revamp.

      • Ipstenu (Mika Epstein) 5:55 pm on February 26, 2016 Permalink | Log in to Reply

        That’s an interesting point. Maybe a ‘requirements’ option would work here?

        This plugin requires [other plugin], [other theme]

        The issue there, of course, is it’d have to be free-form, since people make plugins for premium themes and plugins not hosted here. Or we can just say SOL to them.

        • ccprog 7:49 pm on February 26, 2016 Permalink | Log in to Reply

          A reverse ‘supports’/’implements’ might also be needed.

          As in: if SimpleHistory is installed, this plugin can log its specific events there.

      • Jon Brown 5:56 pm on February 26, 2016 Permalink | Log in to Reply

        Excellent point. I’ll add to that that it’s not just addons for plugins, but also plugins for specific themes, for example Genesis.

        In the former case it would be super awesome if there was a official way to declare associations like that and when viewing a plugin they would show as “related”.

        There does need to be some control though lest everyone start tagging their plugin as being an “add-on” for the most popular plugins to try to gain visibility even when they’re unrelated.

      • Josh Pollock 6:44 pm on February 26, 2016 Permalink | Log in to Reply

        This is a really important point. So many plugins have add-on plugins and there is no good way to find them all and to tell what is official and what is not.

        I would love to have a way for all of the official add-ons for my plugin to be easily found. Right now we use a consistent tag, but that is full of problems and users don’t really know to look for that, and anyone can use that tag.

        There are a few related issues here: official add-on; approved third-party add-on; other add-on, plugin that isn’t really an add-on, but integrates with; plugin that is completely dependent on another plugin to work…

      • jrf 10:28 pm on February 26, 2016 Permalink | Log in to Reply

        What you’re talking about is more a form of inter-plugin/theme dependency management for WordPress, which IMHO is a separate topic from tagging.

        Now there happens to be a feature plugin proposal floating around to get Dependency Management for WP addressed 😉

        There is a survey open about this and your input would be *very* welcome: http://goo.gl/forms/Fq1gbY9vCW

        _Full disclosure: I’m the current lead behind this proposal._

      • Brad Touesnard 1:45 pm on March 8, 2016 Permalink | Log in to Reply

        Plugin dependencies are only tangentially related to tags IMO, but since you brought it up, an experiment in the form of a plugin has been made to accomplish dependencies via an additional plugin header:
        https://wordpress.org/plugins/plugin-dependencies/

        This also reminds me of TGM Plugin Activation. I would love to see a dependency system in core rather than a bunch of themes and plugins including the TGM Plugin Activation library and running a bunch of instances of it in parallel.

    • Remkus de Vries 5:05 pm on February 26, 2016 Permalink | Log in to Reply

      Thank you for all the work that obviously went into this proposal … and I think it’s a very solid plan. The only thing I think that needs tweaking is the three tags. Limiting definitely sounds like a good plan, but if you have a plugin with more than one feature than three tags is just a bit too limited IMO.

      • Ipstenu (Mika Epstein) 5:51 pm on February 26, 2016 Permalink | Log in to Reply

        The problem is where is a line drawn? You could have 100 features. Picking the top three you feel are most important is a good exercise.

        • Remkus de Vries 7:27 pm on February 26, 2016 Permalink | Log in to Reply

          Let’s say I’ve build a plugin for Genesis on top of WooCommerce that has a couple of features. I’ve already lost two tags then … heck even just for Genesis I would only have two tags … Seems thin to me.

        • Mike Schinkel 7:32 pm on February 26, 2016 Permalink | Log in to Reply

          Sounds like Remkus is identifying that we need a “supports” type of tag that would be orthogonal to categorization type of tags?

    • Jeremy Herve 5:12 pm on February 26, 2016 Permalink | Log in to Reply

      I guess my main question is, what are the tags used for right now, and how will they be used in the next version of the plugin repository?

      • If they’re used to improve search, wouldn’t it be better to use content from the whole readme?
      • If they’re used to create categories of plugins, shouldn’t we try to define those categories first? I guess we can start from the most popular tags in use today, but I’m not sure they’ll match categories that would be useful for someone going to Plugins > Add New for the first time. Maybe we could come up with a list of 10 categories, and ask each plugin author to pick up to 3 categories for each one of their plugins?
      • Ipstenu (Mika Epstein) 5:53 pm on February 26, 2016 Permalink | Log in to Reply

        We have to start somewhere though. And starting from ‘what’s popular’ will give us a much better idea of what people are using. If they turn out to be inutile then we can edit them from there. The problem now is we have no idea what the right categories should be.

        Search actually does use the whole readme 🙂 Always has.

    • Jon Brown 6:13 pm on February 26, 2016 Permalink | Log in to Reply

      While we are thinking about this. Would it be useful to define some tags that were informative to users?

      I’m thinking:

      • admin-only/backend-only – ie. a plugin that doesn’t do anything on the front end. Something for example that would add thumbnails images to the post list.
      • dependency-only – ie. something that doesn’t do anything on it’s own. Something for example like CMB2.
      • has-widget – any plugin that includes a widget

      AND by far what I think is the most important:

      • network-compatible – plugins that affirmatively claim to work on multi-site networks.

      Some of these could even be automated for old plugins. Search for “extends WP_Widget”. Search for is_multisite() perhaps?

      and finally the most controversial:

      • requires-php56

      :ducks-and-hides:

      • Marius (Clorith) 8:37 pm on February 26, 2016 Permalink | Log in to Reply

        I actually think these are completely different kinds of categorizations, think “features” vs “information”

        Remember that to many users such informative tags like “has-widget” means little, any plugin could have a widget, but that doesn’t tell me what the plugin does and helps little in that aspect. A ‘requires-php56’ less so as most users don’t know what PHP is, and definitely not what version they have

        For now this is information best suited for the installation instructions screen, and a sane plugin activation hook that checks dependencies before it decides to go belly up on the user 🙂

        I think that down the line, with filterability on the repository, that such tags might hold value, but they should then be a separate set of tags (in my opinion) from the feature describing tags, and not built around the currently proposed changes and limitations.

      • Ipstenu (Mika Epstein) 9:32 pm on February 26, 2016 Permalink | Log in to Reply

        CMB2 in and of itself isn’t allowed in the repository at this time. We don’t allow Frameworks.

        All of those would be nice, optional, classifications, but not tags. Frankly, I can’t see any end user (a normal user) thinking “I need PHP 5.6 plugins only!”

        Multisite, though, yeah, I can see that as a good tag.

        • Remkus de Vries 11:13 am on February 27, 2016 Permalink | Log in to Reply

          Not sure I follow what you’re saying with CMB2 in and of itself isn’t allowed in the repository at this time … because it is in the repo atm.

          • Ipstenu (Mika Epstein) 9:15 pm on February 28, 2016 Permalink | Log in to Reply

            I meant plugins like… CMB2 and Redux Framework are grandfathered in. We don’t let any more in, since a lot of plugins include them inside AS plugins. It’s a mess.

            Also CMB2 shouldn’t have been approved, which is a different mess all together.

            Frameworks are not supposed to be in the repo at this time. Period.

            • Remkus de Vries 12:15 pm on February 29, 2016 Permalink

              Ah, ok. Did not know that. Is there anywhere I can read up on that decision?

          • Ipstenu (Mika Epstein) 4:55 pm on February 29, 2016 Permalink | Log in to Reply

            This isn’t anything new. Frameworks and libraries should be packaged with each plugin (hopefully in a way that doesn’t conflict with other plugins using the framework or libraries). At least until core supports plugin dependencies.

            Since we don’t, we’re trying NOT to add new framework plugins. I’d rather remove them, but we’re in a bad spot right now with it as a whole. We need a composer type requirement setup for plugins in general, which is beyond the discussion of this post.

    • Mike Schinkel 6:41 pm on February 26, 2016 Permalink | Log in to Reply

      Good to hear you are addressing these issues.

      I’ll give my feedback with the backdrop of my experience in the 90’s running a business that sold software components using a printed mailed catalog where every four months I would personally spend about 2 weeks categorizing the products in the catalog.

      First, a static set of tags is problematic because the software world is constantly evolving and there are new categories that will constantly emerge. Googling for web development trends 2014, 2015 and 2016 I came up with “hamburger menu”, “long scroll”, “card layout”, “hero image”, “material design”, “single page app”, “parallax scrolling”, “retina”, “flat ui”, “microinteraction”, etc. All of those may or may not be applicable to plugins but they pretty much all emerged in recently.

      Then there are the “compatible technologies”, i.e. ‘backbone’, ‘reactjs’, ‘flux’, ‘mongodb’, ‘memcached’, ‘redis’, ‘angularjs’, ’emberjs’, etc.

      And then web services they work with: ‘mailchimp’, ‘salesforce’, ‘slack’, ‘twitter’, ‘facebook’, ‘linkedin’, etc.

      And there are certainly other things to note that people have used tags for before that I am not thinking of.

      Next, and this is something that always bedeviled us back in the 90’s when people submitted categories for their own products was the “IS A” versus “CAN BE USED TO BUILD A” question, i.e “Is your component an accounting system, or can it be used to build an accounting system?” We wanted to present the former to customers but all our vendors wanted to include a lot of the latter because the latter were often infinite.

      Further, from experience, some components really only deserved one (1) category and others rightfully deserved many categories. An arbitrary limit to 3 would not be in the best interest of the end-user.

      We found that we could not let people submit their own unedited, that we needed to review them ourselves. Maybe a review board as part of the submission process?

      That said, if you really want to allow people to manage tags on their own I’d suggest considering a few techniques that I came up with for some recent WordPress projects:

      1. If you want to use tags then create two-part tags, i.e. “works-with:mailchimp”, “supports:reactjs”, “implements:card-layout”, “can-create:pinterest-style” and maybe other prefixes you discover. Then apply different rules to the different prefixes.

      2. Or create many different taxonomies of tags as you see in #1 each with their own rules.

      3. And maybe give people the choice of number of tags and then give each tag a different weight. If they pick one (1) tag for the “implements” taxonomy, maybe the weight is “3.” if they pick ten tags, give each tag a weight of “1” and use the weights to drive search results.

      4. Like #3, maybe allow them primary tags, secondary tags and tertiary tags. Give them 1 primary, 3 secondary and 5 tertiary tags where primary gets weight of “3”, secondary a weight of “2” and tertiary a weight of “1.”

      Using some combination of the above I think you might able to to let them self manage tags AND to propose new tags but the constraints of weighting will keep them honest? (Note: You’ll need to fiddle with the actual weights to see what really works; the weights I listed were just examples to explain the concepts. HTH.)

      • Scott Kingsley Clark 6:46 pm on February 26, 2016 Permalink | Log in to Reply

        I like the idea of adding extra taxonomies when this change is made, to support more contextual tagging, and then eventually dropping tagging altogether after a year or so.

      • Mike Schinkel 7:37 pm on February 26, 2016 Permalink | Log in to Reply

        Another thing to consider is that WordPress itself has Categories (often a small number per blog) and tags (typically a large number.)

        Maybe Categories are needed and limited, and Tags are freeform, w/o limit?

        • Ipstenu (Mika Epstein) 10:07 pm on February 26, 2016 Permalink | Log in to Reply

          Sadly I don’t trust your mates to get it right. They would do exactly what they’ve been doing, keyword stuffing and making it so no one can actually find anything useful.

          The issue is that when it’s your blog, you know “Don’t use spam, anti-spam, spammers, spammarific. Just use ONE tag for spam.” Right? Well multiply that by 5000+ users and now you have a mess of people guessing what keywords should be and we’re back to a hot mess.

          Tags are useless as an organizational tool when they’re unmanaged.

      • Ipstenu (Mika Epstein) 9:43 pm on February 26, 2016 Permalink | Log in to Reply

        Remove the list of ‘integration’ tags you listed for a moment. Don’t get mired (yet) in exactly how we’d list those, but presume we’re going to list them separately. Maybe a second taxonomy JUST for ‘this plugin supports’ and ‘this plugin requires’ and so on.

        Pick the top three terms that define your plugin.

        I’ll take Genericon’d and the only tag I now need is ‘font-icons’

        Akismet: ‘anti-spam’ (or ‘spam’ probably)

        The place you start to run into headaches would be Jetpack, which really does a lot of everything. And that’s where tags have always fallen into broken. If we let it remain free-form, we have the same problem we have today. People will use anything and everything to keyword stuff and then start listing their competition. Which is stupid from a marketing standpoint, but they do it.

        If instead we get a better search going based on your readme content, then the need for tags drops considerably and we have the simple question of “Pick three words to describe your plugin”

        It’s a fun exercise to try, actually.

    • Chris Dillon 6:46 pm on February 26, 2016 Permalink | Log in to Reply

      We may be entering XY Problem territory.

      Improve search and tags become irrelevant. Add “network-compatible” and other verifiable, weightable criteria to the readme.

      Has anyone considered polling users on whether they use or trust tags? Do you have any data on keyword vs. tag searching?

      If tags were removed, would anyone miss them?

      • Scott Kingsley Clark 6:53 pm on February 26, 2016 Permalink | Log in to Reply

        More taxonomies for things we can take out of the readme would be super helpful here, including new things we’d like to see too.

      • Mike Schinkel 7:20 pm on February 26, 2016 Permalink | Log in to Reply

        When I have my user hat on I use tags. Tags allow me to find “all the plugins that fit in the category” (yes, I know this can be imperfect) vs. “all the results that happen to have the is the description somewhere.”

        Search is great if I am looking for the first thing that fits my needs. Categorization is better if I want to see all things that I know will have been human-curated so I can compare and contrast. That is why I often add “alternate” to the name of a solution when I google to find all competitive solutions because there are websites with list of alternate solutions that have been SEO optimized for
        ” alternate.” I would hope WP.org would do the same for plugins.

        JMTCW

    • CodeBard 7:32 pm on February 26, 2016 Permalink | Log in to Reply

      3 tag limit is too narrow. There are larger plugins which server numerous purposes and therefore can only be defined by sufficient number of tags. Some plugin authors are us the freeform tags to duplicate their tags is not a reason to bring such a stringent limit to plugin tagging. A technical support plugin may allow tickets, integrate with woocommerce, easy digital downloads, and also allow users to report posts and comments.

      How are you going to express that with 3 tags?

      support, ticket, woocommerce…

      Two major features of the plugin just went out of the window.

      Tags should be a minimum of 5. Preferably 6-8 is much better. If someone cant find a proper tag, no need to use more. But if one needs a tag, s/he should be able to use that.

      Categories are even further limiting. Even in posting in your own blog you regularly have difficulty in fitting a post in some category if the post is broader than a short, snappy piece. Its even more difficult with plugins.

      Tags remedy that problem by offering varied classification. Gimping them is not a good idea.

      • Ipstenu (Mika Epstein) 10:03 pm on February 26, 2016 Permalink | Log in to Reply

        If it was ‘some’ then you’d be right. When it’s ‘most’ it’s gotten to the point that the tags are useless for categorizing. Not only are people using the ‘same’ tags with multiple variations (spam, anti-spam, anti spam, etc), but they’re intentionally adding in mis-spellings. Your plugin included when I look at it. You have ‘crowd funding’ phrased 4 ways, ‘donation’ 3, and you even have the tag ‘plugins’ which I don’t understand why.

        That’s the problem. As an organizational tool, which is what a tag is, you’ve broken the system of classification.

        Have you ever looked up the Dewey Decimal system? It has its flaws, but it has BIG classifications, and then breakdowns. We’re looking big here 🙂

        • CodeBard 7:17 pm on February 27, 2016 Permalink | Log in to Reply

          > You have ‘crowd funding’ phrased 4 ways, ‘donation’ 3, and you even have the tag ‘plugins’ which I don’t understand why

          This kind of practice is not in the same line with misleading intent. This kind of non-misleading misspellings and repetitions are done for a rather simple, human reasons. And rather important. I shall elaborate:

          For starters, standardized terms for a lot of things dont exist:

          Is it ‘crowdfunding’, is it ‘crowd-funding’ or is it ‘crowd funding’.

          Lets say crowdfunding is a rather new term.

          What about support systems?

          Is it “support tickets”, “support ticket system”, “support system”, “helpdesk”, or “help desk”?!

          Among developers we may reach consensus on some. But on the side of users no such consensus is possible.

          Its possible to remedy this to an extent inside wp repository maybe, but wp repository doesn’t work by itself – it is indexed by search engines, and definitely a decent amount of traffic comes from search engines to wp repo, im sure. People who search for plugins outside WP’s plugin admin page are no small number.

          In that respect, tags are most important for relevance in search results. And the number of people who misspell, dont know or outright use different variations of terms when searching in search engines is massive. If you may have noticed, a lot of respectable organizations, websites account for that with their tags, and there exist repetition especially for non-standard terms. like crowd funding.

          And as for even using tags like plugin – WP repo and the user already in WP repo knows that these are plugins. But search engines and users who may come through any other means directly to the plugin page dont.

          These are important for exposure in search results for not only individual plugins, but also WP ecosystem as a whole. You can even come up with a decent percentage of people who use wordpress but do not actually know worpdress plugin repository at all. They search from their plugin admin page, and add plugins, but where do these come from, may have no idea. And when they search in a search engine for something related to a kind of WP plugin which they couldnt immediately find through there, WP repository results should come up at the top – which is not always the case at this point.

          Well scratch ‘there may’ – there are many people like that, as anyone who delivered WP technical support or worked directly with clients would know.

          Then there are many people dont know the correct spelling for many terms
          People misspell a lot of things. This causes uglier situations of course, misspellings are not so orderly and nice, but they are in astounding percentage. And we cant fix that ourselves, as developers or wordpress community.

          In case of number of tags people use without repetition, it is also a natural result of tech: A support system is qualified as a help desk, support desk, support system, support ticket system, support tickets. Anywhere, anything goes. Moreover there are plugins which offer a wide variety of functions which can be refined to specific and singular tags, but needing many tags. Woocommerce supports digital downloads for example. It also supports paypal. Its also ecommerce. Three tags are already used, what about rest of the important features?

          These are important even to me when searching a plugin in repo, as a plugin author.

          ==============================================

          Surely the problems outlined exist and they need to be solved.

          But solution should not take the form of outright limiting the competitiveness of WP repository or pigeonholing plugins and their authors. A viable way must be found.

          For example tags can be aliased. crowd-funding, crowdfunding and crowd funding can be aliased to one single term, inside database or through other means. Alias/repetitive tags can be forfeited if its too much a thorn, but it will hurt visibility for plugins and WP repo itself. There are private repositories which do not have any problem with repetitive tags, for example, and their search standing benefits from that.

          In case of misspelled tags, well, that’s a major thorn indeed. It wouldnt be neat to keep them in the repo database, for sure. Though leaving them out will affect search traffic and visibility of plugins and WP repo in the ‘outer’ internet, i cant reasonably propose a solution for keeping misspelled tags.

          For the number of tags, however, this is the most important. The number of tags being a mere three doesn’t solve any of the either problems, but instead pigeonholes plugins and authors.

          Using three tags for large plugins or plugins which offer a large array of main functions is not rational.

          “Describe woocommerce in three tags” sounds quite like “Describe this movie in one word” games that go about in social networks.

          There ! should be ! more than just 3 tags to classify plugins, even if we arent able to somehow manifest the solutions for the others. Maybe minimum 5, best, up to 10.

          • Ipstenu (Mika Epstein) 5:15 pm on February 29, 2016 Permalink | Log in to Reply

            It still doesn’t explain the tag ‘plugin’ unless that’s just an accident.

            What if all those similar ways of spelling/phrasing ‘crowdfunding’ redirected everyone to the same tag? What if the search engine, like Google, was smart enough to understand typos and bad spelling?

            • CodeBard 4:23 pm on March 18, 2016 Permalink

              > It still doesn’t explain the tag ‘plugin’ unless that’s just an accident

              Wow i didnt see the reply.

              That one is intended for search engines like Google. tags have some weight in search, and even if wordpress.org’s plugin repo is known for plugins, something tagged with the word ‘plugin’ is likely to get higher ratings for search ranking.

              > “What if all those similar ways of spelling/phrasing ‘crowdfunding’ redirected everyone to the same tag”

              Something like that could work actually. Actually that may be a good idea. People can make all the mistakes they want, and if common spellings, different termage and missipellings are accounted for by the plugin search engine that could fix it.

              This would mean that the repo would account for different terms used for the same thing, but this would give far better control to repo and also could be far neater than totally leaving it to plugin owners.

              It would still be necessary to display such different spellings and terms in the tag listing under the plugin though, since search engines will take those into account. a plugin which has ‘support tickets’ and ‘help desk’ as tags can have higher ranking for ‘help desk’ keyword in google than a plugin which only has ‘support tickets’.

          • Ipstenu (Mika Epstein) 5:11 pm on March 31, 2016 Permalink | Log in to Reply

            > That one is intended for search engines like Google. tags have some weight in search, and even if wordpress.org’s plugin repo is known for plugins, something tagged with the word ‘plugin’ is likely to get higher ratings for search ranking.

            That’s actually wrong. Having ‘plugin’ in your tags doesn’t improve your SEO like that.

    • Piet Bos 1:36 am on February 27, 2016 Permalink | Log in to Reply

      I think it is a great idea to overhaul the whole system as the whole tagging indeed is a bit of a problem.

      When you say “If tags now sound a lot like categories, well, that’s intentional.”, then wouldn’t it be an idea to simply let go of tags all-together?

      Google let go its meta-tags a long time ago, why can’t we?

      I think the bigger issue with the current Plugins Directory is that the search functionality simply doesn’t really work. And to be honest I think that changing the tags structure is not going to help one bit.

      If you come up with a set of categories and plugin developers can use up to three of of them, period. Yes, that is going to be difficult, but so is everything else. Change is always difficult 🙂

      Then the search functionality needs an overhaul where – as Mika mentioned: “Well written, contextual, readmes” – can replace the current tagging.

      • CodeBard 7:18 pm on February 27, 2016 Permalink | Log in to Reply

        Google let meta keywords go, but it recognizes and counts tags with which any page/article is tagged with into account – and rather decently. tag listing pages of many websites come up in high ranking in results from web pages. Dor example site.com/tags/ecommerce may appear as high as site’s own ecommerce page at site.com/ecommerce

    • Clifford Paulick 11:36 am on February 27, 2016 Permalink | Log in to Reply

      I love the idea of consolidating tags (eg shortcode, shotcodes, has-shortcode), but I think if you implement that, just leave the unlimited/12 tags limit alone for now.

    • Joost de Valk 2:37 pm on February 27, 2016 Permalink | Log in to Reply

      Categories / Tags whatever you want to call them are going to be important mostly from a findability perspective. So if you’re going to use a search engine based internal search engine for plugins, the categories matter because they’ll help determine the rankings too. I think the idea of a limited set of tags is a good one. Whether you should limit a plugin to a strict number of tags… i don’t think that’s a good idea.

    • Anastis Sourgoutsidis 2:38 pm on February 27, 2016 Permalink | Log in to Reply

      Why not take a hybrid approach?
      Obviously I haven’t think this through, but the general idea is:

      1. A plugin may have an (un)limited number of well-known predefined tags.
      2. A plugin may have an (un)limited number of tags that match the slugs of other themes/plugins in the WP repo.
      3. A list of well-known tag aliases maps to the respective predefined tags (that term_group column has been there forever).
      4. A plugin may have up to 3 freeform tags that doesn’t match any of the above (just to cover cases either not considered before, or references external to the WP repo).
      5. Anything else is ignored.

      Then, perhaps once a year, a tally of the freeform tags could form the list of new, soon to be added, predefined tags. This will give an actual view on tag usage versus a trac ticket requesting a new tag added, followed by the +1’s of a vocal minority.

    • Torsten Landsiedel 11:04 pm on February 27, 2016 Permalink | Log in to Reply

      Nearly all great ideas from this comment thread (theme/plugin dependency, has-widget, multisite-ready, etc.) can be achieved if we use a system like on https://theme.wordpress.com/

      There should be a set of pre-defined tags which you can use to define features(themes/plugins) your plugin supports. So we don’t lose tags to give those informations. The remaining three (or maybe five) tags are now just used to describe the plugin.

      But we need to get rid of things like contact-form-7, cf7, contactform7 – this is bad UX and filtering in the plugin repo is not much fun these days …

      And using tags like “yoast” just to be in the list although your plugin has nothing to do with it, is just … (insert your first thought yourself here)

    • Ste_95 7:32 am on February 28, 2016 Permalink | Log in to Reply

      Couple months ago I developed a plugin that suggests tags from a given tag list, basing on the post text. It basically reads through the text and calculates the relevance of each tag, and then provides the most relevant ones.

      This is the plugin https://wordpress.org/support/plugin/smart-tag-insert and this is the algorithm it’s based upon http://www.thecrowned.org/method-for-pattern-relevance-in-text 🙂 There’s a lot of room for improvement in both, but may be helpful here!

    • NateWr 12:39 pm on February 29, 2016 Permalink | Log in to Reply

      Just throwing my hat in the ring in favor of getting rid of tags. More meaningful taxonomies would be useful, but the open-ness of tags doesn’t work well with plugins because they’re so diverse.

      If categories are chosen, they should remain few and only those that can be very clearly defined. Some plugins fit into broadly recognized purposes (eCommerce, forms, events). But a whole bunch don’t. I’d hate to see them get lumped into poorly defined categories just for the sake of throwing them somewhere. I’d rather see 10 clear, well-defined categories alongside one big completely undefined category (“Uncategorized”) rather than a list of 30 or 40 which I think could discourage searching without really satisfying the user’s need for browsing in a lot of cases.

    • Daniel Llewellyn 1:35 pm on February 29, 2016 Permalink | Log in to Reply

      I concur that the current tagging system is unworkable and admit that I have fallen into the same traps that this post highlights as problems. To improve, I’d like to see the plugin repo to have broad category-style taxonomy instead of tags which could potentially include a hierarchical structure to narrow-down intent. This taxonomy should ideally be configured by the UI rather than via changes in the source-code, i.e. the readme.txt file. I’d preferably like to see the entire readme.txt completely removed from svn and replaced with UI to be included into the downloadable .zip file magically when a user downloads a release. Releases should then be generated whenever a new svn tag is created rather than when the readme gets changed. Changelogs could should remain in a file within the sourcecode tree to maintain changes with their associated log message in unison (CHANGELOG is a standard filename used by other projects).

      The category taxonomy should be utilised for a faceted searching feature where the user can search with free-form text AND filter by category. To plug a colleague’s work which hasn’t been publicly updated in some time, but has had changes privately, an example of my ambition is featured at http://www.justiceinspectorates.gov.uk/hmic/?s=test where you can see there is free-form text and faceted filtering.

      The plugin used in the example above was @marcusdowning‘s “Bang Faceted Search” (https://wordpress.org/plugins/bang-faceted-search) further improved from the public release version by Marcus himself – I’ll try to get him to update the public plugin when he can.

    • yairgelb 3:56 pm on February 29, 2016 Permalink | Log in to Reply

      I think it is great to make these tags more consistent but it might be a good idea to have a couple sets of tags. One describing the data/area of wrodpress the plugin works with. Content, admin, performance, users, e-commerce etc. Then the other set describes the plugin itself. So if a user wants a plugin for category banners they will search under content and look for banners or category. This will allow a plugin to use fewer tags while being placed in the right spot on searches.

    • Syed Balkhi 4:14 pm on March 1, 2016 Permalink | Log in to Reply

      From usability point of view, the plugin repo desperately needs an organization / classification system so I applaud this new initiative as it will be helpful for WordPress beginners.

      However limiting the tags to 3 is not the best idea for variety of reasons that have already been brought up before (i.e plugins like WooCommerce or Envira Gallery or Yoast SEO that offers tons of features).

      From the implementation point of view, I think we should seriously consider using both Categories and Tags – keeping it the WordPress way.

      Categories will be pre-defined by the Plugin Review team and each plugin author can only select 3 categories max (depending on how broad or specific the categories are this limit can be adjusted to 1 or 5).

      These categories can then be used to provide proper browsing / filtering options on the .org repo and perhaps even inside the dashboard for users to find what they’re looking for. By doing this we will solve the usability issue that I believe that we’re trying to solve here.

      This brings me to the Tags. We need to have “unlimited” / 20 – 30 tags limit while allowing plugin authors to choose from popular tags that exist.

      By adding these through the new Admin interface, translators can easily translate them. Use of similar tags allow for translation once — not multiple times. A tag that’s not translated won’t be displayed in the other repo encouraging plugin authors to select from popular tags vs making up their own.

      So what’s the real benefit of the existing tags?

      I always think of categories as the table of content (chapters) and tags as (index) of the book. Organizing it this way, will allow for a more sophisticated search “algorithm” because it’s giving you yet another parameter to add into consideration — this should help improve the search.

      The second and most important benefit is from the business point of view of plugin authors. There are tons of plugins that generate a good chunk of sales through WordPress.org repo. The .org tags rank very well for a lot of keywords in search engines like Google, etc –> i.e type “responsive wordpress gallery” in Google — First 5 results are from .org out of which 3 are tag archives.

      While the .org repo doesn’t give plugin authors any traffic insights, by looking from our own traffic analytics for specific keywords — I can only imagine how much of our sales that’s coming from .org is actually resulting from Google rankings of these .org tag archive pages which then lead the customer to our plugin listing.

      This can have significant ramifications on sales of Pro version of free plugins.

      Right now there are 3.45 million tag pages that are indexed in Google. Properly redirecting them (not sure how that’s even possible) would be a challenging task which is why I suggest the solution of using Categories + Tags.

      This would help us improve the usability overall for the Repo. Strict limit on tags (20 – 30) can be easily enforced from the new admin interface preventing abuse but at the same time ensuring no business is hurt with this change.

      • daverod 4:51 pm on March 2, 2016 Permalink | Log in to Reply

        I think Syed’s take on this very much echoes my own. Restricting to 3 tags would have a massive impact on existing plugins that rely on Google to index that particular aspect and possibly make many plugins unfindable because they must fit into the “3 magic tags” rule. Users don’t think in strict taxonomies (and what’s the chance that your thinking will perfectly match theirs?)–they will use synonyms to discover things and that’s how many authors (myself included) use tags now–to improve discoverability.

        I’m not sure that restricting authors to existing tags will be helpful in the long run. What happens when someone creates a plugin for a feature that no one else thought of before and suddenly needs to tag that? What is the process for adding a new tag?

        Plugin categories would be super-helpful to improve search, but it would be nice to see what proposed list you have to see if something is missing and suggest any additions, of course. 🙂

      • Brad Touesnard 2:08 pm on March 8, 2016 Permalink | Log in to Reply

        ^^^ What Syed said.

        I only disagree with the part about unlimited tags and search using them all as weight for the index. If you do that people will stuff unrelated tags into their readme.txt to broaden their search target. If search does look at tags at all, it should be limited to the first X number of tags.

        I’d personally like the tag archive pages removed from Google’s index. That’s as simple as updating robots.txt on .org. As a user searching for plugins I find those results annoying. The contents of the archive pages are in flux, so sometimes when you click through, the matching keywords aren’t even found on the page anymore. Plus it’s often duplicate results. That is, many of the results shown on the archive page are also shown in the Google search results. If we only saw the plugin pages in the Google search results, I think it would be much tidier and easier to consume.

        • Ipstenu (Mika Epstein) 5:26 pm on March 11, 2016 Permalink | Log in to Reply

          I only disagree with the part about unlimited tags and search using them all as weight for the index. If you do that people will stuff unrelated tags into their readme.txt to broaden their search target.

          Sadly that is exactly what’s happening now, and part of why we have to start kicking things around to figure out what’s better for people who are looking for, you know, PLUGINS 😉

    • Chris Dillon 5:21 pm on March 1, 2016 Permalink | Log in to Reply

      I love this discussion so far. Can I get down to brass tacks for a moment?

      I have a testimonials plugin that is currently displayed at position 26 in a keyword search for “testimonials” despite having more active installations, more reviews and a better rating, after some plugins that haven’t been updated in months, haven’t been tested up to the current version, with infrequently attended if not abandoned support forums.

      If I adhere to whatever the new best practice becomes, will the new system improve my ranking?

  • Ipstenu (Mika Epstein) 12:44 pm on February 17, 2016 Permalink |
    Tags: ,   

    Reminder: Many Javascript Libraries Are Included in Core 

    WordPress includes jQuery with core. Most everyone knows this. But did you also know WordPress includes a great deal of other libraries for your use.

    You should take the time to check the documentation on wp_enqueue_script().

    But that list actually isn’t complete! For a complete list of registered files inspect `$GLOBALS[‘wp_scripts’]` in the admin UI. Registered scripts might change per requested page. You can also check out the massive amounts of files in wp-includes to see even more.

    My point, though, is that 90% of the time, you don’t need ‘your own’ version of something. We have it.

    Even datepicker folks (jquery-ui-datepicker).

    Check if core works. If you call it right, most of the time it will.

     
    • Arnan de Gans 12:48 pm on February 17, 2016 Permalink | Log in to Reply

      And stop f*cking using googleapi hosted scripts if it’s included in WordPress already… Geez.

      @WordPress devs – You should include/optionalize to include (similar to language packs) a bunch of common fonts too so we can stop using the ridiculous google fonts, too 🙂 That would be a major yay!
      Perhaps a scrape function to pull files from remote to local or whatever.

    • Jacob N. Breetvelt 12:50 pm on February 17, 2016 Permalink | Log in to Reply

      I, as plugin developer, very much agree with this. Especially google api jquery libraries don’t work ( at all ).

    • Marcus 1:37 pm on February 17, 2016 Permalink | Log in to Reply

      moreover, it makes your life easier using the scripts shipped with WP since you don’t need to worry about keeping those updated

    • jeffmcneill 2:31 pm on February 17, 2016 Permalink | Log in to Reply

      What (if any) javascripts are loaded by default? If it is zero then all the loading is done by themes and plugins? Trying to get a plain vanilla theme that isn’t chock-a-block with js is very difficult!

      • Ipstenu (Mika Epstein) 5:25 pm on February 17, 2016 Permalink | Log in to Reply

        You’ll have to check the individual pages. On a naked WP site with a default theme, I have jquery, jquery-core, and jquery-migrate

        But. That’s where the beauty of the enqueues and their dependancies array comes in! If you say “I need jquery” then WP knows to only call it once 🙂 So you can enqueue your script, say it needs jquery core, and boom! Everyone wins.

    • Paul Menard 3:12 pm on February 17, 2016 Permalink | Log in to Reply

      Speaking of the date picker and the jQuery UI suite. When will core include some default styling/theming for jQuery UI functionality for use within the Dashboard? At least for some standardized items like the date picker, accordions, etc. Not asking for the front-end.

    • IntellyWP 4:05 pm on February 17, 2016 Permalink | Log in to Reply

      And also… please load your library only when you are seeing your plugin pages and not always!
      And also… please display your notice only inside your plugin pages!

      For this reason, we introduced in our latest plugin, at the beginning, some code check to remove other unnecessary plugins javascript library or css or displayed notice 🙁

      • Joachim Jensen - Intox Studio 11:00 pm on February 17, 2016 Permalink | Log in to Reply

        I agree with loading scripts only when needed.
        I cannot believe that this is not standard practice by all developers, but everytime I see it (and I mostly see it because of code conflicts) I try to contact the developer. I’d say the response rate is about 50%.

        Also, please register scripts by the actual library name. In the example from @ipstenu, use “jquery-ui-datepicker”, _not_ “mytheme-cool-datepicker”.

        • Ipstenu (Mika Epstein) 11:01 pm on February 17, 2016 Permalink | Log in to Reply

          FWIW: We don’t enforce it with developers since about half the time it would require a lot of deep diving into how a plugin is made and why. I personally recommend only loading what has to be loaded when it must be loaded, but then again I’m also pretty snarky about not including demo folders in plugins.

          • Joachim Jensen - Intox Studio 11:50 pm on February 17, 2016 Permalink | Log in to Reply

            I understand, and enforcing such thing could also lead to false positives, e.g. if a plugin really needed a script on each (admin) page. I think it would be more useful if it was written as a “best practice” somewhere in docs (if it isn’t already).

            By the way, I noticed that if you try to register two different versions of the same script, the first one registered is used, not the latest version.
            I know versioning is there mainly for cache reasons, but if wp_register_script is used correctly, wouldn’t it make sense to take it into consideration and always use latest version registered? Perhaps there already is a discussion for it somewhere?

    • A WP Life 5:35 pm on February 17, 2016 Permalink | Log in to Reply

      Yehh! I found it. It’s very useful for every plugin & theme developers.

  • Samuel Wood (Otto) 10:26 pm on February 12, 2016 Permalink |
    Tags: active installs, , plugins, selling, spam   

    On the Topic of Selling Your Plugins… 

    Unlike the title might suggest, this post is not about buying a plugin from a commercial author, or the viability of “freemium” plugins in the directory, or app stores, or anything of that sort.

    This post is directed squarely at plugin authors.

    Question: Who owns your plugin?

    The answer is simple: You do. You wrote it. You hold the copyrights on it.

    Now hold on a minute (one might say), everything in our directory is GPL or compatible. Isn’t that copyleft? Well, yes, and I’m not going to go into excessive amounts of legalese here (IANAL), but the GPL is built on top of copyright. It actually requires it. So yes, you do own the copyrights to your plugin, even when it’s available for free in the WordPress.org plugin directory.

    And yes, that totally means you can sell those rights to somebody else. We won’t stop you. Heck, if you ask, we’ll even help you perform the transfer correctly.

    Now, while we’ve talked about this before, it’s worth re-iterating because it has come up a lot recently: your name is on that plugin. If you sell it to some scummy spammer, then your name is likely to get dragged through the mud. Not by us, of course, we don’t name names. But other people do notice bad things happening, and they tell other people, and make posts in our forums, and leave bad reviews… and before you know it, you can get a bad rap for something you didn’t even do.

    There have been a lot of reports of various unsolicited emails recently asking plugin authors if they would sell their plugins. Sometimes these are legitimate offers. Not often. Usually it’s from marketing agencies looking to add backlinks.

    In a couple of notable cases, some of those plugin authors asked what the person was planning on doing to change the plugin. Surprisingly they responded and told them. Let’s just say that these plans are very much against our guidelines.

    In at least one case, the plugin author told this prospective purchaser as much, and the person responded by asking how long it would be in the directory before we shut it down, and how many sites could he get the code to before getting this noticed and thus removed from the directory. He even asked whether it was a manual or automatic process (hint: it’s both).

    Yes, this guy was actually that blunt about his plans.

    While my evidence is slim, I believe this particular person is a Russian spammer or hacker looking to add malware into the plugins and get this code onto as many sites as possible before we put a stop to him.

    What can I say? WordPress is a big target. Some are going to try to abuse the system. We’re used to that. Now you plugin authors will need to get used to it too, because you can be a target for this sort of thing as well.

    People offering to buy your plugin are generally spammers. They’re probably using fake email accounts, and offering you false information as well. They may be able to pay you, but understand that what they’re looking for is to buy heaps of unrelated plugins, modify them all with SEO spam like backlinks or potentially even malware, and get our systems to push those things to as many sites as possible before we notice and shut them down hard.

    Do you really want to sell your plugin to somebody like that? Do you want your hard work to be abused and to have your good name tarnished?

    Think twice before selling your plugin. Know the person you’re selling it to very well. Ignore unsolicited emails from people you don’t know. If they are going to pay you based on the number of “Active Installs”, then just don’t even consider it.

    Don’t worry about the plugin review team too much though. We can find and shut these things down very quickly, even in real-time. But it does help us quite a bit if you ignore these types of scammers too. 🙂

    But if you do decide to give your plugin to somebody responsible and real and who actually cares about it, make sure they know about the Plugin Directory Guidelines. Because hosting a plugin in the WordPress.org Plugin Directory is a privilege, not a right. We can and will act to remove and stop plugins in our systems from doing bad things, no matter who “owns” them.

     
    • Eric Amundson 12:17 am on February 13, 2016 Permalink | Log in to Reply

      Great post, Otto!

      I’ve received at least a few unsolicited emails asking to buy plugins and I figured they were up to no good as their company had nothing to do with WP development. Like you said, they were marketing agencies.

      Glad to know there are some automated ways to spot and remove bad, or compromised plugins.

    • FolioVision 12:44 am on February 13, 2016 Permalink | Log in to Reply

      Good post Otto. I’m just curious about why you said the person is a Russian spammer or hacker. Do you have specific grounds or is this just kneejerk MSM “blame the Russians” for everything?

      There are plenty of American spammers and scammers. I in specific had contact from some agency in New York, David something or another (can’t find the email now or I’d name names). They said they just wanted to stick advertising in one of our plugins.

      • Ipstenu (Mika Epstein) 12:55 am on February 13, 2016 Permalink | Log in to Reply

        It’s based on the evidence in the emails (header information, urls provided, etc). He has specific grounds.

        • FolioVision 2:37 am on February 13, 2016 Permalink | Log in to Reply

          Well at least he was honest about his dark plans for world domination via underhanded plugin purchases! Good luck with the automated tools to suss out these issues when they happen. I suppose you are running a filter on outbound links added to plugins when updated, both in documentation and PHP, as well as particular patterns in the PHP (which will catch most of the lightweights). An account used once this way is lost forever. Most such buyers would have plugins arriving on accounts with very limited previous WordPress.org participation.

          Thanks for fighting the good fight!

    • JasWSInc 12:58 am on February 13, 2016 Permalink | Log in to Reply

      > Yes, this guy was actually that blunt about his plans.
      Crazy. Thanks for passing this along 🙂 Appreciated.

    • Maeve Lander 1:10 am on February 13, 2016 Permalink | Log in to Reply

      Good post, thanks Otto. I’ve received emails like this and sent them straight to spam but they can look quite convincing on first read.

      Another disturbing thing I’ve noticed recently is marketing/dev companies going through the wordpress.org plugin support threads collecting URLs and email addresses of users having difficuclties, then contacting those users privately with offers of paid assistance. Poor form. And extremely anoying when the user then contacts me as the plugin dev saying “is this you guys or some other chancer” or “can I get some support for this privately cos I don’t want to post my link in the forum”.

    • Arnan de Gans 3:23 am on February 13, 2016 Permalink | Log in to Reply

      I’ve had people approach me over the last 2 years with stupid offers of buying my AdRotate plugin (https://wordpress.org/plugins/adrotate/) from me.
      Some even had the audacity to offer me as little as $5000 for it. Some were willing to go up to $50-70k.

      All appeared to be from India or had names that suggested they were from India.

      The plugin would be “repurposed for marketing goals” or they wanted it because of the user base and they would take the plugin in a “different direction”. All the while crediting me for the original code. As if that is doing me a favour. Hah.

      But… Another thing I noticed from a few of those dudes. They were just after my financial details.
      Trying to find out how rich I am. Who I used to process money. How much income I generate from plugins.Things like that…
      While not irrelevant when selling a plugin, the way they went about these questions made me wonder if they wanted the plugin at all or were just looking for a “best practise” business model to use for whatever they were up to.

      So also beware of people asking about how you run your business 🙁

      Does WordPress/Moderators have a mechanic to report people like this?
      If not, is it an idea to have this? We authors could send suspicious stuff to plugins@wordpress.org for example and after a quick examination of the email exchange the WP team could build a blacklist or something. Such a list can be simple enough. Something like a list; Name, Company, Category, last received report, how many reports received.

    • Milap 7:18 am on February 13, 2016 Permalink | Log in to Reply

      Very useful post Otto. I have my own plugin with more then 60k+ active installs, and i got 3 offers in last 3 months to sell it. They tried to trap me with their healthy money offer, but i denied them every times as i found something wrong with their offer, and i am happy & proud of that decision. WordPress and all related repositories must be remain clean and we developers will always try our best to achieve that.

    • Rene Hermenau 11:53 am on February 13, 2016 Permalink | Log in to Reply

      I ignore such mails, especially when there is no full contact address in their mails. These guys are using freemail address without any other contact data. In 99% of the inquiries you can be sure they are with a bad taste, especially when these guys are entirely unknown in the developer community.

    • George Notaras 7:06 pm on February 13, 2016 Permalink | Log in to Reply

      Great post! Yet another one in a series of great posts lately in the plugins make site!

      As far as I can remember, I haven’t received any such emails. (Or maybe I sent them to the spam box before reading far enough to know what they were about..)

      Trying to think about this for a while from the user perspective and how users could feel safe about their web site after the change of ownership of one of the plugins they use, I always come to the same conclusion: Currently such a change could go unnoticed by the user, but this would not be ideal for most of them as they would possibly want to re-evaluate this new plugin status and make a decision whether to continue using it or not. An ownership change may mean a lot of things, as it has already been mentioned in the post and the other comments, and I think the burden of a decision about whether the plugin should continue to be used is too big and complicated to be taken by wordpress org alone, but the user should also have to decide.

      An idea about chaining all these events together would be the following:

      1. The plugin guidelines could force the previous owner of the plugin to make one last release after having changed the author field name to that of the new owner. This would be just to trigger a notification in WP.
      2. A mechanism could be implemented in wordpress, which (on every plugin update) could compare the author field of the currently installed version of the plugin to the respective field of the updated version. In case these differed, a pop up could be displayed or a notification could be sent (in case of automatic plugin updates) indicating that extra user action should be taken before the update of the plugin could continue. That extra action could just be the acceptance of a confirmation dialog.

      Of course this is not to exclude all the automated or manual testing that takes place at wordpress org.

      This is too simplistic, but I’m sure you get the idea of what I’m trying to say with this example, which is to transfer the final decision of continuing using the plugin to the end user.

    • Jacob N. Breetvelt 9:10 am on April 18, 2016 Permalink | Log in to Reply

      Hi,
      I am the autor of plugin wp-photo-album-plus https://wordpress.org/plugins/wp-photo-album-plus/ and i received an email from Mohammad Noman who wants to buy all the rights of my plugin.
      Does anyone of you know him and/or how do i have to act upon this? He ‘looks’ to be seriously interested to me, but i do not have experience with this kind of things. Can anybody advise me?

  • Ipstenu (Mika Epstein) 9:30 am on February 3, 2016 Permalink |
    Tags:   

    Plugin Review “Inconsistencies” 

    A few people have complained that they feel the review process is inconsistent. I’d like to take a moment to explain exactly why that happens. The tl;dr is, of course, humans make mistakes. But if you really want to understand what’s going on, read on!

    There is no automated review process

    This is the big thing. Every single plugin is opened and read by a human being. We download the plugin, read it, and try to catch the myriad things that are wrong, insecure, not permitted, etc. And we’re humans. We do our best to scan/grep for things we know are easy to find (like I love checking for wp-(con|load|blog) to see if that’s being called). But a lot of times things are buried or hard to catch.

    This means mistakes are made. We don’t claim to be perfect. We claim to try our best to give you the best review we possibly can for your sake, as well as your users.

    Some replies are canned, the process is not

    I’m sure a lot of you have gotten an email starting with this:

    There are issues with your plugin code. Please read this ENTIRE email, address all listed issues, and reply to this email with your corrected code attached. It is required for you to read and reply to these emails, and failure to do so will result in your plugin being rejected.

    Yes, that’s a canned auto-reply. In order to get through reviews faster, we have replies for the common issues. Right now I have 60 in A-Text. That means there are at least 60 problems with plugins I see every single day.

    This makes us able to keep up with reviews. It’s impersonal, we know, but we try to cite examples from your plugin to help you understand what needs your attention.

    We don’t test your plugin on all environments

    Sometimes we do. But really that’s your job, not ours. We do if we notice things that are weird and we think may be problematic. Some days we test on VVV with PHP 5.6, sometimes it’s HHVM, and sometimes its PHP 5.2. Why? It depends on what we have available just then.

    This means sometimes we catch that you coded something for PHP 5.3 and up and sometimes we don’t.

    Every new version is checked top to bottom

    Think about that for a second, please. If you submit a plugin and we pend it for changes, and you send us the new version, we read the whole thing all over again. Every. Single. Time. We check to make sure you did your changes first, yes, but then we go back and re-read everything to make sure we didn’t miss anything, or you didn’t accidentally add in something new.

    This is why, sometimes, you get an email that starts with “We missed this before…” or “This is also not permitted because…” We’re giving you the best review we can.

    No, we don’t list everything wrong

    It’s not what you’re thinking. Every time we do a review, we list everything we see that’s wrong. We do not list out, for example, every instance of a non-sanitized/validated POST call. We do not list out every single usage of script tags instead of enqueues. We will give you an example, especially if you miss some on your first edit, but we expect you to know how to search your own code.

    This helps you learn how to better vet and review your own code. Also it saves us a little time.

    There are multiple people doing reviews

    Some of us are better at some thing than others. When we find a plugin we don’t feel confident in reviewing on our own, we raise a flag and ask our cohorts to spot-check our work.

    This also lets us hand off troublemakers. Let’s be honest here, folks, we don’t all get along with everyone. When it’s clear we’re at an impasse with someone, we ask each other for help.

    Our goal is protecting users first, then you

    The people we care about the most are the users who can’t code or who don’t understand the severity of things like offloading CSS. You may think it’s trivial and makes your plugin smaller. Someone in another country could find them sued for not disclosing it. Or your plugin may not work because Google is blocked where they are.

    We care about protecting the users from XSS and SQL injections. We care about protecting their information. We care about keeping them safe. But we care about you too! We’re so techy about you documenting ‘This plugin calls service XYZ’ because, yes, the users have a right to know where their data is going, but also because you deserve not to have a slew of angry 1-star reviews that you didn’t tell them.

    This is a tricky road to walk. Some people may get exceptions. Some people may teach us more about code! Some people may be told ‘no’ flat out.

    Guidelines evolve over time (so do security best practices)

    We’re constantly looking over the guidelines and evaluating them for clarity, consistency, supportability, and real-world applicability. Have you read our Detailed Plugin Guidelines lately? You should. Similarly, our security checks have gotten better over time. We used to allow you to call wp-config.php directly. We don’t anymore. The more a specific vulnerability is targeted, the harder we are on your code to ensure you are not the weakest link.

    This is for your protection! We’re doing our best to make sure you don’t get dog-shamed for being the reason sites go down.

    Remember: We are mortal

    I said this to start off this post and I’ll say it again. We, your review team, are human beings.

    We make mistakes. We miss things. We read code incorrectly. We don’t test everything as fully as we should. We screw up. We never miss things out of maliciousness or an intent to blacklist you from the repository. We believe you submit your plugins in good faith, and we respect you enough to treat you as adults and point out what you missed or explain how you can do things better.

    This means you should give us the same benefit of doubt we give you.

     
    • Wolly aka Paolo Valenti 9:37 am on February 3, 2016 Permalink | Log in to Reply

      1) Thanx a lot for your job. ( Now I can tell you since I cannot via email 🙂 )

      2) All my plugins have been reviewed and I received information of security problems, or code error.

      My 2 cents, and thanx again for your job.

    • Sami Keijonen 9:56 am on February 3, 2016 Permalink | Log in to Reply

      Are there any others than Pippin and you making great job at plugins review?

      I was also wondering if plugin review is as intense as theme review. I personally think that’s not possible because there are so many new plugins and updates coming in daily.

      • Pippin Williamson 2:47 pm on February 3, 2016 Permalink | Log in to Reply

        It is primarily Mika and I but there are several others who review a few plugins, primarily when we need an extra set of eyes.

        The plugin review process is much simpler and much less strict than themes. Themes have an inherent minimum that they must provide, but there’s no such thing with plugins. A plugin could be one line or 500,000.

    • IntellyWP 11:42 am on February 3, 2016 Permalink | Log in to Reply

      Hi only want to say… Thank you! 😀
      Your review process is amazing and also the information provided are each time very specific.
      Thank you again, Alex (IntellyWP team).

    • Mayeenul Islam 11:50 am on February 3, 2016 Permalink | Log in to Reply

      First of all, thanks a lot for the awesome job.

      I’ve a suggestion for you, as you mentioned:
      “If you submit a plugin and we pend it for changes, and you send us the new version, we read the whole thing all over again. Every. Single. Time.”

      If a version is managed, and all the diffs are visible it’s easy overseeing all the changes. If the changes are right, then you can check the overall thing.

      • Pippin Williamson 2:49 pm on February 3, 2016 Permalink | Log in to Reply

        Plugins do not existing in WordPress.org’s SVN repo until after they are approved, so we cannot automatically generate a diff of the new version.

        Tip: plugin authors can make the review process faster by including a link to a diff when sending a new version for review.

      • Ipstenu (Mika Epstein) 2:50 pm on February 3, 2016 Permalink | Log in to Reply

        Sure, but re-read why I said we do that.

        We know we miss things. That re-review has cought things multiple times. We’re doing this for your benefit. Make sure we get everything right.

        Plus we have to be sure you changed everything we asked and a diff will only show us what you did do, not if you did everything.

        It’s the same if your plugin is closed for security. You get a top-down review to make sure everything is good, even things we didn’t initially flag.

    • OllieJones 12:19 pm on February 3, 2016 Permalink | Log in to Reply

      “we, your review team, are human beings” — Yes, extraordinarily talented and dedicated human beings. Thanks. It’s your work that makes the plugin repo such a useful global asset.

      A suggestion: You said you have sixty or so “canned” reponses. How about posting them, in rough order of how frequently you send them out? That we we plugin noobz can see the kinds of things your code inspection looks for.

    • Chad Butler 1:14 pm on February 3, 2016 Permalink | Log in to Reply

      Thanks for the time and talent that the plugin review team puts into this.

    • Carolina Nymark 2:36 pm on February 3, 2016 Permalink | Log in to Reply

      <3 I just want to copy this over to theme reviews. I love the idea of (nearly) auto-replies.

    • Andy Fragen 3:00 pm on February 3, 2016 Permalink | Log in to Reply

      Thanks Mika, Pippin, and Otto. I appreciate all you time and expertise, and I know my users do. <3

    • Devio Digital 8:19 pm on February 3, 2016 Permalink | Log in to Reply

      I’ve had a few plugins reviewed now, and besides the two getting refused due to names in the slug which I wasn’t Legal owner of, I’ve had nothing but positive results 🙂

      Even with the rejections, I had kind, personal notes, so I don’t have a bad thing to say about the review process. You guys are doing an awesome job!

    • Mark O'Donnell 10:34 pm on February 3, 2016 Permalink | Log in to Reply

      Thanks Mika (Pippin, Otto, and whoever). You guys do an outstanding job. You are extremely knowledgeable, and very responsive. I say that as someone who has had plugin submissions “dinged” for various issues (generally my carelessness). Every time your review has made my plugins better.

    • jeffmcneill 4:24 am on February 4, 2016 Permalink | Log in to Reply

      Just another thank you for taking care of the important but definitely thankless task by whomever is doing all this great work. While still human, the challenge borders on the superhuman.

    • Guido 10:30 am on February 4, 2016 Permalink | Log in to Reply

      I’m just wondering, if a plugin in repository gets updated with for example a depricated function or other bad coding, is this somehow noticed by the review theme? If not, I suggest a report button.

      • Ipstenu (Mika Epstein) 4:14 pm on February 4, 2016 Permalink | Log in to Reply

        We don’t review every single commit to that granular of a level.

        And we’ve talked about a report button, but … well, report to whom? The review team? If it’s not security related, we’re not going to step in, so just leave a support-post for the author or contact them directly 🙂

    • Robin Cornett 5:07 pm on February 5, 2016 Permalink | Log in to Reply

      Just want to chime in and say that y’all are awesome. I’m thinking plugin reviewing is a monumental task. In my experience, y’all have been incredibly fast, courteous, professional, and helpful. Also, the docs for plugin guidelines, and navigating SVN, have been invaluable. Thank you!!!

    • A WP Life 6:03 pm on February 7, 2016 Permalink | Log in to Reply

      In my opinion @Mika you doing great job for all plugin developers.

    • victordemianenko 7:54 pm on February 9, 2016 Permalink | Log in to Reply

      Thanks for your time and talent, guys! It is thanks to your work, I can say this:
      Have you in frustration or may be in stress?
      Helpful for you will be only WordPress! :))

    • pressbro 8:47 pm on February 11, 2016 Permalink | Log in to Reply

      I just today got my first plugin accepted and the help from @ipstenu was more than I expected. Friendly, to the point and helpful. I honestly didn’t expect anything for a week, but everything happened in a mere day and a half or so, and was mostly behind me fixing the issues in my plugin.

  • Ipstenu (Mika Epstein) 7:00 pm on January 26, 2016 Permalink |
    Tags: bad code, filters, scan   

    Catching Bad Code Before It Happens 

    It’s not that easy.

    We’ve got more spam/bad code in the plugin repository than anyone would like to see, and while we do manually curate plugin submissions, we don’t actively or even passively patrol all checkins for the bad stuff. We just can’t. We’re human, and with 600-1000 check ins a day, we can’t keep up unless it was a full time job and we were a Nacin-Bot.

    While we have been adding on filters to plugins, to try and curtail the outright bad stuff without needing human intervention, setting up filters and checks that work more than 10% of the time has been a monumental effort. And frankly, 10% just ain’t good enough. We still have to scan the whole repository for bad code on a semi-regular basis, and manually curate the naughty list. The pre-commit tool we have there now checks for base64 and eval and other obvious stuff. It also can check for non-obvious stuff, such as variable function calls (thanks to PHP’s tokenizer). Until we can get up to 80-90% reliability with those checks, there’s no point in them, since the manual work remains intact.

    And this is where you, the merry followers of this blog, come in. You’re smart people. You know what bad code is. You know what hacks look like. You love regex and filters. You scan plugins for the sheer fun of it (or because your work needs you to). We want your help. We want your code.

    How do you do it? What filters do you use, what strings do you look for, and what’s your best trick to catching the bad guys?

    I know you hate bad code as much as we do, and we won’t get to awesome without your help!

     
    • Marko Heijnen 7:12 pm on January 26, 2016 Permalink | Log in to Reply

      At the community summit some of the hosts did talked about checking the quality of a plugin. Mainly focussed if a plugin still works on a certain PHP version. It’s on my plate and I have played around a bit but nothing specific yet. http://php-grinder.com is still a great project to look at but I guess not really the solution for this problem.

      What I do wonder if the things what currently happens can be placed somewhere publicly.

    • J.D. Grimes 8:04 pm on January 26, 2016 Permalink | Log in to Reply

      Before I use a plugin I usually perform a manual review looking for security vulnerabilities. This is a manual review, but for my own code I automate this process during development using WPCS. The reason that I haven’t used WPCS when checking other code is that its security-related sniffs are very strict. The XSS sniff requires all output to be escaped right at the point of output for example—it can’t detect whether the variable was escaped at some previous time. Early sanitization and late escaping are really practices that all developers should follow, but I realize it might not be realistic to expect those to ever become requirements for all plugins in the repo. Short of that, I’ve considered creating more restrictive versions of these sniffs, that will have many false negatives, but very few false positives. So everything that they would flag would have a very high (99% maybe) chance of being a real security vulnerability (XSS, SQLi, etc.). I think I might even have started work on some of these restricted sniffs. If you’re interested I can find the code. I’d be willing to help work on them if you think that this is something worth pursuing.

      The other thing that I would suggest is that you might want to ban the use of the `move_uploaded_file()` function. Usually when that function is used to upload a file in a plugin, it means that the plugin isn’t properly protecting against arbitrary file uploads. You should require that WordPress core’s `wp_handle_upload()` and `wp_handle_sideload()` be used instead, since these will automatically restrict the types of files that can be uploaded to a safe list (though this can be disabled of `$overrides[‘test_type’]` is set to `false`).

    • Varun Sridharan 1:53 am on January 27, 2016 Permalink | Log in to Reply

      Hi, All
      I just created a small php class which creates a welcome page and also fetch the data about this plugin from wp.org. and this welcome page loads only at the plugin activation..

      https://github.com/technofreaky/WordPress_Plugin_Activation_Welcome_Page

      Do you think its a bad code ??
      Need to modify more ?

      Or is there any other code / class available for plugin welcome screen

    • SimonRWaters 9:28 am on January 27, 2016 Permalink | Log in to Reply

      “How do we do it?” – we put all code through sonarqube, insecure dependency checking, various Java specific tools for Java detecting common bugs and measuring coverage, manual code review, and test with BurpSuite Pro and other tools at the security manager’s discretion (that’ll be me). It doesn’t scale, it doesn’t catch everything (nothing will). We are also solving a different problem (except when using 3rd party plugins), we are looking for accidental mistakes, but you also have to look for deliberate spam, and that is a whole lot harder problem.

      Sonarqube is cool, but it isn’t terribly PHP focused, might be a tool to add to the mix if you aren’t already, although they’ve tended just to re-use or re-implement existing PHP scanners. At least contribution to such a tool might find life and utility elsewhere.

      I’ve also made feedback that you accept contributions to SVN without encrypting credentials, this seems a silly to me, just asking for credentials to be abused. My suggestions got the registration emails changed to suggest developers use TLS but I bet most just followed the emailed instructions and still use unencrypted submissions. Do wonder if there are wider security issues that need addressing when I see that sort of thing.

    • psiinon 10:47 am on January 27, 2016 Permalink | Log in to Reply

      You could always use ZAP: https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project for dynamic security testing.
      ZAP can be used both manually and completely automated, eg as part of a CI environment.
      Its also open source and completely free.
      Disclaimer – I’m the ZAP project lead 😉

    • A WP Life 3:31 pm on January 28, 2016 Permalink | Log in to Reply

      Hi Mika,

      600-1000 check ins a day it so big figure to handle.

      But, I am really appreciate your work.

      You doing great job for all plugin authors.

      Thanks
      aWPLife

    • snowboardmommy 9:14 pm on January 29, 2016 Permalink | Log in to Reply

      I wonder if WordFence and/or the other security plugins could be called upon to help?

      It’s in their best interest if spammy / infected stuff just doesn’t end up on anyone’s installation in the first place.

      I know that WordFence scans every plugin and theme on my wordpress installations, every day for me for hacks, infections … it also compares the files in the repository to make sure my local copy isn’t changed / infected. (For a while, it was driving me crazy with one of readme’s from Ban Hammer, actually!!)

      it seems like it should be possible to “reverse” the mirror and scan the repository itself for the same hacks, infections, etc. or, perhaps a “pre-repository” for not-yet-approved plugins.

      Anyway, if you don’t have their contact info, I can find it for you.

      HTH

      ~Bonnie

    • palmermarc 6:54 pm on February 2, 2016 Permalink | Log in to Reply

      In your post, you mentioned not using variable functions. I have some validation functions that work as follows.

      $meta_fields = array(
      ‘field_1’ => ‘sanitize_text_field’,
      ‘field_2’ => ‘sanitize_html’,
      ‘field_3’ => ‘custom_validation_sanitization_function’
      );

      foreach( $meta_fields as $meta_key => $validation_function ) :
      update_post_meta( $post_id, $meta_key, call_user_func( $validation_function, $_POST[$meta_field] );
      endforeach;

      Is this the type of variable functions you’re actively working against? Or would this be considered okay?

  • Samuel Wood (Otto) 8:20 pm on January 23, 2016 Permalink |  

    [RESOLVED]

    Same issues that were happening two weeks ago are happening again right now. I have alerted relevant parties to the problem.

    For now, new plugin authors won’t be able to commit, and some plugin readme.txt files won’t get processed correctly until this is corrected.

    Sorry for the inconvenience.

    Edit: This seems to be fixed for the moment, we’re working on preventing future recurrences.

    ETA2: If your plugin is still missing, we know and we’re working on it.

     
    • Ipstenu (Mika Epstein) 3:40 am on January 24, 2016 Permalink | Log in to Reply

      Please note this means we will not be approving new plugins until it’s fixed. There’s no point if I have to loop back with you all to explain why you can’t access things.

  • Ipstenu (Mika Epstein) 6:58 pm on January 20, 2016 Permalink |
    Tags: ,   

    Reminder: Policy About Tags In Plugin Readmes 

    This is a reminder of current policy.

    We ask that users limit tags in their plugins to no more than 12 (twelve), with some exceptions. Any time your plugin has a high number of tags, you’re seen as trying to game the system.

    How do you fix this?

    1. Remove any ‘common misspellings’ from your tag list
    2. Remove duplicate tags
    3. Don’t use ‘wordpress’ or ‘wp’ in your tags
    4. Don’t use tags that don’t apply
    5. Don’t use your competitors in your tags (if you’re not a woocommerce plugin, don’t list it)
    6. Don’t list everything under the sun related to your plugin
    7. Do use tags that clearly identify what your plugin is

    As much as some people like to think, “tags” are not the same as “search terms” in our system, so including lots of them doesn’t really benefit you much. By adding multiple tags, you reduce the efficacy of searches and tags for everyone and make the experience of looking for a plugin suck. Yeah. You did that to yourself.

    If you’re looking to improve your search rankings, we suggest improving the parts of the readme intended for human beings to read. The short and long descriptions should be clear and useful. Addressing common problems in the “FAQ” section helps too. The entire contents of the readme file is considered for the search, and tags are really only a small part of that. Removing irrelevant pieces such as lists of languages (like links) or feature bullet points may help a lot as well, to reduce the overall length and to help eliminate irrelevant information about the plugin.

    Make the readme for people, not for machines, and it will help you rank higher in the search results. People actually search for solutions to their problems, not simply for keywords.

     
    • ArtissTheGeek 7:36 pm on January 20, 2016 Permalink | Log in to Reply

      Thanks for this Mika. Can you explain what purpose the tags have then, if the README in its entirety is used for search?

    • George Notaras 7:43 pm on January 20, 2016 Permalink | Log in to Reply

      Hi Mika,

      Thanks for this insight!

      Taking the whole readme into consideration is a good idea, but I think that there might be a little problem with plugins which list functionality of their pro versions inside the readme. This functionality is not part of the plugin that is provided through wordpress org, so this could lead into some search results being a little misleading.

      Also, although I don’t consider it a big problem, at some point it might be a good idea to add some guidelines about the plugin slugs and titles. Sometimes they are ridiculously long, other times the titles are totally different than the slug. Not a big deal, but these are points of possible abuse, so it might be a good idea to take these into consideration for future reevaluation of the guidelines.

      • Ipstenu (Mika Epstein) 5:53 am on January 22, 2016 Permalink | Log in to Reply

        Eh, that’s up selling which is difficult to do.

        Right now we let it go because we permit up sells. I would leave it out of the tags and put it in the content of the read me, though.

        • George Notaras 10:43 am on January 22, 2016 Permalink | Log in to Reply

          > Right now we let it go because we permit up sells. I would leave it out of the tags and put it in the content of the read me, though.

          Hmm, that’s fair enough, but still leaves room for some exploitation in the readme. Maybe there could be a special HTML comment (or a non standard HTML tag) in the future which should be used to enclose the part of the readme that is about the pro functionality and which would not be taken into account by the search algorithm. Just an idea.. I’m sure you’ll figure something out if you notice abuse. Keep up the good work!!

          • Ipstenu (Mika Epstein) 4:24 pm on January 22, 2016 Permalink | Log in to Reply

            Honestly the terrible 1-star reviews they get from doing that hurts them more than anything else. Here’s what happens.

            Developers put in all the features, pro and free, in the readme.

            User googles and finds plugin. Installs only to see the pro is missing. Leaves 1-star review about how the plugin is not as advertisted.

            Developer replies in a snit that it’s clearly stated this is in the pro version.

            User tells developer off.

            Moderators step in, close the post, and leave it for posterity.

            Plugin subsequently gets low marks across the board for how the developer handled an upset user.

            • George Notaras 12:30 am on January 23, 2016 Permalink

              Such things happen around here? Amazing! :p

              PS: Good point!

    • Reedyseth 7:51 pm on January 20, 2016 Permalink | Log in to Reply

      Thank you @Mika for the reminder. I will try to keep track of this and fix if need it.

    • JasWSInc 11:42 pm on January 20, 2016 Permalink | Log in to Reply

      Great suggestions Mika. Thank you for the reminder.

    • Rene Hermenau 9:46 am on January 21, 2016 Permalink | Log in to Reply

      A good step forward to make the plugin rep more structured.

      @ArtissTheGeek The tags are helpful for finding all plugins which are specialized and dedicated for a specific purpose. If everyone will stop ‘spamming’ the rep and will use only the plugin’s main capabilities as keywords we get a much better plugin search experience.

      • ArtissTheGeek 10:17 am on January 21, 2016 Permalink | Log in to Reply

        I don’t disagree Rene, just trying to understand exactly how the tags are used. Even Jetpack breaks some of Mike’s suggested rules, so there obviously isn’t the clarity around this subject that there should be.

        • George Stephanis 2:48 pm on January 21, 2016 Permalink | Log in to Reply

          We do?

          Jetpack’s current tags list looks like this:


          Tags: WordPress.com, jet pack, comments, contact, gallery, performance, sharing, security, shortcodes, stats, subscriptions, widgets

          https://github.com/Automattic/jetpack/blob/master/readme.txt#L3

          The only thing I can surmise you mean is that we list `jet pack` as a tag. But then, you said ‘some’ not ‘one of’ — so what exactly are you thinking we’re violating?

        • George Stephanis 2:54 pm on January 21, 2016 Permalink | Log in to Reply

          Besides, it actually looks like her “suggestions” are phrased as more “ways to pare down your list to about a dozen if you have way too many” — not strict rules. The main rule was not to have too many tags.

          • Ipstenu (Mika Epstein) 5:52 am on January 22, 2016 Permalink | Log in to Reply

            Common misspelling of ‘jet pack’ is understable here, and would be allowed anyway. Now if there was JetPack, jetpack, and Jerkpack, we’d have words, George 🙂

    • A WP Life 5:23 pm on January 21, 2016 Permalink | Log in to Reply

      We will do. Thanks @Mika.

    • FolioVision 12:51 am on February 13, 2016 Permalink | Log in to Reply

      Not sure that a blanket rule on banning tags with competitor plugin names is a good thing, Mika. Especially if the competitor has (had in this case) a near monopoly on a space (thinking of Yoast for example). Or for example Sucuri for instance (we don’t have a horse in that race).

      Could you explain the reasoning, Mika? I’m asking you here so others can see your thoughts on the issue as well.

      Alec

      PS. There’s a way you could easily fix the twelve tag rule without deleting or delisting plugins: just go and delete any tags after twelve automatically from the database. In this case, abusers will only have their first twelve tags.

      • Ipstenu (Mika Epstein) 1:04 am on February 13, 2016 Permalink | Log in to Reply

        Because a tag should describe what your plugin does, not what someone else’s is named.

        Folgers coffee wouldn’t use the tag ‘sanka’ or ‘nestle’ because those aren’t them. They might use shared terms but they don’t use someone else’s brand because it hurts theirs and they know it. It’s like a smear campaign, it’s bad for everyone, mostly you.

        PS. There’s a way you could easily fix the twelve tag rule without deleting or delisting plugins: just go and delete any tags after twelve automatically from the database. In this case, abusers will only have their first twelve tags.

        Easily no. But we will probably have to switch to how Themes do it and stop letting y’all have a free-for-all with tags.

        • FolioVision 2:30 am on February 13, 2016 Permalink | Log in to Reply

          I’m not sure Mika. I can see your point when a plugin author has 59 tags and they cover every tag possible in an area (including software which shares very little functionality with their own plugin). But if an author stays within her/his 12 tags and considers it important to list a competitor as a tag, that seems to me fair game.

          All those guys like Piet Bos for example working hard on Yoast alternatives should be allowed to use Yoast as a tag and certainly within their descriptions. Otherwise it seems to be you would be giving too big an advantage to the established players and dooming new plugins in a popular sector to just suffocate.

          Have a good weekend.

          Alec

          PS. Just deleting tags over 12 is about as easy a command as it gets. A couple of lines in MySQL and tag spammers will be sitting at 12 tags just like those of us playing it legal. If you were feeling mischievous you could knock plugins with more than 12 tags down to 5 or even zero tags as a reward for breaking your rules. Heck, send all plugin authors this warning (please not once per plugin but just once per author: authors don’t like email promiscuity any more than you do).

          I know you face an issue with bounces but you could send the warning on a special no-reply address (normally I hate those no-reply addresses but in this case it would serve a purpose).

  • Ipstenu (Mika Epstein) 8:57 am on January 12, 2016 Permalink |
    Tags: , ,   

    2015 Community Summit And How You Can Help the Plugin Team 

    Sadly, many of the same reasons we could not add new members to the Plugin Team last year are still an issue (see 2014 Community Summit Wrapup). The codebase has been improved, but the process is slow. Just to give you some hope, the work done on the Theme Repo is being used to help us. So. Soon. Soon. We’re restructuring the backend to make it more clear as to who can do what, but most things are waiting on the re-vamp.

    The only real ‘news’ is that we’ve been sneakily moving our documentation over to https://developer.wordpress.org/plugins/wordpress-org/ – Please check it out to keep up with all the information about what makes good plugins in the repo. Oh, and we’ve swapped reps. I’ll be taking over as the plugin team rep and that really changes… nothing at all. @boone did a great job and I thank him for it.

    You Can Help

    While we are still stuck on the old system, you can jump in and help us by emailing plugins@wordpress.org when you find people playing fast and loose with the rules.

    We encourage and welcome updates from everyone, but please don’t be snippy. Be serious. If someone has powered by links, or is phoning home, yes, please let us know. But don’t let your personal feelings get in the way. This is a big deal. A lot of people send us reports from a place of anger. Don’t be that person. That person makes it harder for us to figure out if someone has a personal vendetta against a plugin and/or developer, or a legit concern. We’re all passionate, but remember to channel that passion into something beneficial.

    How to Report Issues

    If you’ve found a plugin _doing_it_wrong(), email plugins@wordpress.org and remember:

    1. Make your subject clear. (“XSS Vulnerability in Hello Derpy” or “Derpack Developer swearing at users in forums” are good)
    2. Always provide an exact link to the plugin.
    3. Report plugins with guideline violations.
    4. Report developers who are behaving badly.
    5. Be detailed. If you know what file and line of code is the problem, tell us.
    6. Provide examples of vulnerabilities. If you already know what’s hackable, show us. It makes it faster for us to verify and reproduce. Link to forum threads etc etc.

    Remember: We don’t retroactively enforce guideline changes unless there is a legal, copyright, or security related reason. For example, we no longer allow new plugins to call wp-load.php directly, however we don’t hunt around for plugins that do so. If a plugin is closed for using a non-GPL library and, in the review, we note other best-practices violations, we will require them all to be fixed before reopening.

    Also, we won’t be following up with you as to what happened most of the time. We’d love to. We can’t and keep up with emails. Please don’t take it personally. As we add more people to the team we may be able to change that, but right now it takes us away from validating security issues.

     

    Tools

    Rami asked “What do you guys even use to check plugins and look for bad things?” and the real answer is “Our eyes.” We don’t have a theme-check type plugin because there are very few ‘standard’ things to look for (possibly it could check for license issues, including jquery files, and calling wp-load directly sort of things).

    Remember: Thou Art Mortal

    And so are we.

    We’re people too. We make mistakes. We miss things. We have bad days. We get sick. We have families. If we don’t reply to you super fast, please sit on your hands and give us five days. Five. You should get some sort of reply from us within five, even if it’s ‘we’re still talking about this, sorry but it’ll take a while.’ Sending us an enough every 12 hours (yes, someone did that) is annoying.

    Hunting us down on Twitter and Slack because we didn’t reply right away is similarly uncool and harassing. We use the email so that everyone on the team can read the conversations. Don’t take it off-line. Keep it in the email and that way, if you’re talking to Otto and he goes to a BBQ fest for two weeks days without access, Pippin can pick up the conversation and help you out.

    Just be patient and calm. Especially if we’ve just closed your plugin. We know that sucks, and we totally get you’re angry sometimes. Just try to remember we’re all humans and treat us with respect like fellow humans.

    Grumpy Otto (is there another kind?) looking at the camera.

    Take the plugin. Leave the cannoli.

     
  • Ipstenu (Mika Epstein) 4:31 pm on January 11, 2016 Permalink |  

    [RESOLVED] Jan 11 – Issues committing to SVN 

    0100 UTC

    This problem should be fixed now. Let us know if you have any continuing issues. -Otto

    2339 UTC

    We’ve ruled out a couple things. The access table seems okay. But right now we don’t have an ETA 🙁 I’m sorry.

    2141 UTC

    Just an update to let you know we’re still looking into it. You don’t need to tell us your plugin names. Pretty much everyone who was approved this weekend and on has this issue.

    1631 UTC

    We’re aware of this and looking into it. Please keep an eye on this post. We will update as soon as we have any information.

     
c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel
Skip to toolbar