WordPress.org

Ready to get started?Download WordPress

Make WordPress Core

Tagged: plugins Toggle Comment Threads | Keyboard Shortcuts

  • Ryan McCue 2:12 am on April 14, 2014 Permalink | Log in to leave a Comment
    Tags: , , plugins, symlinks   

    Symlinked Plugins in WordPress 3.9 

    One of the cool little features included with 3.9 is the ability to symlink plugin directories. While it has been possible to symlink plugins in the past, functions such as plugins_url() return the wrong URL, which causes breakage in most plugins.

    In #16953, r27158 and the followup r27999, we corrected this with the help of a new function: wp_register_plugin_realpath(). This function is called automatically during the plugin loading phase, and registers which plugin directories are symlinked, and where they’re symlinked to. This functionality is then used by plugin_basename() (the core of plugins_url(), along with other
    functions) to reverse symlinks and find the correct plugin directory.

    This enhancement means that you can symlink individual plugin directories, or even the whole plugins directory itself.

    For anyone who’d like to use this, keep in mind that there are a few caveats:

    • Single-file plugins are not handled by this code. Any plugins you’d like to symlink must be in subdirectories of the main plugins folder. This restriction is due to the way these paths are registered.

      You can still symlink single-file plugins, however any use of plugin_basename() will be as broken as it was before 3.9. This is not a huge issue, as the main use of this is in plugins_url(), which is not frequently used in single-file plugins.

    • Must-use plugins cannot be symlinked. For the same reasons as single-file plugins, mu-plugins are not handled.

      For anyone using the common pattern of subdirectories within mu-plugins with a common loader file, you can use wp_register_plugin_realpath() directly to ensure that your subdirectories are handled.

      The following example code demonstrates how to use the function:

      <?php
      $plugins = array(
      	'my-mu-plugin/my-mu-plugin.php',
      );
      foreach ( $plugins as $plugin ) {
      	$path = dirname( __FILE__ ) . '/' . $plugin;
      
      	// Add this line to ensure mu-plugins subdirectories can be symlinked
      	wp_register_plugin_realpath( $path );
      
      	include $path;
      }
      

      Hopefully this change is as helpful for you as it was for me! One of the great advantages to this is that plugin developers can keep their plugin separate from their WordPress installation. This is a boon for developers with multiple installs who want to test compatibility; keep in mind that you can symlink the entire plugins directory if you're testing multiple!

      If you have any questions about this, please leave a comment on this post and we'll be happy to help you out!

     
    • PeterRKnight 2:29 am on April 14, 2014 Permalink | Log in to Reply

      This is super handy

    • Mike Schinkel 4:25 am on April 14, 2014 Permalink | Log in to Reply

      Kudos Ryan for pushing that feature through.

    • Julien 6:50 am on April 14, 2014 Permalink | Log in to Reply

      That’s great news! Thanks!

    • Fab1en 7:36 am on April 14, 2014 Permalink | Log in to Reply

      Thanks for this Ryan !
      I was using a custom plugin that tweaked `plugin_basename` to make it work with symlinked plugins. Thanks to you, I will not need this plugin anymore !

    • klihelp 12:37 pm on April 14, 2014 Permalink | Log in to Reply

      Thanks for the post.

      >> This is a boon for developers with multiple installs who want to test compatibility
      Tell me more about this.
      Could I read as a multiple WP installs uses the same plugin directory, so you don’t have multiple copies of the plugins?

      • Fab1en 3:42 pm on April 15, 2014 Permalink | Log in to Reply

        yes, that is what you can read ! Just add a symlink to a shared plugins directory in each WP install wp-content folder, and your installs will share the same plugins copy.

    • hinnerk 3:06 pm on April 14, 2014 Permalink | Log in to Reply

      Thanks a lot! Great enhancement! Makes my developer live much easier!

    • Frank 3:18 pm on April 14, 2014 Permalink | Log in to Reply

      Really useful, reduce the custom work.

    • Brian Layman 3:44 pm on April 14, 2014 Permalink | Log in to Reply

      This is a neat little thing. We’d experimented with symlinking the files back in b5media days with our 350ish sites, but there were enough little oddities to make it not the right choice for a poor man’s MU option.

    • Primoz Cigler 5:33 pm on April 14, 2014 Permalink | Log in to Reply

      Very important and useful update. But I have a question: is something like this possible with the themes as well? Would make perfect sense for the same reason, if you are a theme developer: “One of the great advantages to this is that theme developers could keep their theme separate from their WordPress installation. This is a boon for developers with multiple installs who want to test compatibility; keep in mind that you could symlink the entire themes directory if you’re testing multiple!”

    • Primoz Cigler 5:34 pm on April 14, 2014 Permalink | Log in to Reply

      This is very important and useful update. But I wonder if something similar would be possible with the themes too? For the same obvious reasons as for plugins.

    • hinnerk 7:25 am on April 15, 2014 Permalink | Log in to Reply

      I had to add Options +FollowSymLinks to my .htaccess in order to remove a 403 Forbidden on all pages (using symlinks in plugins directory).

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

      I had to add Options +FollowSymLinks to my .htaccess to remove a 403 Forbidden on all pages (using symlinks in /wp-content/plugins/).

    • Todd Lahman 8:45 am on April 15, 2014 Permalink | Log in to Reply

      This is totally awesome!

  • Jen Mylo 10:44 pm on August 18, 2012 Permalink
    Tags: , , plugins   

    In the better late than never category: notes about plugins from core team meetup in December! http://make.wordpress.org/plugins/2012/08/18/93/

     
  • Andrew Ozz 3:50 am on August 11, 2012 Permalink
    Tags: plugins   

    A bunch of unused images were removed from core in changeset 21498. Several of them were background gradients that were replaced with CSS 3 gradients. The rest have been unused in core for few releases.

    However there are some plugins that use a few of these images and would need updating. Best thing to do would be to copy the images locally as that makes a plugin independent from core changes. If the images were gradients, best would be to use CSS 3 gradients (example).

     
  • Andrew Nacin 3:33 pm on May 21, 2012 Permalink
    Tags: , plugins   

    On Saturday, Matt posted to the WordPress Blog that the plugin directory has been refreshed.

    Also also posted to our new P2 at make.wordpress.org/plugins: what this means for developers. @otto42, @coffee2code, and I go through the changes in detail. They include:

    • The new Developers and Support tabs for plugins
    • Subscribing to commit emails (Hint: see the Developers tab)
    • Following and managing support threads
    • How the new support statics are calculated

    (Sidebar: We hope to use make.wordpress.org/plugins for announcements and resources for plugin developers. This blog will also move to make.wordpress.org soon. More to come.)

     
  • Andrew Nacin 2:57 am on June 22, 2011 Permalink
    Tags: plugins, ,   

    Plugin committers now receive svn notify emails with every commit to their plugin. This is something we’ve been planning to do to assist with collaboration, but we added it today without extra things like being able to sign up for other plugins. (Look for that soon, though.)

    And not to sound like the PA in a subway or at an airport, but if you see something, say something. Say things to security@wordpress.org.

     
  • Andrew Nacin 12:10 am on June 22, 2011 Permalink
    Tags: plugins, ,   

    Commit access has been restored for plugins. If you get a 403 error, you need to go reset your password. Please, to something new.

     
  • Samuel Wood (Otto) 10:18 pm on December 22, 2010 Permalink
    Tags: , plugins,   

    It was pointed out to me that I never mentioned it anywhere when I made this change last month, but the plugin search engine at http://wordpress.org/extend/plugins/ has been much improved. So now when you search for things like “buddypress”, you should get what you’re looking for on the first page of results more often.

    It was a minor adjustment, so it didn’t occur to me to tell anybody. Sorry about that. :)

     
    • Valentinas 10:45 pm on December 22, 2010 Permalink | Log in to Reply

      Well try to search for ad-minister. Other search strings to test: wp-e-commerce, wp-ad-manager, basically anything that has wp prefix will produce the same search results. And you know there’s plenty of plugins with that prefix.

      • Otto 10:58 pm on December 22, 2010 Permalink | Log in to Reply

        The search engine treats dashes as search operators. Meaning foo-bar searches for items containg foo but NOT bar.

        Leave out the dashes when searching, for now.

        • Jane Wells 5:03 am on December 23, 2010 Permalink | Log in to Reply

          Maybe drop a text instruction to that effect on the plugins search page? People search for wp e-commerce all the time.

        • Otto 12:25 pm on December 23, 2010 Permalink | Log in to Reply

          Jane: I was planning on just fixing it so it didn’t do that, actually. Nacin’s idea was the same one I was planning on implementing.

        • Otto 1:05 pm on December 23, 2010 Permalink | Log in to Reply

          Done. Hyphens now get escaped properly for the search when they don’t have spaces around them. So “e-commerce” will actually search for that as a word instead of considering it to be a control character. You can still use a hyphen in front of a word for exclusion, as long as it doesn’t have some other word character in front of the hyphen.

      • Andrew Nacin 12:03 am on December 23, 2010 Permalink | Log in to Reply

        We can probably make it convert hyphens into spaces if the hyphen isn’t preceded by a space. I’ll check it out.

    • Bill Erickson 12:49 am on December 23, 2010 Permalink | Log in to Reply

      When I search for Contact Form 7, the plugin shows up on the second page, even though I search for its exact name. This has been bugging me for about a month :)

      • Otto 1:47 am on December 23, 2010 Permalink | Log in to Reply

        Yep. But, that’s a pretty generic title too. I didn’t say it was perfect, just better. :)

        • Jane Wells 5:03 am on December 23, 2010 Permalink | Log in to Reply

          Actually, I think it used to come up as one of the first results, so for that one it looks like a loss. There are a couple I can’t find by searching now. What was changed to the search/what’s it searching now? If there are things we can do to the plugin metadata or readme files or whatever to make them more findable with the new search, we can publicize it.

        • Otto 12:29 pm on December 23, 2010 Permalink | Log in to Reply

          Basically, I added extra weighting to the title, gave the tags a bit more weight, and turned on the “extended” matching mode, which makes it actually use the weights. Before it was in a simple text-only keyword search mode, which didn’t use any relevance or closeness matching at all.

          The thing is that “Contact Form” is a fairly generic name, and while it does give the title a lot of boosting, every single one of the results on the first two pages has “Contact Form” in its title.

        • Sergey Biryukov 3:25 pm on December 23, 2010 Permalink | Log in to Reply

          Perhaps if there’s an exact match, it can go first?

      • Valentinas 10:37 pm on December 23, 2010 Permalink | Log in to Reply

        Yes, I wanted suggest the same as Sergey, exact match should definitely be the first.

        • Otto 10:52 pm on December 23, 2010 Permalink | Log in to Reply

          Well, that’s not the easiest thing to do in the world. The question is what do you define as an exact match?

          The Sphinx search engine works based on phrase matching. Now, in the particular case of “Contact Form 7″, the 7 is pretty much being ignored because it’s too short. So we’re really talking about “Contact Form” here. Note that it doesn’t much matter even if we were talking about the full “Contact Form 7″ because several of the other plugins above it also have “Contact Form 7″ in their titles as well.

          And that’s the trick. The whole thing is based on a weighting algorithim. I gave titles a lot of weight specifically in order to push title matches up to the top, but in this case, all the ones that show up in the top 20 results have “Contact Form” in their titles. Several of them have “Contact Form 7″ in their titles as well, because they’re addons to it or what have you. So how is the search really supposed to know that “Contact Form 7″ is more important than “Contact Form 7 Addon”? Sphinx doesn’t give extra weight to “whole” titles.

          I also give a bit of extra weight to tags, which is probably why some of those are coming up a bit higher than others. The relevance scores are all pretty close right there.

          Basically, doing exact whole-phrase matches in Sphinx is kind of a hacky PITA, involving adding extra data to the database using delimiters for before and after and such. I’d prefer to get the 90% solution where people are searching for keywords and titles and having it get close-enough rather than adding a ton of extra data just to cover that one particular case. Especially when the case involves a really generic title like “Contact Form”.

          So Protip for code authors: Come up with a unique name to be listed higher in searches. This is not specific to our search engine.

        • Matt 10:57 pm on December 23, 2010 Permalink | Log in to Reply

          We’re not really discussing matching, but ranking. I think it’s fair to, given the results that Sphinx returns, re-order based on a metric like popularity or bump exact match (search == title) to the top.

        • Otto 10:59 pm on December 23, 2010 Permalink | Log in to Reply

          Popularity ordering is already there if somebody wants to use it: http://wordpress.org/extend/plugins/search.php?q=Contact+Form+7&sort=popular

        • Matt 11:01 pm on December 23, 2010 Permalink | Log in to Reply

          I guess it’s odd to me that popularity and rating are not part of relevance — if you think outside of the strict-matching sense of relevance, they’re all really one and the same. Whichever provides the best results to the most people should just be the default.

        • Otto 11:11 pm on December 23, 2010 Permalink | Log in to Reply

          Ordering by rating is already there too: http://wordpress.org/extend/plugins/search.php?q=Contact+Form+7&sort=top-rated

          But I find the other side of this odd, really. It doesn’t make a whole lot of sense to me that popularity and rating have anything to do with relevance. Relevance is really more a measure of how well the plugin’s description/name/tags/whatever fits the keywords/phrase you’re searching for. In other words, relevance is about the plugin itself and your search query, not about user-generated meta data about the plugin like popularity or ratings.

          Could we include rating and popularity as a metric? Probably, but I’d have to investigate Sphinx in more depth. Those fields are not stored in the Sphinx database right now for sure, so it can’t include them in the relevance matching algorithm.

        • Otto 11:14 pm on December 23, 2010 Permalink | Log in to Reply

          Scratch that, they are in there (rating and downloads over the last week), so they can be used. I’ll do some testing, see if it makes any difference.

        • Matt 11:16 pm on December 23, 2010 Permalink | Log in to Reply

          I don’t think most people think of relevance that way. The core bug is you type in the name of one of the top ten most used plugins in the world and it doesn’t come up in the first page.

          Type “akismet” and Akismet is #5.

          Type “stats” and you see a page with 2 results, and 40 pages. (The counting/paging bug mentioned.)

          My goal is to not give people multiple ranking options for the plugin search, just to have one that always gives you the results you’re looking for.

        • Otto 11:19 pm on December 23, 2010 Permalink | Log in to Reply

          Yes, but everything is a tradeoff. At what cost do we bump more popular plugins? The cost is that less popular, but possibly better or more useful, plugins get bumped down.

          Moving exact whole-title matches to the top is one thing (technically tricky, actually, but doable), but counting popularity and rating in seems different to me.

        • Andy Skelton 11:25 pm on December 23, 2010 Permalink | Log in to Reply

          Stats and Akismet are good test cases. Almost any plugin can legitimately use the word “stats” in its description and many could reference Akismet, but a title including such words indicates extreme relevance. Titles are always more relevant than descriptions.

        • Otto 11:27 pm on December 23, 2010 Permalink | Log in to Reply

          This is the problem with generic phrases. “stats” has 591 results over 74 pages, and the first several dozen (at least) have the word “stats” in their titles.

          I’m doing more testing/tweaking to it now.

        • Otto 11:29 pm on December 23, 2010 Permalink | Log in to Reply

          Also, the title of the plugin is actually “WordPress.com Stats”, so an exact matching check wouldn’t help it out there for “stats” anyway. Slugs are not included in the search system at all.

        • Otto 12:13 am on December 24, 2010 Permalink | Log in to Reply

          Still looking at how to bump an exact title match to the top (this requires bypassing the search engine results to make it work), but after looking at the weights, I can at least tell you some specifics of why you see the results you see.

          Akismet is 5th because the other 4 above it include “Akismet” as a tag. So they get bumped for that.

          WordPress.com Stats: Same problem. The ones above it have tags with “stats” in them.

        • Andy Skelton 1:19 am on December 24, 2010 Permalink | Log in to Reply

          WordPress.com Stats has “stats” as a tag.

        • Valentinas 3:33 am on December 24, 2010 Permalink | Log in to Reply

          Some thought on why akismet should be first:

          Download count (maybe take into account how many copies were downloaded recently). So up to 10.000 downloads – 0%, 10k-100k: 0.1%, 100k-1m: 1%, 1M-10M: 10% and so on..
          Vote count (probably the same as download count, just different numbers, 100 votes – 1%, 500 votes – 10% and so on)
          Vote value (only take into account if has 50 or more votes): 1 star: -10%,2: -5%, 3: 0%, 4: +5%, 5L +10%.

          compactability (also only take into account if 10 or more votes)….

          and so on..
          I think these properties are good way to tell if the plugin is good or not. So by combining them with relevance you should be able to get good results. Of course this kind of stuff requires fine tuning..

          As Matt mentioned, you should test the search engine with top plugins. also do you have analytics running on plugins directory? would be a good idea to look at what keywords brings people to certain plugins and test with them.

        • Peter Westwood 7:53 am on December 24, 2010 Permalink | Log in to Reply

          To me the preferences for sorting would be:

          1. Exact Match in Title
          2. Order by install count / rating – download count is meaningless to me as it is too easily affected by having 100s of plugins release versions for minor buglets

        • jb510 8:57 am on December 24, 2010 Permalink | Log in to Reply

          Thinking a little outside the box, Otto is right each search category (rel, new, upd, pop, rating) is there, but what I really want is the ability to combine those types of search. I want the radio buttons to be check boxes so I can search for “relevance” AND “popularity”.

          Also, I wonder if you couldn’t add the abilty to search for exact name matches by entering the plugin name in quotes, ie. “Contact Form 7″?

        • Valentinas 9:23 am on December 24, 2010 Permalink | Log in to Reply

          jb510, that would be useful for advanced user, but what i’d like to have is something like Google (I think we can agree, that Google is an example of good search :) ). You don’t have any “popularity” or “relevance” or anything in Google, all you do is enter the name ( like before mentioned “contact form 7″) and you get the result. Google sells their search engine ( http://www.google.com/enterprise/search/mini.html ), but that may be not an option for WP, since it’s quite expensive (starts from $3000).

          Other than that idea about ability to search for exact name sounds pretty good (maybe even with a fallback to regular search informing the user about that – “we couldn’t find exact match for your query, but here’s some similar results”).

        • Otto 11:11 pm on December 29, 2010 Permalink | Log in to Reply

          Exact name/slug matches (or fairly close) now get bumped to the top of search results.

          In doing this, I discovered a case where results can be duplicated as well. it’s been there a while, but nobody noticed. That will take more time to figure out how to clean up.

        • Otto 10:30 pm on January 4, 2011 Permalink | Log in to Reply

          Duplicate search results removed. These were rare, but they’re gone now.

    • Rich Pedley 8:15 am on December 23, 2010 Permalink | Log in to Reply

      either the number of search results is still incorrect, or we are missing page links.

      • Otto 12:38 pm on December 23, 2010 Permalink | Log in to Reply

        The page links code was slightly off. It didn’t have the correct number set for its “per_page” count, so it had the wrong number of pages. I’ve corrected it.

        • Rich Pedley 3:26 pm on December 23, 2010 Permalink | Log in to Reply

          nope still broke. search for eshop:
          Showing 1-6 of 10 plugins with 6 displayed
          page shows 9-9 of 10 plugins , and only 1 displayed

          and why 6 per page, seems a weird amount.

        • Rich Pedley 3:28 pm on December 23, 2010 Permalink | Log in to Reply

          sorry that should have been page 2 shows 9-9etc

        • Otto 3:30 pm on December 23, 2010 Permalink | Log in to Reply

          I don’t know what you’re seeing, but for “eshop” it shows me 1-8 out of 10, with 2 pages. Works properly.

        • Otto 3:33 pm on December 23, 2010 Permalink | Log in to Reply

          Ahh, okay, actually you’re seeing different results because you are not an admin who can see the hidden plugins. Basically those are plugins that have been entered and approved but which no code has been uploaded for them yet. So they are getting removed from your display, but not from the total count.

          I’ll look closer at fixing that. But the normal display is 8 per page. If you see less, then the search is finding “unfinished” plugins then hiding them.

        • Rich Pedley 10:59 am on December 24, 2010 Permalink | Log in to Reply

          Yeah that would explain it – but won’t help others ;) Majority of people searching are not admins.

          and even so, 8 per page seems weird, can’t you bump it to 10? or is there some reason that octal rather than decimal is being used? Or even better a drop down selection to show 10/25/50 per page.

        • Rich Pedley 12:59 pm on January 3, 2011 Permalink | Log in to Reply

          a search for directorypress is returning this in the results:
          http://wordpress.org/extend/plugins/directorypress/
          but that plugin no longer exists, so I’m guessing it got removed. But it’s still being found when searching.

        • Otto 7:51 pm on January 3, 2011 Permalink | Log in to Reply

          Fixed. Numbers for searches are still going to be a bit off though. Working on it.

  • Samuel Wood (Otto) 9:32 pm on August 27, 2010 Permalink
    Tags: compatibility, , plugins   

    New for Extend/Plugins:

    If a user clicks the “Broken” link, it will record the click as usual, but now also redirect them to the start a new topic support form, and nicely ask them to leave a new topic explaining what’s broken. Hopefully, this will make the broken button more useful.

    Note: if you want to test this, feel free, but realize that you’re marking the plugin as broken by doing so, whether you leave a new topic or not. So please, go back afterwards and change your vote to “works” if it really does work.

     
    • Ipstenu 10:14 pm on August 27, 2010 Permalink | Log in to Reply

      Sweet!

    • Ofer Wald 11:40 pm on August 27, 2010 Permalink | Log in to Reply

      How about doing the same for the dreaded single star vote?

    • Denis 11:56 pm on August 27, 2010 Permalink | Log in to Reply

      Is there an RSS feed that plugin authors can use to grab all of these forum threads? If not, it would be even more useful… Especially if advertised.

      • Otto 12:33 am on August 28, 2010 Permalink | Log in to Reply

        Every forum thread made via this manner gets tagged with the plugin’s slug. So you can subscribe to a plugin’s topic list that way.

        Example: http://wordpress.org/tags/simple-facebook-connect has an RSS feed on it of http://wordpress.org/support/rss/tags/simple-facebook-connect .

        Email notification hopefully coming soon.

        • hakre 7:33 am on August 28, 2010 Permalink | Log in to Reply

          Feedburner offers Email Integration for RSS.

        • Denis 9:45 am on August 28, 2010 Permalink | Log in to Reply

          That’s not good enough. It’s fine when you’ve a plugin or two. But when you’ve dozens, it becomes a lot of feeds to track.

          Moreover, these tags point to multitudes of support requests that are related to WP bugs and incompatibilities introduced by third party plugins — stuff that I don’t even want to be reading.

          What’s needed are two unified feeds. The first should lead plugin devs to all open threads related to his plugins, regardless of tags. The second should lead plugin devs to the subset of these threads that were opened by the broken button.

          Using tags for any of these two feeds is not an option unless the community spirit and attitude have improved dramatically. When I was answering support requests in the WP forums, the tag I was using got dropped in a hostile effort to move it out of the hot tags page.

        • Otto 6:22 pm on August 28, 2010 Permalink | Log in to Reply

          Better ways of notification are coming as well. Email notification is next on my list, followed by handling tags better.

          One step at a time, man.

        • Denis 6:42 pm on August 28, 2010 Permalink | Log in to Reply

          Personally, I don’t read emails any more than Knuth:

          http://www-cs-faculty.stanford.edu/~knuth/email.html

          I do subscribe to RSS feeds, however. So if anything, that works better. :-|

        • Otto 10:12 pm on August 28, 2010 Permalink | Log in to Reply

          It’s a combo deal. Emails come first, because though I use RSS and agree with you, the majority want the emails. Emailing an existing feed is simpler than emailing a non-existent one.

        • Matt 4:21 am on August 29, 2010 Permalink | Log in to Reply

          Denis, I’m sorry it’s not good enough. it’s better than before. And it’s being worked on.

    • Chip Bennett 3:19 am on August 28, 2010 Permalink | Log in to Reply

      Next step: change the vote not to record until a new forum topic is posted. :)

      (Either way, very cool stuff, Otto!)

      • Rich Pedley 7:20 am on August 28, 2010 Permalink | Log in to Reply

        oh yes that would be nice. Then add automatic changing of vote to works once thread is marked resolved… Oh sorry I think I just saw a cuckoo in the clouds.

    • hakre 7:34 am on August 28, 2010 Permalink | Log in to Reply

      Yeah, nice! I’ll play a bit with it and let you know :)

    • Denis 9:52 am on August 28, 2010 Permalink | Log in to Reply

      Adding to my last comment… Isn’t there a risk that end users report plugins as broken when they run into a WP bug or some incompatibilities introduced by their theme or other plugins?

      • Pross 1:19 pm on August 28, 2010 Permalink | Log in to Reply

        Maybe the author should verify its broken?

      • Devin Reams 2:06 pm on August 28, 2010 Permalink | Log in to Reply

        Are you really suggesting that doesn’t already happen?

      • Otto 6:20 pm on August 28, 2010 Permalink | Log in to Reply

        They were doing that already. Now they have a chance to report the problem.

        Ignoring their vote because they refuse to explain it would be rather unfair. The number of people who think it doesn’t work is valid data, regardless of why they think that. This isn’t ebay, where one negative means nobody trusts it.

        • Denis 6:35 pm on August 28, 2010 Permalink | Log in to Reply

          I believe you’re misunderstanding the question. On occasion, users report things as broken when it really isn’t. For instance:

          http://wordpress.org/extend/plugins/sem-admin-menu/

          One reports CSS is loaded, always. Which is an enhancement at best…

          The next is an incompatibility with another plugin…

        • Otto 3:33 am on August 29, 2010 Permalink | Log in to Reply

          No, I understand just fine. However, if they’re reporting it broken, then that’s between you and them. What, we’re supposed to make somebody jump through hoops or make it harder or something?

    • scribu 5:05 pm on August 28, 2010 Permalink | Log in to Reply

      some info from the readme is missing: http://core.trac.wordpress.org/ticket/14719

      • Otto 5:42 pm on August 28, 2010 Permalink | Log in to Reply

        Not a bug, Matt told me to remove them.

        • Ipstenu 2:54 am on August 29, 2010 Permalink | Log in to Reply

          Otto, would that be why some authors don’t show up on their plugins? I don’t seem to be listed as an author on any of my plugins, and that …. Well, makes it hard for people to know how to get in touch with me for support :)

        • Otto 7:52 pm on September 2, 2010 Permalink | Log in to Reply

          Ipstenu: No, this was because your plugin didn’t have your correct wp.org username in the Contributors: line in the readme.txt. Caps count there too.

          I’ve just modified this to show those author listings correctly. Although, if it can’t find you as a valid user, you get no gravatar and no link (because there’s nothing in profiles to link to). This will at least prevent the link weirdness we once had on the authors listing.

        • Stephen Cronin 12:48 am on September 6, 2010 Permalink | Log in to Reply

          As a plugin author, the more links to my site the better! :)

          But that’s not important. What’s important is this:

          As a user, I’ve found that *most* plugins have extra information, comments, etc on the plugin home page on the authors site. The removed link to the plugin home page is something I clicked a lot.

          I take Matt’s argument that this link can be added to the content area, but a) the vast majority of plugins aren’t going to have this and b) those that does will have it in a slightly different location.

          End result, instead of having a *consistent place* on *all* plugin pages where I can easily find this link, I have to search for it and in many cases it won’t even be there. There’s a term for that sort of thing:

          Usability fail

          The link to the author’s site is less important, but the link to the plugin’s homepage (on the author’s site) should remain (in my opinion) – because that makes the site more usable for the users.

      • scribu 5:51 pm on August 28, 2010 Permalink | Log in to Reply

        An explanation would be nice. Spamming can’t be a valid reason, since you can insert links directly into the description.

        • Otto 5:57 pm on August 28, 2010 Permalink | Log in to Reply

          Dunno. You’ll have to ask him. Anyway, I don’t think the design there is final yet, so they may make a comeback. We’ve basically just been playing with it, to see what looks and works better. Eventually I hope to have some useful stats for authors as well, for example.

          Bringing any of this up on trac is probably premature. Email me directly if you have concerns, I read them all and respond to most. otto at ottodestruct.com

        • Denis 6:44 pm on August 28, 2010 Permalink | Log in to Reply

          I fail to see any incentive to write a free plugin if you don’t even get some web traffic as a result.

        • Alex M. 8:42 pm on August 28, 2010 Permalink | Log in to Reply

          If that’s the only reason you’re writing plugins, then I feel sorry for you Denis. :)

        • Otto 10:18 pm on August 28, 2010 Permalink | Log in to Reply

          I gotta say that I think those links drive very little traffic. Matt said at #wcsav that I remember (because we used my plugin to do it), that something like 20% of his ma.tt traffic now comes from his facebook links (which are auto-published by SFC). There’s better ways to drive traffic back to you. Developing is generally done to fill a need, not to drive traffic.

        • scribu 11:57 pm on August 28, 2010 Permalink | Log in to Reply

          As a counter-example, about 20% of my referrall trafic (10% overall) come from wp.org

        • Otto 3:34 am on August 29, 2010 Permalink | Log in to Reply

          If it’s that big a deal, put your links in the description of the plugin. You can put links there, you know.

        • Matt 4:25 am on August 29, 2010 Permalink | Log in to Reply

          Plugin links are a little redundant now that each plugin has a page on the directory. If someone has a page on their own site as well easy (and more effective) to link from the main content area.

          Author links only work for single-author plugins, for multiple author plugins (which we want to encourage) it’s broken so better to build it off the commit list, so each author gets credit.

        • Alphawolf 3:00 pm on August 29, 2010 Permalink | Log in to Reply

          Well, if it remains like this, we have a useless profile field “Website URL ” then:

          (which funnily enough sais “Give yourself some link love.” :-) )

          It’s useless if the website URI neither shows up on the profile pages nor on the plugin pages anymore.

          On a side note, the wp.org repository would be the only plugin repository I know that doesn’t link back to the dev’s website at least. Personally I found some really nice blogs worth subscribing through the plugin pages (such as Viper’s, Ozh’ etc.).

        • Matt 3:11 pm on August 29, 2010 Permalink | Log in to Reply

          Our goal is to drive even more back to plugin authors than we do now, but give some time for the iterations to finish up.

        • scribu 5:24 pm on August 29, 2010 Permalink | Log in to Reply

          Thanks for the explanation Matt. Makes sense now.

          Michael H. asks to move the author info back to the top:

          http://core.trac.wordpress.org/ticket/14725

        • Matt 10:14 pm on August 29, 2010 Permalink | Log in to Reply

          That’s nice, but not really useful at this stage. If you have something you really want on that page maybe just send me an email.

      • scribu 5:27 pm on August 29, 2010 Permalink | Log in to Reply

        Speaking of developer site links, I think we can all agree that it makes sense to show them on profiles.wordpress.org (they were there, but vanished at some point)

        • Matt 10:14 pm on August 29, 2010 Permalink | Log in to Reply

          Definitely — not sure what’s up with those pages. The URLs are wrong too.

      • filosofo 8:33 pm on August 29, 2010 Permalink | Log in to Reply

        With profiles.wordpress.org being pushed into greater prominence, can we either fix or remove the activity stream? For example, it shows my last core trac activity as having occurred in March.

        I will volunteer to make the fix.

    • John James Jacoby 6:07 pm on August 29, 2010 Permalink | Log in to Reply

      Nice work Otto! Like the changes so far and know it will only improve as you iterate.

      • Otto 9:12 pm on August 29, 2010 Permalink | Log in to Reply

        Thanks! I think a lot of people aren’t getting the “iteration” concept here. :)

        • Alphawolf 1:27 pm on August 30, 2010 Permalink | Log in to Reply

          I’m sure you are aware already, but just for the sake of completeness, the short description above the tabbed navigation doesn’t convert Markdown currently. But that’s just a minor minor issue that came to my eyes. :)

        • Otto 3:28 pm on August 30, 2010 Permalink | Log in to Reply

          The short description should be text only. Markdown is not allowed there.

        • Alphawolf 3:40 pm on August 30, 2010 Permalink | Log in to Reply

          Sorry, my fault then. ;-)

  • Samuel Wood (Otto) 7:02 pm on August 25, 2010 Permalink
    Tags: plugins   

    Gravatars are now shown on the plugin listing page. It’s a minor thing, but people like pictures and clicking on pictures. Clicking on somebody’s picture will take you to their plugin profile, showing all their plugins.

     
    • Michael Torbert 7:04 pm on August 25, 2010 Permalink | Log in to Reply

      Awesome!

    • Glenn 7:09 pm on August 25, 2010 Permalink | Log in to Reply

      Nice touch!

    • Andrea_R 7:20 pm on August 25, 2010 Permalink | Log in to Reply

      Very very way cool.

      On multiple-author plugins, are the gravatars supposed to be stuck together, or do you think they’d look better with a wee bit o’ padding?

      • Otto 7:25 pm on August 25, 2010 Permalink | Log in to Reply

        I stuck ‘em together intentionally cause I liked the way it looked, but I’m open to suggestion on layout there if somebody has a better one.

    • Ipstenu 7:25 pm on August 25, 2010 Permalink | Log in to Reply

      padding 1px ;)

    • Rich Pedley 7:46 pm on August 25, 2010 Permalink | Log in to Reply

      Wouldn’t it make sense to add the gravatar to this page as well: http://wordpress.org/extend/plugins/profile/ ?

    • Rich Pedley 8:11 pm on August 25, 2010 Permalink | Log in to Reply

      and on my final note, will it be added for themes as well…

      apologies for my poor speeling today, one of those days again.

    • kyleabaker 8:20 pm on August 25, 2010 Permalink | Log in to Reply

      I think you should add something like this to the avatars:
      border: 1px solid #999;
      padding: 1px;

      It looks great like this with 4 avatars per line, but the text-indent is forcing 3 per line on every row after the first. If you could get these to all line up correctly then it would look great!

    • Alex M. 8:50 pm on August 25, 2010 Permalink | Log in to Reply

      Is the second line of Gravatars supposed to be indented?

      http://wordpress.org/extend/plugins/akismet/

    • Utkarsh Kukreti 11:35 pm on August 25, 2010 Permalink | Log in to Reply

      I’d suggest adding authors name as the title attribute of the link, so the name shows up on mouse hover.

    • Ron 12:45 am on August 26, 2010 Permalink | Log in to Reply

      Saw this earlier today. Love it.

    • hakre 8:57 am on August 26, 2010 Permalink | Log in to Reply

      the sidebar get’s crowded. Maybe placing into main content under authors?

      • Otto 2:45 pm on August 26, 2010 Permalink | Log in to Reply

        Some other changes are coming to the sidebar soon, actually, so it won’t be as bad.

    • Matt 3:23 pm on August 26, 2010 Permalink | Log in to Reply

      I expected the gravs to be smaller, and inline with the “Authors:” list.

      • Otto 3:26 pm on August 26, 2010 Permalink | Log in to Reply

        What, just like a tiny picture on the left of each name in the list? Seems like that’d look strange to me. Easily changed though.

        • Matt 3:27 pm on August 26, 2010 Permalink | Log in to Reply

          Let’s try it out, and axe the sidebar one. Like how avatars show up on Trac.

        • Otto 3:37 pm on August 26, 2010 Permalink | Log in to Reply

          Trac uses 24 px icons. If I make them that big, it looks pretty strange. But if I make them smaller at 16, then they’re almost too small to see.

    • Otto 5:42 pm on August 26, 2010 Permalink | Log in to Reply

      After some review and such, this whole thing is getting changed much more extensively. Expect gradual updates over the next day or two.

      • Alex M. 11:10 pm on August 26, 2010 Permalink | Log in to Reply

        A link to the plugin’s homepage is missing. :)

        • James 7:22 am on September 16, 2010 Permalink | Log in to Reply

          Are there any plans to bring back to “Plugin URL” and “Author URL” links that used to be near the top right of the page?
          Thanks

        • Otto 9:18 pm on September 16, 2010 Permalink | Log in to Reply

          James: No. If you want to link back to your homepage, add the link into your description area. The markdown for links looks like this: [http://example.com](link text).

    • w3prodigy 6:08 pm on August 26, 2010 Permalink | Log in to Reply

      Not sure if this is a bug, or you guys doing your thing – (going based off of my plugins) if a plugin does not have a readme file then no author name shows up

      • Rich Pedley 7:27 am on August 27, 2010 Permalink | Log in to Reply

        If the plugin doesn’t have a readme, why is it there? I thought it was a requirement for the plugins to have a readme?

        • Jay Fortner 12:55 pm on August 27, 2010 Permalink | Log in to Reply

          “To make your entry in the plugin browser most useful, each plugin should have a readme file” – I always took “most useful” as a recommendation to create a readme file, not a requirement.

          Since the plugins would still function without a readme, I generally don’t create the readme file until my plugin reaches a stable version – this is a better development cycle for me… clearly though, if the plugin directory is changing and now explicitly requiring a readme to display properly, I’ll add it. I was simply noting the differences between the previous way the plugin directory functioned and how it functioned after the recent changes.

        • Otto 1:30 pm on August 27, 2010 Permalink | Log in to Reply

          Several things probably have to be clarified but:
          a) Readme’s are not really optional. All plugins must have a readme.txt.
          b) The Contributors line in the readme should contain a list of the authors, using wp.org usernames only.

          This is how it’s going to be. If you give it bad input, you’ll get bad output.

        • Jay Fortner 1:50 pm on August 27, 2010 Permalink | Log in to Reply

          Thanks for the clarification Otto, looks like I have some readme’s to write.

        • Otto 2:46 pm on August 27, 2010 Permalink | Log in to Reply

          It’s been pointed out that I should clarify the above.

          A plugin will go into the repo just fine without a readme.txt file. However, without the readme, then several pieces of the plugin’s webpage won’t display. The authors (contributors) is one of these pieces. So is the description and everything else. That listing in the plugins page is built mainly off the readme.txt file.

          So while’s it optional in practice, it really should be there. The plugins/about page makes it a point to say that you should upload your plugin with a readme.txt file.

        • Otto 9:17 pm on August 29, 2010 Permalink | Log in to Reply

          @Jay:
          I’ve noticed that a lot of people aren’t putting valid author info in the readme file (they should be wp.org usernames, but many are not), so there’s a change I’m working on for that.

          Still, you should have a readme. It’s not needed for WP, but it is really needed for a good plugin page entry.

    • Otto 3:10 am on August 27, 2010 Permalink | Log in to Reply

      Like I said, after my conversation with matt and the upgrades, lots of things are changing. Gimme a day before suggestions, because what you see now is temporary. :)

  • Aaron Jorbin 5:32 pm on August 25, 2010 Permalink
    Tags: , , plugins   

    Plugin Developer Handbook Chapter List 

    Thank you to everyone that commented and help me brainstorm what is needed for a good plugin developer handbook. I’ve synthesized that information and have come up with the following chapter list / section plan behind the jump. Please let me know if there is anything you think I missed. Remember, this handbook is designed specifically for the task of Plugin development. It’s not designed to be the end all, be all guide to WordPress. It’s designed to help new plugin developers get to the point that they can build a plugin and assist existing plugin developers with finding the best practices for doing things.

    The next step is going to be to find authors for all of these sections. I’m going to be reaching out to a number of people to help out, but I’d also love to see some people volunteer. Please contact me @aaronjorbin on twitter or jorbin in IRC if you think you might be interested in writing a chapter or section. I’m going to be leaning on many of you, the experienced core developers and plugin developers.

    (More …)

     
    • Stefano Petroni 5:39 pm on August 25, 2010 Permalink | Log in to Reply

      Can’t wait to read it! :-)
      Thank you!

    • Jane Wells 7:23 pm on August 25, 2010 Permalink | Log in to Reply

      It would be great for volunteer authors to leave a comment on this post rather than using twitter etc. so that we can keep a record here.

    • Alex M. 7:39 pm on August 25, 2010 Permalink | Log in to Reply

      I assume you’ll want me to take oEmbed? If no one else steps up, I can also document some other APIs such as shortcodes, transients, or caching. My freetime is limited though, so don’t heap too much on me. ;)

      • Aaron Jorbin 7:35 pm on August 26, 2010 Permalink | Log in to Reply

        Alex, You were just the man I had in mind for oEmbed. I don’t want to over burden you, but may come back and ask for help on another after I’ve talked to a few others.

    • peterchester 1:22 am on August 26, 2010 Permalink | Log in to Reply

      This is great! We’ve been working on bits and pieces of something like this at our company (Shane & Peter, Inc.) with the intent of ensuring that we all abide by the same coding conventions.

      Is the idea behind this that developers would read the whole thing start to finish or that they would read a couple intro parts and use the rest of it as a look up index?

      • Aaron Jorbin 3:13 pm on August 27, 2010 Permalink | Log in to Reply

        Section 1 is largely going to go over basics and outside of the introduction, should be skippable/skimmable by experienced developers.

        Section 2 will hopefully be read by everyone. Section 3, pretty much the same though skimmable if you’re not storing any data.

        Section 4 will largely be a reference section.

        Section 5 will be used mostly for people releasing plugins publicly…which should be all plugin developers :)

    • mercime 8:21 pm on August 26, 2010 Permalink | Log in to Reply

      Hi Aaron, perhaps in tips or dev section, add list of tools/arsenals to create a plugin. like basic text editor, poEdit, FF with Firebug and Web Dev extensions, etc. Or maybe that’s too basic? :-)

    • Jacob Santos 8:53 pm on August 26, 2010 Permalink | Log in to Reply

      Well, I could probably write the entire 5th section if you need a draft.

      • Aaron Jorbin 9:16 pm on August 26, 2010 Permalink | Log in to Reply

        I’m going to Ping you in IRC one of these days. I think that at least one of the parts of Section 5 will be right up your alley.

    • Aaron Jorbin 9:17 pm on August 26, 2010 Permalink | Log in to Reply

      One Additional Section I forgot to add (Section 6 or maybe Appendix A) will be a list of tips, tricks, and notes from a wide variety of developers. That will be assembled and worked on much later.

    • John P. Bloch 9:44 pm on August 26, 2010 Permalink | Log in to Reply

      I’ve got WP_Rewrite like we discussed.

    • Stephanie Leary 9:53 pm on August 26, 2010 Permalink | Log in to Reply

      I wrote a basic walkthrough of SVN for people who’ve never used SVN before as part of the plugin chapter in my WP book. It has a ton of screenshots using Versions for Mac and Tortoise for Windows. If it would be helpful, you can have it.

      I think I also have the How to Get Help chunk.

    • Brian Layman 5:06 am on August 27, 2010 Permalink | Log in to Reply

      I’m up for the Short Codes entry if you need someone. Or one of the two other sections we’d discussed if needed…

    • Jay Fortner 1:11 pm on August 27, 2010 Permalink | Log in to Reply

      If you need anyone for Actions and Filters or Coding Standards – I’m here.

    • Marjorie Roswell 1:12 pm on September 17, 2010 Permalink | Log in to Reply

      Could this be placed on a wiki, so that names could appear next to the actual chapters? Might make it easier to see what’s left to claim.

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