WordPress.org

Make WordPress Plugins

Updates from Ipstenu (Mika Epstein) Toggle Comment Threads | Keyboard Shortcuts

  • Ipstenu (Mika Epstein) 5:31 pm on June 5, 2015 Permalink |
    Tags: ,   

    ‘Policy’ on PHP Versions 

    The official stance of WordPress.org is that WordPress is supported on PHP 5.2.4 or greater.

    The official stance of the Plugin Team regarding what version of PHP your plugins can use is .. not that.

    We don’t have an official stance. We’ve never needed one. We do (often) test complex plugins on multiple versions of PHP (and sometimes HHVM) to make sure there’s proper degradation and support, but at the same time, we do not have an official requirement that you must support version X or Y.

    This is not an official requirement post.

    This is a reminder post.

    Use whatever version of PHP works best with the code you’re writing. If you’re using, for example, Amazon S3’s library, you must use PHP 5.3 and up because otherwise the libraries won’t work. From that standpoint, your plugin should require PHP 5.3 and up. That’s a decision prompted by circumstances outside of WordPress.

    For everyone who just wants to know what to do if your plugin must be on PHP 5.3 or 5.4, the answer is this:

    Make sure your plugin checks for any and all requirements on activation and, if they’re not found, it should gracefully fail and alert the user as to why.

    This includes things like required software (if your plugin is an add-on to WooCommerce, yes, check that WooCommerce is installed and active), but also PHP versions and (if needed) SQL versions. That’s your responsibility. We’re not going to force you to do it at this time, but understand that your plugin’s reviews and ratings will be directly impacted by how you handle those things.

    Fail gracefully. Degrade gently. Error politely. Consider your users. Remember: WordPress can be used on anything.

    This can be complicated or not, depending on your requirements. The main thing to think of here is that if you don’t support PHP 5.2, then your main plugin still needs to work in PHP 5.2.

    Practical Examples

    Let’s say you use a function that only works in PHP 5.3 and up. A simple function_exists check will do the job:

    if ( !function_exists( 'some_function' ) ) {
        add_action( 'admin_notices', create_function( '', "echo '<div class=\"error\"><p>".__('Plugin Name requires PHP 5.3 to function properly. Please upgrade PHP or deactivate Plugin Name.', 'plugin-name') ."</p></div>';" ) );
        return;
    }
    
    

    Note the use of create_function here, because anonymous functions (aka closures) don’t work in PHP 5.2.

    The use of return prevents the rest of the plugin from executing here, preventing that function call later from causing a syntax error.

    Sometimes though, you need more complicated checks. Let’s say your plugin uses PHP namespaces. Those are not supported in PHP 5.2, and will cause a syntax error just from having them in the file, before any of your code runs.

    So, your main plugin file needs to not have namespaces and basically only be a shiv to load the rest of the plugin from another file if the requirements are met:

    if ( version_compare( PHP_VERSION, '5.3', '<' ) ) {
        add_action( 'admin_notices', create_function( '', "echo '<div class=\"error\"><p>".__('Plugin Name requires PHP 5.3 to function properly. Please upgrade PHP or deactivate Plugin Name.', 'plugin-name') ."</p></div>';" ) );
        return;
    } else {
        include 'rest-of-plugin.php';
    }
    

    Here, the plugin does not load the files that can cause errors unless the requirements are met.

    Maybe you need to check against the WordPress version. Plugins load in the global context, so the $wp_version variable is available to you to check:

    if ( version_compare( $wp_version, '4.0', '<' ) ) {
        add_action( 'admin_notices', create_function( '', "echo '<div class=\"error\"><p>".__('Plugin Name requires WordPress 4.0 to function properly. Please upgrade WordPress or deactivate Plugin Name.', 'plugin-name') ."</p></div>';" ) );
        return;
    }
    

    Although, if you’re requiring a specific WordPress version, then you’re more likely to be requiring a specific function instead, in which you should check for that specific function as in the first example.

    If you want to be complicated about it, you can indeed do so. Here’s code for a plugin which will deactivate itself if the PHP version requirement is not met:

    if ( version_compare( PHP_VERSION, '5.4', '<' ) ) {
        add_action( 'admin_notices', create_function( '', "
            echo '<div class=\"error\"><p>".__('Plugin Name requires PHP 5.4 to function properly. Please upgrade PHP. The Plugin has been auto-deactivated.', 'plugin-name') ."</p></div>'; 
            if ( isset( $_GET['activate'] ) ) 
                unset( $_GET['activate'] );
            " ) );
         
        add_action( 'admin_init', 'pluginname_deactivate_self' );
        function pluginname_deactivate_self() {
            deactivate_plugins( plugin_basename( __FILE__ ) );
        }
        return;
    } else {
        include 'rest-of-plugin.php';
    }
    

    The reason for the unset of $_GET[‘activate’] here is so that the normal plugin activation process will not show the normal activation message, showing the plugin’s message only.

    These are not the only ways to perform a check like this, however they should be enough to get you started. Remember: Make things obvious to your users what the problem is, so they can understand the situation and take action.

     
  • Ipstenu (Mika Epstein) 3:41 am on May 7, 2015 Permalink |  

    Genericons Example File is Unsafe 

    If you use Genericons in your plugin, please exclude the example.html (which is no longer included in the Genericons package itself).

    The Genericons icon font package, which is used in a number of popular themes and plugins, contained an HTML file vulnerable to a cross-site scripting attack. All affected themes and plugins hosted on WordPress.org (including the Twenty Fifteen default theme) have been updated today by the WordPress security team to address this issue by removing this nonessential file. To help protect other Genericons usage, WordPress 4.2.2 proactively scans the wp-content directory for this HTML file and removes it. Reported by Robert Abela of Netsparker.

    See the full release notes: https://wordpress.org/news/2015/05/wordpress-4-2-2/

     
  • Ipstenu (Mika Epstein) 6:00 am on May 4, 2015 Permalink |
    Tags: ,   

    Reporting Plugin Issues 

    Note: I’ll be using Hello Dolly as my example ‘bad’ plugin for this post. It’s fine and not (to my knowledge) vulnerable.

    There are a few reasons people report plugins but the main two are as follows:

    • Guideline violations
    • Security vulnerabilities

    If you report a plugin, you can make everyone’s life easier if you do the following:

    Verify that it’s still applicable

    Before you do anything, check if the exploit is on the latest version of the code or not. If it’s not, we may not do anything about it, depending on how popular the plugin is.

    Use a good subject line

    “Plugin Vulnerability” is actually not good at all. “Plugin Vulnerability in Hello Dolly – 0 Day” is great.

    Send it in plain text

    SupportPress is a simple creature. It doesn’t like your fancy fonts and inline images. Attachments are fine, but we cannot read your ‘Replies in-line in red’ so just keep it simple.

    Link to the plugin

    https://wordpress.org/plugins/hello-dolly/

    Yes, it’s that easy. Put the URL on it’s own line, no punctuation around it, for maximum compatibility. With over 35k plugins, and a lot with similar names, don’t assume, link.

    If the plugin is not hosted on WordPress.org, I’m sorry, but there’s nothing we can do, so please don’t bother reporting it to us. We have no power there.

    Explain the problem succinctly

    Keep it simple.

    “Hello Dolly has an XSS vulnerability” or “The Author of Hello Dolly is calling people names in the forums” or “Hello Dolly puts a link back to casino sites in your footer.”

    Think of your intro like a tweet. Boil it down to the absolutely basic ‘this is what’s wrong.’

    Keep the details clear

    If someone’s acting up in the forums, link to the forum threads.

    If you know that on line 53, the plugin has a vulnerability (or a link back to that casino site), then you can actually link right to that line: https://plugins.trac.wordpress.org/browser/hello-dolly/tags/1.6/hello.php#L53

    We love that. If you don’t have that line, it’s okay. Tell us exactly what you see. “When I activate the plugin using theme X, I see a link to a casino site by my ‘powered by WordPress’ link.” Perfect. Now we know where to look when we test.

    Show us how to exploit it

    Don’t ask us ‘Can I send you an exploit?’ Just send us all the information. If the exploit’s already up online, like on Secunia, link us to it.

    If you know exactly how to exploit it, tell us with a walk through. If the walkthrough involves a lot of weird code, you may want to consider using a PDF.

    We’re going to take that information and, often, pass it on directly to the developers.

    Tell us if you want them to have your contact info

    We default to not passing it on, out of privacy, so “If the developer needs more help, I can be reached at…” is nice. Even “You can give the developer my information so they can credit me…”

    We’re probably not going to follow up with you

    We love the report, we review them, but we’re not going to loop you back in and tell you everything that’s going on for one very simple reason. We don’t have the time. If you told us to give the dev your contact info, then we did, but we don’t have any way to promise they will, and we don’t have the time to play middle management.

    Emailing us over and over asking for status gets your emails deleted. It’s not personal, it’s seriously a time issue. We’re nothing more than gatekeepers, we are not a security company and we’re not equipped for keeping everyone up to date. We don’t have an administrative assistant to handle that. We work with the developer to fix the issue and we work with the .org team to see if we need to force update the plugin, and that takes a lot of time.

    We don’t do bounties

    This is a little interesting but basically we’re not going to pay you. A lot of people ask for ‘credit’ so they can ‘earn’ a bounty, and that’s cool, but we’re not going to report that for you. Generally if you say you want a bounty, we give your info to the plugin dev, though, so they do know you’re interested.

    How do you report?

    You can report plugins by emailing plugins@wordpress.org

    That’s it :) Thanks!

     
    • J.D. Grimes 1:09 pm on May 4, 2015 Permalink | Log in to Reply

      Thank you for laying this out for everyone, it’s nice to have things clear. Now if we could just get this into the hands of people who are/should be reporting plugin issues… :-)

      • Chad Butler 3:55 pm on May 4, 2015 Permalink | Log in to Reply

        Awesomely descriptive! Thanks, Mika.

        I want to second J.D.’s comment – how to get this into the hands of the general public who report these things? I’m guessing they don’t follow Make threads.

        • Ipstenu (Mika Epstein) 4:01 pm on May 4, 2015 Permalink | Log in to Reply

          Man, if you guys have an idea I’d love to hear it.

          The idea of ‘Make a button!’ is not a great one since we’d just get a lot of bad reports and spam :/

          • J.D. Grimes 4:09 pm on May 4, 2015 Permalink | Log in to Reply

            What about just a link to this article or similar, “How to report vulnerabilities/violations”? Then people would have to read it to figure out how. But I guess some folks would still just scroll down to get the email address and you’d still get bad reports.

            I’ve been following https://wpvulndb.com/, and I’ve noticed that some of the researches don’t seem to know how to report the vulnerabilities to the plugins team. Maybe the folks at WPScan could help out with educating security researchers by including a note and a link to this article somewhere.

    • M Asif Rahman 4:23 pm on May 4, 2015 Permalink | Log in to Reply

      We already have button to report broken plugins. Maybe add another like “Report a plugin”. the button will lead to this post. And instead of emailing, maybe lets make a mail to form, with captcha.

    • Nile Flores 12:27 am on May 5, 2015 Permalink | Log in to Reply

      I’ll refer to this article, Mika. Thanks for putting this up. My co-mod shared it in All About WordPress on FB. :)

    • ethicalhack3r 9:05 pm on May 13, 2015 Permalink | Log in to Reply

      What incentive is there for any one who volunteers their time to email you about a plugin vulnerability to do so again if you’re not even going to acknowledge their email?

      You need to gamify this process, give them an incentive to do it again. After all, they are taking their own time to email you about the issue which helps protect *your* users.

      I’m sorry but ‘we do not have the time’ is not an excuse. If there is not enough time then not enough resources are being used for this.

      • J.D. Grimes 9:15 pm on May 13, 2015 Permalink | Log in to Reply

        Note that the email will be acknowledged in my experience. While the heading says “We’re probably not going to follow up with you”, it clarifies that to actually mean “we’re not going to loop you back in and tell you everything that’s going on.” However, the response is usually from a can (but not automated).

        • ethicalhack3r 9:22 pm on May 13, 2015 Permalink | Log in to Reply

          Maybe I miss interpreted it. I can confirm that, looking back through my emails, I have only ever not received a reply once.

          • J.D. Grimes 9:32 pm on May 13, 2015 Permalink | Log in to Reply

            But of course, it isn’t acknowledged in the sense of giving any kind of recognition to reporters, like rep points or a hall of fame mention. Maybe that was more the gist of what you were trying to get across?

            • ethicalhack3r 9:43 pm on May 13, 2015 Permalink

              Yea, that was part of what I was trying to get across. Even just building up a ‘relationship’ with the reporters by following up and saying ‘hey, thanks, we really appreciate the effort’.

              I think a another commenter touched on a submission form type idea. Most people who contact wordpress won’t have read this post. A submission form with all the necessary fields and explaining what wordpress want. I think this would increase the quality of submissions and thus waste less time.

              Full disclosure: I work on wpvulndb.com

              I think a wordpress supported version of what we are doing would improve plugin/theme security. Shine a light on vulnerabilities and credit researchers/reporters. I would be more than happy to work with WordPress in any way we can if they wanted.

          • Ipstenu (Mika Epstein) 3:07 pm on May 14, 2015 Permalink | Log in to Reply

            I can promise you we do reply. Always. Even if just to say “Thank you!”

            Normally people get a form email reply, but it’s something a human had to manually do.

      • Ipstenu (Mika Epstein) 3:09 pm on May 14, 2015 Permalink | Log in to Reply

        We ALWAYS reply to the email. Always. Even yours. I see it in our out boxes. Maybe you need to check you spam filter and make sure pluginsATwordpress.org is on the whitelist? Gmail has been particularly daft about it…

        Nope, not gamifying.

        Incentive? What’s my incentive for doing any of this? I’m not compensated by .org :) I do it because it’s the right thing to do for my community. Do it or don’t do it, we can’t make you, but we can suggest how it would best help US if you choose to. And we do greatly appreciate those who do.

  • Ipstenu (Mika Epstein) 5:04 am on April 21, 2015 Permalink |
    Tags: , testing   

    Reminder: Please Test Your Plugins With 4.2 

    WordPress 4.2 is being released this week. Are your plugins ready?

    After testing your plugins and ensuring compatibility, it only takes a few moments to change the readme “Tested up to:” value to 4.2. This information provides peace of mind to users and helps encourage them to update to the latest version.

    For each plugin that is compatible, you don’t need to release a new version — just change the stable version’s readme value.

    In the same vein, please take the time to make sure the people listed as committers on your plugin are only the people who are actively developing the plugin.

    Finally, if the email associated with your wordpress.org plugin author’s account has an auto-reply, please for the love of peanut butter change that or put plugins@wordpress.org on a magic whitelist that doesn’t get the auto-replies. We very rarely send you out important emails, but when we do, they’re related to security or upgrades. When you give us an auto-reply, it delays things and makes our in-box insanely large.

     
    • Varun Sridharan 5:07 am on April 21, 2015 Permalink | Log in to Reply

      :) Thanks For The Info

    • Pär Thernström 6:25 am on April 21, 2015 Permalink | Log in to Reply

      > In the same vein, please take the time to make sure the people listed as committers on your plugin are only the people who are actively developing the plugin.

      Is that the Contributors-field, or is there any other field that I have missed in my plugins? :)

    • rahul286 7:03 am on April 21, 2015 Permalink | Log in to Reply

      > When you give us an auto-reply, it delays things and makes our in-box insanely large.

      Just wondering if outgoing emails can have reply-to header set to no-reply@wordpress.org or some mail address which is not monitored. It might save plugins@wordpress.org inbox.

    • Rami Yushuvaev 3:38 pm on May 11, 2015 Permalink | Log in to Reply

      make sure the people listed as committers on your plugin are only the people who are actively developing the plugin.

      Actually, this is not correct. If I develop plugins for brands, and I’m the only committer, I can’t remove the brand username, it’s against your policy.

      • Ipstenu (Mika Epstein) 10:44 pm on May 11, 2015 Permalink | Log in to Reply

        Not our “policy,” but that’s a different thing and it’s actually exactly what I mean.

        What Rami’s talking about is that if you make a plugin for a company (say LiveJournal hires me to make a plugin to autopost), then I really should be using a LiveJournal company account to MAKE the plugin because the company owns the trademark, not you.

        So in that example, there might be two committers.

        1) LiveJournal – The plugin owner who is responsible for all things security, guideline, etc.
        2) My Account – The person who is in charge of writing the code.

        And there, Rami, you may be the only person actively developing the plugin, but the owner is someone else.

        What we meant by that statement is that if you quit development for a plugin, you should have your name removed. Otherwise you get all the emails about all the issues, and you may not want them.

  • Ipstenu (Mika Epstein) 5:50 pm on April 14, 2015 Permalink |
    Tags: js,   

    Isotope 2.2 And Up is GPL Compatible 

    For a long time, the Isotope jquery library has had a commercial license that made it not really compatible with the GPL.

    Isotope v2.2.0 has shipped with revised licensing model that is GPLv3 by default. Purchasing a commercial license allows use outside of the GPL, under the Commercial License terms, without causing conflicts. You can read details at: http://isotope.metafizzy.co/license.html

    You can see the whole history here: https://github.com/metafizzy/isotope/issues/800

    The tl;dr is this: If you’re using Isotope 2.2 and up in your plugin, it’s permitted in the plugin repository but you need to license YOUR plugin as GPLv3.

     
  • Ipstenu (Mika Epstein) 7:25 pm on February 27, 2015 Permalink |
    Tags: , ratings, , reviews   

    Ratings Rebuilt 

    Did your ratings suddenly change dramatically? Hopefully not, but if they did, it’s because the ratings for all plugins were recently reset and rebuilt earlier this week. All ratings now correspond exactly with existing, non-deleted, reviews.

    As Otto put it:

    Back when we launched the review system 2.5 years ago, we tied ratings to reviews. However, up until that point, we had existing ratings in the system. At the time, some argued that the ratings should be wiped and everybody start fresh. I argued for the opposite, that we should leave the existing ratings in place until such time as we had enough reviews in the system to build up a good body of ratings.

    That time has finally come. What you see now is the ratings that correspond to your reviews. The data comes directly from the reviews themselves, and is accurate. Any ratings previously left over from the pre-review world are no longer available.

    Additionally, the ratings now will accurately reflect the actions of the moderation team. If a review is deleted for whatever reason, then the associated rating for it will not be reflected in the results.

    Please keep in mind, this means that all of the people who thought making sockpuppets to spam the reviews with 5-stars on their own plugins (or 1-stars on their competitors) have had the biggest swings. It should go without saying that you should never leave multiple reviews on your own product (we’re pretty sure you like it 😉 ) and you should never attempt to hide behind proxies and fake accounts to leave reviews. Be honest. It works out better.

     
    • Drew Jaynes 11:11 pm on February 27, 2015 Permalink | Log in to Reply

      Awesome! Thanks for the update @ipstenu :)

    • jeangalea 3:27 am on February 28, 2015 Permalink | Log in to Reply

      These changes are very welcome, thanks! I also notice that there is now an estimate of the number of installs on the main page of every plugin, rather than the amount of times it has been downloaded. How is that figure being calculated? I’d like to know how accurate it is.

    • Varun Sridharan 8:07 am on February 28, 2015 Permalink | Log in to Reply

      Awesome!.. thanks for good update .. @ipstenu

    • WPSecureOps 11:40 am on February 28, 2015 Permalink | Log in to Reply

      Oops, we’ve some weird error on our plugin’s stats page:
      “Cannot read property ‘title’ of undefined×”
      https://wordpress.org/plugins/wpsecureops-easy-firewall/stats/

      Any ideas what can be causing that?

      • WPSecureOps 11:41 am on February 28, 2015 Permalink | Log in to Reply

        In case that this is helpful: Chrome Version 40.0.2214.111 (64-bit) (OSX)

      • Samuel Wood (Otto) 5:31 pm on February 28, 2015 Permalink | Log in to Reply

        This has nothing to do with the ratings, as the stats are a separate change still being worked on. However, the people in the know about that have been notified of the issue and will look at it soon. :)

        • WPSecureOps 5:30 pm on March 1, 2015 Permalink | Log in to Reply

          Ah!
          At least, i’m happy that I was able to help to report another problem then :)

          Good luck with the new stats, they look awesome, especially this new version specific bar!

    • Varun Sridharan 1:58 am on March 1, 2015 Permalink | Log in to Reply

      Hi,
      Can i please know how do you calculate `Active Installs: Less than 10`. because
      https://wordpress.org/plugins/wpsecureops-easy-firewall/ = is used by more that 10 live sites. but in that status its only less than 10 ??

      • Ipstenu (Mika Epstein) 2:23 am on March 1, 2015 Permalink | Log in to Reply

        That code isn’t complete yet, which Otto said in the post above. Obviously there’s an issue, since the graph isn’t even showing. Don’t spend your time worrying about this yet, we’ll post and explain it when it’s done.

        Now if you have a question about the RATINGS, please let us know. That’s done and that’s why we posted here :)

      • WPSecureOps 5:33 pm on March 1, 2015 Permalink | Log in to Reply

        You are using our plugin on more than 10 live sites?!

        WOW! We are really happy to hear that !!!!

        If you have any feedback/suggestions/need of help or simply want to say “Hi!”, don’t hesitate to ping us at support@wpsecureops.com :)

        PS: Sorry for going a bit off topic, but …. :)

    • Joachim Jensen (Intox Studio) 5:09 pm on March 1, 2015 Permalink | Log in to Reply

      I wondered why the total number went down for Content Aware Sidebars, but the average rating didn’t change. This “cleanup” is appreciated very much!
      I’ve noticed a few plugins with very questionable reviews though, and those have not been removed? I won’t call out anyone, but I’ll be glad to give the info to @ipstenu so you can check it out?

    • Chad Butler 10:15 pm on March 2, 2015 Permalink | Log in to Reply

      Thanks for the update Mika. I am really glad to see this change implemented as it will improve the usefulness of the rating system.

    • Ajay 12:43 pm on March 6, 2015 Permalink | Log in to Reply

      Mika, this cleanup is definitely a good one. Helped improve ratings on most of my plugins. However, there remains one issue that might be worth considering. Some plugins have very few reviews. Shouldn’t there be a threshold post which you start displaying ratings? e.g. maybe 10 reviews/ratings?

  • Ipstenu (Mika Epstein) 4:47 pm on February 26, 2015 Permalink |
    Tags: ,   

    Getting Support Notifications For Your Plugin 

    When you have a plugin, it’s important that you get notified when people have support questions. We have a way for you to keep up to date on these things and have since the Great Plugin Refresh of 2012. But for those of you who missed the news or need a refresher, here we go.

    All Plugins

    We’ve always had a couple convenience views of plugin-committers and plugin-contributors, and these are still there as well. Committers are managed in on the Admin tab (i.e. people who have access to commit code via SVN), while contributors are taken from readme.txt (which is why it’s important for you to use the proper WPORG forum ID, capitalization and all).

    Example URLS:
    https://wordpress.org/support/view/plugin-committer/Otto42
    https://wordpress.org/support/view/plugin-contributor/Otto42

    Your username is case sensitive. Otto42 will work, otto42 will not. Not sure what yours is? Go to https://wordpress.org/support/profile/ (yes, that works for everyone) and look at the header:

    Example of Otto's profile, his name is capitalized

    The name in the grey header is capitalized, thus he must use a capital_O_dangit.

    Otto fixed this, lowercase works, still, check your login name because I know some of you have weird spaces and stuff

    Since anyone can add you as a plugin contributor, I recommend following plugin-committer.

    The RSS URLs for this look like https://wordpress.org/support/rss/view/plugin-committer/Otto42

    At this time, we don’t have email for this.

    Per Plugin

    Every single plugin allows you to follow it by email. Go to the Support Page for your plugin, scroll down to the bottom, and you’ll see this:

    Example of Email/RSS links

    RSS and email. Done. Even if there are no posts you can register for those emails, so make that a part of your workflow.

     
    • Lester Chan 4:59 pm on February 26, 2015 Permalink | Log in to Reply

      Thanks for this! It is a #TIL for me!

    • Chad Butler 5:16 pm on February 26, 2015 Permalink | Log in to Reply

      Great insight! Thanks for posting it. I was never aware of the “convenience” views before.

    • danieliser 5:36 pm on February 26, 2015 Permalink | Log in to Reply

      The one thing that is missing and I would desperately love to see is a new view for unresolved issues only. Would make sorting through hundreds of tickets much easier.

    • Samuel Wood (Otto) 5:44 pm on February 26, 2015 Permalink | Log in to Reply

      You know, if you would email me before writing these things, then I could go in and fix the bugs in them before you finish writing them. 😉

      I’ve just made two important corrections to this code:

      1. It no longer uses your login name. It uses your URL slug (aka “nicename” for those who know what that means). This would be the same as in the URL of your profiles page.

      So, my profiles page is https://profiles.wordpress.org/otto42 . This means that my feed would be https://wordpress.org/support/view/plugin-committer/otto42 .

      2. Because of this, the case-sensitivity is now gone. Or rather, it will redirect you to the lowercase URL instead. No more case-sensitive BS for us, not when we can avoid it.

      The associated RSS feed should also no longer be case sensitive.

    • Paul de Wouters 8:20 am on February 27, 2015 Permalink | Log in to Reply

      We have the RSS feed trigger a Slack notification with Zapier or IFTTT, which is handy.

  • Ipstenu (Mika Epstein) 9:14 pm on January 23, 2015 Permalink |
    Tags: ,   

    It's Not You – The repo cache is very sticky right now 

    FYI: This should be resolved now

    So you made an update recently and it’s stuck on the old version, but the downloads are right for your new release?

    We know.

    It will update, eventually. We’ve made some recent changes to everything and updates are running a little slower to sync and flush the cache. We’re aware of the delays and kicking the gerbils running the servers to make it faster.

    You should refrain from making multiple updates to ‘fix’ it right now, though. It won’t help.

     
  • Ipstenu (Mika Epstein) 9:47 pm on November 3, 2014 Permalink
    Tags: community summit, status,   

    Post Summit Status 

    The number one question asked at the summit of me was “Can I join the plugin review team?” I told everyone “Follow make/plugins and I’ll post there by [last] Friday.”

    Sorry about the delay, we had coordination issues which ironically is why the current answer is “No, we’re not adding anyone new to the review team.”

    State of Things

    The way the review of new submissions is sorted right now, it’s a single-thread system. There is a single queue that contains all submitted plugins, and it can only be viewed by one person at a time – or we run the risk for two people reviewing a plugin at once, which can end with one rejecting and one approving simultaneously. In order to avoid this, we are constantly asking each other which of us is currently in the queue. Even then, the system is archaic and has issues. So yes, it’s entirely a technical limitation and it’s one we ARE actively addressing. We’ve all talked (in one-offs) about what we want and need, and we have it spelled out. A lot of this is because we were intentionally waiting for the inevitable bbPress 2.x upgrade, but since that’s not happening any time soon, we’re going to have to make an interim plan.

    What We Do

    But there IS a future where we will want more people to help out in various roles and it’s with that in mind I want to talk to you all about what we actually do.

    Review New Submissions

    This means we download a submission, check it for any violations against the guidelines, test it on a sandbox of our own, and make sure there isn’t anything egregiously wrong. We also have to check for licensing and trademarks, which leads to fun things like the time I rejected the Official Facebook plugin because they used a gmail email address and a dropbox URL for the zip.

    Right now, the check is 100% manual. We’re developing a Plugin Checker (like the Theme Checker) but it’s much harder since themes are pretty standard when you compare them to how crazy plugins get. We have, finally, boiled down to what we know we can auto-reject and what we need to warn/inform people about, so we’re making progress on that end.

    One thing we don’t do is put our own feelings into a plugin review. If the code is good and there’s nothing ‘morally offensive’ about it, it comes in. That’s why we have a bajillion twitter plugins. Determining what is and is not offensive is hard, though. We don’t allow things we determine to be black-hat SEO (“This plugin will improve your SEO by 1000%!”) and we don’t allow things we feel would be detrimental to the community, but we do allow things we know will offend some people. It’s a fine line.

    Handle Guideline Violations

    Every single email you send to plugins AT wordpress.org saying ‘So and So’s plugin puts in powered by links!’ has to be verified. Usually this is easy, but once you report one user, we check all of their plugins. This can take a while and it gets worse when we get a submission like “Joe’s twitter plugin emails him when installed!” Sounds easy, right? Go on and figure out how many twitter plugins that might actually refer to. I reply to those a lot and ask “WHICH plugin? Please link to the repository page.”

    What we really need is simple.

    1) A link to the plugin page (ex: wordpress.org/plugins/evil-twitter/
    2) A clear explanation as to what’s wrong (ex: The widget puts in a link for non logged in users)
    3) Optional: A link to where the evil code is (ex: https://plugins.trac.wordpress.org/browser/evil-twitter/trunk/index.php#L2 )

    With that it speeds up everything.

    Handle Security Reports

    Everything we do in the guideline violations has to be done here, but worse, we have to reproduce the bug and give suggestions/information about possibly fixing it. Why? Because not everyone actually understands why they have to sanitize, or why their plugin which we approved 4 years ago, calling wp-load.php directly, needs to remove that now. The guidelines and standards change over time, and while we don’t expect people to keep up with them 100%, when they do change, it’s a waste of time to argue with us that they changed… Which bring us to the number one thing we actually do.

    Be patient with angry people

    If you’re not good at handling support tickets or forum posts, I have news for you. You will not survive the plugin team. Getting sent the dread “Your plugin has been removed…” email is possibly the worst day for a plugin developer. It’s earned us a lot of anger from the community, from people who feel we single them out or that we specifically hate them. We don’t.

    Just because you’re the most awesome person when it comes to reverse engineering security issues and solving them doesn’t mean you’re great at explaining to people why they can’t phone home or why something that was okay 4 years ago isn’t now, or even teaching them how to fix an issue even if it’s not actually our responsibility. And yes, people absolutely lose their minds to the plugin team fairly regularly. Buy me a coffee, I’ll tell you about the guy who tried to impersonate me by sending emails ‘from me’ telling other devs their plugins were removed, because I’d closed his.

    The point here is that we really need people who either are great communicators from day one, or who are comfortable asking for help when they know someone’s gone off the rails and can’t be reasoned with by them. If you’re this guy, you’re not ready:

    Duty Calls

    So … now what?

    Well now we just want this post to get you all on the page we are. And we want you to understand that until we fix the technical issues, we can’t actually address the training people up to help out. I promise you, I’m just as riled up about not having more people on the team as you are, because right now if two of us go away for a week, we have a massive queue which is just depressing. Trust me, we’re all in agreement here. But since they won’t let me reboot the plugins directory, we’re going to have to take this seriously and careful, and I beg of you to be patient.

    And that’s what we need most of all. Be patient. Stick around here. Be understanding. Don’t nag. Seriously, that never helps. We know who’s interested, and maybe we’ll come up with some quizzes and tests to see ‘Would you approve this plugin?’ and sort folks out even more. But it’s not today, and it’s not because we don’t want more people. It’s because more people would break a broken system worse.

    And that is your state of the plugin review team at this moment.

     
    • Alberto Hornero 10:03 pm on November 3, 2014 Permalink

      Thank you very much for your complete explanation.

      I agree to this procedure, and please tell me if I can help you. I want to help.

      Alberto.

    • Slava UA 10:09 pm on November 3, 2014 Permalink

      Several questions:
      1) what about using tags to gain more downloads? Like BuddyPress tag – https://wordpress.org/plugins/tags/buddypress – lots of plugins include it but give 0 functionality around BuddyPress
      2) Sometimes approved plugins just don’t work, as they use for example php short tags like <? instead of <?php.
      Codex article: https://make.wordpress.org/core/handbook/coding-standards/php/#no-shorthand-php-tags
      Guilty plugin: https://wordpress.org/support/topic/errors-everywhere-4?replies=6
      How such plugins come into the repository (reviewer overlook?) and will that be checked in future somehow?

      • Ipstenu (Mika Epstein) 10:33 pm on November 3, 2014 Permalink

        Because not everyone actually understands why a plugin which we approved 4 years ago, calling wp-load.php directly, needs to remove that now.

        The guidelines have evolved over time. We change and fix and evolve and we do not usually go back. So if no one takes the time to email plugins AT wordpress.org and tell us, we probably don’t know. Now that I do, I’ll go handle that one.

        We’re also not being overly naggy about tags at the moment, though that may change.

    • Arnan de Gans 11:03 pm on November 3, 2014 Permalink

      A plugin of mine has a php file that may be loaded directly via an AJAX request. It loads wp-load.php to get to $wpdb and some other stuff. I noticed you mentioned that’s not ok anymore? What’s the alternative, I can’t seem to find a conclusive answer.

      • Ipstenu (Mika Epstein) 11:30 pm on November 3, 2014 Permalink

        The official reply:

        ## Calling core loading files directly

        Including wp-config.php, wp-blog-header.php, wp-load.php, or pretty much any other WordPress core file that you have to call directly via an include is not a good idea and we cannot approve a plugin that does so unless it has a very good reason to load the file(s). It is prone to failure since not all WordPress installs have the exact same file structure.

        Usually plugins will include wp-config.php or wp-load.php in order to gain access to core WordPress functions, but there are much better ways to do this. It’s best if you tie your processing functions (the ones that need but don’t have access to core functions) into an action hook, such as “init” or “admin_init”.

        Please consult the Plugins API reference for more information: https://codex.wordpress.org/Plugin_API

        If you’re trying to use AJAX, please read this: https://codex.wordpress.org/AJAX_in_Plugins

        For other possibilities, or to better understand why we disallow this, read this: http://ottopress.com/2010/dont-include-wp-load-please/

        If you’re trying to use it because you need to access WordPress functions outside of WordPress, we’d actually much rather you didn’t do that at all. Your plugin should be inside WordPress, only accessible to people who are logged in and authorized, if it needs that kind of access. Your plugin’s pages should be called via the dashboard like all the other settings panels, and in that way, they’ll always have access to WordPress functions.

    • webaware 1:36 am on November 4, 2014 Permalink

      Love your work (all of you); keep the faith!

      Sounds like maybe you’re fighting with the wrong tools. I’d imagine something like HelpScout would be beneficial here — a queue of issues, reviewers who can self-assign as they pick one off the queue, canned responses, notes, reassignment / unassignment. Even hooks for magic like auto-scanning zip files perhaps. I say HelpScout but basically anything similar. Surely better than bbpress.

      Such things cost something, but what price your own time? Who pays might be an issue, I don’t know, but I’m sure sponsorship wouldn’t be hard to find. Even “reviewer pays” where the reviewers stump up the $15/month for the privilege of putting WordPress Plugin Review Team (if you see me running, try to keep up) on their T-shirts.

      cheers,
      Ross

      • Ipstenu (Mika Epstein) 1:53 am on November 4, 2014 Permalink

        The real issue we’re facing is integration with the system, otherwise we’re right back to the same issue. Multiple people in the queue at once == disaster. Until we fix THAT, everything else is theory. We already have notes, canned replies, and actually a queue. We just have it single-threaded. We need to fix it :)

        Also we will never ever EVER ever ever consider ‘paying’ for reviews. If you see me tweet about how I’ll review faster for Smarties or Kinder Eggs, that’s just me being a goof. No. No monetization of this. EVER. That’s just the antithesis of the repositories.

        • webaware 6:04 am on November 4, 2014 Permalink

          OK, cool. Sounds like maybe you just need assignment / ownership to take something from the queue so others know to get the next available victim.

          To be clear, I wasn’t implying payment for plugin reviews, just sponsorship for a non-free system (like HelpScout). But let me know about the Smarties, OK? :)

          cheers,
          Ross

          • Ipstenu (Mika Epstein) 2:32 pm on November 4, 2014 Permalink

            Sponsorship for anything review related starts coming across like bribery to a lot of people, even with the best intentions. “I give money/time, I should get precedence in reviews!” We don’t even review our own new plugins first!

            But yes, the ownership/assignment ability is what we’re working on.

    • Hugh Lashbrooke 4:16 am on November 4, 2014 Permalink

      Thanks for the really thorough explanation. I’ve nagged Pippin a few times about joining the plugin review team, but now that I know all this I’ll stop nagging and wait patiently :) I’m really keen to help out, so looking forward to when it becomes possible.

    • Daniel Dvorkin (MZAWeb) 12:59 pm on November 4, 2014 Permalink

      Am I the only one that went to wordpress.org/plugins/evil-twitter/ expecting to find something there? 😛

  • Ipstenu (Mika Epstein) 10:31 pm on August 21, 2014 Permalink |  

    Plugin Icons 

    In December 2011, we added header images to the top of plugin screens. In 2012 we made even more changes to the plugin directory and started supporting HiDPI images for those plugin headers as well. Then we let you put screenshots in the assets folder too.

    Continuing that grand tradition of making your plugins prettier, we’re tossing a new one into the mix. Plugin Icons.

    Plugin icons are 128 pixels square. HiDPI (retina) icons are supported at 256 pixels square. Like banners, these go into your /assets directory and can be either a PNG or JPG. So just create assets/icon-128x128.(png|jpg) and/or assets/icon-256x256.(png|jpg) and you have an icon.

    You also have another option: SVG. Vectors are perfect for icons like this, as they can be scaled to any size and the file itself is small. For an SVG file, you simply need an assets/icon.svg file.

    We may implement SVG-to-images fallbacks in core for browsers that don’t support them, so if you go the SVG route, I’d suggest also turning your SVG into a PNG. (SVG takes precedence.)

    Huzzah! Make ’em rock, folks! But don’t worry, there are fallbacks

    Read the announcement post. Enjoy.

     
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