WordPress.org

Ready to get started?Download WordPress

Make WordPress Plugins

Tagged: directory Toggle Comment Threads | Keyboard Shortcuts

  • Samuel Wood (Otto) 6:12 pm on June 9, 2012 Permalink | Log in to leave a Comment
    Tags: directory, plugin, readme, repository, svn   

    The Plugins directory and readme.txt files 

    Every once in a while, somebody pings me to say that their plugin isn’t showing up properly in the directory. Almost always it’s a problem with the plugin itself having incorrect information somehow. So I thought I’d do a quick post to explain some aspects of the plugin directory, and explain some of the more obvious stuff which a lot of people miss.

    Layout

    First, let’s briefly go over the layout of your plugin in the SVN repository. There’s three directories created by default, and an optional fourth one that you can create yourself.

    Trunk: The /trunk directory is where your plugin code should live. The trunk can be considered to be the latest and greatest code. It’s the development version. Hopefully, the code in trunk should always be working code, but it may be buggy from time to time because it’s not necessarily the “stable” version. For simple plugins, the trunk may be the only version of the code that exists, and that’s fine as well.

    Tags: The /tags directory is where you can put versions of the plugin at some specific point in time. Usually, you’ll use version numbers for the subdirectories here. So version 1.0 of the plugin would be in /tags/1.0, version 1.1 would be in /tags/1.1, and so forth. Again, not every plugin uses tags for versioning.

    Branches: The /branches directory is a place that you can use to store branches of the plugin. Perhaps versions that are in development, or test code, etc. The WordPress.org system does not use the branches directory for anything at all, it’s considered to be strictly for developers to use as they need it.

    Assets: The last optional directory doesn’t exist by default (Edit: It does now, older plugins may be missing it, but all newly added plugins will get it by default.) You can create it yourself though. Just make a directory called “assets” next to those other three directories. Assets currently only has one use, which is to store the banner image to be displayed on your plugin page. We may use it for more things in the future. For now, you can just make an image, name it banner-772x250.png or banner-772x250.jpg, and put it in there. Easy.

    Additional Info: Since creating this post, some new files have been added to the assets folder. You can create a banner-1544x500.png or banner-1544x500.jpg now too. This high-resolution banner will be shown to users with high-resolution displays, such as phones or tablets or certain newer laptops. Additionally, screenshots which once lived in the plugin’s own directory can now be moved from there into the assets directory. This allows the screenshots to be shown on the plugin page, but not included in the download of the plugin, reducing file size. It’s recommended to put screenshot files in /assets.

    Parsing the plugin information

    All plugins contain a main PHP file, and almost all plugins have a readme.txt file as well. The readme.txt file is intended to be written using a subset of markdown.  The example readme.txt explains most everything pretty well, but there’s a few little tidbits that are worth pointing out.

    First is the concept of the “Stable Tag”. When WordPress.org parses the readme.txt, the very first thing it does is to look at the readme.txt in the /trunk directory, and then read that “Stable Tag” line. If the Stable Tag is missing, or is set to “trunk”, then the version of the plugin in /trunk is considered to be the stable version. If the Stable Tag is set to anything else, then it will go and look in /tags/ for the referenced version. So a Stable Tag of “1.2.3″ will make it look for /tags/1.2.3/.

    Important bit: Everything else is read from this new location. If the Stable Tag is 1.2.3 and /tags/1.2.3/ exists, then nothing in trunk will be read any further for parsing by any part of the system. If you try to change the description of the plugin in /trunk/readme.txt, and Stable Tag isn’t trunk, then your changes won’t do anything on your plugin page. Everything comes from the readme.txt in the file being pointed to by the Stable Tag.

    Now let’s get to the plugin information itself. The WordPress.org directory reads the main plugin PHP file to get things like the Name of the plugin, the Plugin URI, and most importantly, the version number. On the plugin page, you’ll see the download button which reads “Download Version 1.2.3″ or similar. That version number comes from the plugin’s main PHP file.

    Some people get this versoning confused due to the tags system. The Stable Tag points to a subdirectory in the /tags directory. But the version of the plugin is not actually that, it’s the version that is listed in the plugin’s PHP file itself. If you have changed Stable Tag to 1.4 and the plugin still says 1.3 in the PHP file, then the version listed will be 1.3.

    Readme.txt pieces that everybody gets wrong

    Back to the readme.txt. There’s a line called “Contributors”. This line has always been expected to be WordPress.org usernames only. WordPress reads those, gets information about that user, gets their gravatar, name, etc, and makes the authors listing. If you put anything here that’s not a WordPress.org username, then it doesn’t look nearly as good. No picture, no link, just text.

    Other information in the readme.txt is read and used at various points on the Plugin listing. The Donate link makes a “Donate to this plugin” link in the sidebar. The “Requires at least” and “Tested up to” fields are used for compatibility checking, even on the WordPress installation itself. Few people get these wrong.

    One thing a lot of people get wrong is this line:
    “Here is a short description of the plugin.  This should be no more than 150 characters.  No markup here.”

    That bit is serious, and you should read it again. That one line people get wrong more often than anything else. That line of text is the single line description of the plugin which shows up in big letters right under the plugin name, and if it’s longer than 150 characters, it gets cutoff and makes your plugin page look silly.

    Markdown allows for easy linking in your readme.txt as well. Just write like this to link a word to a URL:

    [WordPress](http://wordpress.org)

    Videos can be put into your readme.txt too. A YouTube or Vimeo link on a line by itself will be auto-embedded. It’s also possible to embed videos hosted on VideoPress using the wpvideo shortcode. More on that topic here: http://wpdevel.wordpress.com/2010/02/20/plugins-can-now-include-videos-in-their-readme-txt-files/

    Summary

    I don’t think I covered everything, but hopefully that will explain some of the more obscure features of the directory and how it works. If it reduces the number of times people send me the question “why didn’t my version change show up in the directory”, then I think this post was time well spent. :)

     
    • Marcus 7:32 am on June 10, 2012 Permalink | Log in to Reply

      I must admit, I’ve made one or two of these mistakes starting off :)

      Useful article, it would go great linked somewhere in the developer center, as I’m sure that’s where people starting would look first.

    • Lance Cleveland 2:37 pm on July 12, 2012 Permalink | Log in to Reply

      Don’t forget about the new “high definition” banners for the header image. If memory serves this is twice the resolution of the standard banner in the assets directory at 1444×500.

    • Mike Schinkel 7:16 pm on August 3, 2012 Permalink | Log in to Reply

      Just replying so I can get subscribed to this blog (might be another way, but can’t figure out how.)

    • Brad Touesnard 3:53 pm on August 17, 2012 Permalink | Log in to Reply

      @Otto Would it be possible to start supporting the filename README.md in addition to readme.txt? A lot of developers host their plugins on GitHub as well but the filename readme.txt isn’t run through the markdown parser at GitHub. It would be nice if .org supported the README.md filename as well.

    • Gwyneth Llewelyn 10:12 pm on November 18, 2012 Permalink | Log in to Reply

      Ok, I’m a bit confused now.

      “If the Stable Tag is 1.2.3 and /tags/1.2.3/ exists, then nothing in trunk will be read any further for parsing by any part of the system. If you try to change the description of the plugin in /trunk/readme.txt, and Stable Tag isn’t trunk, then your changes won’t do anything on your plugin page. Everything comes from the readme.txt in the file being pointed to by the Stable Tag.”

      So if I understand this correctly, the best way to deal with this scheme is simply to have a single file under /trunk/, which is readme.txt, and that needs only to hold 9-10 lines or so with the headers — and just point to the “Stable Tag”? Then the *rest* of the readme.txt *which is under the tag, not trunk* will be read & parsed instead? I don’t need to have a full copy of readme.txt both under /trunk/ *and* /tags/X.Y.Z/ ?

      You see, I hate unnecessary file duplication :) I love the idea of having a super-small, 9-line only, readme.txt file under /trunk/ which just points to the correct place. Also, it makes this far easier to revert to earlier versions in case something goes seriously wrong!

      Sorry if all of this sounds incredible obvious to you seasoned plugin developers :)

      • Gwyneth Llewelyn 10:44 pm on November 18, 2012 Permalink | Log in to Reply

        Maybe all that’s needed on trunk/readme.txt is 2 lines after all:

        === Plugin Name ===
        Stable tag: X.Y.Z

        Is that right? The remaining readme.txt will come from tags/X.Y.Z instead? If so, this is just awesome!

      • Samuel Wood (Otto) 4:38 am on November 19, 2012 Permalink | Log in to Reply

        Yes, that works.

        No, you absolutely should not do it that way.

        There is a *convention* in place here. People expect trunk to contain the latest development code of your plugin. In other words, the latest and greatest code, unstable changes and all, belongs in trunk. The latest stable, versioned, tagged code, will be in a tags directory.

        The directory is based around this concept. There are beta-tester plugins which assume this to be true. Forget about “duplicated files”, do it the way everybody else does it so that you don’t mess up the friggin’ system. :)

        Put your development code in trunk. Tag the ready-for-release versions of the code in the tags directory. This is the best way to manage things. Even repository systems such as git and github have the concept of a main trunk for development and tags for versioning. The goal isn’t to make things easier for you to manage, the goal is to make the code accessible to everybody else in a sane way.

        • Gwyneth Llewelyn 4:42 pm on November 19, 2012 Permalink | Log in to Reply

          Thanks for the clarification and I do apologise if I have understood you wrongly. Maybe you should clarify that duplication of everything continues to be mandatory, and not optional, to stick to conventions. Your article, read in a certain light, seemed to convey the idea that the convention was changed exactly for the benefit of keeping things simple.

          I’m not here to discuss what is better and what is not — I’ve just asked the question on how to do things from now on because the article lead to believe me that the convention had changed, or, if it hadn’t, that “beginners were always making mistakes and can do things in much simpler ways if they understand the directory structure better”. And I appreciate your answer: no, nothing has changed.

          “The goal isn’t to make things easier for you to manage”. Why not? KISS is always a good philosophy, IMHO.

          • Samuel Wood (Otto) 4:59 pm on November 19, 2012 Permalink | Log in to Reply

            It’s not really duplication though. SVN doesn’t store files that way, it really just stores changesets. The trunk/tags/branches convention is SVN’s, not ours. You can tag things using an svn copy operation, and that’s not making new files in svn, just marking copies of the files at a specific point in time.

            The Stable Tag and readme.txt stuff is indeed ours, simply for the purpose of keeping things in the directory sane.

    • brasofilo 2:08 pm on December 18, 2012 Permalink | Log in to Reply

      Finally I got the /tags/ concept and am correcting a wrongful use of the “Stable Tag” (I had it declared, but the version was not present in the tags folder), although the system was kind enough to make it work.

      Now, I’m looking for articles on how to use the /trunk/ when developing a new version of the plugin.
      I mean, is it possible to install and update from there?

      • Samuel Wood (Otto) 5:56 pm on December 18, 2012 Permalink | Log in to Reply

        Trunk should be the “beta” version, and have its version numbers indicating such. So if my Stable Tag was like 1.0, and I had a /tags/1.0 directory, then I could make trunk’s version into 1.1-beta or something like that, and make all the changes I liked, then when it was ready for release, change it to 1.1 and tag it and update the Stable Tag field in the readme.txt to point to the new one.

        If you use this sort of structure, with trunk containing the latest beta code, then you can easily use a plugin like http://wordpress.org/extend/plugins/plugin-beta-tester/ to update to that beta version on a site.

        • brasofilo 7:29 pm on December 18, 2012 Permalink | Log in to Reply

          Perfecto, Otto, gracias!

        • Hinjiriyo 1:56 pm on January 31, 2014 Permalink | Log in to Reply

          Now I got the concept of the trunk dir! Thank you very much for your explanation.

          There are other informations about the way the readme file and tag files are processed by the WP plugin repo. I wish someone would extend the Plugin Developer FAQ with that article and the role of the trunk.

    • amineoujda 10:09 am on July 16, 2013 Permalink | Log in to Reply

      Hi,
      I want to change the line description that appears below the plugin name

    • bendoh 4:44 pm on January 22, 2014 Permalink | Log in to Reply

      Hey,

      Is there any sort of documentation as to the exact subset of Markdown that’s being used on these readme.txt files, or could you perhaps point me to the code that’s actually producing the rendered markup?

      I just submitted a plugin with standard Markdown list formatting, (e.g., * Item 1\n*Item 1) in the readme.txt, and it was not rendered correctly on the plugin page: it just appeared all together in one paragraph without any markup.

    • duck__boy 9:32 am on April 14, 2014 Permalink | Log in to Reply

      A very will written post, but I must admit, I’m still struggling with the `readme.txt` file. I suspect I’m just missing something, but I’m hoping you are able to help.

      I have both a version of my plugin with the `readme.txt` file, in the `/trunk` and `/tag/1.2.4` folders, but none of the details from `readme.txt` seem to be read, including the Stable Tag. This also means that the `Installation`, `FAQ` and `Changelog` sections are not available on the plugins `Details` page).

      So taking the above in to account, if I change the version number of the main PHP file in `/trunk` to say `1.3-beta`, that version number is shown when you search for my plugin, and my `/tag/1.2.4` file is ignored.

      The plugin in question is http://wordpress.org/plugins/admin-bar-button/

  • Andrew Nacin 8:51 pm on May 19, 2012 Permalink | Log in to leave a Comment
    Tags: directory, favorites, support   

    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: http://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: http://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: http://wordpress.org/support/view/plugin-committer/Otto42 http://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

      Seriously?
      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. :(
      *sigh*

      • 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 http://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 – http://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,

      Zorro………

c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel