WordPress.org

Ready to get started?Download WordPress

Make WordPress Core

Updates from Samuel Wood (Otto) Toggle Comment Threads | Keyboard Shortcuts

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

    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/

  • Samuel Wood (Otto) 5:45 pm on April 14, 2011 Permalink
    Tags: , ,   

    I’m going to be upgrading the /extend/themes bbPress install to bring it up to the same level of bbPress where the ideas and plugins and support forums are. This is to allow the login cookies to integrate properly across the whole site.

    This means that parts of the themes directory will be non-functional or broken for short periods of time as I track down issues with it. These times should be short and as minimal as possible.

     
    • DH-Shredder 5:59 pm on April 14, 2011 Permalink | Log in to Reply

      Since this is work on bbPress specifically, it should only affect the front-end of the directory, and not the SVN repo, correct?

      • Otto 6:34 pm on April 14, 2011 Permalink | Log in to Reply

        The display and search capabilities of /extend/themes and the API calls from core will be temporarily affected until I can make the proper adjustments to them. Access to the SVN will not be affected.

    • Otto 8:24 pm on April 14, 2011 Permalink | Log in to Reply

      This update is complete. Let me know if any bugs are spotted and I’ll correct them.

  • Samuel Wood (Otto) 4:50 pm on February 3, 2011 Permalink
    Tags: , ,   

    Theme pages now have a little “Theme SVN” link in their FYI box. This just gives a link to the theme’s SVN, for people that want to use it.

    This is something several of the theme reviewers asked for, and it fits with the long term goal of allowing some theme authors the ability to directly update themes via SVN instead of using the ZIP file uploader. Encouraging SVN use is a good thing, I think.

     
    • Rich Pedley 6:52 pm on February 3, 2011 Permalink | Log in to Reply

      That just lists all the versions, ala the ‘Other Versions »’ link on plugin pages. Shame it can’t be WordPress.org-ified rather than a simple listing though.

      • Otto 6:54 pm on February 3, 2011 Permalink | Log in to Reply

        That’s what it’s supposed to do. The theme SVN isn’t organized like the plugin SVN, with trunk and tags and such. It just has one directory for each theme version.

        • Rich Pedley 7:28 pm on February 3, 2011 Permalink | Log in to Reply

          So it could be pulled into a WordPress themed page then…
          ;)

        • Dion Hulse (dd32) 1:13 pm on February 5, 2011 Permalink | Log in to Reply

          Rich: Given it’s a SVN repo, I’m not really sure it’s possible to style it like WordPress.org. That aside, as it’s a SVN repo, it’s not designed to look like WordPress.org :)

        • Rich Pedley 8:09 pm on February 5, 2011 Permalink | Log in to Reply

          On a site such as WordPress.org having unstyled pages like that is very un-professional. I still think the data could be pulled into a themed page, and even if it can’t I have seen better web front ends for SVN.

        • Peter Westwood 10:08 pm on February 5, 2011 Permalink | Log in to Reply

          You can style the SVN web interface but I wouldn’t want to be the person writing the XSLT to do it – it’s not fun and you won’t make it look much better – I don’t see why it needs styling at all.

        • Alex M. 6:58 am on February 6, 2011 Permalink | Log in to Reply

          If you want to look at a pretty version of the code, then use the plugins Trac instead of browsing the directory via SVN. Or even better just use a proper SVN client.

          The SVN repository isn’t really meant for browsing with your browser. ;)

        • Matt 6:14 pm on February 6, 2011 Permalink | Log in to Reply

          I think it would be worth a little XSLT to just put a note at the top, like “This is blah blah blah for the plugin’s page please see LINK or visit WordPress.org.”

    • Radhe 6:45 am on February 4, 2011 Permalink | Log in to Reply

      This is welcome addition,
      but I do think “trunk” folder should be given, that will be helpful when author modify theme code in response to theme-users support request.

    • Dion Hulse (dd32) 1:13 pm on February 5, 2011 Permalink | Log in to Reply

      Could we get the same thing for Plugins?

      • Otto 6:00 pm on February 5, 2011 Permalink | Log in to Reply

        Plugins have had the SVN links in their Admin sections forever. Not sure it’s worth exposing them on the public side of things.

        • Dion Hulse (dd32) 10:34 pm on February 5, 2011 Permalink | Log in to Reply

          Not everyone has access to the admin section of every plugin.

          I personally see SVN access for Plugins as more useful than for Themes. Every task is common between them however (Other than Theme review team stuff, but thats a not a normal front end task anyway). Allowing easier access to the SVN repo from the plugins page will help people who are not aware of SVN get into it at well, encourage them to use svn..

          One of the first thing I do, and I’d hope other Plugin developers do, is open the plugins SVN repo and take a glance at the code, it’s what tells me if I’m going to atttempt to use it or not. That’d be my main use for it for Plugins (as well as for Themes).

        • Rich Pedley 9:37 am on February 7, 2011 Permalink | Log in to Reply

          erm plugins already have a link to the Development log in the FYI box. This was what I was referring to when I thought that the themes should match it.

    • Denis 6:00 am on February 12, 2011 Permalink | Log in to Reply

      Slightly off topic, but… It just occurred to me that the default vote for compatibility was for 3.1 at a time where it was not released. As much as I like the idea that one can vote on works/broken for the latest beta/RC, it seems to me that the vote should apply to the latest and greatest *released* WP version by default. (Or maybe it already is the case, in which case it’s not clear at all…)

      • Denis 6:01 am on February 12, 2011 Permalink | Log in to Reply

        i’m meaning for plugins, btw. But since you’re also worrying about that and I can only assume the same logic applies for themes, I figured I’d raise it here.

  • Samuel Wood (Otto) 6:11 pm on January 20, 2011 Permalink
    Tags: ,   

    I added child theme support to the theme previewer for /extend/themes. The only child theme we have in there at present that I know of is this one: http://wordpress.org/extend/themes/mazeld , but now the preview works for it. Note that the parent theme of a child theme must also be in /extend/themes for this to work.

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

    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: , ,   

    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:17 pm on December 16, 2010 Permalink
    Tags: ,   

    Profiles now shows up-to-date info from the various trac installs once again. It won’t be up-to-the-minute, but it will be updating on a somewhat regular basis.
    Example: http://profiles.wordpress.org/users/nacin

     
  • Samuel Wood (Otto) 8:50 pm on November 9, 2010 Permalink
    Tags: ,   

    The theme uploader tool now performs a much more extensive scan of uploaded themes and gives the results back in a list format to the uploader. Hopefully this will allow theme developers to more easily fix problems with their themes and reduce some of the load on the theme review team.

    Example of the resulting output (truncated). Note that I intentionally used a failed theme here, to show an example of what that looks like.

    And so on. This is an improvement over the previous method, which just stopped at the first error found and didn’t give a whole lot of useful output. While that old system is still in place (for now), this one is there in addition to it and will give all the results for any theme uploaded.

     
    • Denis 9:20 pm on November 9, 2010 Permalink | Log in to Reply

      Lol. Are you guys actually receiving “I created a new theme” spam? :-D

      • Otto 9:24 pm on November 9, 2010 Permalink | Log in to Reply

        Not exactly, but the process for getting a theme approved was rather frustrating. The uploader checked for a number of basic conditions, but then only reported the first error. This made it hard to use because it became a process of upload, fix the problem, repeat until it goes through. And even then, the theme review requirements are somewhat more stringent. So I made this checker code to hit all the major points and provide a sort of feedback system, to allow theme authors to fix up their themes before uploading them. I wasn’t the first to do so, Pross had a fairly extensive checker system in place which I used parts of.

    • Rich Pedley 9:23 pm on November 9, 2010 Permalink | Log in to Reply

      Could this be turned into a plugin for theme developers?

      • Otto 9:25 pm on November 9, 2010 Permalink | Log in to Reply

        Yep, Pross is way ahead of you there. He’s got a plugin in the works which can be used for development environments. Basically it runs the checks on the current theme and displays the results on an admin screen.

      • Ben 1:53 pm on November 10, 2010 Permalink | Log in to Reply

        I was going to ask the same thing – that would be awesome.

    • David Cowgill 11:07 pm on November 9, 2010 Permalink | Log in to Reply

      Great idea Otto. Being a theme developer, it will be nice to have a dev plugin to test all this before rolling out a new theme. Will Pross announce the plugin here once it’s available?

    • Ryan McCue 12:03 am on November 10, 2010 Permalink | Log in to Reply

      While this is awesome, the screenshot you’ve attached shows wp_specialchars() and attribute_escape() being used in a backwards compatibility file.

      Does this mean that themes are unable to use functions like this for backwards compatibility? (e.g. I can see a case where the theme author checks if esc_html() exists, and if not, maps to to wp_specialchars() )

      • Alex M. 12:05 am on November 10, 2010 Permalink | Log in to Reply

        Why support ancient insecure versions of WordPress?

        • Chip Bennett 3:13 am on November 10, 2010 Permalink | Log in to Reply

          Bingo!

          Right now, we would (probably) make an exception for a Theme that provides awesome, thorough, and consistent backward-compatibility for a given WordPress version. Of course, I’ve yet to see such a Theme. Usually, it’s a one-off compatibility check.

      • Otto 2:52 am on November 10, 2010 Permalink | Log in to Reply

        This check system doesn’t currently prevent the upload from succeeding (although all the previous checks are still in place). I expect to make changes before making a “pass” on this a requirement. Discussion must ensue, and such.

      • Justin 5:07 am on November 10, 2010 Permalink | Log in to Reply

        I don’t think I’ve seen a theme that’s actually backwards compatible. Many will have a function_exists() check for things added in WP 2.3 then no compatibility check for something in 3.0.

    • Mile 2:16 pm on November 11, 2010 Permalink | Log in to Reply

      These auto-search type scripts are ridiculous. I have a theme in review for weeks because of them.
      I understand the deprecated function search, but why on earth are you blacklisting php functions like “base64_encode/decode”, fopen, and force use of comment-reply script? At least mark them as suspicious and make the theme reviewer check them manually for improper use, because some themes might actually have a good reason to use them.

    • Tom 2:38 pm on November 11, 2010 Permalink | Log in to Reply

      Is the new theme uploader/reviewer available to download at all? It would be very helpful for themes that aren’t going to be uploaded to wordpress.org.

    • Tomas Kapler 11:59 pm on November 22, 2010 Permalink | Log in to Reply

      Are you going to improve the same way the plugin uploader. E.g.
      a) screenshot page with no screenshots
      b) recommended usage of all pages
      c) using of deprecated functions (php or WP)
      d) using of direct sql and not wp_query
      e) not commenting functions
      f) not using objects
      g) using non translantable strings and not allowing translations at all
      h) using very often problematic things like <?= in place of <?php echo
      … and many other problems if they can be easily detected

  • Samuel Wood (Otto) 12:14 pm on October 22, 2010 Permalink
    Tags: , ,   

    New and improved this morning, we have a two-fer.

    First, on the extend plugin directory, you may notice some new pie chart fun on the stats tab for each plugin. This shows a percentage breakdown of the versions being actively used by that plugin’s users. Only slices greater than 1.0% are shown.

    Secondly, since data kept in a box is not very useful, there’s a new API for getting this data. Usage is fairly obvious from just a simple example, which gets the version breakdown of one of my own plugins:

    http://api.wordpress.org/stats/plugin/1.0/simple-facebook-connect?callback=demo

    The callback parameter is optional, of course, and provided for people who want JSONP usage.

    Note that the version data is relatively new, so we don’t have it for all plugins at present. It will get better as reporting continues. For those interested, it’s saving the total counts of the version numbers as reported by the plugin update-checks over the last week. Since the data at present is only from one day, it’s not very accurate.

     
    • Kelvin Jayanoris 1:54 pm on October 22, 2010 Permalink | Log in to Reply

      Wow, AMAZING. You do all the fun stuff :p

    • Rich Pedley 1:54 pm on October 22, 2010 Permalink | Log in to Reply

      Hmm couple of comments
      1 – doesn’t show on http://wordpress.org/extend/plugins/simple-facebook-connect/
      2 – does show here: http://wordpress.org/extend/plugins/eshop/ but the containing box seems to be wider that it should be
      3 – multi coloured wheel looks nice but the key needs looking at, can it either list the last 2 versions + the most used version rather then what appears to be a random selection.
      4 – http://api.wordpress.org/stats/plugin/1.0/eshop?callback=demo – about half way you’ll see mine appears to be messed up?
      5 – are we able to get actual number of installs as well as the % ?

      Other than, nice feature ;)

    • Mo 2:00 pm on October 22, 2010 Permalink | Log in to Reply

      Nice! This is going to really useful as the plugin developer!

      Questions/notes:

      • Any chance you could throw in WordPress version data in there too (assuming that’s available)?
      • Does this represent active plugin count or just the installed count?
      • It’s unclear on the plugin page what the pie chart represents. I initially thought it was a pie chart version of the Compatibility data. Maybe a one-liner saying “The pie chart shows the versions of this plugin in use by WordPress users”?

      (Also: are you working on a secret v500 of SFC that you haven’t released yet? ;))

    • Rich Pedley 2:08 pm on October 22, 2010 Permalink | Log in to Reply

      my reply seems to have disappeared :)

      1 – please check out: http://api.wordpress.org/stats/plugin/1.0/eshop?callback=demo for possible error (half way)

      2 – containing box on the plugin page is a bit wide.

      3 – the key is weird, can we have last couple of versions, plus most popular as defaults?

      4 – it doesn’t actually appear on your plugin page…

      5 – can we get access to actual number as well as the & ?

      other than that looks good ;)

      • Rich Pedley 2:08 pm on October 22, 2010 Permalink | Log in to Reply

        that & should have been %

      • Otto 2:11 pm on October 22, 2010 Permalink | Log in to Reply

        1. Not an error, although some cleanup may be in order. Somewhere, somebody is actually reporting that back to us as the version. I could limit it to numbers only, but then plugin that use something other than numbers in their versions might have a problem.

        2. Intentional. Google’s chart API adds huge margins on either side of the stupid thing, so I put in new CSS rules to cut those off the sides and force it back into the right place. Looks good in Chrome, FF, and IE to me.

        3. Not sure what “key” you mean here.

        4. I see it just fine. Can you give me a link?

        5. No.

        • scribu 2:52 pm on October 22, 2010 Permalink | Log in to Reply

          2. It looks fine here:

          http://wordpress.org/extend/plugins/wp-pagenavi/stats/

          but it doesn’t seem to be applied on the main plugin page:

          http://wordpress.org/extend/plugins/wp-pagenavi/

        • scribu 2:57 pm on October 22, 2010 Permalink | Log in to Reply

          Also, I think it would make more sense to put it to the right of the History box, below the bigh bar graph.

          Anyway, it’s really nice to have access to this information. :D

        • Otto 2:59 pm on October 22, 2010 Permalink | Log in to Reply

          Yeah, I could put it there (and make it larger). My thinking was that the version information would be useful for users as well as for authors, to know how much usage a plugin got, or how much updating it got, etc.

        • scribu 3:02 pm on October 22, 2010 Permalink | Log in to Reply

          Don’t regular users have access to the /stats tab too?

        • Otto 3:02 pm on October 22, 2010 Permalink | Log in to Reply

          Yes, they do. I just didn’t think of it.

        • Rich Pedley 3:24 pm on October 22, 2010 Permalink | Log in to Reply

          now shows on your plugin, wasn’t before.

          the key – the ‘version number color block references’ on the right of the chart, if you look at yours for instance the biggest use by far is 0.21, yet that doesn’t even appear within the key.

          The padding/margins around it are still making it stick out of the sidebar .

          And I agree the stats tab would be a better place for it, allowing it to be bigger as well. – mine is multi coloured ;)

        • Otto 3:31 pm on October 22, 2010 Permalink | Log in to Reply

          • The key can be too long if there’s too many versions in use. I eliminated everythign under 1.0% to minimize this. Maybe I need to go higher.
          • Stupid CSS changes didn’t take effect. Working on it.
          • Probably will move it to the stats tab. Dunno yet.
        • Gary 11:31 pm on October 24, 2010 Permalink | Log in to Reply

          You can get a rough estimate of total installs by looking at the API – find the version with the lowest % of installs, this probably corresponds to 1 install. Divide 100 by the % to get a total number of installs.

          Notes:

          • Because the stats are limited to 3 decimal places, the higher the total is, the more inaccurate it is.
          • If you have any versions showing 0, then your plugin as > 200,000 installs. There are only a few plugins with this problem.

          @Otto: It seems Google Sitemap Generator breaks the API call:
          http://api.wordpress.org/stats/plugin/1.0/google-sitemap-generator?callback=demo

        • Otto 11:36 pm on October 24, 2010 Permalink | Log in to Reply

          Gary: if there’s no data, then it returns nothing. Remember that it’s only a couple of days old. I didn’t know what to return for a null result.

        • Gary 11:40 pm on October 24, 2010 Permalink | Log in to Reply

          That plugin is currently the 4th most popular. It should have data associated with it by now.

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

          Weird. I’ll check it out.

        • Otto 4:23 pm on October 28, 2010 Permalink | Log in to Reply

          @Gary: This has now been fixed. Most plugins (over 11000) should be showing data now.

    • Oliver Schlöbe 2:15 pm on October 22, 2010 Permalink | Log in to Reply

      Thanks a lot, Otto. Pretty much what I’ve been asking for some time ago. :) Although it would be more valuable (for the plugin dev) if it would show the versions of those WP environments the plugin is currently installed on. Would make it easier to drop compatibility for versions of WP that aren’t used with the plugin anymore..

      Anyways, thanks a lot!

    • Otto 3:56 pm on October 22, 2010 Permalink | Log in to Reply

      Moved it to the stats tab. It does make more sense there.

      • scribu 6:13 pm on October 22, 2010 Permalink | Log in to Reply

        Neat. It would be great if it could be moved a little higher, so that the ‘Active Versions’ header would have the same baseline as the ‘History’ header.

        Another thing would be to make the headers the same size. Don’t know if that’s possible though.

      • Rich Pedley 7:20 pm on October 22, 2010 Permalink | Log in to Reply

        looks a lot better, thanks.

    • Alex M. 6:17 pm on October 22, 2010 Permalink | Log in to Reply

      It’d be nice if it was sorted by percentage rather than version number I think. For example, why is yellow listed in the key instead of light green? Light green is a larger section:

      http://wordpress.org/extend/plugins/vipers-video-quicktags/stats/

      For that matter, I think the pie should be sorted by percentage too maybe.

    • Pat 6:13 am on October 23, 2010 Permalink | Log in to Reply

      Awesome! Except for the fact that my plugin’s chart looks like a tasty lollipop. We really need to get these users upgraded…

      The total # of active users would be a very valuable stat to show alongside downloads. Working on it? :)

    • scribu 5:34 pm on October 23, 2010 Permalink | Log in to Reply

      Now that I look at it better, the percentages seem to represent slices of the total download count.

      I was under the impression that an “active version” meant the number of users currently using that version on their site.

      • Otto 2:06 pm on October 24, 2010 Permalink | Log in to Reply

        Nope. Download count is entirely separate. This is using the data from the plugin update-check.

        • scribu 2:26 pm on October 24, 2010 Permalink | Log in to Reply

          So, on Front-end Editor when I hover over the largest slice, I get this:

          1.9.1
          28.141 (29.8%)
          

          What does 28.141 represent?

        • Otto 2:35 pm on October 24, 2010 Permalink | Log in to Reply

          The 28.141 is the actual percentage. The other number is different because I cut out everything less than 1.0%. So the total percentage I’m showing is actually less than 100%, which is then getting stretched to 100%.

        • scribu 3:14 pm on October 24, 2010 Permalink | Log in to Reply

          Ok, thanks for the explanation. Would be great if it would display the actual number of users though.

    • Scott 7:37 pm on October 23, 2010 Permalink | Log in to Reply

      Awesome feature, thanks for making this! FYI: it renders poorly in IE9 without compatibility mode enabled.

    • Aaron Jorbin 8:01 pm on October 23, 2010 Permalink | Log in to Reply

      Thanks for doing this! Out of curiosity, is this based on all sites with each plugin it installed or activated?

    • Maurice 1:09 pm on October 24, 2010 Permalink | Log in to Reply

      Very nice feature! I have noticed few things :
      1/ There are usually way more active versions than plugins download. Does this mean that the download count only count the users that clicked on the download link and not the one that are directly installing the plugin from the WP built in installer?
      2/ The askimet stats have apparently an issue : active versions for 2.4.0 : 28.26 (should miss some numbers).

      • Otto 2:09 pm on October 24, 2010 Permalink | Log in to Reply

        1. I don’t understand what you mean. You can’t have more active versions than total downloads. And no, the download count includes direct downloads as well.

        2. I see nothing wrong there. What do you mean?

        • Maurice 3:06 pm on October 24, 2010 Permalink | Log in to Reply

          1. If you do sum of active versions for some plugins, you will see that it is well above the total downloads… Sometimes 3 or 4 times…
          2. Check out the askimet stats page, release 2.4.0 is active on 28.26, it should probably 28.261 or 28.262… It is just missing the trailing number.

        • Otto 3:07 pm on October 24, 2010 Permalink | Log in to Reply

          Those are percentages, not raw counts. And it’s not missing the trailing number, the value is 28.260, so the zero doesn’t need to be shown.

        • Maurice 3:49 pm on October 24, 2010 Permalink | Log in to Reply

          There are two numbers, one is the percentage but the other one is a count, isn’t it? You have for each pie : the release number, the active version count and then between parenthesis, the percentage the active version count represents in the overall count, isn’t it? If this is the case, then the raw count for Askimet is wrong. It shows 28.26 (29,4%).

        • scribu 3:51 pm on October 24, 2010 Permalink | Log in to Reply

        • Otto 3:58 pm on October 24, 2010 Permalink | Log in to Reply

          No, they’re both percentages.

          I just don’t display any slice of the real pie smaller than 1%. The first number (the 28.26) is the actual percentage of the data. It’s the value you care about.

          The second number (the 29.4%) is the percentage that that slice in the pie you’re seeing actually represents.

          Because I’m cutting out some of the data (any slice less than 1%), the remaining data expands to fill the pie. Thus the number is slightly higher, but it is not significant enough of a difference to actually worry about.

          There is no “raw count” anywhere on that version number chart. The raw count is not data that will be made available.

        • Maurice 4:44 pm on October 24, 2010 Permalink | Log in to Reply

          Ok got it, it is a bit confusing like this even if it very valuable data! Why don’t you want to display the raw count? It would be very interesting data as well and won’t break any privacy as you aren’t displaying which blog is using it…

        • Matt 6:26 pm on October 24, 2010 Permalink | Log in to Reply

          The raw numbers bounce around a bit, but the percentages are usually consistent.

        • Maurice 1:09 pm on October 25, 2010 Permalink | Log in to Reply

          We won’t blame anybody if the numbers aren’t 100% accurate. More than the raw numbers, it is the trend that is interesting. Perhaps you could provide the global number of blogs on which the plugin is installed, this would be maybe simpler and less subject to error. Would be nice anyway ;)
          Anyway, many thanks for this new feature, very valuable! Congrats folks!

        • Matt 6:39 pm on October 25, 2010 Permalink | Log in to Reply

          Hopefully in the future we’ll be able to show rankings and rough %s.

    • anmari 12:42 am on October 25, 2010 Permalink | Log in to Reply

      Hi, just wondering whether there is a problem here, or whether I am missing something? Would love to see this data, and would appreciate if someone would enlighten me.

      Visibility of Pie chart, Google response?

      I understand that version data is not available for all plugins, but I have only managed to see the “pie chart” once for one plugin at http://wordpress.org/extend/plugins/vipers-video-quicktags/stats/ and once I navigated away (tried one of my plugins of course, nothing there, tried others mentioned above, nothing there (yet others had obviously seen pie charts), came back to viper, but now no chart, then just had a long… “transferring data” which is also what I was getting with others.

      Maybe the pie charts should be cached in case the google chart api fails?

      API access

      I assumed maybe problem was with the google chart api response, so thought I’d see if I could get the stats via the api mentioned above, since without the chart api the data is not visible. I assumed that it would work similar to other wp api call’s (version check and plugin search/info calls). No matter what plugin slug I use from thos ementioned above or akismet, eg:
      http://api.wordpress.org/stats/plugin/1.0/simple-facebook-connect or
      http://api.wordpress.org/stats/plugin/1.0/eshop

      I get an empty OK response?

      array(4) { ["headers"]=> array(5) { ["content-type"]=> string(9) “text/html” ["content-length"]=> string(1) “0″ ["date"]=> string(29) “Mon, 25 Oct 2010 00:28:45 GMT” ["server"]=> string(9) “LiteSpeed” ["connection"]=> string(5) “close” } ["body"]=> string(0) “” ["response"]=> array(2) { ["code"]=> int(200) ["message"]=> string(2) “OK” } ["cookies"]=> array(0) { } }

      • Otto 9:03 pm on October 28, 2010 Permalink | Log in to Reply

        There were some problems with this which I’ve since solved. You should get a valid response for almost all of the plugins now.

    • duck_ 7:01 pm on October 25, 2010 Permalink | Log in to Reply

      Looks like you might have noticed judging by the data shown in http://api.wordpress.org/stats/plugin/1.0/simple-facebook-connect, but is it possible to cut out invalid version numbers (e.g. 500.0 in SFC)

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

        Yes, but it’s not something I’m going to do yet. I want to see what builds up after being there a whole week. After that I’ll work on filtering to eliminate strangeness.

    • David Artiss 7:19 am on October 26, 2010 Permalink | Log in to Reply

      Otto – this is really useful, as a plugin developer, to see this information.

      One question, though – is there anywhere I can go to find out more information about other WordPress.org API calls like this one? I’d like to be able to access other plugin information but the api.wordpress.org site shows that there is currently no documentation.

      Thanks.

    • Ade 12:49 pm on October 31, 2010 Permalink | Log in to Reply

      Great tool for plugin developers, Otto. Thanks! I’ve been hoping for something like this for a long time. :-)

    • Jeff Lambert 7:02 am on November 19, 2010 Permalink | Log in to Reply

      Otto – Thanks for your work on this. Looks like I jumped on the plugin development bandwagon at the right time. Here’s a thought. I know you aren’t showing slices < 1.0% and, instead, are stretching the other slices of the pie to make up for this. Instead of doing that why not add all these slivers together and put them into an "Others" slice? Just a thought.

      • Otto 4:00 am on November 20, 2010 Permalink | Log in to Reply

        I could do that for the display, sure. Note that the API call returns all the (valid) numbers, not just those above 1.0.

    • Michael Torbert 12:53 am on November 20, 2010 Permalink | Log in to Reply

      Not sure how I missed this. Thanks!

    • Jeff Lambert 6:04 pm on December 11, 2010 Permalink | Log in to Reply

      So, the output on the stats tab, and via the specific plugin URL seems to flip around quite a bit and today I’m getting a return that 100% of my install base is on a rather old version, which I definitely know is not the case. Is this code still moving around a lot? Any idea when it will be locked down as I can’t say I’m happy when I go to the plugin on wordpress.com and see that 100% is v1.0.2 when the current version is 1.1.2. Let me know how it’s going. Thanks

    • Jeff Lambert 1:46 am on December 12, 2010 Permalink | Log in to Reply

      • Otto 3:25 am on December 12, 2010 Permalink | Log in to Reply

        Not enough users. The database only shows 9 reported active installs in the last week. And versions with counts of 1 are ignored.

        Note that some data may have been lost a few days ago, when I was making some other stats changes. This will self-correct as time goes by and sites do update checks.

    • Jeff Lambert 6:27 pm on December 12, 2010 Permalink | Log in to Reply

      Gotcha. Are there other APIs into the stats? Like you’re able to see counts but I believe I can only see percentages. Would be nice to know how many folks actually have it installed verses how many folks have downloaded it. Not that I’d want others to see this info necessarily but from a perspective of how much ongoing effort to put in or as an indication to maybe review it for improvements…. Thanks for this!

      • Alex M. 2:22 am on December 13, 2010 Permalink | Log in to Reply

        You should read the previous comments on this post. Counts are purposefully not revealed. ;)

        • Jeff Lambert 6:36 am on December 13, 2010 Permalink | Log in to Reply

          Thanks Alex, I had read this a back in October. My question was around whether there were other APIs, outside of the one in this topic, that would provide more details. Numbers would be nice. I can understand why specific domains might not be shared but seems like sharing numbers with developers isn’t a bad thing. After all, this is “open” source, right?

  • Samuel Wood (Otto) 4:54 pm on October 18, 2010 Permalink
    Tags:   

    The codex now recognizes the single-sign-on wp.org cookies and signs you in with them.

    Note that MediaWiki has its own cookies too, so logout doesn’t quite work right. I’ll work on that soon.

     
    • Mike Schinkel 10:21 pm on October 18, 2010 Permalink | Log in to Reply

      I was wondering why Codex how gives nothing more than “Failed to get ID from name ‘MikeSchinkel’”; ideas how to fix; clear cookies?

    • Ipstenu 10:27 pm on October 18, 2010 Permalink | Log in to Reply

      Log out, delete cookies, and try again?

    • Jane Wells 10:30 pm on October 18, 2010 Permalink | Log in to Reply

      Maybe a note on the Codex home page letting people know this would be good? Seeing some chatter via forums that people think it’s broken.

      • Otto 11:17 pm on October 18, 2010 Permalink | Log in to Reply

        Okay, this is temporarily disabled until I figure out what went wrong. Mike, email me directly please, since you can reproduce this and I can’t.

    • Mike Schinkel 11:50 pm on October 18, 2010 Permalink | Log in to Reply

      Emailed, but it seemed to have cleared up.

    • Otto 12:00 am on October 19, 2010 Permalink | Log in to Reply

      Okay, problem is solved for the subset of people that were having the problem.

      Long story short: If your username matches without regard to case, then you’ll get logged in properly now. If it can’t find a matching user for you, then, well, you just won’t get logged in. Better than getting that error.

      In theory, it should make a new user for you in MediaWiki in that particular case, but that doesn’t seem to be working for now. I’ll sort that out tomorrow. At least you’ll be able to access the codex regardless.

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