Make WordPress Plugins

Updates from Andrew Nacin Toggle Comment Threads | Keyboard Shortcuts

  • Andrew Nacin 7:48 pm on April 23, 2013 Permalink  

    Plugins SVN Repository DNS Change Today 

    In a short while (next 30 minutes or so), plugins.svn.wordpress.org will undergo a DNS change as part of a datacenter migration. The TTLs are low, so this should only take a few minutes.

    Nothing will go down, but the SVN repository will become temporarily read-only. If you try to commit code during this time, you’ll receive an maintenance message pointing you here. Plugin pages and downloads will not be affected.

    Also, the associated Trac at plugins.trac.wordpress.org will be taken offline (for up to an hour) while it is migrated and re-synced.

    • Sam 8:15 pm on April 23, 2013 Permalink

      ok good luck andrew ^-^

    • Andrew Nacin 8:17 pm on April 23, 2013 Permalink

      Plugins SVN is online again. If your commits are not working, flush your DNS cache. Here’s the proper IP address for plugins.svn.wordpress.org:

      $ dig plugins.svn.wordpress.org +short

      Trac remains down while it re-syncs.

    • Andrew Nacin 8:37 pm on April 23, 2013 Permalink

      Everything is back online.

    • jquindlen 11:54 pm on April 23, 2013 Permalink

      If you don’t know how to flush your DNS on Windows, open up cmd and type:
      ipconfig /flushdns

    • jquindlen 11:55 pm on April 23, 2013 Permalink

      To flush your DNS on Windows, open a command prompt (run > cmd) and type: ipconfig /flushdns

    • JAkzam 7:11 pm on May 15, 2013 Permalink

      Hey could someone maybe help me out…I’m a long time WP Developer, but just release our first public Plugin that has been accepted and approved for the WP directory and the SVN.

      I received the email to wait about an hour (it’s been many) and login with this account information.

      But I think I may have screwed up, as I think I have a previous registration on the SVN Repository using this same username. When I log in to the already created account, it says I am not involved in any projects, but the link to the SVN Repository shows my files…

      So what do ya think…should I just be a little more patient?



      p.s. Sorry if this isn’t a good place to ask this question. But I’m a quick learner.

      • Ipstenu (Mika Epstein) 6:41 pm on May 23, 2013 Permalink

        Email plugins AT wordpress.org if you need help with this. Also re-read the email we sent, especially the part where it says to use the WordPress.org login ID and password to get into SVN. 😉

    • Shrinivas 11:02 am on July 28, 2013 Permalink

      My second plugin got approved by WordPress, and I also got SVN repository URL. I checkout out the plugin with Tortoise SVN, copied my plugin files to trunk folder, but when I am trying to commit it, I am getting the following error.

      Commit failed (details follow):
      At least one property change failed; repository is unchanged
      Server sent unexpected return value (400 Bad Request) in response to PROPPATCH
      request for ‘/!svn/txn/747084-g5of’

      am I doing it right? How to solve this issue?

      Here is the my question in support forum https://wordpress.org/support/topic/commit-failed-while-uploading-my-plugin-to-repository?replies=1

  • Andrew Nacin 8:51 pm on May 19, 2012 Permalink |
    Tags: ,   

    Plugin Directory Refreshed — What It Means for Developers 

    Matt just announced on the WordPress Blog — and many of you have already noticed — a number of recent changes to the plugin directory, profiles, and the support forums. Now let’s go into detail all of the individual changes, and what it means for plugin developers.

    Design refresh for plugin pages.

    We’re glad to see so many of you use the plugin headers we launched in December. Now, we’ve provided a further refresh. We’ve made authors much more prominent and with bigger Gravatars and better placement, and cleaned up the styles for the ratings, support, and compatibility sections. There’s a great before-after shot in the announcement post.

    Support is now integrated into your plugin page.

    In the past, creating new support topics for plugins has been special, and not in a particularly good way. It had this specialness by overloading the tags in the support forums to indicate that a thread was about a particular plugin. No longer. We’ve promoted plugins up a notch and given them their own area.

    So now, on your plugin pages, you’ll see a “Support” menu in the header, and you’ll see the topics for that plugin in that tab. You’ll also find a submission form at the bottom of that tab, to add new support topics specifically for your plugin. Topics about plugins made from here get a special sidebar with links to the plugin, to the plugin’s FAQ page, and to the list of Support Threads for that plugin.

    While this section looks like it’s on the Plugin’s page, it’s not really. These support threads are actually in the same place they’ve always been, in the Support forums. What you’re seeing as far as the look and feel of that view of the support forums is just some clever trickery on our part. 🙂

    Akismet, for example, will have it’s “support forums” at this URL: https://wordpress.org/support/plugin/akismet.

    How to follow support threads for your plugins.

    You may want to take advantage of this by subscribing to the RSS feed for your plugin: https://wordpress.org/support/rss/plugin/akismet. Email subscriptions are not available for these yet, but we will be adding them this week.

    For plugin authors who have been using them, the old convenience views of plugin-committers and plugin-contributors are still there as well. (Committers are managed in on the Admin tab, while contributors are taken from readme.txt.) We’ll be exposing these links in more places, but you can use them with URLs similar to the following: https://wordpress.org/support/view/plugin-committer/Otto42 https://wordpress.org/support/view/plugin-contributor/Otto42. (RSS feeds exist for these as well.)

    Support statistics are now shown to users.

    You’ll notice a new area on the plugin page sidebar showing information about how many topics there are for your plugin, and how many of them have been marked as resolved. These are handy for users to see if questions are likely to get a response.

    You have had the ability to mark plugin support threads as resolved for some time now. It’s now really easy — you can mark a thread as resolved while making a post with a simple checkbox. Note that the user who opened the thread can also mark threads as resolved and unresolved. Threads that are marked “Not a support question,” such as suggestions or feedback, are not counted toward these stats and do not need to be marked resolved.

    Statistics will be based on a rolling two-month period, based on when the thread was opened. Currently, the statistics cover threads opened in the last two weeks, and will continue to increase until it reaches two months, to allow you some time to resolve existing threads.

    Managing your forum with sticky topics.

    You can now make threads “sticky”  threads to the top of your plugin’s support forum, just like the other forums on WordPress.org. (You’ll find a link “Stick topic to this plugin’s support forum” in the sidebar.) Threads marked as sticky will show at the top of your plugin’s Support tab. (They won’t be sticky on the regular forums.) We hope you find this handy for posting FAQs or other important information about your plugin.

    A new section for developers.

    Every plugin now has a Developers tab where you can find links for browsing the code in Subversion, the development log, and development versions. Here, you can now subscribe to get an email whenever a commit is made to a plugin repository, even if it isn’t yours. (You will of course continue to receive commits for your own plugins.)

    Favoriting plugins.

    As I’m sure you’ve now seen, plugins can now be favorited by logged-in users — and have been more than 2,000 times since we soft-launched this feature earlier in the week! When you favorite a plugin, it gets added to your profile. And if you’ve also rated that plugin, your rating gets shown.

    We expect to do a lot more with all of this in the future — favorites, plugins, support, and profiles. Until next time, we hope you enjoy these changes as much as we do!

    — written by Nacin, Otto, and Scott

    • Arnan de Gans 5:15 pm on May 21, 2012 Permalink | Log in to Reply

      So i guess you’ve just rendered my own forum useless? Because i don’t want to give my users the impression i ignore support. Which your support stats will suggest if i keep ignoring the WP forums and use my own setup…
      And what’s up with this whole overhaul anyway, pulling visitors away from my plugin page by adding all these features. 🙁

      • Andrew Nacin 10:02 pm on May 21, 2012 Permalink | Log in to Reply

        The plugins directory is a hosting site, not a listing site. Your “plugin page” is https://wordpress.org/extend/plugins/your-plugin/ — while it may provide you traffic to your own site, it’s designed to be a dedicated and trusted area for users. If plugin authors don’t keep up with support topics on WordPress.org, we can no longer glean any statistics, and it is more difficult for users to identify which plugins are supported. I have been really happy to see so many users already benefit from the new tools we are giving developers. That’s a win-win to me.

        We think — and I think you probably agree — that these changes provide a far better experience for individuals looking for help. By choosing to have two support forums, you’ve already fragmented the experience for your users. (I imagine they even need to create a second account to simply provide feedback or ask a question.) Now you are experiencing this same thing for yourself.

        We may consider the ability to specify a location for support in the future, but we’d like to try this out for a while. And at least on WordPress.org, we can also guarantee your users will be greeted with the proper spelling of WordPress. 😉

        • Jon Brown 4:20 am on May 22, 2012 Permalink | Log in to Reply

          Nacin – While that seems sensible on the surface, many plugins don’t lend themselves to a single forum for support and plugin author’s who’ve built forums with multiple topics…

          For example I note that both BuddyPress and bbPress link out to their own forums…. as they should since trying to answer the myriad of support requests under a single tag would be a nightmare. I am not a plugin author (yet), but I feel all plugin authors ought to have this same option available to them to link to their own support location.

          Further there is still no good easy way (that I know of) to search a single plugin’s forum to see if a topic has been mentioned and resolved previously which is what has always rendered the forums on WordPress.org minimally useful to me.

      • Marcus 12:24 pm on May 22, 2012 Permalink | Log in to Reply

        would definitely like this. tried resolving topics myself yesterday, not really up for it 🙂

        Touching on Arnan’s comment above, I must admit I do feel the same way somewhat. Whilst I do value being able to support on WP and agree that ideally (but may not be realistic) support should be on wp.org, I don’t think statistics is a productive feature, at least as it stands right now.

        Constructive criticism below:

        Take my (the author’s) point of view and my plugin – https://wordpress.org/extend/plugins/events-manager/

        The wp support forum is usually visited at least once a day during the week. I myself go through this plugin support forum every weekday when possible, yet as it stands right now the stats are:

        15 of 84 support threads in the last three weeks have been resolved.

        However, look at the forum, and you’ll see they’ve pretty much all been answered by me or angelonwl.

        There’s a few issues here right off the bat:

        • Various questions get resolved by the opener somehow, but the topic never gets updated.
        • Some things are just unreasonable to ask from the author (i.e. how do I completely change this plugin to do what I want?), yet they count as an unresolved question.
        • Various questions aren’t support questions.

        I’m sure there’s more, but the above is already enough to, in my opinion, make this a misleading bit of information.

        As an author, I’m now expected to keep track of 3 weeks of questions, and resolve them proactively, since <50% (way less) of users will update tickets when they resolve things themselves. What's worse, contributors can't help out. I think this is unreasonable, and whilst I don't mind making do, I think this will decrease the overall experience in WP, with some immediate downfalls:

        • Good plugins will likely get misleading support stats.
        • This will likely dishearten many authors, meaning less quality plugins being made for WP.
        • I’m sure you’ll see on the forum a “hey my issue isnt’ resolved!” because it’ll become tempted to resolve every topic one answers.

        I think the most important thing for you to implement to make this work would be some sort of auto-approve or nullify tickets that the creator doesn’t keep on top of (e.g. it becomes not a support question if the author doesn’t reply to our reply in say a week). Or maybe a response rate?

        Don’t even get me started on the works/doesn’t work stats too! 😉

        • Marcus 12:30 pm on May 22, 2012 Permalink | Log in to Reply

          by “would definitely like THIS”, i meant letting contributors be able to resolve tickets

        • Marcel 9:00 am on January 12, 2013 Permalink | Log in to Reply

          +1 for including response rate statistic. Many support requests cannot be resolved because users ask for functionality that the plugin does not, or never will, offer. A state like ’10 of 12 support threads answered by plugin contributor’ would give users a better insight in plugin contributors involvement.

    • Marcus 5:30 pm on May 21, 2012 Permalink | Log in to Reply

      Great work guys! The plugin page keeps looking better and better.

      Who can ‘resolve’ topics, by that I mean committers, contributors etc. of a plugin?

      Is there a way to add users that aren’t committers/contributors so topics can be resolved?

      • Andrew Nacin 6:41 pm on May 21, 2012 Permalink | Log in to Reply

        Committers can resolve topics. At the moment, there isn’t a way to grant someone permission to resolve topics without making them a committer. It might be something we add in the future.

    • Joost de Valk 6:37 pm on May 21, 2012 Permalink | Log in to Reply

      Awesome guys, thanks for all the hard work!

    • ray 8:57 pm on May 21, 2012 Permalink | Log in to Reply

      I’m looking for a like button on this page… thanks

    • Jason Caldwell 12:51 am on May 22, 2012 Permalink | Log in to Reply

      Just wanted to say thanks for the recent changes to the plugin directory, profiles, and the support forums. Great work over there!

      I do want to make a request though. PLEASE give plugin developers the ability to use their own external support forums. That is, please make it possible (perhaps through a readme.txt file), for developers to use an external support forum system of their own.

      Many of the best plugins thrive on support, and you can’t expect us to operate our support departments within an outline set forth by WordPress.org. That is, we can’t be expected to use the support system that WordPress.org uses (we need to use what works for us).

      I, like many other plugin developers, have my own administrative system, support forum system, along with employees to assist me. As the plugin directory exists now, all support is expected to take place at WordPress.org, which is just not realistic. This is only going to result in people getting the wrong impression about plugins in your directory, because they’re looking for (and expecting) support from the forums at WordPress.org. When, in reality, the support for many plugins occurs offsite. Let’s give plugin developers the ability to direct WordPress site owners to the proper location.

    • Myatu 6:40 am on May 22, 2012 Permalink | Log in to Reply

      Couple things…

      Is there a way to see how many people have actually marked a plugin as their favorite, and optionally, who?

      Also, I’d really like to see the email subscriptions for support threads back again, the sooner the better.

      As for support itself goes, that needs some work with respect to what the plugin developer wants (better said, can do). I can understand your point about the consistency in user experience across WordPress plugins and an ability to measure plugin quality, but at the same time, what if a plugin developer would like – or already uses – a ticket system, provides phone support, use their own forum or simply use good ‘ol email, then what? There’s currently no method to integrate that with WordPress.org’s plugin listings, nor do they count toward the quality measurements.

      Something to consider perhaps, is improve the way users can vote on a plugin. More often than not, people do not vote. They install, and use it. Don’t like it, uninstall. That’s it. So, if a user uninstalls, why not ask them “Why are you uninstalling this plugin?” – plugin developers and the community could do with that sort of feedback. And voting from within the WordPress plugins page would be another option, though some care has to be taken to avoid someone using a “bot” on that (which is detectable, and could perhaps be reason for removal).

    • Mike Challis 6:14 pm on May 25, 2012 Permalink | Log in to Reply

      As a plugin author, I now have the ability to make a sticky post. Thanks.
      But after 10 minutes(or 20 or whatever) I have no ability to edit any of my posts. A sticky post is not very useful if I will not be able to edit it later if needed. Please give plugin authors the ability to edit their own posts.

    • Ipstenu 8:16 pm on May 25, 2012 Permalink | Log in to Reply

      Forum mod hat 😉

      The support forums have always been there for plugins, whether or not you used them. So this does make them more prominent, but for now if you don’t want to use them (and you certainly dont have to) I would do this:

      1) Put a link to your support location in your readme. No support at all? Just say that too 🙂
      2) Make a sticky ‘This plugin not supported on these forums.’ And inside, a link to where it is.

      No, it’s not perfect, but when the mods come through and clean up snark like ‘Bob’s a bad dev! He doesn’t help me!’ we can say ‘Well, actually, RTFM. Bob said to go to bobplugins.com instead.’

    • zorro1965 4:32 am on December 14, 2012 Permalink | Log in to Reply

      I have been so waiting for this to become a feature. So much easier then trying to keep a place where you have all these plugin details archived.

      Being able to access these in the backend after you have them marked is HUGE…!

      Now I only have a few suggestions for future.

      1. Allow the member to have ability to create their own categories for favorites to help quickly sort through what you need for a kind of site you are working on or group them for other reasons.

      2. Have a different view choices to see excerpt of description, last updated, ratings, # downloads

      Thanks very much,


  • Andrew Nacin 5:21 am on May 11, 2012 Permalink |
    Tags: trademarks   

    The WordPress trademark and domain names 

    A friendly reminder to plugin authors: Per the WordPress trademark policy, do not use “wordpress” in your domain name. We have been actively notifying developers that reference such domains in readme files or plugin headers. If you are violating the trademark, please update your plugins. Your next step should be to switch to another domain.

    As our page on wordpress.org says, “We see this most frequently with spammy sites distributing plugins and themes with malware in them, which you probably don’t want to be associated with.”

  • Andrew Nacin 5:06 am on May 11, 2012 Permalink |

    Plugin licensing: GPLv3 is now accepted 

    Cross-posted from the main development blog:

    The plugin directory’s licensing guidelines have been updated. The guidelines will now allow code that is licensed under (or compatible with) version 3 of the GPL.

    The guidelines still encourage use of “GPLv2 or later,” the same license as WordPress. However, we understand that many open source libraries use other licenses that are nonetheless compatible, such as GPLv2 only, GPLv3, and Apache 2.0.

    Now may be a good time for plugin authors to review their plugins to ensure a license is specified. You can add License and License URI headers to readme.txt and the plugin’s headers. (You may also wish to include a copying permission statement.) For example:

    License: GPLv2 or later
    License URI: http://www.gnu.org/licenses/gpl-2.0.html

    You can see this used in the sample readme.txt.

    This change brings the guidelines in line with the themes directory, which has for some time accepted GPLv3-compatible code. (Probably a good time to note that Creative Commons licenses are still incompatible with the GPL, and the theme and plugin directories.)

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
Skip to toolbar