WordPress.org

Ready to get started?Download WordPress

Make WordPress Core

Tagged: wordpress.org Toggle Comment Threads | Keyboard Shortcuts

  • Matt Mullenweg 7:09 pm on August 3, 2012 Permalink
    Tags: meta, wordpress.org   

    You might notice that this P2 has gotten a big head. All of the Make P2s have actually, and like the rug in the Big Lebowski we think it really ties the room together.

    The Get Involved tab has been added, docs have been moved under support, home has been hidden. This isn’t ideal — we’d eventually like to move to more of a verb-oriented navigation system — but it is better than everything under Make being its own island and not really linked to or from the main WP.org side, or to each other. Hopefully it will also let more folks know about how to get involved (I added a link to the Make Core Handbook to the top sidebar widget.)

    I’ll be talking more about some of the improvements to WP.org tomorrow at 11am PST and you can still get streaming tickets if you’d like to tune in: http://2012.sf.wordcamp.org/tickets/

     
  • Samuel Wood (Otto) 3:36 pm on July 4, 2012 Permalink
    Tags: banner, , , wordpress.org   

    Fun with High-DPI displays 

    With the release of a lot of high-DPI displays (aka “retina” displays, but also others on both Android and iOS devices), it’s just a truism that images on these displays have tended to not look their best, all the time. High-DPI displays are having to scale up low-resolution images, and it’s just not great.

    There is a simple solution for this, using either CSS or Javascript tricks, but the basic principle behind it is to make an image twice as big on each dimension (four times the area), and then let the browser scale it down into the space it’s supposed to fit into. This lets the high-DPI displays have more information to work with and to make images which scale much better. The problem, of course, is that larger images require more space and bandwidth. With various CSS and JS techniques, you can target it such that the high-res images are only sent to browsers that really need them, saving on the bandwidth.

    Anyway, lately we’ve been making those sorts of changes to WordPress.org too. If you’re visiting on a high-DPI display, you may notice that the main header logo is of a higher quality, or you might have noticed that the Showcase looks particularly good, or that we now have some very high resolution images on the Logos and Graphics page. Little changes to the graphics, here and there. It’s an ongoing project to “retina-all-the-things”.

    Back in December, we made some changes to allow plugin authors to put banner images above their plugins in the directory, and the response has been great. So, now they get the high-DPI love too.

    Plugin authors already have the ability to make a banner-772x250.jpg or png file in their assets directory and have that be used for the banner image on their plugin listing. As of today, they can add a banner-1544x500.jpg or png file, for use on high-DPI displays only. When the website detects that the viewing browser both has a high-DPI display and the high-res image exists, then that image will be shown instead of the low-res image, but scaled to fit into the proper space. This makes them look particularly sharp on high-DPI displays.

    Now, before you go forth and create, please remember that one thing to keep in mind here is filesize. If you’re using photographic material for your banner, then it is highly recommended that you use the JPG file format. If you’re using drawn or generated materials, PNG is the favored format. However, in either case, you will want to apply high compression and try to keep those files as small as possible. Small files transfer to the browser faster. Also consider that a fair number of high-DPI displays will be phones, for example, and perhaps not using high-speed connections. So keeping that high-res file as small as you can would be a good thing. If you wish to use a PNG compression tool before uploading, that might be a good idea as well.

    And there you have it. Plugin authors, go forth, and show us your high-resolution banner skills! :)

    BTW, if you want to see it, I gave my Pluginception plugin a high-res image, for testing. It’s a simple image with some well-defined lines that make the difference easy to spot if you’re looking for it. You’ll need a high-DPI display to see it though. :)

     
    • John James Jacoby 3:50 pm on July 4, 2012 Permalink | Log in to Reply

      Added to bbPress.

    • Brian Layman 4:01 pm on July 4, 2012 Permalink | Log in to Reply

      What are the effective resolutions that are being seen in these high DPI devices? I would assume the current max width is over 1544..

      • Samuel "Otto" Wood 4:13 pm on July 4, 2012 Permalink | Log in to Reply

        It’s not about resolution as much as it’s about pixel density. The new Macbook Pro, for example, has 220 PPI, giving the screen a resolution of 2880×1800. However, that resolution is clearly insane for a 15-inch screen, since you can’t see a pixel at that low of a size. So images have to be scaled up, and that’s where it falls apart.

        See, if I have a page on a normal screen that looks good at 1600px across, then try to display the same thing on a screen that’s 2880px across, it’s either going to be tiny, or I have to zoom in, making one “pixel” in the image take up more than one “pixel” on the screen.

        So, the trend is divorce the web “pixel” from the actual physical pixels on the monitor. If I make a 1000px wide image, but then use CSS to display it in a 500px wide space, then a browser on a very high-resolution monitor can recognize when the “500px” wide space is actually taking 1000 physical pixels on the screen, and thus properly display the high resolution image, while still fitting it properly into the webpage.

        The keyword here is “device-pixel-ratio”. If one web “pixel” == one physical pixel, then the device-pixel-ratio is 1.0. On high DPI displays, the ratio may be larger. On a retina display, that ratio is 2.0. On my Samsung Galaxy SII, it’s 1.5.

        The plugin banner space is 772px wide. If you’re displaying it on a device where the device-pixel-ratio is greater than about 1.5, then using the high-res image will give you more detail in the same space, and fit properly. On a retina display, you get all the detail, because 1 “web pixel” = 2 “physical pixels”.

        More info: http://en.wikipedia.org/wiki/List_of_displays_by_pixel_density

    • Daniel Chatfield 4:15 pm on July 4, 2012 Permalink | Log in to Reply

      On my 3rd gen iPad I do not see retina graphics on the showcase page.

      • Samuel "Otto" Wood 4:17 pm on July 4, 2012 Permalink | Log in to Reply

        Refresh a couple times, or visit the main front page of the site first. It won’t recognize your device the first time, until the cookie gets set for you. This is to prevent us from having to waste a lot of bandwidth by serving low-res images and then converting them to high res images. Most people will get recognized before navigating deeper into a high-image area.

        • Matt 8:04 pm on July 4, 2012 Permalink | Log in to Reply

          It might not be that much of a waste.

        • Samuel "Otto" Wood 8:06 pm on July 4, 2012 Permalink | Log in to Reply

          For certain cases, I think I’ll probably look at optimizing the high-res images so that we can just use them always (if the filesizes are the same, then it doesn’t matter). Other cases can probably be converted to the CSS background approach, making JS unnecessary. I’m sure there’s further optimizations we can do.

      • Otto 8:18 pm on July 24, 2012 Permalink | Log in to Reply

        This should be fixed now, it’s using a CSS method instead.

    • Kaspars 8:00 pm on July 4, 2012 Permalink | Log in to Reply

      It would be nice if you posted all the server and WordPress related scripts that are used to accomplish this.

      • Samuel "Otto" Wood 8:04 pm on July 4, 2012 Permalink | Log in to Reply

        There’s not much to post, really. Adding this was just a matter of hacking in a few lines of code. The plugin SVN system is originally derived from the bbPress SVN Tracker plugin (http://bbpress.org/plugins/topic/svn-browser/) and the code that isn’t in there is just a bunch of customizations specific to the wp.org plugin repository and the theme for displaying it and such. Adding a line to make it find assets like these and use them when needed is just some additional add-on bits to that theme, nothing particularly special about it.

        • Kaspars 8:16 pm on July 4, 2012 Permalink | Log in to Reply

          Well, I see that you are setting a devicePixelRatio cookie, just like on Matt’s site, but the PHP thing which replaces the image URL must be something custom. Is that a cookie check on every request followed by “if_file_exists”?

        • Samuel "Otto" Wood 8:19 pm on July 4, 2012 Permalink | Log in to Reply

          Kaspars: Sort of. It is a cookie check at display time, but the file is only checked for during the scanning process which builds the plugin’s topic-page to begin with. I check for certain files and then add info about them to the topic-meta for the plugin’s topic. So it’s checking for a cookie, and then for the corresponding topicmeta. The cookie is site-wide, and used in a lot of places.

    • Kaspars 8:30 pm on July 4, 2012 Permalink | Log in to Reply

      OK, that means every page request has to be 100% dynamic and the complete WP stack has to be involved.

      What do you think of using nginx internal rewrites for resolving the correct image based on the cookie value?

      • Samuel "Otto" Wood 8:34 pm on July 4, 2012 Permalink | Log in to Reply

        I’m not trying to solve this as a generic problem, I’m solving it for WordPress.org. A generic solution such as you’re suggesting would very likely work though. However, you’d need a generic way to both produce and name the high-resolution images for them to be found and served programmatically. I’d also be concerned about naming and proxy-caching by other systems, you’d likely want to redirect browsers to alternate URLs in case they’re behind a caching system of some sort. Having the same URL return two different things depending on a cookie (or user-agent sniffing) is a recipe for problems.

        • Kaspars 8:40 pm on July 4, 2012 Permalink | Log in to Reply

          That explains it, and I completely agree.

          Out of curiosity, what are the average requests per second on WP.org and how many server are involved doing the PHP (and what is “X-nc: BYPASS luv 138″)?

        • Lloyd Dewolf 4:36 pm on July 5, 2012 Permalink | Log in to Reply

          BYPASS means that it’s bypassing WordPress(.com) “full html” cache, based on the information in your request (likely cookie or useragent).
          luv is the datacenter: Love Field Airport (DAL)
          138 relates to which of the static caching servers it would have HIT, I believe.

    • dartiss 11:57 am on July 5, 2012 Permalink | Log in to Reply

      If only I’d kept the originals for some of my banners ;) Oh well, Artiss Content Reveal has been updated, if anybody wants another example to try!

    • SK 4:26 pm on July 10, 2012 Permalink | Log in to Reply

      Otto — I was a bit confused which approach you took provider higher resolution images for devices with high DPI displays.

      1) Are you performing user-agent detection in PHP and rewriting the the URLs in HTML from something such as image.jpg to image-high.jpg?

      OR

      2) Are you replacing the images with JS after the page loads? I’ve seen popular snippets such as http://retinajs.com/ making their rounds on Hacker News.

      Feedback would be awesome, thanks!

      • Otto 8:20 pm on July 24, 2012 Permalink | Log in to Reply

        For the vast majority of cases, I’m using pure CSS now. For edge cases, there’s a cookie that gets set with your device pixel ratio which we can use on the server side of things to determine which image to show you.

    • Matt Mullenweg 8:40 pm on July 12, 2012 Permalink | Log in to Reply

      The Jetpack plugin is now updated: http://wordpress.org/extend/plugins/jetpack/

  • Andrew Nacin 8:07 pm on April 20, 2012 Permalink
    Tags: , wordpress.org   

    We’re seeing increased reports in readme.txt files not updating for plugins. Likely related to the migration to nginx from earlier this week, as in the process a number of configurations were updated (also PHP 5.2 to 5.3), and now signs point to memcached caching algorithms (riveting). @bazza is looking into the problem; @otto42 and I are also looking into some wider issues.

     
  • Andrew Nacin 1:16 pm on April 19, 2012 Permalink
    Tags: , wordpress.org   

    Thanks to @bazza and @stankea, WordPress.org has been fully migrated to nginx from Litespeed and Apache. Please let me know if you find things wonky with anything on wordpress.org, api.wordpress.org, bbpress.org, buddypress.org, etc. (Beyond the usual wonkiness, of course.)

    The only known issue is that query strings were temporarily broken on translate.wordpress.org. The rewrite rule has been fixed.

     
    • Paul Gibbs 1:23 pm on April 19, 2012 Permalink | Log in to Reply

      http://buddypress.org/wp-login.php is throwing a “No input file specified.” on buddypress.org; http://buddypress.trac.wordpress.org/ticket/4153

    • netweblogic 1:45 pm on April 19, 2012 Permalink | Log in to Reply

      The works/broken on plugins seems to be ‘broken’. The numbers are all 0 on any version combination.

      • Andrew Nacin 2:22 pm on April 19, 2012 Permalink | Log in to Reply

        Example plugin and combination? I’m getting it to work on both nginx (new) and Litespeed (old).

        • netweblogic 6:12 pm on April 28, 2012 Permalink | Log in to Reply

          sorry for late reply but fyi it was fixed pretty quickly, like within the day, so well done :)

    • Boone Gorges 2:16 pm on April 19, 2012 Permalink | Log in to Reply

      /extend/plugins search pagination doesn’t seem to be working: https://wordpress.org/extend/plugins/search.php/page/2?q=search+index

    • Marko 3:25 pm on April 19, 2012 Permalink | Log in to Reply

      It apears downloads here http://sl.wordpress.org/wordpress-3.3.1-sl_SI.zip are broken since this update, also the admin area of said locale site reports error 500.

      • Andrew Nacin 3:27 pm on April 19, 2012 Permalink | Log in to Reply

        Looking, thanks.

      • Andrew Nacin 4:12 pm on April 19, 2012 Permalink | Log in to Reply

        Fixed. This was a problem specific to sl_SI. The plural expression that was running on Rosetta was very, very wrong:

        Plural-Forms: nplurals=4; plural=n != 1;plural=n != 2;plural=n != 3;

        It should be:

        Plural-Forms: nplurals=4; plural=(n%100==1 ? 0 : n%100==2 ? 1 : n%100==3 || n%100==4 ? 2 : 3);

        Our pomo library choked on the extra semi-colons and caused parse errors in PHP 5.3 (something I will look into). To fix, I deployed new PO/MO files for you from translate.wordpress.org.

        More information about the old Plural-Forms header, so you may track down what happened on your end. The file was generated by Poedit on by you on 2011-02-23 17:12:19+00:00.

        • Andrew Nacin 4:33 pm on April 19, 2012 Permalink | Log in to Reply

          By fixed, I was referring to the download, not the admin. Still working on that.

        • Marko 4:57 pm on April 19, 2012 Permalink | Log in to Reply

          Wow, that translation is from a year ago. I was sure I did a deploy request at least back in december. Guess not.

          Thank you!

    • jb510 4:39 pm on April 19, 2012 Permalink | Log in to Reply

      Yesterday I couldn’t login to wordpress.org for quite a while using my normal browser (chrome), but could with other browsers… deleted my browser cookies and got in just fine. Nothing major, but mentioning it in case it’s related and someone else has the same problem.

      • Barry 4:48 pm on April 19, 2012 Permalink | Log in to Reply

        Howdy – thanks for the report. Probably not related. Is everything working for you now?

    • Todd Lahman 5:28 pm on April 19, 2012 Permalink | Log in to Reply

      Could you post the WordPress.org Nginx configuration and other Nginx configuration files, and detail any special configuration issues? Is WordPress.org running as singlesite, or multisite? It would be nice to also know if PHP-FPM is also being used, and what that configuration file looks like, etc.

      It would make a great scalable case study where Nginx + WordPress is being used.

      • Andrew Nacin 5:38 pm on April 19, 2012 Permalink | Log in to Reply

        Our setup is pretty crazy, but I’ll see what can be extracted out once things are stabilized. WordPress.org runs multiple multisite installations, as well as standalone bbPress, GlotPress, and other things both cool and uncool. We are not a great case study. :-)

        • Jacob Gillespie 9:39 pm on April 19, 2012 Permalink | Log in to Reply

          Even if we can’t directly relate to the complexity of the WordPress.org installation, there are very few documented examples of complex WordPress installations (or any LEMP installations for that matter), so it would be awesome if you could post any config details, no matter how complex/hackish.

      • Barry 5:47 pm on April 19, 2012 Permalink | Log in to Reply

        Sure – we are still fixing some bugs and cleaning up some stuff. WordPress.org, and the associated .org sites are kind of complicated :) A few multi-site installs, some single site, and a bunch of other stuff. We are using PHP-FPM as well.

    • michelwppi 8:52 pm on April 19, 2012 Permalink | Log in to Reply

      tuesday, I updated xili-language plugin to 2.5.0 and do some fixes in read me end of tuseday. But today thursday, the displayed texts and tabs are not as in the read me.txt file of zip but again old version of read me . The version on left changes but not the content of tabs. Backup db bps issues due to the move ??? tell me if you need tracs ID

    • Emil 12:42 am on April 20, 2012 Permalink | Log in to Reply

      Nice, I see that after the migration Most Popular Themes http://wordpress.org/extend/themes/ download count jumped for about 4-5K each. While on the stats itself this looks as usual.

    • David Decker 1:08 pm on April 20, 2012 Permalink | Log in to Reply

      In the Plugins repo It seems that the readme.txt will not update – I’ve comitted a new plugin all ok, except for the readme display on .org. I’ve comitted/updated readme about 10 times but nothing changes. All tabs are the same with description I used when adding the plugin in the repo.

      What’s going on here?

      Thanx for any help!!
      -Dave :)

      • David Decker 1:15 pm on April 20, 2012 Permalink | Log in to Reply

        …seems that a lot other devs who newly added plugins have the same problem: repo does not refresh…

        You can detect such plugins with too long descriptions in the listing and all tabs with the same content… though if you download the zip, all content is ok!

        Hope this helps, Dave :)

      • Otto 8:09 pm on April 20, 2012 Permalink | Log in to Reply

        The repo *does* actually refresh properly. What you’re seeing is basically a very complicated caching problem.

        So everybody: PLEASE STOP TOUCHING FILES IN THE SVN TO TRY TO FORCE IT. You’re giving the system a nervous meltdown. Your data is there. It has refreshed already. You just can’t tell right now. It’ll be fixed when it’s fixed.

        • David Decker 8:16 pm on April 20, 2012 Permalink | Log in to Reply

          Thank you for the update! Sorry, that I did update one of my readme’s a few times. Won’t do that again. I’ll just wait a little longer.
          Thanks for your hard work!!!

    • Knut Sparhell 6:41 pm on April 24, 2012 Permalink | Log in to Reply

      I used to use the support forums RSS feed at http://wordpress.org/support/rss/ (as still published in the header of http://wordpress.org/support/ ) but this now gives a 404.

  • Matt Mullenweg 1:14 am on December 22, 2011 Permalink
    Tags: wordpress.org   

    MT has given the typography on WordPress.org a refresh to bring it more in line with our sans-serif (instead of Lucida) approach in the WP dashboard, and also tightened up the vertical space the sub-heads were taking up on the page. Helvetica / Arial is a bit tougher than Lucida at smaller pixel sizes, so drop a comment here if you notice anything funky on the site.

     
  • Andrew Nacin 2:57 am on June 22, 2011 Permalink
    Tags: , , wordpress.org   

    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: , , wordpress.org   

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

     
  • Jen Mylo 5:14 pm on May 8, 2011 Permalink
    Tags: , wordpress.org   

    @otto42: in theme repo on .org, search results for “Twenty Ten” put Twenty Ten as result #6. Higher results are Freedream2010, 2010 Weaver, Third Style, Clear Style, and Atmosphere 2010. Can you do some magic so exact matches come up first?

     
  • Samuel Wood (Otto) 10:48 pm on January 13, 2011 Permalink
    Tags: wordpress.org   

    Added a new page to WordPress.org: http://wordpress.org/extend/mobile/
    Also added it to the dropdown menu under extend.

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

    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.

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