WordPress.org

Ready to get started?Download WordPress

Make WordPress Core

Tagged: API Toggle Comment Threads | Keyboard Shortcuts

  • Nick Halsey 1:58 am on July 8, 2014 Permalink | Log in to leave a Comment
    Tags: , , API, customize   

    Customizer Improvements in 4.0 

    Building on the addition of Widgets to the Customizer in 3.9, and alongside my GSoC Menu Customizer project, @westonruter, @ocean90 and I have been working on a series of Customizer improvements for 4.0. In this post, I’ll summarize the changes and proposed changes that we’d like to get in before beta. Anything with an asterisk (*) still needs to be committed but has a patch. Keep in mind that everything here is liable to change before 4.0 is released.

    We currently have eight enhancements and feature requests that need to be completed before beta, but half of them are already marked for commit and all have patches. If you’re interested in helping out with these changes, we could still use help reviewing and testing many of them (especially for UI/UX). Huge thanks to everyone who’s helped out so far this cycle.

    Terminology Notes

    We recently renamed the Appearance trac component to Customize. I’d like to clarify a few things regarding terminology used to describe the Customizer:

    • We’re shifting toward using “Customizer” rather than “Theme Customizer”, as it isn’t necessarily theme-specific (though most of its uses currently are).
    • “Customize” is the action, “Customizer” is the thing. Most UI elements use “Customize” or “customizing”, but most documentation should probably use “Customizer”. If you’re questioning which to use, consider whether you’re looking for a noun or a verb and pick accordingly. Feel free to conjugate the verb form (eg. “customizing”).
    • “Customize” could refer to anything. That’s the point; it could be used to customize any part of a site. The Customizer can be used for anything, and we’d like to encourage more experimentation with different uses of the Customizer.

    UI Changes

    In 4.0, most of the Customizer UI changes are for the Customizer itself; the user experience inside the Customizer. I’m expecting a focus on the experience of accessing and navigating through the Customizer in future releases. In 4.0:

    • Widget areas are all grouped into a “Widgets” context, implemented via the new “Panels” API. Panels are a way to group Customizer sections, just like sections are a way to group controls. Panels slide over to the side, rather than expanding down, and contain vertically-expanding sub-sections. This could use some more work on the UI/UX side, see #27406 for details.
    • Only show “You are previewing / [theme name]” and the theme details & screenshot section when the Customizer is previewing an inactive theme. Otherwise, show “You are customizing / [site title]”, with a short description of the customizer. This matches panel headings, which are displayed as “You are customizing / [panel title]”, with the panel description as that heading section’s contents. #28550.
    • Replace Customizer close button with an “X” icon. This fits better with the arrow icon used to exit panels and makes the Customizer controls feel more like a modal/panel that is contextual to the front-end of the site, rather than a confusing mix between the admin and the front-end. We’d also replace the mess of buttons in the theme-install previewer (which looks like the Customizer) with icons and move them around. #28655.
    • Prevent loss of unsaved changes in the Customizer by warning users with an AYS if they try to close the customizer and there are unsaved changes. #25439.
    • Always return to the screen that the Customizer was opened from in the admin, like on the front-end. Look for more work here in the future. #25457.
    • All core customizer controls now support descriptions (#27981), complementing the ability to add descriptions to sections and panels. We could potentially add descriptions to some core controls if they seem needed, might want to do a UI/UX audit of the core Customizer controls and/or user testing.

    Here’s a screencast demonstrating some of these UI changes:

    API Additions & Improvements

    Customizer Panels

    The Customizer now includes a new way to group options together: panels. Just like a section is a container for controls, a panel is a container for sections. This was implemented in #27406. The Panels API is easy-to-use and works almost identically to the existing customizer section API. Add a panel with the following, within the customize_register action:

    $wp_customize->add_panel( 'panel_id', array(
    	'priority'       => 10,
    	'capability'     => 'edit_theme_options',
    	'theme_supports' => '',
    	'title'          => '',
    	'description'    => '',
    ) );

    As always, only use the arguments where you aren’t using the default values. Note that the panel will not be displayed unless sections are assigned to it. To add a section to a panel, just use the panel id for the new panel argument:

    $wp_customize->add_section( 'section_id', array(
    	'priority'       => 10,
    	'capability'     => 'edit_theme_options',
    	'theme_supports' => '',
    	'title'          => '',
    	'description'    => '',
    	'panel'  => 'panel_id',
    ) );

    You may notice that $wp_customize->add_panel and $wp_customize->add_section have the same arguments (other than panel, of course). This is because panels are a special type of section; technically speaking, WP_Customize_Panel extends WP_Customize_Section. Your sections are backwards-compatible: you can add the panel argument to existing sections without issues. However, you do need to check for the existence of WP_Customize_Manager->add_panel() if you’re maintaining pre-4.0 compatibility. As with Customizer Sections, you can access and modify Panels via:

    • $wp_customize->get_panel( $id );
    • $wp_customize->remove_panel( $id );

    New Built-in Customizer Controls

    WordPress core now provides support for a much wider array of Customizer controls. Implemented in #28477, these changes eliminate the need to create custom controls for most common use cases. The textarea type is now supported in core. For any type of input that uses an input element, you can simply specify the type attribute using the type parameter of $wp_customize->add_control().
    Here’s an example:

    $wp_customize->add_control( 'setting_id', array(
    	'type'     => 'url',
    	'priority' => 10,
    	'section'  => 'title_tagline',
    	'label'    => 'URL Field',
    ) );
    

    Which results in the following markup in the Customizer:

    <li id="customize-control-setting_id" class="customize-control customize-control-url">
    	<label>
    		<span class="customize-control-title">URL Field</span>
    		<input type="url" value="" data-customize-setting-link="setting_id">
    	</label>
    </li>
    

    This is pretty powerful, as you can now use the built-in WP_Customize_Control for most common use-cases rather than creating a custom control. But what about input types like number and range that require additional attributes like min, max, and step?

    New Built-in Customizer Control Parameters

    First of all, all of the built-in Customizer controls (including the custom controls such as WP_Customizer_Color_Control) now support descriptions, just like Customizer sections have descriptions (see #27981). This was much-needed and allows for inline help text at the control level.

    More interestingly, to complement the new support for arbitrary input types, a new input_attrs parameter allows you to add attributes to the input element (also implemented in #28477). This extends beyond just using min, max, and step for number and range, to the ability to add custom classes, placeholders, the pattern attribute, and anything else you need to the input element. Here’s an example:

    $wp_customize->add_control( 'setting_id', array(
    	'type'        => 'range',
    	'priority'    => 10,
    	'section'     => 'title_tagline',
    	'label'       => 'Range',
    	'description' => 'This is the range control description.',
    	'input_attrs' => array(
    		'min'   => 0,
    		'max'   => 10,
    		'step'  => 2,
    		'class' => 'test-class test',
    		'style' => 'color: #0a0',
    	),
    ) );

    Which results in the following markup in the Customizer:

    <li id="customize-control-setting_id" class="customize-control customize-control-range">
    	<label>
    		<span class="customize-control-title">Range</span>
    		<strong><span class="description customize-control-description">This is the range control description.</span></strong>
    		<input type="range" min="0" max="10" step="2" class="test-class test" style="color: #0a0;" value="" data-customize-setting-link="setting_id">
    	</label>
    </li>
    

    Which displays as follows (in Chrome 35):

    customizer-4.0-range-control

    The ability to add classes is particularly useful if you need to target specific controls with CSS or JS, but you don’t need any special markup. I’m using this in the Menu Customizer for the Menu Name field, which is just an ordinary text control with a special setting type.

    Contextual Controls

    Customizer controls can now be displayed or hidden based on the Customizer’s preview context. For example, options that are only relevant to the front page can be shown only when the user is previewing their front page in the Customizer (see #27993). This is already implemented in core for Widgets; Widgets have always been contextually faded and shown/hidden based on their visibility in the preview, but this functionality is now built off of the core active_callback API in both PHP and JS. There are three different ways to specify whether a given control should only be displayed in a certain context. The first, and most straightforward, is to use the active_callback argument in $wp_customize->add_control().

    $wp_customize->add_control( 'front_page_greeting', array(
    	'label'           => __( 'Greeting' ),
    	'section'         => 'title_tagline',
    	'active_callback' => 'is_front_page',
    ) );

    Note that you may use either built-in conditional functions or a custom function. If you have a custom control (via a subclass of WP_Customize_Control) and a custom callback function, you can skip the active_callback argument and override the active_callback method instead:

    class WP_Greeting_Control extends WP_Customize_Control {
    	// ...
    
    	function active_callback() {
    		return is_front_page();
    	}
    }

    Finally, the customize_control_active filter will override all of the other active callback options and may be a better solution in certain cases (note that this particular example will be avoidable with future work on expanding the Customizer’s JS API, and does not hide the title_tagline section, only the controls in it):

    function title_tagline_control_filter( $active, $control ) {
    	if ( 'title_tagline' === $control->section ) {
    		$active = is_front_page();
    	}
    	return $active;
    }
    add_filter( 'customize_control_active', 'title_tagline_control_filter', 10, 2 );
    

    In addition to the PHP API for contextual controls, you can override the control-visibility-toggle function on the JS side. By default, controls will slideUp and slideDown as they become visible or hidden when the Customizer preview is navigated. If you’re familiar with the Customizer control JS API (see wp-admin/js/customize-controls.js, and wp.customize.Control), the Widgets implementation of a custom toggle function is a good example:

    api.Widgets.WidgetControl = api.Control.extend({
    // ...
    	/**
    	* Update widget control to indicate whether it is currently rendered.
    	*
    	* Overrides api.Control.toggle()
    	*
    	* <a href='http://profiles.wordpress.org/param' class='mention'>@param</a> {Boolean} active
    	*/
    	toggle: function ( active ) {
    		this.container.toggleClass( 'widget-rendered', active );
    	},
    // ...
    ) };
    
    /**
     * Extends wp.customize.controlConstructor with control constructor for widget_form.
     */
    $.extend( api.controlConstructor, {
    	widget_form: api.Widgets.WidgetControl,
    } );
    

    Changes to the customize_update_ and customize_preview_ Actions

    You probably already know that the Customizer supports both option and theme_mod types for settings. But did you know that you can register arbitrary types? Since this is generally undocumented, I’ll show how it works (this has been in place since 3.4):

    $wp_customize->add_setting( 'setting_id', array(
    	'type'                 => 'custom_type',
    	'capability'           => 'edit_theme_options',
    	'theme_supports'       => '',
    	'default'              => '',
    	'transport'            => 'refresh',
    	'sanitize_callback'    => '',
    	'sanitize_js_callback' => '',
    ) );

    There are a few actions that you can use to handle saving and previewing of custom types (option and theme_mod are handled automatically). Namely, customize_update_$type and customize_preview_$type are useful here. Previously, the value of the setting was passed to these actions, but there was no context. In 4.0, via #27979, the WP_Customize_Setting instance is passed to these actions, allowing more advanced saving and previewing operations. Here’s an example from my Menu Customizer project:

    function menu_customizer_update_menu_name( $value, $setting ) {
    ...
    	// Update the menu name with the new $value.
    	wp_update_nav_menu_object( $setting->menu_id, array( 'menu-name' => trim( esc_html( $value ) ) ) );
    }
    add_action( 'customize_update_menu_name', 'menu_customizer_update_menu_name' );
    

    This part of the Customizer API is a bit too complex to fully explain here, as most of it already existed, but suffice it to say that the addition of the setting instance to these actions greatly expands the possibilities of working with custom setting types in the Customizer.

    New “customize” Meta Capability

    The Customizer has been essentially decoupled from edit_theme_options in favor of a customize meta capability (mapped to edit_theme_options by default), which is assigned only to administrators by default. This allows for wider use of the Customizer’s extensive capability-access options, which are built into panels, sections, and settings. Additionally, this makes it possible to allow non-administrators to use the customizer for, for example, customizing posts. This change is an important step toward expanding the scope of the Customizer beyond themes. See #28605.

    function allow_users_who_can_edit_posts_to_customize( $caps, $cap, $user_id ) {
            $required_cap = 'edit_posts';
            if ( 'customize' === $cap && user_can( $user_id, $required_cap ) ) {
                    $caps = array( $required_cap );
            }
            return $caps;
    }
    add_filter( 'map_meta_cap', 'allow_users_who_can_edit_posts_to_customize', 10, 3 );

    Customizer Conditional Function

    The new is_customize_preview() conditional function can be used to check whether the front-end is being displayed in the Customizer. The naming derives from the fact that the term “preview” applies to both theme previews and previewing changes before saving them. See #23509 for some sample use-cases from WordPress.com.

    Future Work

    Most of the changes in 4.0 focus on the Customizer’s PHP API and the user experience within the Customizer. In the next few releases, we’ll probably shift focus to building out the Customizer JS API (#28709) and work on the user experience of accessing and navigating through the customizer (potentially with something like #28602 and related), as well as improving the experience on mobile (#28784). The Customizer can be very slow currently but we’re exploring ways to improve performance; for example, controls could be dynamically loaded on an as-needed basis once a more complete JS API is in place (#28580). We’ll work on improving custom background images and potentially add menus and/or theme-switching to the Customizer eventually. We’ll also want to address what to do with screens that the Customizer effectively replaces (headers and backgrounds, maybe eventually widgets, menus, and themes).  Check out the future release Customize component tickets for more ideas.

    Thanks again to everyone who’s helped out with the Customizer in 4.0. If any of the outstanding items here pique your interest, feel free to jump in on trac!

     

    Update: all UI changes have been committed. Additional work to improve focus styling will happen during beta, see #28267.

    Update 2: everything here is in WordPress 4.0 beta 1, with the exception of the customize capability. The capability will most likely be implemented as a meta capability, not a primitive one, see #28605 for details.

    Update 3: customize meta capability is now in trunk, will be in 4.0 beta 2. Added usage example.

     
    • prionkor 2:10 am on July 8, 2014 Permalink | Log in to Reply

      >We’re shifting toward using “Customizer” rather than “Theme Customizer”, as it isn’t necessarily theme-specific (though most of its uses currently are).

      Correct me if I am wrong. We are still on “Theme Customizer” stage as customizer settings (on save) only affects theme options.

      Is there any plan for implementing Customizer with post meta in addition to the options? That is when we might truly customize things with the customizer.

      • Nick Halsey 2:31 am on July 8, 2014 Permalink | Log in to Reply

        The short answer is that it depends on what plugins you’re using. You’d probably be interested in the Post Customizer plugin (also linked above).

        However, note that many core (and plugin) options in the customizer are not theme-specific; for example, site title and tagline. That is, the settings are saved as options, not theme_mods, so they persist when switching themes. They’re just contextualized to being directly related to the theme in the customize context.

    • JakePT 3:50 am on July 8, 2014 Permalink | Log in to Reply

      I’ve been digging into the customizer a lot lately, and I’m really loving it. It’s a great way to open up parts of a theme so low-tech clients can make certain changes without an extra options page or awkward single-purpose widget areas. I’m happy to see most of the limitations I ran into being addressed here.

      The one thing that is apparently still missing that I really want is a proper Media control. The current one uploads files to the Media Library, but there’s no way to recover them in the customizer. If you upload 2 images, change your mind and want to go back to the first one, you have to upload it again and end up with duplicates in the media library. From a developer perspective, I’d also like it if it returned the attachment ID so I could do more with the file than just spit out the URL.

      • Weston Ruter 3:59 am on July 8, 2014 Permalink | Log in to Reply

        JakePT: Yeah, that’s being worked on. Have you seen the new Header Image control? You can select any image from the Media Library via the Media Manager. This same ability is being worked on for background images.

        • JakePT 10:12 am on July 8, 2014 Permalink | Log in to Reply

          No I haven’t. Thanks for pointing that out, I’ll take a look.

          Honestly, the reason that I hadn’t is that I generally avoid the Custom Header because I find it kind of ambiguous. Maybe it’s just the sites my company and I develop, but the images near the top couldn’t really be described as being in the ‘Header’, which makes it confusing. What is in the header is usually a logo (these are generally business sites), and the Custom Header functionality doesn’t work perfectly for that since, again, ‘Header Image’ isn’t how I would describe it, and if I want to allow uploading of a High Res logo for Retina, I can’t easily create a second Header control (last time I tried, anyway).

          But I’m glad to hear that it’s being enhanced in this way nonetheless, however I do hope that this enhancement eventually comes down to WP_Customize_Image_Control.

      • Nick Halsey 4:09 am on July 8, 2014 Permalink | Log in to Reply

        The media thing really bugs me too. In fact, I almost worked up a patch to try to get into 4.0 this past weekend, but I didn’t have enough time to get very far with it.

        What should (and probably eventually will) happen is that WP_Customize_Upload_Control should invoke the media library, and then the image and background controls would build off of it with slightly more specialized functionality. It should then be easy to create a custom control that extends this behavior to do all sorts of custom things with JS (like using other attachment metadata). Patches welcome on #21483.

    • Aristeides Stathopoulos 8:25 am on July 8, 2014 Permalink | Log in to Reply

      This is really exciting!
      It was about time this happened…

      The thing that bugs me the most in the Customizer is the fact that it’s almost impossible to save an array as an option… It’s easy to create new controls, but it’s almost impossible to create a control like for example a multi-select control and save it as an array. Instead we have to do some voodoo to convert the array as csv and save it that way.
      Any plans to change that soon?

    • Graham Armfield 10:21 am on July 8, 2014 Permalink | Log in to Reply

      When you’re building your changes to the Customizer as proposed here, please ensure that everything is keyboard accessible and is also providing enough information for screen reader users – not everyone will be using a mouse.

      The Customizer is currently pretty good from an accessibility perspective, and we wouldn’t want to see the Customize take a backward step with these changes.

      Keyboard only testing you’ll be able to do yourself, but feel free to post on the Make WordPress Accessible blog if you need help and guidance with anything else.

      • Nick Halsey 2:30 pm on July 8, 2014 Permalink | Log in to Reply

        Maintaining and improving accessibility is definitely a goal here. All of the new proposed icons (exiting panels, customizer close, etc.) have strong focus styling and use .screen-reader-text. I believe the focus indicators are sufficient even though the change is only color because the colors are inverted, with the darker color moving to the background and the lighter color for the icon. There is also an outstanding patch on #27406 that ensures that only visible elements are focus-able.

        It would be great if the Accessibility team could do an audit of the Customizer’s accessibility, particularly for screen readers, once these changes are committed. We could also maybe fix #27591 in 4.0 if it gets a patch soon.

        • Graham Armfield 1:56 pm on July 10, 2014 Permalink | Log in to Reply

          Nick, I’d like to have a look at the changes with a screen reader. Which ticket patches do I need to install to get the complete picture of the changes?

          • Nick Halsey 4:28 pm on July 10, 2014 Permalink | Log in to Reply

            Excellent!

            All of the user-facing changes are in WordPress 4.0 beta 1, so you should be able to test with that and won’t need any patches at the moment. The remaining known issue with accessibility is insufficient focus styling for Customizer sections and panel headings, which will be addressed in #28267. We’re definitely ready for an in-dept audit, keeping that in mind.

    • simplethemes 3:35 am on July 11, 2014 Permalink | Log in to Reply

      Very nice!

      Has anyone else noticed width issues with panels in Chrome (Testing in Version 35.0.1916.153)?

      http://d.pr/i/j93I

      No problems in latest Firefox.

    • nikeo 1:53 pm on July 15, 2014 Permalink | Log in to Reply

      Panels => just what I needed
      I also love the custom type and the context handling possibilities it creates with customize_update_$type, which I was ignorant of.

      Looking forward to see the JS API enhancements!
      Thanks for this overview @celloexpressions

    • Aniruddh 12:25 am on August 26, 2014 Permalink | Log in to Reply

      I don’t know if I’m missing something here but do we have contextual sections, too?

      • Nick Halsey 12:56 am on August 31, 2014 Permalink | Log in to Reply

        Not yet. There is currently no JS API for sections or panels, so there’s no good way to implement contextual sections. But this feature will be available in the future, once that’s in place. See #28709.

        You might look at what Widgets do in core to make sections contextual by doing special handling with a contextual control within the section.

    • Scott Smith 12:33 am on August 31, 2014 Permalink | Log in to Reply

      So is it possible to use the new ability to specify ‘type’ => ‘url’ in a way that’s compatible with WordPress 3.9 and lower?

      • Nick Halsey 1:07 am on August 31, 2014 Permalink | Log in to Reply

        Unfortunately, no. But you can check for the existence of `$wp_customize->add_panel()` for a 4.0 check and then act accordingly (just use text instead of url as the type). And it won’t cause any critical issues, the control just wouldn’t be displayed.

        It is forward compatible – if core implements something special for a specific html5 input type in the future, it will work with the current fallback input type handling back to 4.0.

    • kmavrov 11:43 am on September 5, 2014 Permalink | Log in to Reply

      Hi there, is it possible to have an indicator next to the range slider, which shows the current value, like when you set min = 1, max = 5, step = 0.25, and to be able to see that the current value of the range slider is 3.75 ?

      • Nick Halsey 7:14 pm on September 5, 2014 Permalink | Log in to Reply

        If you really want to do that, you could add some javascript that does that. But if you want the value to be displayed, you should really be using a `number` input (still with min, max, and step – which most browsers now support). The specs for the range input type specifically state that range should be used for inputs where the exact value is unimportant, and accordingly it wouldn’t make sense to display it. See also #28849. Core is unlikely to adopt this for the reasons above and because `range` doesn’t have to represent something numeric from a user’s perspective.

    • AxisThemes 5:04 pm on September 5, 2014 Permalink | Log in to Reply

      Hi Nick, how could we make theme customizer panel support in 3.9 or 3.8 are there any core plugins. Please adapt changes for customizer how the MP6 was done and later release. If the customizer core WP plugin was started for adapting changes let me know.

      • Nick Halsey 8:46 pm on September 5, 2014 Permalink | Log in to Reply

        Because the panel API is deeply integrated with core, it was developed directly in core instead of in a plugin. In fact, it was developed as part of my GSoC project to integrate Menus into the Customizer in a plugin, which required this functionality.

        New features that can act as standalone plugins are developed as plugins (for example, the Widget Customizer and the Menu Customizer). Iterative enhancements to the central APIs in the Customizer are better developed directly in core. And any smaller feature or API change is best developed in core, only sweeping changes should happen via plugins first.

        There’s pretty much no reason to be worried about supporting 3.8 and 3.9, because there’s pretty much no reason NOT to update to 4.0, since WordPress is backwards-compatible. If you need to use things that have been added in 4.0, simply require your users to update.

    • AxisThemes 10:40 pm on September 6, 2014 Permalink | Log in to Reply

      Hello Nick, Could you please help me with this type of setting. I have gone through almost everything in this post but truly I could solve. So some bit of example for this will be great solution.

      http://d.pr/i/xOBH

      Tip: Until the users select the “Custom” from the ‘Header Size’ select option that range control should be hidden.

      • Nick Halsey 6:16 pm on September 9, 2014 Permalink | Log in to Reply

        You can actually accomplish controls that are conditionally displayed based on the values of other controls with the new active_callback argument for controls. Pass in a custom callback function that checks the value of the other setting (with get_option or get_theme_mod) and return true or false whether to show the conditional control. See an example.

    • steven_gardner 8:10 pm on September 17, 2014 Permalink | Log in to Reply

      Hi, Thanks for the post its helped me a lot.

      One question though, You mentioned “check for the existence of WP_Customize_Manager->add_panel()”, How would I write that in PHP?

      Just learning PHP as I’m going and everything I’ve tried has failed.

      Thanks
      Steven

      • steven_gardner 8:28 pm on September 17, 2014 Permalink | Log in to Reply

        I managed to work this out, I think:

        if(method_exists('WP_Customize_Manager', 'add_panel')):
        $wp_customize->add_panel('themename_homepage_panel', array(
        'title' => __('Homepage Settings', 'themename'),
        'priority' => 12,
        ));
        endif;

        If this is wrong please let me know. Thanks

  • 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.

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