Ready to get started?Download WordPress

Make WordPress Plugins

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

  • Ipstenu (Mika Epstein) 10:31 pm on August 21, 2014 Permalink | Log in to leave a Comment  

    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.

  • Ipstenu (Mika Epstein) 7:24 pm on March 20, 2014 Permalink | Log in to leave a Comment  

    Plugin Screenshots Downloading? 

    Edit: This should no longer be an issue as we’ve modified how our SVN server does mime-types. However, you won’t see it for existing plugins until they update. Eventually this problem will hopefully go away entirely. So, the info in this post should now be out of date. Email me directly if you still have issues. -Otto

    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 | Log in to leave a Comment  

    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


      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


      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.


      • 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


      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:


      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.

  • Ipstenu (Mika Epstein) 8:12 pm on January 20, 2014 Permalink | Log in to leave a Comment  

    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 | Log in to leave a Comment
    Tags: announcement   

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

    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” :D

  • Ipstenu (Mika Epstein) 3:12 pm on September 12, 2013 Permalink | Log in to leave a Comment
    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: http://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?

  • Ipstenu (Mika Epstein) 9:04 pm on June 21, 2013 Permalink | Log in to leave a Comment
    Tags: , swfupload   

    Secure SWFUpload 

    Do you use SWFUpload? Have you been getting a lot of emails from us telling you it’s not secure? We have a solution. Or rather, WordPress has one.


    The WordPress security team has officially forked the long-abandoned SWFUpload project and is strongly encouraging all web developers who use SWFUpload to update.

    We strongly suggest you do not use SWFUpload. But if you must, use this fork.

    Read More at Make/Core

  • Ipstenu (Mika Epstein) 10:18 pm on May 1, 2013 Permalink | Log in to leave a Comment
    Tags: ,   

    Font Awesome is permitted in the Plugin Repository 

    This took longer than we would have liked to say, but there were communication issues on multiple fronts.

    You can use the Font Awesome font files and CSS in your code, per the current Font Awesome License:

    As far as crediting is concerned, we feel attribution is always good. You should always put that in your source code, but your readme is optional. Credit links must be opt-in if they show on the front facing part of your site (this includes the login page), but that’s nothing new.

    So with that said, we’re going through the plugins that had been closed for Font Awesome usage and opening them. If we missed yours, please email us at plugins at wordpress.org, with a link to the plugin (like http://wordpress.org/extend/plugins/font-awesome/ which is open) and we’ll check right away.

  • Ipstenu (Mika Epstein) 6:45 pm on April 22, 2013 Permalink | Log in to leave a Comment  

    Plugins to embed audio/video or use HTML, please read 

    If you have a plugin with the sole purpose of embedding video into WP posts, or one that makes HTML5 work in WP, you need to know that there is HTML5 support for Audio and Video coming in WordPress 3.6, so please test ASAP.

    Read Audio/Video Support in Core

  • Ipstenu (Mika Epstein) 1:51 am on April 11, 2013 Permalink | Log in to leave a Comment
    Tags: , api   

    Google Maps JavaScript v2 API To Be Removed 

    If you’re using the Google Maps JavaScript API v2 (and 78 of you are), your plugins will break on May 19th. This means we’ll not be accepting any plugins that use the old code (and probably will close your plugins that do if you don’t fix ‘em).

    From Google, Google Maps JavaScript v2 (Deprecated)

    The Google Maps JavaScript API Version 2 has been officially deprecated as of May 19, 2010. The V2 API will continue to work until May 19, 2013. We encourage you to migrate your code to version 3 of the Maps JavaScript API.

    The Google Maps API lets you embed Google Maps in your own web pages with JavaScript. The API provides a number of utilities for manipulating maps (just like on the http://maps.google.com web page) and adding content to the map through a variety of services, allowing you to create robust maps applications on your website.

    The Maps API is a free service, available for any web site that is free to consumers. Please see the terms of use for more information.

    To use the Maps API on an intranet or in a non-publicly accessible application, please check out Google Maps API for Business.

    So please update your plugins.

    (Props to Kailey Lampert for this post)

compose new post
next post/next comment
previous post/previous comment
show/hide comments
go to top
go to login
show/hide help
shift + esc