WordPress.org

Ready to get started?Download WordPress

Make WordPress Core

Tagged: API Toggle Comment Threads | Keyboard Shortcuts

  • John Blackbourn 12:00 am on October 25, 2013 Permalink
    Tags: , , API   

    JSON Encoding and SSL for api.wordpress.org Communication in WordPress 3.7 

    There are two changes to the way WordPress communicates with api.wordpress.org in 3.7: JSON encoding and SSL.

    JSON Encoding

    In versions prior to WordPress 3.7, data that WordPress sends to (and receives from) api.wordpress.org is serialized using PHP’s native serialization functions. PHP-serialization has two main problems:

    • Security: It has the potential to lead to security exploits via PHP object injection.
    • Portability: It’s hard to unserialize these strings in other languages besides PHP.

    In WordPress 3.7, most API calls have now changed so they send and receive JSON encoded data instead. The three major ones are:

    • Core update checks
    • Plugin update checks
    • Theme update checks

    The following calls have also changed, but you’re probably not so interested in these:

    • Importers list
    • Credits list
    • Browse Happy (the browser version check)

    How might this affect plugin or theme developers?

    In general this won’t affect developers at all. If your plugin or theme just consumes the API then you don’t have to make any changes. The API calls that send and received JSON encoded data have all had their version numbers bumped from 1.0 to 1.1 (for example, api.wordpress.org/plugins/update-check/1.1/. If you are consuming the version 1.0 endpoints you’ll continue to get PHP-serialized data. If you want JSON encoded data, you can switch to using the version 1.1 endpoints.

    There is one situation that developers may need to account for. If your plugin or theme hooks into the update API requests in order to remove certain plugins or themes from the update checks, your code may need updating.

    A common method for removing a plugin or theme from the update checks is to hook into http_request_args, unserialize the data being sent to the API, remove the given theme or plugin from the data, and serialize it again. This will no longer work in WordPress 3.7 and your code will need to be updated so it decodes and encodes the data as JSON instead.

    An example of a plugin which has been updated to handle JSON encoding along with fallback support for PHP-serialization (depending on the version number in the API call) can be seen here: https://github.com/cftp/external-update-api/compare/f4d58e2…281a0ef

    Note that there are two API calls which have not yet changed to using JSON encoding:

    • Plugin info
    • Theme info

    These two calls will most likely be updated to use JSON encoding in WordPress 3.8.

    SSL Communication

    As part of the hardening process of this release, WordPress 3.7 will only communicate with api.wordpress.org using SSL (HTTPS) when the server supports it. This is an especially important security enhancement, given that automatic background updates are now a part of WordPress. Indeed, automatic background updates are disabled if the server cannot communicate securely with the api.wordpress.org.

    How might this affect plugin or theme developers?

    Again, this won’t affect developers in general. If your plugin or theme hooks into API calls you may need to update your code to it handles calls to https://api.wordpress.org/ in addition to http://api.wordpress.org/.

    JSON encoding and support for SSL means the WordPress.org APIs are in a much better position going forward.

     
    • Lester Chan 1:00 am on October 25, 2013 Permalink | Log in to Reply

    • djmceltic 8:17 pm on November 5, 2013 Permalink | Log in to Reply

      I have installed 3.7.1 cleanly on a server with SSL. The server is behind a firewall and many of the admin features are broken out of the box. Not sure what the fix is for this but it seems like there might need to be more configuration during install for SSL if you are going to force it.

      • John Blackbourn (johnbillion) 8:25 pm on November 5, 2013 Permalink | Log in to Reply

        Could you get some details of your server together (name and version of the OS, web server, TLS (OpenSSL/GnuTLS/etc), details of the firewall) and post a ticket to Trac? Thanks!

        • djmceltic 12:42 am on November 6, 2013 Permalink | Log in to Reply

          Hi John

          Windows 2008 R2 PHP 5.4.16 MySQL 5.5. With 3.6 and earlier we have had issues behind the firewall searching for plugins and themes and simply didn’t use this functionality – just did uploads. We have about 40 different WP installs (many different versions – couple haven’t been touched in years) and these are all working fine on same server.

          It looks like WP sees that I have ssl running on sever (which I do) and then whenever in the code we see if ( $ssl && is_wp_error( $request … it returns the warning message – PHP Warning: An unexpected error occurred. Something may be wrong with WordPress.org or this server’s configuration. If you continue to have problems, please try the support forums. (WordPress could not establish a secure connection to WordPress.org. Please contact your server administrator.) in C:\inetpub\wwwroot\ticket\wp-admin\includes\theme.php on line 298 – or whatever line the error comes from.

          It doesn’t happen on the update link which I find odd but happens on themes.php and install-plugin.php and a couple other areas.

          It is frustrating to think that we have to have an internet connection to change a theme or install a plugin. I work offline on my laptop all the time. But to fix the server issue is there a way to tell WP that we don’t want to use ssl? Or is there any other suggestions (I have tried adding my proxy server and all of that stuff in the config and no help)? Also our proxy does pass ssl urls – so not really sure if this is an ssl issue or proxy issue or both.

          • Dion Hulse 12:54 am on November 6, 2013 Permalink | Log in to Reply

            This sounds like you’re having connectivity troubles or latency issues, the WordPress.org API’s have a timeout of 3 seconds, if you exceed that it doesn’t work.

            Plugin/Theme update checks however have a 30 second timeout when run via Cron, so they’re probably succeeding which explains why updates work but installs don’t.

            So this is probably completely irrelevant to SSL by the sound of it, You might want to increase the timeouts for connections:

            add_filter( 'http_request_timeout', function( $timeout ) {
               return max( $timeout, 10 ); // minium of 10 seconds as a default timeout for HTTP
            } );
            

            Yes, it’s frustrating that you have to be online or with an internet connection for Update Checks and Install-from-web to work, Core Developers suffer the same problems sometimes, but, WordPress is a web-app and expects to operate in an online world, there are constants available to block outgoing HTTP requests when running in a locked-down environment though (See WP_HTTP_BLOCK_EXTERNAL and friends)

            • djmceltic 1:22 am on November 6, 2013 Permalink

              Dion

              I am fine with those updates requiring you to be online – but not just switching between already installed themes and plugins.

              Also the issue I detailed is not a proxy server timeout issue. I just installed 3.7.1 on server on same LAN as my web server that does not have SSL and it works fine. Not sure why but SSL is killing the apps. And the warnings I am getting are directing me to lines looking for $ssl = true.

      • Dion Hulse 11:29 pm on November 5, 2013 Permalink | Log in to Reply

        Not quite sure what the issue is, is it, a) SSL is broken in your install, b) Firewall blocks HTTPS but not HTTP? c) Firewall blocks all outgoing HTTP/HTTPS, d) Something else?

        Either way, create a trac ticket as John said if it’s something we can fix.

  • Andrew Ozz 6:47 am on September 23, 2011 Permalink
    Tags: , API   

    Javascript changes in 3.3 

    Now that WordPress 3.3 is in feature freeze, it’s time to have a look at some new Javascript goodies for developers:

    • jQuery 1.6.4 and jQuery UI 1.8.16. And that’s the full UI including widgets and effects. This will make it a lot easier and simpler for plugins using UI components that are not used in core as they will be able to just enqueue whatever they need.
      Note: there is a known bug/regression in UI Draggable since version 1.8.13. When connecting a draggable item to a sortable container, the HTML ID of the item is removed, #17952.
    • WordPress Editor API. This is an updated API for both TinyMCE and Quicktags that outputs all parts of both editors in the same way as used on the Add / Edit Post screens, #17144. Plugins will be able to use the WordPress editor anywhere including the Visual/HTML tabs and the links to upload files and show the media library.
    • Quicktags refactoring. This was necessary in order to make it fully multi-instance compatible, #16695.
      Note: if your plugin adds a Quicktags button please enhance it to use the new methods in quicktags.js.
    • New multi-file uploader. Plupload was included as a result of Google Summer of Code project, #18206. It’s more stable and has a lot more features as well as chooses the best available interface that the current browser supports: HTML 5, Silverlight or Flash.
      Note: two actions that were specific to SWFUpload were renamed and there is a new filter ‘plupload_init’ that gives access to all initialization options.
    • Other enhancements: wp_enqueue_script() now works mid-page and prints the late enqueued scripts in the footer #9346, wp_localize_script() uses json_encode to properly escape and output all strings, #11520.
     
    • Scott Kingsley Clark 2:18 pm on September 23, 2011 Permalink | Log in to Reply

      We were using a very early version of #2 and it’s been working great, excited to integrate the full 3.3 Editor API and have it work to the full extent we and plenty of other hungry developers have waited for :)

    • Conor Hughes 2:00 pm on September 26, 2011 Permalink | Log in to Reply

      Question about plupload, Does it include the option to spilt the upload in to samller chunks? So basicly does core included all the feature of the wplupload plugin https://wordpress.org/extend/plugins/wplupload/

      • Andrew Ozz 7:17 pm on September 28, 2011 Permalink | Log in to Reply

        No that’s not enabled by default but can be set by a plugin. Seems only Chrome handles splitting the file into chunks properly at the moment. It would have been nice to remove the upload size limit :)

        When more browsers start to support this reliably we can enable it by default, probably 3.4.

        • Conor Hughes 7:39 pm on September 28, 2011 Permalink | Log in to Reply

          Currently using the plugin and file spliting works in opera and Firefox 6+, However I am using the flash runtime not HTML5.

    • Stas Sușcov 7:47 pm on September 27, 2011 Permalink | Log in to Reply

      Great news on Editor API and `wp_localize_script()`!!!

    • Jason Penney 8:05 pm on September 28, 2011 Permalink | Log in to Reply

      Glad to see the full jQuery UI (also, looks like I picked the correct script names in Use Google Libraries way back, so I won’t need to make changes in there when 3.3 comes out).

    • Joerg 9:59 am on September 30, 2011 Permalink | Log in to Reply

      I hope the TinyMCE editor will offer tables in WP by standard so that I would not need to install any plugins anymore….

      • Andrew Ozz 4:10 pm on September 30, 2011 Permalink | Log in to Reply

        No, the default TinyMCE configuration in core has not changed. Most functions related to it were combined in WP_Editor class.

    • Max 9:14 am on November 4, 2011 Permalink | Log in to Reply

      Too late for jQuery 1.7?

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

    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?

  • Joseph Scott 10:32 pm on August 31, 2010 Permalink
    Tags: API,   

    Previously we’d talked about putting up a stats page on WordPress.org (WPORG) so that more people could see what was happening. While working on some of the new stats processing code on WPORG I realized that people would likely end up scraping this data for their own uses. That seemed like a waste, so instead as a first run the stats numbers are available in JSON format via:

    http://api.wordpress.org/stats/wordpress/1.0/

    http://api.wordpress.org/stats/php/1.0/

    http://api.wordpress.org/stats/mysql/1.0/

    A few notes about these numbers. First, they are summary percentages for the previous day (where day is based on GMT). You’ll also notice that these numbers don’t really line up with each other, this is because the system normalizes the version numbers and throws out odd/invalid versions (I was surprised by how many odd version strings there are out there). As a result each category is best compared to itself, instead of trying to compare PHP with MySQL numbers.

    The content type returned for this data is ‘application/json’, your browser may or may not display them correctly.

    This is a start, there are more things to be added to this in the future. One obvious item is support for getting numbers for previous days and date ranges. Another would be to add some pretty graphs to WPORG to display this data.

     
    • Andrew Nacin 7:48 am on September 1, 2010 Permalink | Log in to Reply

      Very cool! I’ll try to build a nice page for dotorg that uses this snapshot data.

      Along with change over time, I think minor versions would potentially be useful. I know it was helpful when we needed to choose a MySQL version to move to, and also identifying the number of installs actually affected by bugs like #14160. And it’s more data for people to play with.

    • Ben Forchhammer 11:56 am on September 1, 2010 Permalink | Log in to Reply

      Wow, this is great :-) Should be very useful when trying to decide which versions to support.

    • Denis 10:28 pm on September 2, 2010 Permalink | Log in to Reply

      Could it be possible to have php and mysql by WP version too? As well as WP and MySQL by PHP, and WP and PHP by MySQL? It seems the latter three would be more interesting.

      • Joseph Scott 4:41 pm on September 3, 2010 Permalink | Log in to Reply

        Certainly the data is there for that to be possible, we’d need to look at the queries involved to make sure it could be done in a reasonable way.

        • Denis 3:54 pm on September 4, 2010 Permalink | Log in to Reply

          I’ve no idea of your schema’s specifics, or whether you keep duplicate records related to each site in your stats, but I was thinking something like this:

          SELECT wp_version, mysql_version, php_version, COUNT(DISTINCT site_key)
          FROM stats
          WHERE stat_date > NOW() – interval ’1 day’
          AND wp_version IN ( $valid_versions )
          GROUP BY wp_version, mysql_version, php_version;

          The raw output of the above as /stats/raw/1.0/ would, I think, be the most interesting for plugin devs. It doesn’t necessarily need to be normalized as percentages, either: having the actual number of sites is useful to get an idea of how many users one is potentially targeting exactly.

    • Ryan McCue 11:39 am on September 3, 2010 Permalink | Log in to Reply

      Whipped up a quick Google Visualisation of these: http://ryanmccue.info/wp/stats/

    • filosofo 6:05 pm on September 3, 2010 Permalink | Log in to Reply

      Thanks for doing this, Joseph, Otto, and Ryan! A great combination of data and visualization.

    • Sergey Biryukov 6:33 pm on September 12, 2010 Permalink | Log in to Reply

      Is there any chance of making stats for localized versions available too?

    • Mike Schinkel 5:59 pm on July 8, 2011 Permalink | Log in to Reply

      Just found this thanks to Ryan C. Duff (thanks Ryan!) Curious, how is this data collected? From API requests to list plugins and themes?

  • Mark Jaquith 4:54 pm on May 18, 2009 Permalink
    Tags: API, , esc_url, esc_url_raw,   

    Deprecated clean_url() in favor of esc_url(), and deprecated sanitize_url() in favor of esc_url_raw().

     
  • Mark Jaquith 3:13 pm on May 18, 2009 Permalink
    Tags: API, , esc_attr, esc_html,   

    Deprecated wp_specialchars() in favor of esc_html() (also: esc_html__() and esc_html_e()). Using wp_specialchars() with more than one param works for backwards compat. Also, esc_html() (or wp_specialchars() with one param) escapes quotes, just like esc_attr(). This buys security for plugin authors who were mistakenly using a one-param wp_specialchars() call in an HTML attribute. See this wp-hackers message for more detail.

     
  • Mark Jaquith 9:16 pm on May 5, 2009 Permalink
    Tags: API, ,   

    Standardizing and shortening the WP security escaping functions.

    attribute_escape() is now esc_attr()

    Additionally, you can do attribute escaping and translation in one go. Just add the translation function to the end. Like so:

    • esc_attr__() — translate and return, attribute-escaped.
    • esc_attr_e() — translate and echo, attribute-escaped.

    Will be following up with esc_html (with __() and _e() variants), esc_url(), maybe some more. Will be nice, short, predictable, and allow you do translate/escape in one go without a lot of nested parenthesis.

     
    • Viper007Bond 5:04 am on May 6, 2009 Permalink | Log in to Reply

      An esc_js() or whatnot might be useful to (i.e. an improved js_escape() (see #7648).

      • Mark Jaquith 5:58 am on May 6, 2009 Permalink | Log in to Reply

        Yes, I meant to include that in the list of “coming soon” ones. Though js_escape() would continue to work, as would attribute_escape() and wp_specialchars().

        Improvements to esc_js() née js_escape() are a separate issue — I’ll take a look at that ticket.

    • Leandro Vieira Pinho 3:11 am on May 9, 2009 Permalink | Log in to Reply

      Why not escape_attr than esc_attr?. Write escape is more intuitive than esc.

  • Ryan Boren 10:51 pm on September 9, 2008 Permalink
    Tags: API, ,   

    New API that allows plugins to add sections and fields to settings pages and register new settings along with sanitization callbacks. add_settings_section(), add_settings_field(), register_setting(), unregister_setting()

     
    • Administrator 2:27 pm on September 12, 2008 Permalink | Log in to Reply

      Is there backward compatibility with the old API? (add_management_page and add_options_page)

      Where can plugin authors find out more about these changes?

    • Ryan 6:24 pm on September 12, 2008 Permalink | Log in to Reply

      The new API is more for adding to the default settings pages. You’d still use add_options_page() to add a new page. Right now the only docs are the inline phpdoc, which needs to be fleshed out more before release.

  • Ryan Boren 10:50 pm on September 9, 2008 Permalink
    Tags: API,   

    New wp_page_menu() API that creates a menu of pages. Themes will no longer have to do this for themselves.

     
    • Joel Goodman 5:00 pm on September 10, 2008 Permalink | Log in to Reply

      awesome!

    • Xavier 9:35 am on September 12, 2008 Permalink | Log in to Reply

      This is very cool, and could prove quite useful for WP-as-CMS websites, but I’ve heard of some that are afraid that implementing such features, generally handled by plugins or theme authors, might bulge the WP core code. One told me this: “I love the concept of having a simple core that you can build anything upon, it’s great. But with these new methods, I’m afraid WP is turning into a Rube Goldberg machine.”

      With wp_page_menu, inline editing and threaded comments all going to core, aren’t you afraid you might over-adding features?

    • Muhammad Siyab 1:35 pm on September 12, 2008 Permalink | Log in to Reply

      fantastic! finally, its here!

    • Rick Beckman 1:35 pm on September 12, 2008 Permalink | Log in to Reply

      Somewhere a chorus of angels sings.

      Hallelujah! :)

    • TDH 3:32 pm on September 12, 2008 Permalink | Log in to Reply

      Actually, that really does sound awesome!

    • Steve Meisner 4:15 pm on September 12, 2008 Permalink | Log in to Reply

      shweeet.

    • matt 5:30 pm on September 12, 2008 Permalink | Log in to Reply

      is there any example of this in action somewhere that we can check out?

    • lostkore 6:08 pm on September 12, 2008 Permalink | Log in to Reply

      Great news!

    • marti garaughty 9:25 pm on September 12, 2008 Permalink | Log in to Reply

      I looking forward to the release of WP 2.7 & child themes, this is just the cherry on the cake. Thx!

    • Ben 7:02 am on September 16, 2008 Permalink | Log in to Reply

      Maybe I am being dumb but I don’t understand what this is or why i should be excited? From what people have been saying it’s cool, but the lack of info makes it hard for me to interpret the limited news.

    • Ryan 5:56 pm on September 16, 2008 Permalink | Log in to Reply

      Ben, it’s not a big deal. It’s almost the same code you use at the top of Regulus for creating the menu. I just packaged it up into wp_page_menu() for convenience. I got tired of seeing this code having to be recreated in theme after theme.

  • Ryan Boren 6:53 am on February 9, 2008 Permalink
    Tags: API, ,   

    Avatar support is now baked in. Themes can use get_avatar() to fetch the avatar for an author or commenter.

     
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