Make WordPress Plugins

Recent Updates Page 2 Toggle Comment Threads | Keyboard Shortcuts

  • Samuel Sidler 10:56 pm on September 1, 2015 Permalink |
    Tags: translations   

    Plugin Translations on WordPress.org 

    Howdy plugin authors!

    In case you haven’t heard, WordPress.org will be expanding the services we provide to you, offering language packs to all plugins. This post is to outline exactly what the plan is and when your plugin will take part.

    For a bit of background, see this post on make/meta and this one on make/themes.

    Over the past few months, the meta team has been working behind the scenes to enable language packs for themes and plugins, just like the ones core has. Language packs on WordPress.org are powered by translate.wordpress.org and the polyglots team, who translate WordPress.

    As of today, all themes have been imported into translate.wordpress.org and can take advantage of language packs (see also). We chose to import themes first to work out any weirdness with translate.wordpress.org, which has never seen this many projects. There were a few bumps along the way, but language packs are now flowing for themes and we’ve added a number of improvements to translate.wordpress.org to make it the process easier for translators.

    Now, it’s time to do the same for plugins.

    The gist of plugin translations are as follows (see the FAQ below for more information):

    1. Eventually, all active plugins will be imported into translate.wordpress.org and made available for translation. However, we will import them in phases.
    2. Upon import, if you have any translations, we will import them into translate.wordpress.org. This only happens during initial import.
    3. Before importing your plugin, we will email you when your plugin is in the next “batch” of imports. You should ensure that all translations are up-to-date.
    4. If you do not wish to use language packs, you may continue to ship translations with your plugin.

    I am sure there are some questions. Let me try and address them:

    Why do I want WordPress.org managing translations for my plugin?

    WordPress.org provides translations in dozens of languages and is ever expanding as new contributors join. (There are currently 140 locales on translate.wordpress.org, but not all are active.) While you may have translated your plugin into a few languages (or none at all), there are likely more translators on WordPress.org in more languages.

    But that’s not all! Plugins in the WordPress.org directory will be able to take advantage of language packs! That means smaller download sizes for users, because plugins will no longer need to ship translations. Eventually, we also plan to give priority to localized plugins in localized directories; e.g., someone searching the Romanian plugin directory will see Romanian plugins prioritized over English-only plugins.

    A great example of what your plugin will look like in a translated directory is Akismet.

    When will you import my plugin into translate.wordpress.org?

    We will import plugins in order, by the number of active installs they have, starting with the most active installs and working down to the least active installs. You will be emailed when your plugin is in the next batch of imports. Be sure to keep translations up-to-date.

    Will you import my plugin ahead of time?

    We’re importing in stages to monitor our systems and ensure the entire site does not break. We will not import your plugin out of order.

    How do you define “active” plugins?

    Plugins are considered “active” if they have been updated in the last two years. This is the same standard that the plugin directory uses when showing plugins in the search results.

    My plugin doesn’t have any strings to translate. Does this apply to me?

    Yes! Translators have the ability to translate your plugin’s readme.txt file and even its name.

    What if my plugin already ships translations?

    Translations that are already shipped in plugins will be initially imported into translate.wordpress.org. Again: we’ll import the strings and the translations on the initial import. We won’t continue to do that because the end goal would be for plugin authors to remove the translations from their download, allowing language packs to fill the void.

    What if I don’t want language packs?

    As mentioned, you can opt out of language packs and plugin translations on WordPress.org, by shipping translations in your plugin, just as you do now.

    I currently ship translations with my plugin. How do I enable language packs?

    WordPress ships with a mechanism that gives priority to shipped translations over language packs. If you wish to take advantage of language packs, you must remove the languages from your plugin zip.

    How do I add support for translations and language packs?

    @Otto42 wrote up a great post on the topic back in 2013. (Wow, it’s been a long time!) There’s also a great page in the plugin developer handbook which walks through how to internationalize your plugin.

    Keep in mind, your plugin’s textdomain must match its slug and, as mentioned above, to fully support language packs, you’ll want to remove translations from your plugin after the import, when language packs are going out (language packs go out as soon as a translation is at 100%).

    What if I want my translators to approve translations on WordPress.org?

    Many plugins already have their own translators and will want to bring them over to translate.wordpress.org. We’ve written up a plan for working with the polyglots team to enable this. There will be some initial pain in adding new, project-specific (aka plugin-specific) translation editors, but afterwards, your translators will join a growing group of WordPress translators and help make the entire ecosystem better.

    If you have any other questions, you’re probably not the only one, so leave them in the comments below.


    • Matthew 11:12 pm on September 1, 2015 Permalink | Log in to Reply

      Awesome @samuelsidler! That’s for the helpful information.

    • Ronald Huereca 11:43 pm on September 1, 2015 Permalink | Log in to Reply

      Hiya, will plugin authors still meed to maintain/update their own pot files, or is this soon to be a thing of the past?

    • Blue Liquid Designs 12:18 am on September 2, 2015 Permalink | Log in to Reply

      What if your textdomain doesn’t match your slug? Are there any options other than change your textdomain (our plugin had a name change but uses the old slug)?

    • Matthew 12:53 am on September 2, 2015 Permalink | Log in to Reply

      How long is the entire process expected to take?

      • Samuel Wood (Otto) 2:30 am on September 2, 2015 Permalink | Log in to Reply

        Maybe 20 or 30 years. Oh wait, you wanted an actual answer? :)

        It took a couple months for the themes, but there are like 35 times as many plugins. It’s almost certain we’ll find issues in the process and pause it to deal with them. So, many months is quite likely. No way to give an estimate because we will fix issues as we find them.

    • Alex Mills (Viper007Bond) 12:58 am on September 2, 2015 Permalink | Log in to Reply

      Can’t wait to not have to deal with accepting translations from people and updating my plugins to include them. Great, great news!

    • Maeve Lander 2:09 am on September 2, 2015 Permalink | Log in to Reply

      Wow, great news!

    • Ryan Hellyer 7:25 am on September 2, 2015 Permalink | Log in to Reply

      A huge thank you to those involved in setting this up. This will save us all a LOT of work in the long run, and hopefully result in a lot more translated plugins because of it.

      Pro-tip for those who have never translated a plugin before: Make sure you use as few strings as possible. The more strings you use, the more work it is for the translators.

      • buzztone 8:10 am on September 2, 2015 Permalink | Log in to Reply

        Do have any tips on how to minimize the number of strings? Any documentation, links, videos etc. would be greatly appreciated.

    • NateWr 7:40 am on September 2, 2015 Permalink | Log in to Reply

      I’m really excited about this. Can I ask for some further clarification about maintaining backwards compatibility? As a plugin author, am I safe to just remove the translations from my plugin (once I get added into the language packs program)? What about all the people who have already implemented their own translations? Will it be clear to them how to find an updated .pot to work from?

    • Slava UA 7:52 am on September 2, 2015 Permalink | Log in to Reply

    • buzztone 8:18 am on September 2, 2015 Permalink | Log in to Reply

      Thanks so much for this. I really hope & believe this will make a big difference in helping non-native English speakers use WordPress.

    • J.D. Grimes 12:57 pm on September 2, 2015 Permalink | Log in to Reply

      Thank you all for the hard work on this.

      I do have one question:

      You said that language packs don’t get shipped out unless they are 100% translated. I (and probably many other plugin authors) often include language files in my plugins that aren’t 100% translated. So, what will happen after the initial import if I remove those language files? I think that anyone using an incomplete translation will suddenly loose it when they update my plugin. The language files that were previously included included with the plugin will be overwritten when it is updated, and the language pack won’t be installed because it won’t be 100% translated yet. Has that scenario been considered?

      • Samuel Wood (Otto) 2:11 pm on September 2, 2015 Permalink | Log in to Reply

        Yes. Basically, don’t remove any particular language file until it reaches 100% translation on translate.wordpress.org.

        Like, if I look at one of my plugins like theme-check, here:


        Then I can see which languages have reached 100%, and consider them available for language packs. You can use that as a guide for when it’s safe to remove the old files from your plugin.

        • J.D. Grimes 2:23 pm on September 2, 2015 Permalink | Log in to Reply

          Thanks for clarifying.

          I suppose that plugin updates work the same way? That is, when a plugin is updated with some new strings the language pack updates won’t be pushed out until the translation reaches 100% again, right? So ideally any string changes in a plugin would be committed some time in advance of the release of the next version. But many of us develop on GitHub, and only sync with wp.org when we tag a new release. How would we give translators time to update? Would we need to sync a beta to trunk a bit before release?

          • Samuel Sidler 2:27 pm on September 2, 2015 Permalink | Log in to Reply

            We recommend syncing to trunk SVN as frequently as possible for this purpose. Each plugin actually has four projects in translate.wordpress.org: two for trunk and two for stable. (See here.) Syncing to trunk will give translators the strings ahead of time.

            • Jason Hendriks 8:14 pm on October 31, 2015 Permalink

              It seems to me my plugin code on translate never matches what is in the plugin repo. What is the trigger to copy code from Subversion to Translate? Is there a schedule?

            • Samuel Wood (Otto) 2:00 pm on September 9, 2015 Permalink

              I would not say to sync to trunk “as frequently as possible”, but rather “as frequently as makes sense for the project”.

              If you’re using the tagged version methodology in SVN, then your Stable version is some tagged version number, and /trunk is your beta or even alpha version. Now, I get that you may do your primary development in Github or something, and so you don’t sync that to /trunk. Nor should you, really.

              But if you sync to /trunk some time before actually releasing, then any string changes you’ve made will become available to translators before you tag a new release and thus create a new Stable version.

              That said, I would not use an automated process to do this either. If no strings change, then you have no reason to push to /trunk, eh? And if strings are still in the process of changing, pushing to /trunk too often leads to them getting translated and re-translated when they change again, for no good reason.

              The bottom line is that you need to update /trunk when it makes sense for your particular project. There’s no rule-of-thumb here, and certainly no definite time in which to do so. When your project changes enough that it warrants getting a “beta” created for it, then sync to /trunk. And then Tag on release.

            • Marcus 12:00 pm on September 4, 2015 Permalink

              oops @netweb see above (habit)

            • Marcus 12:00 pm on September 4, 2015 Permalink

              @netweblogic ah, that sounds better :) as I said I need to take a little time to read all the related docs before I start asking away! I really do think this is the way forward, or at least in the right direction 😉

            • Marcus 11:07 am on September 3, 2015 Permalink

              I’m trying to compile a few questions whilst I wrap my head around the issues I’ll run into with this move (although overall I think it’ll be a positive one).

              I think J.D. puts forward a very good point, I have a similar situation. A 100% threshold might be a little unproductive, it puts a burden on the developer to get behind translators to update and taking action if it’s not translated in time for the update (upload translations to folder, etc.). Devs will spend more time going after translations instead of developing cool code.

              Aside from the burden on the developer I wonder how it’d affect user experience. If you add a new string, and nobody is around to translate it, is it worth taking down the whole translation from automated updating, and the translated version on the website?

              Why not a 90% threshold, provided certain crucial strings like the readme.txt, plugin title etc. are translated?

            • Stephen Edgar 6:09 am on September 4, 2015 Permalink

              @netweblogic The process here is following the same rules and guidelines that WordPress Core (and themes) already use, translations are only shipped once they are 100% translated. This was discussed at great length many times in many places when first implemented in WordPress 3.7, 7 releases ago, since then WordPress, Akismet, bbPress and BuddyPress have benefited massively from these automatic translation updates.

              The other point I’ll make is if your plugin version 7.4 is 100% translated for a locale and you release 7.5 though it is not 100% translated the 7.4 translations of that locale won’t be deleted when version 7.5 of the plugin is downloaded, the 7.4 translations will only get deleted/overriden when the 100% 7.5 translations for that locale are delivered.

            • Marcus 10:37 am on September 4, 2015 Permalink

              Thanks for clarifying Stephen, with your example, say 7.4 is 100% and 7.5 is 99% at time or release, does that mean until it’s 100% people won’t be able to download language packs automatically for that language?

            • Stephen Edgar 11:57 am on September 4, 2015 Permalink

              @netweblogic Correct in the context of “automatic language updates”, even at 99% the language pack won’t be automatically generated and made available via automatic updates.

              ** Stepping away from “automatic updates”, translations for a moment, any WordPress locale, Theme, or Plugin are always able to have translations manually exported and added to the site manually via FTP/SFTP etc, thus theoretically that 7.5 version of the plugin only at 99% could be updated manually, once it did hit 100% then a language pack would be generated and would then in turn update and everyone would be doing the happy dance :)

            • J.D. Grimes 3:42 pm on September 9, 2015 Permalink

              Thanks Otto, that is basically what I had in mind for my project. I wouldn’t sync to trunk all the time, only once the next version was in beta, and then only when there were string changes.

        • Jenia 11:39 am on September 7, 2015 Permalink | Log in to Reply

          Could you talk me through what happens in the following scenario (I saw the related discussion below, still unclear on details though). E.g. plugin A at version 1.2 has locale XX translated at 100%. As part of the transition process described in the original post, plugin author removes the XX language file from SVN, now that the translations live in GlotPress on wordpress.org. The plugin author is happy, and the end user is happy as they see the plugin 100% translated to their language.

          Then, the plugin updates to 1.3, removing/changing/adding new translatable strings, and now locale XX is only 80% translated. What happens from the user point of view? Will their plugin update automatically to the latest version, meaning that they will see the strings 80% in language XX and 20% in English? It won’t revert to 100% English, right?

          If 99% of strings are translated in GlotPress, the user will still see only 80% of strings translated?

          And suppose, hypothetically, this locale lingers over the time… The plugin is now at 2.6, it only uses 20% of the strings that were translated in 1.2, the translation in GlotPress is at 85%. What does the user see on their site — the plugin at 2.6, with 20% strings in XX and 80% in English?

          • Samuel Sidler 12:02 pm on September 7, 2015 Permalink | Log in to Reply

            Certainly. I’d be happy to clarify this scenario. Let’s give things some names to make it easier.

            Sam’s Awesome Plugin just released version 1.2. As part of that, the Dothraki translation team translated all of the strings in Sam’s Awesome Plugin such that the plugin was now at 100% translated into Dothraki. At this point, the Dothraki language pack will go out to anyone who has installed Sam’s Awesome Plugin and also selected “Dothraki” as their language in WordPress.

            It’s also important to note here that, in translate.wordpress.org, Sam’s Awesome Plugin version 1.2 is in the “stable” subproject. New strings in the development version of Sam’s Awesome Plugin will appear in the Development subproject. (Here’s an example with bbPress.)

            When it’s time to release version 1.3 of the project, Sam’s Awesome Plugin will move the trunk version over to the stable branch (in SVN) and the strings will follow in translate.wordpress.org. At this point, if the Dothraki translation team has been keeping up with the development version, the strings will already be at 100%! But if they haven’t (more likely), the following will happen:

            • All users of Sam’s Awesome Plugin will receive an “update available” notice and can update.
            • If a user updates Sam’s Awesome Plugin to version 1.3, they will still have the old, version 1.2 strings, which may only reflect 80% of the strings translated (per your example).
            • The remaining strings will be in English and will stay in English until a new language pack ships.
            • A new language pack will only ship once the strings are translated to 100%
            • As in your example, when Sam’s Awesome Plugin reaches, say, version 2.6, users who are still on the Dothraki version will see only the strings from version 1.2 translated into Dothraki. All other strings will be in English, regardless of its status in translate.wordpress.org. (Assuming no new language packs have been shipped between version 1.2 and 2.6.)

            I hope that all makes sense. We’re hoping that the “translation memory” in GlotPress (not a real translation memory, of course!) combined with a “development” subproject will help keep most projects current. However, we’re willing to reevaluate the 100% bar for language packs if it makes sense in the future. Part of the slow roll out is to see how these things work in practice.

    • Stephane Daury (stephdau) 2:50 pm on September 2, 2015 Permalink | Log in to Reply

      Happy dance! :)

    • Zach Tirrell 3:48 pm on September 2, 2015 Permalink | Log in to Reply

      I have a few question.

      • How many plugins will be in each batch to start?
      • Who will be emailed when a plugin is in the next batch to be imported? I’m hoping the answer is “all admins of the plugin.”
      • How much lead time between getting the email and the import happening?
      • Samuel Wood (Otto) 12:35 am on September 3, 2015 Permalink | Log in to Reply

        Slow start, ramping up as needed.

        All commiters for a plugin will get an email. Make sure your email on the support forums is correct and up to date.

        A few days before the actual import.

    • RobertHarm 5:24 pm on September 2, 2015 Permalink | Log in to Reply

      this is great news, thanks for working on this!

      just two question:
      1. do you plan to also offer this feature for plugins not hosted on wordpress.org?
      2. if as in my case the pro version of my plugin also uses the same text domain (and same po-files as the free version) as a consequense, will they also be updated

      • Samuel Wood (Otto) 12:32 am on September 3, 2015 Permalink | Log in to Reply

        1. No.
        2. No, but also don’t do that. It will create problems down the line. Use a different slug and domain and directory name for your pro plugin. Slugs need to be unique.

        If you want extra advice on this, email me the details. Happy to advise.

    • Samuel Wood (Otto) 12:40 am on September 3, 2015 Permalink | Log in to Reply

      If any plugin authors have questions about how to transition their existing translations, by all means, email me about it. I’m otto@wordpress.org. Not a big deal to look into specific cases and recommend a best course of action. This is actually kind of easy to grasp. 😉

    • Jeremy Herve 12:40 pm on September 3, 2015 Permalink | Log in to Reply


      Quick question: GlotPress includes a “Glossary” feature ref) enabling translation editors to give helpful tips to translators. Here is an example. Will plugin authors be able to create or import glossaries with vocabulary specific to their plugins?

      • Samuel Sidler 2:24 pm on September 3, 2015 Permalink | Log in to Reply

        Plugin authors won’t be able to, but translation editors can upload them for their language (per-project). This includes per-project translation editors, of course, so if I’m the translator for Twenty Fifteen and only Twenty Fifteen, I can create a glossary for the Twenty Fifteen project.

      • Stephen Edgar 6:20 am on September 4, 2015 Permalink | Log in to Reply

        Plugin authors can, and should when necessary add translation comments to their code to help translators though, see the handbook docs here on how to help translators understand the context of strings in your plugin.

    • eventualo 2:44 pm on September 4, 2015 Permalink | Log in to Reply

      Great news!
      A question: in order to make initial import works, the plugin trunk must have .po AND .mo files? (My plugin has only .mo on WP.org repo).

    • Jenia 9:44 am on September 7, 2015 Permalink | Log in to Reply

      I have a question, the post makes it sound that it’s possible to opt out of using language packs (by shipping language files in the plugin), but that it’s the initial import of translations into translate.wordpress.org is a given (the timing is a given and there is no opt-out option). Is that correct?

      • Samuel Sidler 11:47 am on September 7, 2015 Permalink | Log in to Reply

        Hi Jenia!

        Just to clarify, plugins cannot opt-out of the initial import, but plugins can opt-out of language packs (and, thus, using translate.wordpress.org).

      • Jenia 10:49 am on September 7, 2015 Permalink | Log in to Reply

        Found the answer in the logs and it’s a no.

    • helmu 1:03 pm on September 7, 2015 Permalink | Log in to Reply

      What if I have my own unique translation for a plaug. I don#t6 want to redo this every time an update is provided?

    • Daisuke Takahashi 10:02 am on September 9, 2015 Permalink | Log in to Reply

      @otto42, “Languages” section of https://wordpress.org/plugins/nothing-much/ mentions Japanese twice. It seems like a bug. Could you take a look?

    • Joachim Jensen - Intox Studio 12:57 am on September 11, 2015 Permalink | Log in to Reply

      I really like the idea of decoupling translations and auto-updating them. It will make the localization flow so much faster.

      I do have a question though; will it be possible to import translation files into ones projects at translate.wordpress.org? I am asking because I use an existing service for one of my plugins to let people translate it, and as it works perfectly fine, I wouldn’t start trying to force the users to use a new service.

      • Samuel Sidler 1:51 am on September 11, 2015 Permalink | Log in to Reply

        Great question!

        After the initial import, our script won’t import language files (.mo) from your plugin again; the initial import is a one-time deal. If you use an existing translation service, we recommend you bring your trusted team of translators over to translate.wordpress.org. The polyglots team would gladly get them setup with “translation editor” status for your plugin(s). Translation editors can import language files at-will for their respective locales and projects. (e.g., a German translation editor for Akismet can import translations for Akismet in German, but not for other projects or other locales.)

        The last question in the FAQ links to a post that walks you through getting your translators setup.

        • Jason Hendriks 6:20 am on October 9, 2015 Permalink | Log in to Reply

          A translator just sent me a completed .po, but he’s missed the deadline for the auto-import of my plugin’s language files. As the plugin author, I can’t find an option anywhere to import the language file – what am I missing, a special status? A buried command?

    • David Anderson 2:09 pm on September 11, 2015 Permalink | Log in to Reply

      Is there some documentation somewhere on the hooks/filters that WP will be using to download translation packs? As a developer of third-party plugins (i.e. ones not hosted at wordpress.org), I want to see how I can hook in so that WP can download translation packs for third-party plugins so that they don’t need bundling.

      • Dion Hulse 12:32 am on September 14, 2015 Permalink | Log in to Reply

        There isn’t really any documentation for anyone not using WordPress.org infrastructure yet.
        You’ll want to start by looking at Language_Pack_Upgrader and also the translations key on the plugins/themes/core update check endpoints.

        • David Anderson 7:57 pm on September 21, 2015 Permalink | Log in to Reply

          Thank you…

          Slightly different question: Any idea about whether the wordpress.org plugin directory will allow plugins in wordpress.org plugins to host their language packs elsewhere? WooCommerce currently does this, so presumably it’s OK. Personally, I’d prefer not to migrate my existing translation system to wordpress.org, and would prefer to ship a 99%-ready translation for a plugin update instead of having people left on the previous version. To do that, I’d need to host my own stuff – but am wondering if the wordpress.org rules will allow it. It’s not 3rd-party code, so presumably, as with WooCommerce, it ought to be OK, but it’d be useful to know if there’s anything more official than that.


    • Maros Polak 12:06 pm on September 14, 2015 Permalink | Log in to Reply

      Hello @samuelsidler,

      I want to ask you for the approximate date, when you start to plan add other plugins to https://translate.wordpress.org/. And how long (approximate) it will take from start adding the most ‘active installs’ plugins until it reaches this concrete plugin https://wordpress.org/plugins/fv-wordpress-flowplayer/

      Thanks for you reply

      • Samuel Sidler 1:01 pm on September 14, 2015 Permalink | Log in to Reply

        Hello! We can not give you a set timeline at the moment. Rest assured that when we are ready to import your plugin, you will be emailed about it ahead of time.

    • Maros Polak 4:30 pm on September 14, 2015 Permalink | Log in to Reply

      It is possible that it starts this year or the next?

    • TobiasBg 8:52 am on September 16, 2015 Permalink | Log in to Reply

      It would be great if authors/commiters of a plugin could be added as Translation Editors for all locales (just for the plugin, of course) automatically. Or should we just go through the post to make/polyglots process for that as well?

      • Samuel Sidler 11:28 pm on September 17, 2015 Permalink | Log in to Reply

        We strongly recommend that plugin authors are not made translation editors for all locales (for their plugin) as they do not speak 155 languages. We believe that translations are better off in the hands of native speakers who are able to understand the complexities of those languages.

        • TobiasBg 6:51 am on September 18, 2015 Permalink | Log in to Reply

          Totally agree with that! But unless there’s a translation community around a plugin, very small changes will lead to incomplete translations quite fast, so that users who newly install the plugin will not get the 99% translation.

          For example, in my case, I’ve fixed a typo or added a single word, so that I could translate that myself (at least for those languages that have almost-complete translations).

          I’d most certainly not be validating translations of languages that I have no clue of, but I’d at least like to have the same possibilities as before (where, as a committer, I’d have full power over the translations), for emergency or one-off situations.

          • John Blackbourn 9:45 am on September 28, 2015 Permalink | Log in to Reply

            This is my concern, too. If a translation is updated for a language that has very few moderators, there’s a bottleneck for getting that translation pushed out in a timely manner. Without the plugin/theme author being able to approve translations for their own plugins/themes, I imagine this could become very frustrating.

    • Jordy Meow 11:49 pm on September 16, 2015 Permalink | Log in to Reply

      I actually noticed that system when today I received an email from WordPress. However, it says: “A scan of the code indicates that your plugin does not have a text domain”. Problem is… my plugin has definitely a text domain, and with the right name. Not sure what should I do or who should I tell?

      • Samuel Sidler 11:22 pm on September 17, 2015 Permalink | Log in to Reply

        If you’re confused as to why you received that email, please join Slack, specifically the #meta-i18n channel. You can find more information on chat.wordpress.org.

        It’s very likely that you do not properly have “Text Domain:” in your plugin header, but there could be other reasons that you’re seeing that error.

    • Tran Ngoc Tuan Anh 1:59 am on September 17, 2015 Permalink | Log in to Reply

      Great news. Today I received the email notification for moving the translation of my plugin (Meta Box) to translate.wordpress.org. I updated the plugin with the text domain and domain path. But I have a small question: should I still need to ship the plugin with .mo files? Can I remove them completely?


      • Samuel Sidler 11:23 pm on September 17, 2015 Permalink | Log in to Reply

        If you have questions on this process, we recommend you join Slack, specifically the #meta-i18n channel. You can find more information on chat.wordpress.org.

        After the initial import, you can remove the language (.mo) files from your plugin so that language packs appear. If you do not wish to use language packs, you can keep the language (.mo) files in your package. If you need further clarification, just pop into Slack and ask.

    • RobertHarm 11:16 am on September 25, 2015 Permalink | Log in to Reply

      I have some questions regarding the upcoming language pack support for plugins & hope someone can help me here. I am the developer of the free mapping plugin Leaflet Maps Marker and the premium plugin Maps Marker Pro. In order to increase efficiency, both plugins currently use the same text domain ‘lmm’. Anyway this is not compatible with the new system according to your info email – for the free version I would need to change this to the slug ‘leaflet-maps-marker’. The pro version has the slug ‘leaflet-maps-marker-pro’. I now wonder if it is supported & allowed to use the new translation pack support for plugins also for my pro plugin? e.g. by also adding the text domain ‘leaflet-maps-marker’ there and by adding “Text Domain: leaflet-maps-marker” in the primary PHP file? So to sum up my question: can another plugin (not hosted on wordpress.org) with a different slug use the text-domain of a plugin hosted on wordpress.org? Would really be great in terms of service for users if that would be possible!

      • Samuel Wood (Otto) 11:20 am on September 25, 2015 Permalink | Log in to Reply

        No, it simply will not work. The text-domain must be identical to the “slug” of the plugin. The slug of the plugin is the same as the directory name the plugin lives in, or the end part of the URL of where it lives here, on WordPress.org. That is the name that will be used for the language pack, any other text domain will not work.

    • Joel James 3:27 pm on September 25, 2015 Permalink | Log in to Reply

      What if my plugin is not translation ready? (I mean strings are not given properly)

    • webaware 10:53 pm on September 25, 2015 Permalink | Log in to Reply

      This is a great idea in general, and I can see most plugins benefiting greatly from it. My map plugin, Flexible Map, maybe not so much because of a specific feature.

      I initially developed the plugin with translations in JavaScript, which allowed me to easily incorporate multiple translations into a single site (or page, even) according to shortcode attributes. For example, a website can have a page with a map in English and a separate page with a map in Chinese. Once I got my GlotPress installation going, I refactored for .mo based translations, still supporting the multiple translations feature. For this to work, the plugin needs to find all of the .mo files.

      With this change, it sounds like I’ll need to keep delivering all of the .mo files with my plugin distribution so that they will all be loaded, otherwise websites will only receive the single .mo file specific to the selected translation for that website, is that correct? Or will website admins simply need to run through the list of languages they want in Settings > General so that language packs will be installed for those languages?

      Is there a way to receive notifications from GlotPress on WordPress.org when new translation strings have been approved? I only speak English (barely, some would say) so I won’t be signing up as a validator, and certainly not on the wide range of supported languages. I looked in the handbook and could not see anything about notifications. I guess I could just pull all .mo files each time I cut a release, perhaps with a Grunt process, but it would still be nice to know when a new language hits > 90% for example.

      More generally, how are language packs handled with multisite and WMPL translated websites? Does having the WordPress language packs installed in wp-content/languages mean that all plugins will receive language packs for those languages?

    • Jacob N. Breetvelt 8:43 am on October 2, 2015 Permalink | Log in to Reply

      What should i tell users who ask me for an not yet existing translation? If their language is xy_XY, when will the translation of my plugin in the xy_XY language be added?

    • Martin Tod 12:46 pm on October 4, 2015 Permalink | Log in to Reply

      Just done this on ‘Rotating Tweets’. Removed the language packs. Changed the `load_plugin_textdomain();` command to `load_plugin_textdomain( ‘rotatingtweets’ );`, auto-upgraded a version on an eng-GB site (which should swaps the word ‘favorite’ to ‘favourite’)… and it doesn’t work. Have I missed something?

    • Jenia 7:49 am on October 5, 2015 Permalink | Log in to Reply

      Hi Sam, I have a question about how string sharing/leveraging will work across different plugins.

      Example: Jenia’s Plugin has a string “Post”. Hans, German translation editor for Jenia’s Plugin, translates as “Beitrag”.

      This same string (“Post”) also exists in Sam’s Plugin. Gretel, German translation editor for Sam’s Plugin, feels that a more appropriate translation would be “Artikel” and updates that translation in the plugin.

      Question: will the string change from “Beitrag” to “Artikel” for German translation of Jenia’s plugin? Which German translation will any other plugins that have the string “Post” leverage?

      • Marcel Pol 5:58 pm on October 10, 2015 Permalink | Log in to Reply

        The code for a plugin uses a certain text domain. The translation for that plugin is loaded for that text domain. The php code will only use strings from files loaded for that text domain.
        So no, it won’t conflict. It will be inconsistently translated though :).

    • nosilver4u 4:02 am on October 20, 2015 Permalink | Log in to Reply

      If your plugin isn’t ready for translations, then you should work on that 😉 https://developer.wordpress.org/plugins/internationalization/how-to-internationalize-your-plugin/
      Just wanted to share that even though it can be a lot of work to make your plugin translation ready, it is really amazing to see the results down the road. Two years later, I have translations in 15 different languages, and I’m excited to see how these new changes will improve things. My translators are having all sorts of fun with the new platform (even though we already used GlotPress for EWWW Image Optimizer), and it is pretty neat to see the language packs rolling out automatically as the translations hit 100%.

    • DareDevil73 11:59 am on November 23, 2015 Permalink | Log in to Reply

      Hi, I hope to use the translation platform asap to give to the community a better service, so I would ask you if you planned to import my (active) plugin https://wordpress.org/plugins/google-analytics-counter-widget/.

      Thank you very much!

  • Ipstenu (Mika Epstein) 2:16 pm on August 26, 2015 Permalink |
    Tags: fork, policy   

    Forks and Copies 

    This has come up recently. What happens when someone submits a plugin that’s a copy of another?

    The tl;dr here is this: Please email us at plugins@wordpress.org if you find someone has slipped an uncredited fork or identical copy of another plugin into the repository.

    In general, we spot these before they ever get published. We rejected 10s of plugins a month for being identical copies. That said, we also approve double that for being legitimate forks.

    While the GPL and it’s compatible licenses allow for forking, we have an ‘above and beyond’ rule for hosting here, that means your plugin must be a substantial change of the original. We do not allow direct copies of other plugins to be re-listed under somebody else’s name, we allow changed forks.

    What does that mean? It’s very simple. You have to add new features, remove features, modernize, fix, clean up, or otherwise make a change to the plugin that differentiates it from the original. In rare cases, a simple clean-up will be accepted, but normally we try to get a hold of the original authors and have the fixes folded in to the original plugin. If you have a fork, we require you to retain all credit and/or copyright information.

    That’s all well and good. What happens when we miss one?

    Contact us. Email us at plugins@wordpress.org and tell us “Plugin A is a copy of Plugin B.” If both plugins are on the WordPress.org repository, provide links — there are 45k plugins in our repository, no links means it takes us an extra email or three to sort out which plugin you were talking about. Anyone can report this, though we ask you be reasonable and not accusatory. We are real humans who will read your emails. Treat us like that :)

    We’ll open up both plugins, the current versions and the originals, and run a diff between them to see what’s different. If it’s just renaming plugin functions, we’re going to close the copy. If it’s clearly a full rewrite, with moving functions to namespaces etc, we’re likely to keep both versions open. A full modernized rewrite is a legit fork. We will go back and ask them to put credits and copyright info back in, but rarely more.

    If the original plugin is NOT hosted on WordPress.org, then it’s more complicated because we need to see them to compare. This means if you, as a user, see a copy of a premium plugin, you need to ask the original developers to contact us. Why? Well, have you ever tried, as a non-paying customer, to contact some of these folks? It’s an uphill battle. It’s worse when they’re hosted on places which protect their email addresses. That’s great, we totally get why you do that, but we have no way to contact them. Many times we’ve reached out and gotten auto-replies that take weeks to get back to us with a real human.

    If you’re the original developer, email us a copy of your plugin (we promise not to steal it) and if you can, explain how you know it’s a copy and not a fork.

    But whatever you do, please, please, please, don’t take all this to the forums and post complaints that the forked plugin authors are evil or what have you. That doesn’t make for a happy community. Report things properly. Let us know. We’ll take the angry hit from them for you.

    If you’ve written a fork or a copy? Please make sure you’re really making a fork! Just slapping on your name and changing function names isn’t enough of a fork for us to host it here. We don’t want to have 100 plugins that are the same, save the credits. We want to have plugins that do different things.

    Edit: All questions about the GPL-100% rule and how it applies to WORDCAMPS needs to be asked of the https://make.wordpress.org/community/ team – All those comments are being deleted for derailing the topic here.

    • Brajesh Singh 2:37 pm on August 26, 2015 Permalink | Log in to Reply

      Thank you for the write up Mika.
      That’s some seriously great points about properly forking/reporting the shallow forks properly. It would be nice to have these points as part of the developer faq section too.

    • Rene Hermenau 2:41 pm on August 26, 2015 Permalink | Log in to Reply

      > This has come up recently.

      I follow the case you are probably approaching and had a look at both plugins so I really welcome this official statement.

      Thanks for making it clear!

      I feel vindicated to continue to publish my plugins under the GPL and on wordpress.org, Now more than ever because the WP team does not allow to have simple copies of my plugins be listed in the wp repository.

    • Dave Navarro, Jr. 2:57 pm on August 26, 2015 Permalink | Log in to Reply

      Do derivatives of plugins/themes in the repo that are NOT GPL compatible effect their eligibility to be in the repo?

      For example, I know of a plugin in the repo that is 100% GPL. However, the same author sells a forked version of his own plugin as a premium plugin and he claims copyright in the code (not GPL).

      I ask because WordPress has started banning developers from officially sanctioned WP events who do not release EVERYTHING WordPress related as 100% GPL. So I’m wondering if the same standard applies to putting free versions of premium plugins in the repo when the premium version is not compliant.

      • Pippin Williamson 3:03 pm on August 26, 2015 Permalink | Log in to Reply

        What someone does outside of the repo does not effect their eligibility to be listed in the repo as long as the code in the repo follows the guidelines and does not violate any repo regulations.

        Note: this is where it gets super tricky so don’t take this as fact or legal advice.

        WP plugins themselves cannot be non-GPL, only other items (non-derivatives of WP) included with the plugin can be non-GPL. As long as the fork does not contain any of the non-GPL components, it’s perfectly acceptable to have a fork in the repo.

        • Dave Navarro, Jr. 3:08 pm on August 26, 2015 Permalink | Log in to Reply

          Thanks Pippin, I know about the whole “cannot be non GPL” debate, which I agree with.

          I just know that Automattic is preventing developers who “claim” non GPL compliance from officially participating in WP events. So it would make sense if developers were pulling the same shenanigans with premium versions of their free plugins in the repo from similarly having WordPress allow them to participate in the repository.

          • Pippin Williamson 3:15 pm on August 26, 2015 Permalink | Log in to Reply

            The event participation issues for non-GPL products is a super sticky situation. I can’t (read won’t) say anything much there since I have no affiliation with Automattic.

        • Andrey "Rarst" Savchenko 3:30 pm on August 26, 2015 Permalink | Log in to Reply

          > WP plugins themselves cannot be non-GPL

          Official repository rules allow GPL–compatible plugins (such as MIT), which are non–GPL.

          Tangential to the question, but pet peeve when people make hard statements like this.

        • FolioVision 12:55 pm on August 27, 2015 Permalink | Log in to Reply

          Hi Pippin,

          Your statement below is a legal opinion:

          WP plugins themselves cannot be non-GPL, only other items (non-derivatives of WP) included with the plugin can be non-GPL.

          The opinion is extremely contentious. As it is not fact it should not be cited as such.


      • Casey Driscoll 6:12 pm on August 26, 2015 Permalink | Log in to Reply

        > WordPress has started banning developers from officially sanctioned WP events who do not release EVERYTHING WordPress related as 100% GPL

        [citation needed] please.

      • Ipstenu (Mika Epstein) 11:03 pm on August 26, 2015 Permalink | Log in to Reply

        https://plan.wordcamp.org/planning-details/speakers/ – Speakers have to be 100% GPL. One presumes that extends to staff as well.

        What the WordPress Foundation choses to require in order to maintain their oversight of WordCamps is their decision. Just like we have a requirement that we don’t permit a split license, or powered-by links that aren’t opt in, and so on for hosting your code here, they’re allowed to have ‘above and beyond the GPL’ requirements for what they control.

    • Lisa 3:44 pm on August 26, 2015 Permalink | Log in to Reply

      Do the non-GPL components mean graphics and CSS?

    • George Stephanis 6:29 pm on August 26, 2015 Permalink | Log in to Reply

    • Dylan Ryan 2:31 am on August 27, 2015 Permalink | Log in to Reply

      If file_A.php has WordPress related functions (imagine, add_actions) and includes file_B.php (imagine, custom PHP), which has NO WordPress functions, then could you license file_B.php as MIT and leave file_A.php as GPL? Delete this if it’s off-topic – I’ve always just been curious where the line is drawn between GPL and Non-GPL.

      • Dion Hulse 2:46 am on August 27, 2015 Permalink | Log in to Reply

        As MIT is an even more permissive license than the GPLv2 license (ie. it does not apply extra restrictions upon the codes usage) then it’s classified as an GPLv2-compatible license and as a result you can license the entire plugin as MIT and be accepted into the Plugins Directory.

        The issue is where the license applies restrictions above/beyond what what GPLv2 license does, in that case it won’t be accepted into the WordPress.org directory as the entire plugin is not GPLv2 compatible.

        You may be interested in this older post and it’s linked resources:

    • Vladimir Prelovac 9:32 am on August 27, 2015 Permalink | Log in to Reply

      Hi Mika

      This is indeed a good move.

      I am wondering what is the stance towards cases when this happened in the past.

      Let’s say there was a plugin A and plugin B forked it and entered the repo as an almost identical copy, two years ago. Now both have significantly changed. Could plugin A author still request removal of plugin B?

      • FolioVision 1:06 pm on August 27, 2015 Permalink | Log in to Reply

        Good point Vladimir. I think that the rule should be applied retroactively. Stopping code copiers/code thieves should be public policy.

        In these cases, the copycat plugins could then redirect to the original (so people don’t end up stranded).

        If the copiers want back into the repository, they’d better make substantial changes and improvements. Those caught systematically copying should face slightly higher standards than accidental clones, just as professional con men face stricter standards in court.

        • Ipstenu (Mika Epstein) 1:33 pm on August 27, 2015 Permalink | Log in to Reply

          Those caught systematically copying have all their plugins removed and get banned. It’s not happened a lot. Most people are mature about this.

        • Samuel Wood (Otto) 12:35 pm on August 28, 2015 Permalink | Log in to Reply

          The rule is absolutely not applied retroactively, and you and Vladimir need to understand what a proper “fork” is.

          A proper fork is when you take a copy of something, and modify it to suit your needs. Obviously, at first, that copy is a *copy*. So just because it started out as a copy does not mean it’s not okay. It absolutely is okay to do that, the GPL explicitly allows it. That’s the whole point of open source, to be open.

          What Mika is saying in this post is that we require forks to be *forks*. Not just copies. Even if a plugin started out as a copy, if it has undergone substantive change over time, then we will not remove it just because it started as a copy. All forks start as copies. That is the nature of forking.

          Some plugins go into the directory with nothing more than the function names changed and the credits scrubbed off. Then they never get changed again. That’s not okay, and we do not allow that. But a plugin that was copied, edited, modified in some meaningful way, that’s a legitimate fork. That’s acceptable.

          • Ipstenu (Mika Epstein) 2:36 pm on August 28, 2015 Permalink | Log in to Reply

            It would only be applied retroactively if it was something like Plugin B was always 100% copying Plugin A, and only changing function names. I can honestly tell you that’s so rare, I only think I MIGHT have once seen one…

            • Samuel Wood (Otto) 11:25 pm on August 28, 2015 Permalink

              > Again this implies a copy would never be allowed into the repo, only a changed fork is allowed.

              But lets say we miss that fact, and a copy does make it into the repo. That doesn’t instantly damn it forever with no hope of recovery.

              If a copy gets substantive change over time, then it is no longer a copy, it’s now a legitimate fork. Because that’s what a fork is: a copy that got modified for some purpose.

              Forks are welcome in the Plugin Directory, regardless of their origins.

            • Vladimir Prelovac 5:22 pm on August 28, 2015 Permalink

              There is a ‘timing’ confusion here.

              Otto you basically say that a plugin can enter the repo as a copy and you expect it to change with time or be removed.

              However what happened to LeadPages confirms a different view, one aligned with what Mika explicitly wrote:

              “In general, we spot these before they ever get published. We rejected 10s of plugins a month for being identical copies. ”

              This implies copies are not allowed to be published at all, which is consistent with the removal of leadpages plugin.

              Couple of sentences later adding:

              “We do not allow direct copies of other plugins to be re-listed under somebody else’s name, we allow changed forks.”

              Again this implies a copy would never be allowed into the repo, only a changed fork is allowed.

            • Ipstenu (Mika Epstein) 8:06 pm on August 28, 2015 Permalink

              @freediver – No there isn’t a confusion at all.

              Again this implies a copy would never be allowed into the repo, only a changed fork is allowed.

              Yes, that is 100% exactly what we’re saying.

              If you’re about to kvetch that we miss plugins, please accept our apologies. We’re sorry we missed every single copy we missed, but we don’t have a TARDIS and crossing time streams is bad, so we can’t go back and be 100% perfect every single time we do these things.

              The point of posting this was to remind you all that if you see something, there is a place to say something instead of making a stink on Twitter or your blogs. You can come to us for HELP.

      • Ipstenu (Mika Epstein) 1:32 pm on August 27, 2015 Permalink | Log in to Reply

        Plugin A can always request. What we do depends on how divergent they are.

        Edited to note of course you can ask, but we expect you to have put a measure of thought into it. Is it a COPY or a FORK? Copy bad, fork good.

        We tend to enforce that plugin B put in credit/copyright information, or at least say “Inspired by A”

        You can usually still see the bones of the original, after all, and a show of good faith goes a long way to making a happier community.

        I will note that we did have a case where a fork was a total rewrite. They moved the whole thing to Singletons, moved files around, and had ONE (yes one) function that was identical. We asked them to credit the original, and nothing more. That was a legit fork.

    • FolioVision 1:09 pm on August 27, 2015 Permalink | Log in to Reply

      Thank you for making these rules clear and explicit Mika. They are a big help to those developers making a real contribution. Sharks and scam artists are only going to become more common in the WordPress world. Not giving them breathing space in the repository is one very good step to making the WordPress world safer, fairer and more fun.

    • Ahmad Awais 1:18 pm on August 27, 2015 Permalink | Log in to Reply

      Hey, Mika!

      Thanks for posting this. As much as I love GPL and have it in my plugins/themes as the only license, I was wondering if someone could do that to me, but then when a recent plugin got removed from W.org repo, I was actually looking forward to an official response.

      Copying something, slapping one’s name on it and forking to improve and enhance the code are two different things.

    • Ipstenu (Mika Epstein) 1:28 pm on August 27, 2015 Permalink | Log in to Reply

      If you folks have questions about the WordCamp rules, please talk to the https://make.wordpress.org/community/ team – I’m nuking them here because you’re at the place where it’s off topic to the point of wasting Pippin’s and my time. We (he and I) aren’t on that team. We cannot tell you fact. Be smart. Go to the source.

    • @modemlooper 3:52 pm on August 27, 2015 Permalink | Log in to Reply

      Here’s a remark about forking and releasing to repo; I had someone who would take every one of my BuddyPress plugins and fork and re-release into the repo. Then I got a ton of support requests via email for this forked plugins. One person, who, when I said I don’t support forked versions decided to send me DEATH THREATS.

    • webdevmattcrom 4:07 pm on August 27, 2015 Permalink | Log in to Reply

      Excellent response and clarification, Mika. Thanks to all on the Plugin Team for their dilligence here. We appreciate it!

    • webdevmattcrom 4:20 pm on August 27, 2015 Permalink | Log in to Reply

      I’m curious though whether this “above and beyond” approach will be mentioned in the Plugin Guidelines so that authors are aware before submitting: https://developer.wordpress.org/plugins/wordpress-org/detailed-plugin-guidelines/

      • Ipstenu (Mika Epstein) 4:41 pm on August 27, 2015 Permalink | Log in to Reply

        18. We reserve the right to alter this list in the future. We reserve the right to arbitrarily disable or remove any plugin for any reason whatsoever. Basically, this is our repository, and we will attempt to maintain a standard of conduct and code quality. We may not always succeed, but that is our goal, and we will do whatever we feel is necessary in furtherance of that goal.

        The issue with enumerating every single thing is you get a bunch of rules lawyers who will nit-pick and argue that we said it had to be significantly different, and this is because they did XYZ.

        It’s really hard to have the rule be “Don’t be a thief, a liar, a spammer, or otherwise a not cool and good person.” Because that’s really what all of this boils down to. Respect everyone. Treat everyone how you would like to be treated. Don’t be mean.

    • Dejan Markovic 1:44 pm on August 28, 2015 Permalink | Log in to Reply

      Hi I have “technical/GPL/forking” question for Mika or Pippin.

      I am currently working on a Pro version of one of my themes. Instead of re-inventing the wheel I would like to use some free plugins from WordPress.org repo (not pro versions) to fulfill my needs. For example testimonials plugin for CPT testimonials and so on. I will create my own HTML and CCS for displaying the Testimonials on the front end but on a back-end I would like to use the functionality from that plugin (take something out that I don’t need but also add some of the features that I need). I will put a GPL v2 license on that theme and on those plugins.

      Is that OK thing to do regarding WordPress.org policies? Also, I don’t want to be accused of stealing somebody’s work as I think this is a proper forking approach as I am adding:

      • my front end look,
      • my features in the back-end
      • allowing everybody to do whatever they want to do with my version/fork of that code.

      Thank you very much, your help is greatly appreciated!

    • Dejan Markovic 4:14 pm on August 28, 2015 Permalink | Log in to Reply

      Thank you Pippin and Mika!
      I will credit the original plugins and of course have their copyright present in my fork.
      Thank you so much!

  • Ipstenu (Mika Epstein) 4:03 pm on August 19, 2015 Permalink |
    Tags: guidelines, submissions   

    Plugin Submission ZIP files 

    This comes up now and then so I thought we should have a quick post about what your plugin zip should be when you submit.

    Keep in mind, if we email you and tell you we cannot download or open your zip, please don’t just say “Well it works for me!” The fact is, we’re smart people. If we cannot get the zip to open, there actually is a problem. Check the link and check the zip. Attach the zip to your email reply.

    It should be a zip file

    I know, that’s obvious, but we actually force you to send a zip for a number of reasons. I strongly urge you NOT to use anything fancy like winrar to compress it, because that can make your zip un-openable on Mac or Linux boxes. Protip? We all use Mac or Linux.

    Use a real URL

    Don’t use localhost. Don’t use your dev environment. Don’t try to upload the zip. It’s a link to where your zip is publicly accessible. No more, no less.

    Be very careful when you use ‘free’ upload sites. If they open up a dozen popups, we’re not going to risk them. We don’t like viruses.

    Speaking of…

    The link should be one that’s accessible to NON-logged in users

    Bitbucket folks, this means you, eh? If you’re using GitHub, you can link us to the zip they make UNLESS you’re including submodules. Surprise! Github’s autogenerated zips don’t include that. Drives me nuts. I know.

    Test the URL in an incognito window, just to be sure. It takes a second and you’ll see exactly what we see.

    The zip should be only the plugin

    It should be exactly what you would upload manually to WordPress to test (which you did test, right?) because that’s what we are going to do! Don’t include themes or other zips or required plugins. All of those requirements should be accounted for in your plugin by making checks and properly informing users as to what they need to do.

    By the way, please don’t nest your zips. Seriously. We see a lot of zips that have a readme.txt and then a second zip file. That means we have to open the zip, extract the other zip, check that it’s right, and then upload it.

  • Samuel Sidler 2:47 am on August 8, 2015 Permalink |
    Tags: ,   

    WordPress 4.3 Field Notes (Lots of Changes for Plugin Developers!) 

    Do you follow the make/core blog? If not, you should!

    Over on the make/core blog, we compiled all of the developer-focused changes in WordPress 4.3 in one spot. In case you don’t want to click, here’s a reprint of those changes:

    Just a week and a half left to get your plugins updated. Thanks for all your hard work!

  • Ipstenu (Mika Epstein) 8:51 pm on August 3, 2015 Permalink |
    Tags: , , core   

    4.3 Change to Plugin Dashboard Pages 

    Per #31650, there’s been a change to the way headers are processed.

    Previously we used H2 in order to create the header at the top of our pages like this:

    <div class="wrap">
        <h2><?php _e("My Cool Plugin", 'my-plugin'); ?></h2>
        <p>All my cool dashboard things</p>

    This was done because, prior to the Toolbar, WordPress put in an H1 header itself. With the change to the Toolbar quite a while ago, that was removed and it created a new problem for accessibility. In order to fix that issue the H2s were changed to H1s in core.

    This will not break your plugins.

    There is no visual difference, the styles stayed the same. Only the underlying markup has been changed.

    If you want to fix your plugins, just change that H2 to H1 and call it a day. Screenreaders will thank you.

  • Ipstenu (Mika Epstein) 10:21 pm on July 29, 2015 Permalink |
    Tags: 4.3, dfw   

    WordPress 4.3 Removes Old DFW 

    From Old Distraction Free Writing Code Removed in 4.3

    This release we removed all old DFW code, which hasn’t been used in core since 4.1. We left it in core for two releases so plugin authors had the time to update. If it is essential to your plugin, the files in 4.2 can still be reused and improved. See [32677].

    Please make sure you update your plugins before 4.3 is released.

  • 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>';" ) );

    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>';" ) );
    } 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>';" ) );

    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__ ) );
    } 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


    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.

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

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

    • Cx Rana 4:14 pm on August 13, 2015 Permalink | Log in to Reply

      currently i have 5/6 plugin hosted on wordpress.org
      but i didn’t got plugin developer badge in my profile…. why and how can i fixed it ?

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

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