WordPress.org

Make WordPress Plugins

Recent Updates Page 2 Toggle Comment Threads | Keyboard Shortcuts

  • 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.

     
  • Samuel Wood (Otto) 6:57 am on April 7, 2014 Permalink |
    Tags: mysql, mysqli, php, wpdb   

    MySQL in WordPress 3.9 – Implications for Plugin Authors 

    If you’re a plugin developer and you have a plugin using any of the php mysql functions directly, then you might start to see breakage in WordPress 3.9.

    See, the php mysql extension is very old. As of PHP 5.5, it’s also deprecated and will very likely not be receiving further updates.

    So starting in WordPress 3.9, if PHP 5.5 is being used, the built in WPDB class will switch to using the mysqli extension instead.

    What this means for your plugin is that if you’re using any mysql_* functions directly, and somebody tries to use your plugin on a WordPress 3.9 + PHP 5.5 system, then all your database code will no longer work properly. Since the mysql functions are no longer being used in such a case by WordPress, then there is no longer an implicit database connection available to these function calls.

    Instead of using a direct database connection, you can switch to using the global $wpdb instance of the WPDB class to access the database. @pento gives a great rundown on what functions to use as drop-in replacements on this make/core post: https://make.wordpress.org/core/2014/04/07/mysql-in-wordpress-3-9/

    Now, as this is currently limited to PHP 5.5 and up only, the amount of breakage will likely be very minor. Our stats currently show that PHP 5.5 is being used on less than 1% of installations. Nevertheless, hosts are starting to upgrade PHP versions more and more frequently. This number is thus expected to grow over the next year or two. So before your users start having broken sites, please, take the time to switch your plugins over to the WPDB based methods. This will ensure future compatibility and minimal breakage.

    WordPress will always maintain backward compatibility in its own functions, so using them ensures that you’ll be good for the forseeable future, no matter what database methods are being used internally.

     
    • rahul286 7:27 am on April 7, 2014 Permalink | Log in to Reply

      Glad to hear this. mysqli is much better.

      We use PHP 5.5 and mysqli on all sites. I hope WordPress site’s running PHP 5.5 and mysqli will run faster soon. :-)

  • Ipstenu (Mika Epstein) 7:24 pm on March 20, 2014 Permalink |  

    Plugin Screenshots Downloading? 

    It’s not you, it’s SVN. And you.

    The tl;dr is that the MIME Types on your images aren’t correct. Per Otto:

    On Windows, using TortoiseSVN, you can right click the screenshot file, and select the TortoiseSVN->Properties menu. There you will find the svn:mime-type property, probably incorrectly set to “application/octet-stream”. Change that to the proper mime type of “image/png” or “image/jpg” accordingly. Afterwards, commit the change.

    If you prefer command line SVN:

    svn propset svn:mime-type image/png screenshot-1.png
    svn commit
    

    Or similar. If somebody uses a different SVN client, look for “properties” and then the svn:mime-type property.

    Once you do that, upload the changes and go make coffee. The information will sync out, but it may take a little while.

     
  • Ipstenu (Mika Epstein) 10:06 pm on February 6, 2014 Permalink |  

    Clarification on Taking Over Plugins 

    Sometimes people get random emails from strangers about taking over their old plugins, and I wanted to take a moment to explain how that works.

    First of all, the plugin team does not hand out your email. If you’ve been contacted by someone, they got your email or contact information off your website or plugin code.

    When someone comes to us asking about taking over a plugin, we ask if they’ve attempted to contact the original dev first. If they have and gotten no reply (or if they can’t find a way to contact you), we’ll email you about it and give you their email so you can contact them back. It is possible that someone may just email you out of the blue asking about taking over your plugin. However. Under absolutely no circumstances should you feel like you must give up your plugin, even if it’s old and out of date.

    Your plugin is yours. We will only close it if there are security issues or guideline violations, and we will always email you about that (so remember to keep your email up to date in your forum profile!). We also will never just give away your plugin without contacting you first, and getting your approval. The only exception to this is if you’ve totally dropped off the planet, your email bounces, and your website is gone. Then we assume you’re done.

    If someone would rather close a plugin than hand it over, that’s their call and we support it. We would rather have the plugin carry on, of course, but hey, things happen. That’s why some names are ‘blocked’ from the repository, by the way. We’ve closed an older plugin.

    If you want to close your plugin email us at pluginsATwordpress.org and link us to the plugin page. But do consider giving it away too!

     
    • Eric Amundson 10:10 pm on February 6, 2014 Permalink | Log in to Reply

      Mika,

      Is there a list or wiki page where plugin authors can add their plugins to a list of those in need of new ownership?

      If not, would it be helpful to have one for people who don’t want to, or can’t, support their plugins anymore to offer them up to the community for new development and support blood before closing them down?

      • Ipstenu (Mika Epstein) 10:12 pm on February 6, 2014 Permalink | Log in to Reply

        No, and since the Wiki is editable by anyone, it wouldn’t be maintainable and verifiable easily. Generally I suggest people update their readme to say “This is no longer maintained.”

      • Alex Mills (Viper007Bond) 7:37 am on February 7, 2014 Permalink | Log in to Reply

        It’d be cool if there we could just flag our plugins in need of new management.

        EDIT: Mika’s suggestion of editing the readme to say so is probably better as it’s unlikely it’d be useful to have a list of plugins that need new ownership.

      • Cleanshooter 6:31 pm on July 1, 2014 Permalink | Log in to Reply

        This is a great idea as there are some really great plugins out there that have simply fallen into disrepair. They get copied re-coded/updated then re-released as new plugins resulting in multiple version out their doing essentially the same thing (with similar code bases) but for different versions of WordPress.

    • Ben Lobaugh (blobaugh) 10:12 pm on February 6, 2014 Permalink | Log in to Reply

      Thanks Mika! As someone who has been on both sides of this I have to say the plugin team does a great job!

      Eric- I do not think there is one on WordPress.org anywhere, but there are a couple 3rd party sites that have setup systems like that.

    • Chad Butler 10:20 pm on February 6, 2014 Permalink | Log in to Reply

      Thanks Mika! This is great clarification.

      I always assumed that the plugin team approached it the way you described, but it is good to have it said out loud.

    • Andrew Nacin 10:35 pm on February 6, 2014 Permalink | Log in to Reply

      I’d say that it’d be cool if we have a system for putting plugins up for adoption, but I think this would work fine: If a plugin author wanted to put a plugin up for adoption, I’d suggest they create a post in their plugin forum and make it “sticky”. They could also update their readme if they wanted to link to that post. Those interested could then comment.

    • Ajay 12:10 am on February 7, 2014 Permalink | Log in to Reply

      What about cases where the plugin developer has disappeared and is no longer contactable?

    • Stephen Cronin 2:49 am on February 7, 2014 Permalink | Log in to Reply

      Mika,

      What happens when you close a plugin? Does the plugin slug become reserved or can it be reassigned at a later date?

      If it can be re-assigned, then someone could release a plugin reusing a retired slug and anyone out there still using the original plugin would get an update notice (assuming sufficiently high version number). That could potentially be confusing / dangerous.

      I’ve always wondered about that..

      • Ipstenu (Mika Epstein) 4:06 am on February 7, 2014 Permalink | Log in to Reply

        The slug is reserved and remains so unless the owner wants to give it to someone else.

        Example of something that happened once. A plugin was closed for security issues. Dev said “meh, I’m done.” Another dev asked to take it over. Original Dev said “Sure!” We added the new Dev, but the code was required to be patched before we reopened the plugin. Everything worked out better than expected :)

      • Ajay 8:45 pm on February 8, 2014 Permalink | Log in to Reply

        I closed a few plugins since they really couldn’t be used again because the services they were integrating no longer existed. I can still see the URL with a big RED message saying it is closed.

    • Workshopshed 9:58 am on February 7, 2014 Permalink | Log in to Reply

      I had someone contact me regarding taking over a plugin I was no longer interested in maintaining as it needed significant changes to work with an API change.
      However all that seemed to happen was a banner advert was placed on it and no further changes were done.

      https://wordpress.org/plugins/twitter-badge-widget/

      • Ipstenu (Mika Epstein) 4:48 pm on February 7, 2014 Permalink | Log in to Reply

        An … ad? Is not okay. I’ll take a look to see if it’s violating our guidelines. That said, I often ask that people show me what code they want to update BEFORE I give a plugin away. I gave away one that I just don’t care to work on anymore :)

    • FranceImage 2:04 pm on February 8, 2014 Permalink | Log in to Reply

      Hi,

      I think the repository would gain in adopting another paradigm like github.

      As it is, plugins are abandoned because the authors are demotivated; an easy way to accept code from contributors may help them keep their motivation.

      If an author neglects his project, code consumers could see if it has been forked; the forked project would gain momentum if it is more alive.

      My 2 cents

    • Todd Lahman 1:01 pm on February 11, 2014 Permalink | Log in to Reply

      This post from Mike Jolley completely sums up what needs to be done:

      http://mikejolley.com/2013/12/wordpress-org-wishlist/

      I would add to this, the developers need mod permission to delete comments that are off topic. My preference would be to fully integrate with Github, adopting their system entirely. WordPress.org is outdated, and the moderators system reminds me of the IRC back in the mid 1990s when Eggdrop bots ruled the chat rooms.

    • theforgotten35 8:53 am on October 7, 2014 Permalink | Log in to Reply

      Hi Mika,
      I have installed the post notification plugin and deployed upon a 5.5 mysql database.
      There is a mysql evolution that makes the plugin installation obsolete (due to a timestamp field).
      The plugin is no longer maintained and I wondered if anyone took over its development ?
      I also wondered how the development is handled i.e. how could I update the repository (SVN) … ?
      Regards
      Loïc

  • Ipstenu (Mika Epstein) 8:12 pm on January 20, 2014 Permalink |  

    TinyMCE 4.0 

    In case you missed the announcement over on Make/Core, we’re moving to TinyMCE 4.0

    I shall quote:

    This is a major upgrade for the WordPress editor. There are many changes in 4.0:

    • New UI and UI API.
    • New theme.
    • Revamped events system/API.
    • Better code quality, readability and build process.
    • Lots of (inline) documentation.
    • And generally many improvements everywhere.

    All default TinyMCE plugins have been upgraded. The WordPress implementation custom plugins  were upgraded too. Looking in the plugin repository, there are a lot of WordPress plugins  that add a TinyMCE plugin. Because of all the API changes, most of these plugins would need an update too. If you are the author of such plugin, please test it in trunk now.

    Generally there are three groups of TinyMCE plugins added by WordPress plugins:

    • Custom plugin created specifically for the WordPress plugin. If you’ve developed this kind of plugin, please see the 3.x to 4.0 migration guide and the 4.0 API documentation.
    • WordPress plugins that add third-party or default TinyMCE plugins would (of course) need to be updated to include the 4.0 version of the plugin. The PHP global $tinymce_version can be used to determine which plugin to load.
    • Mini-plugins that only add a button to the toolbar. This works pretty much the same. It is advisable to update to use the ‘dashicons’ icon font instead of image icon.

    TinyMCE 4.0 includes a ‘compat3x’ plugin that should prevent all fatal errors caused by old plugins and adds compatibility for most of the 3.x API methods. If there are any editor related Javascript errors while running trunk, please open a trac ticket quoting the first error from the browser console.

    So please read, test, and update your plugins as needed.

     
  • Ipstenu (Mika Epstein) 2:14 am on December 22, 2013 Permalink |
    Tags:   

    Notice: SVN will reject PHP with errors 

    When you commit PHP files, the repository will no longer let you commit them if they have PHP syntax errors. Such an error would make the plugin fail when it tried to load the file anyway, so think of this as a ‘for your own protection’ kind of thing.

    So if you get a kick-back error like this:


    Error: Commit failed (details follow):
    Error: Commit blocked by pre-commit hook (exit code 1) with output:
    Error: PHP Parse error: syntax error, unexpected end of file in - on line 1234
    Error:
    Error: ***********************************
    Error: PHP error in: really-cool/tags/1.0/really-cool.php:
    Error: Errors parsing really-cool/tags/1.0/really-cool.php
    Error: ***********************************
    Error: This error was generated by a custom hook script on the Subversion server.
    Error: Please contact your server administrator for help with resolving this issue.
    Completed!:

    you need to fix the syntax errors in the file before uploading.

     
    • J.D. Grimes 2:09 pm on December 22, 2013 Permalink | Log in to Reply

      That’s great! I’ve seen this happen occasionally, and its no fun for the developer or the plugin users.

    • Andrew Nacin 8:18 pm on December 22, 2013 Permalink | Log in to Reply

      Please note: This currently does a PHP 5.4 syntax check. Please be careful if you are using 5.3 or 5.4-specific language features, like namespaces, closures, short array or ternary syntaxes, etc. These will break sites running PHP 5.2 (which is a majority of sites).

      This has actually been enabled for many months.

      • Rafael Ehlers 10:36 am on December 23, 2013 Permalink | Log in to Reply

        Hi @nacin can you elaborate on “ternary syntaxes” that you’ve mentioned ?!

        • Samuel Wood (Otto) 2:47 pm on December 23, 2013 Permalink | Log in to Reply

          A ternary operator in PHP looks like this:

          ( expression1 ) ? expression2 : expression3

          If the expression1 evaluates to true, then the result is expression2. If not, then the result is expression3. A simple example:

          $variable = ( $a > $b ) ? ‘A is greater than B’ : ‘A is not greater than B’;

          Obviously the expressions can be more complex than this.

          Now, as of PHP 5.3, there is a shorthand ternary operation that works like this:

          ( expression1 ) ?: expression3

          This basically evaluates expression1, and if it’s equivalent to true, then the value of expression1 is returned. If not, then expression3 is returned. This is useful in either/or cases.

          Say you have a function returns a string or false. You want to replace the false case with some other string, like “fake”. This will do it:

          $var = ( getString() ) ?: ‘fake’;

          However, the ?: shorthand is PHP 5.3 only. In 5.2 it will cause a syntax error. You could do the same thing in 5.2 code without the shorthand:

          $var = ( getString() ) ? getString() : ‘fake’;

          Or if you needed to not call getString twice, by using a separate call:

          $var = getString();
          $var = ( $var ) ? $var : ‘fake’;

          If you’re using 5.3-only code of any sort, make sure that your plugin checks for 5.2 cases (still more than half of all installs) and fails gracefully. Or just write 5.2 compliant syntax. There’s nothing in 5.3 and up that’s actually required for most cases.

      • Barry 4:27 am on December 27, 2013 Permalink | Log in to Reply

        This has actually been enabled for many months.

        It was actually broken (disabled) until ~11 days ago

    • elitetreecare 4:13 pm on January 1, 2014 Permalink | Log in to Reply

      Thanks for the info Samuel

    • Zane Matthew 3:09 pm on September 8, 2014 Permalink | Log in to Reply

      Would love to see this also support “warnings” and “notices” 😀

  • Jon Cave 12:56 pm on November 24, 2013 Permalink |
    Tags:   

    How to fix the intentionally vulnerable plugin 

    If you have not reviewed the intentionally vulnerable plugin, then I suggest you do so before reading on.

    The intentionally vulnerable plugin demonstrates a range of security vulnerabilities that are commonly seen in WordPress plugins. In this post I aim to go through each vulnerability giving a little background on why it is dangerous and how it should be fixed.

    SQL injection

    This is a rather famous vulnerability that can be exploited by an attacker to modify database queries. This can allow the attacker to read sensitive information from the database, modify data stored in the database, and possibly even execute commands on database server, among other things. The basic idea is that if untrusted user input is included directly in a query then maliciously formatted input can be used to alter the query’s syntax.

    The first SQL injection vulnerability is caused by the incorrect usage of the wpdb::prepare() method on line 42:

    $wpdb->query( $wpdb->prepare( "INSERT INTO login_audit (login, pass, ip, time) VALUES ('$login', '$pass', '$ip', '$time')" ) );
    

    When using the prepare() method placeholders, such as %s and %d, should be used in the query string which is the first argument of the method — the method is not magic, it cannot parse the query to determine what was user input! The variables are then passed in as separate arguments so that they can be escaped properly before being included in the query. This rather common error has been made more obvious since the release of WordPress 3.5 which required more than one argument to be passed to the method.

    The correct usage, and the fix, is:

    $wpdb->query( $wpdb->prepare( "INSERT INTO login_audit (login, pass, ip, time) VALUES (%s, %s, %s, %s)", $login, $pass, $ip, $time ) );
    

    The other two SQL injection vulnerabilities, on lines 102 and 127, are caused by incorrectly escaping user input that is not used in a quoted context of an SQL query. The esc_sql() function can only be safely used to escape input that will be used within quotes. However, the two queries are using input as a numeric argument that is not enclosed within quotes:

    $log = $wpdb->get_row( "SELECT * FROM login_audit WHERE ID = " . esc_sql( $id ), ARRAY_A );
    // ... and ...
    $wpdb->query( "DELETE FROM login_audit WHERE ID = " . esc_sql( $_POST['id'] ) );
    

    To fix this you should use the prepare() method with a %d placeholder:

    $log = $wpdb->get_row( $wpdb->prepare( "SELECT * FROM login_audit WHERE ID = %d", $id ), ARRAY_A );
    // ... and ...
    $wpdb->query( $wpdb->prepare( "DELETE FROM login_audit WHERE ID = %d", $_POST['id'] ) );
    

    It is also possible to sanitize numeric input by casting to int or using the absint() method.

    Cross-site scripting

    Cross-site scripting (XSS) is one of the most prevalent security vulnerabilities in web applications. XSS is also commonly found in WordPress plugins, so it features heavily in the intentionally vulnerable plugin. XSS is often classed as either “persistent” or “reflected”. An XSS vulnerability is persistent if the unsafe user input is stored in the database, and then output to other users in future requests. It is known as reflected if the unsafe user input is output immediately in response to a request containing the dangerous input. To exploit a reflected XSS vulnerability the attacker would have to convince a victim to click on their specially crafted link that triggers a malicious script. However, a persistent XSS vulnerability will allow the attacker to input their malicious script themselves and then wait for unsuspecting users to visit or click on benign looking links.

    There are two instances of persistent XSS in the intentionally vulnerable plugin, in dvp_view_all_logs() and dvp_view_log(). Both of these functions output data straight from the database without escaping it. All of this data originated from the user in dvp_log_failed_login(). For example, an attacker could purposefully fail a login attempt using a password of <script>alert(1)</script>. The fix for this would be to use an appropriate escaping function, such as esc_html() or esc_attr() when outputting data from the database. Data can also be sanitized when being stored in the database using KSES, or strip_tags() when no HTML is expected, in addition to escaping on output.

    There are also multiple examples of reflected XSS. On lines 104 and 115, the $id variable, which was originally $_GET['id'], is output without any escaping. Line 104 should be fixed with esc_html(), and line 115 should be fixed with esc_attr(). Another problem is the use of $_SERVER['PHP_SELF'] on line 116 to get the current URL. This is an extremely common problem that allows XSS since an attacker can control its value and include malicious HTML that will break out of the attribute and execute a script. This should be fixed by using a WordPress function, such as menu_page_url(), to get the correct URL.

    Cross-site request forgery

    Another extremely common vulnerability in web applications is the failure to prevent cross-site request forgeries (CSRF). This type of attack exploits a request handler that checks authorisation, but not intention. A malicious website is able to send a request to another site that the user is authenticated to. The vulnerable target site will accept this request since it is sent with valid authentication cookies. However, the user did not intend for the action to be performed. WordPress plugins can defend against this type of attack by using nonces. These are action dependent random strings that cannot be predicted by an attacker, but can be verified by WordPress. So, if a request does not include a valid nonce then it is rejected.

    The intentionally vulnerable plugin looks as if it makes use of nonces to defend against CSRF, but the author has made a couple of mistakes that leave it exploitable. Firstly, the use of nonce generation and verification functions without passing the $action parameter is insecure. Lines 114 and 123 should be edited to add the use of an action. Note that this mistake would be caught when developing with WP_DEBUG enabled as this use of check_admin_referer() raises a notice.

    The second mistake is more subtle. On line 137 the following check is made:

    if (isset($_REQUEST['nonce']) && ! wp_verify_nonce($_REQUEST['nonce'], 'dvp_settings'))
        // ... failed nonce check
    

    The problem with this check is that it requires the nonce request parameter to be set to ever evaluate to true. This means that an attacker can simply omit this parameter to bypass the nonce verification. This type of logic error means that it is highly recommended that you use check_admin_referer() instead of wp_verify_nonce() directly.

    Missing capabilities checks

    The lack of capabilities checks in the log deletion handler allows for a privilege escalation attack. Any logged in user is able to delete rows from the login_audit table since there are no privilege checks. Note that unauthenticated users cannot exploit this because the handler is not hooked into a _nopriv admin-post.php action. However, this is still a serious security failure. So, always remember to use the appropriate current_user_can() capabilities checks on your admin pages and privileged request handlers.

    Failure to exit after a redirect

    When a script redirects the user to another page execution will actually continue on the server side until it exits. This means that it is almost always desirable to make a call to exit or die() when making a redirect. The failure to do this on line 140 means that the capabilities check and CSRF defence (even if it didn’t have a logic error) are rendered useless as a forged request or request made by a low privilege user will actually cause the settings to be updated even though the conditional triggered a redirect. (Note that using check_admin_referer() would have also nullified the problem for a forged request since it calls die() on failure.) The other locations where redirects are used are not vulnerable in the same way because they are called at the end of script execution, but it would be good practice to add exits there as well.

    This vulnerability is exacerbated by the fact that the plugin has a ridiculous update loop that would allow a successful attacker to update any option in the database. Instead a plugin should know which options it is in charge of and only modify those whitelisted options.

    Open redirect

    On a redirect related note, there is an open redirect vulnerability in the deletion handler on line 130. In this plugin the intention is to return the user to the list of failed login attempts, so wp_safe_redirect() should have been used instead of plain old wp_redirect(). However, in this situation it would be even better to redirect to a hardcoded URL using menu_page_url() or admin_url() and then remove the ability to specify the redirect through the request parameters.

    IP forgery

    The dvp_get_ip() function can be tricked into logging an incorrect IP address since the X-Forwarded-For header is user controllable. This is bad news for a variety of reasons. For security logging purposes it degrades the utility of the audit trail as an attacker pretends to be coming from a legitimate address. If it were used for securing access then it is trivially by-passable. In the case of this plugin this can also lead to SQL injection and persistent XSS.

    Conclusion

    There are many things that plugin authors can do wrong! The number one rule to remember is that the user is not to be trusted. Always validate and escape anything that could be controlled by a user.

    I hope that participants found this to be a useful exercise and that this review post has helped your understanding of plugin security.

     
    • Jon Cave 12:57 pm on November 24, 2013 Permalink | Log in to Reply

      I’m sorry that this took so long to be published. It has been sitting as a draft for many months because I forgot I hadn’t pushed the button!

    • Brian Hogg 1:13 pm on November 24, 2013 Permalink | Log in to Reply

      No worries, thanks for posting and for creating the original exercise!

    • Andrey "Rarst" Savchenko 3:22 pm on November 24, 2013 Permalink | Log in to Reply

      Why not dedicated methods for INSERT and DELETE queries?

      Will you be replying to fixes submitted? I vaguely remember considerably butchering it, so I am curious if I got the issues *and* hadn’t created any new horrible holes in my solution. :)

    • Gregory Karpinsky 3:48 pm on November 26, 2013 Permalink | Log in to Reply

      Those who come to WordPress from plain (or semi-plain) PHP, probably know well the escaping, etc.
      But for the “WP-born” developers this article is a gem!
      Thank you!

    • lorax 6:57 pm on November 27, 2013 Permalink | Log in to Reply

      Very helpful for me as I write plugins for our own use.. Thanks.

    • muddg 5:26 am on April 17, 2014 Permalink | Log in to Reply

      I am so thrilled to find this very useful information. I’ve been grappling with a security issue and have been trying to find this type of information so that I can check plugins that we’ve come to rely on. Even plugins we’ve paid for seem to be a problem. Thank you for this great resource!

    • Ploufside 2:33 pm on May 14, 2014 Permalink | Log in to Reply

      Now the question is : how to detect an intentionally vulnerable plugin 😀 Is there another way that checking plugin author trust ? Very useful anyway thanks a lot dude !

  • Ipstenu (Mika Epstein) 3:12 pm on September 12, 2013 Permalink |
    Tags: 3.6.1, ajax, error   

    The Order of Things 

    Since WP 3.6.1, you may get odd errors like “Call to undefined function wp_validate_redirect()” errors in WP Admin where AJAX is used. The error is due to plugins that call wp_get_referer() on init.

    While this will be patched more in 3.6.2, today’s quick lesson in ‘Making your plugins better’ is this simple note:

    Doing anything before plugins_loaded or init is a bad idea.

    If you find an affected plugin, please feel free to report it here: https://core.trac.wordpress.org/ticket/25294

     
    • takien 3:24 pm on September 12, 2013 Permalink | Log in to Reply

      Thanks for this info bro

    • Mike Schinkel 4:10 pm on September 12, 2013 Permalink | Log in to Reply

      In general @nacin‘s advice that the only thing a plugin should be doing on inclusion is add_action() and add_filter() is extremely good advice, but I’m concerned it might be taken too literally.

      There are other things that can and should be done when loading files and I’d hate for people who review code for best practices for corporations but who are not really experienced with WordPress to add that literally to the list of required best practices without including some caveats.

      Here are some caveats I would add to @nacin‘s advice as being okay to do on plugin inclusion:

      • Capturing __FILE__ or __DIR__ into a static variable of a class for later use.
      • Calling spl_autoload_register().
      • Pre-parsing of environment variables such as $_SERVER['REQUEST_URI'] into static variables of classes.
      • Defining architectural relationships between classes in a plugin that are beyond what PHP provides at the language level, i.e. defining one class as a mixin to another and storing that information in static variables of a class.
      • Possibly other things that are pure PHP/environment and/or that do not have an dependencies on the functions or classes in WordPress, depending on use-case, of course.
    • Andrey "Rarst" Savchenko 6:54 pm on September 12, 2013 Permalink | Log in to Reply

      > The error is due to plugins that call wp_get_referer() on init.

      You probably meant on load rather than init?

    • Knut Sparhell 5:05 pm on September 14, 2013 Permalink | Log in to Reply

      Maybe more precise: Calling any WordPress functions, except add_action() and add_filter(), on plugin inclusion is a bad idea.

      • brasofilo 5:08 am on October 17, 2013 Permalink | Log in to Reply

        Knut, just to clarify my ignorance, what do you guys refer as “plugin inclusion”? I suppose it’s an activated plugin start up…. Normally, if it’s the case, I call

        
        if( is_admin() )
            add_action( 'plugins_loaded', 'start_everything' );
        

        I also suppose is_admin() is not a bad idea, is it?

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