WordPress.org

Ready to get started?Download WordPress

Make WordPress Core

Tagged: widgets Toggle Comment Threads | Keyboard Shortcuts

  • Weston Ruter 8:10 pm on April 17, 2014 Permalink | Log in to leave a Comment
    Tags: , , appearance, widgets   

    Live Widget Previews: Widget Management in the Customizer in WordPress 3.9 

    The WordPress 3.9 release includes widget management in the Customizer: previewing changes to widget areas before publishing them live for the world to see. This feature was birthed out of the Widget Customizer plugin which started development in the 3.8 release cycle, it was formally proposed for merging into core at the start of the 3.9 release cycle, and then it was merged and followed by many changes. I wanted to follow-up here to talk through the changes to Widget Customizer since it was initially proposed (read this post for a full overview of the feature). Here is what has changed since then:

    No more opt-in for theme support

    The Widget Customizer plugin implemented a mechanism for doing fast live widget previews. By default, all changes made to settings in the customizer cause the preview window to do a full page refresh. This causes a lag between when you make a change and when the change appears. The customizer also supports an alternate non-refresh mechanism for previewing changes in the customizer (the postMessage transport) which you often see themes implement for live-previewing the blog name or the header color.

    Implementing such immediate live-previews requires all of the logic for previewing the change to be implemented in JavaScript, in addition to the underlying PHP logic for rendering the change when the setting is saved. This is not possible for widgets, since they all use PHP to handle the sanitization of the form inputs and for rendering arbitrary content that a widget may contain. (You’ll notice that when you make a change to a widget in the customizer, it actually does an Ajax request to submit the widget form for sanitization every time.) Well, to get around having the customizer preview refresh for every widget change, we implemented an Ajax renderer for the widgets, and then used the postMessage transport to initiate this widget render request, and then the rendered widget response would get swapped out in the DOM.

    Long story short, we decided to remove this feature to use postMessage for faster live previews. We have created #27355 to re-add this feature, but to generalize it so that any customizer control can take advantage of doing these partial preview refreshes. So for now, you’ll have to wait a moment for the preview to refresh when you make a change to a widget area, but now you don’t change your themes or widgets to add explicit support for Widget Customizer.

    No more Update button (usually)

    Widget forms on the admin page have a familiar Save button. In previous versions of Widget Customizer, we adapted the Save button to be an Update button, since it wouldn’t actually save the widget but would just update the preview with the widget’s latest state. Having to click this Update button to see the preview update, however, was a poor user experience and was unnecessary. Therefore, we implemented a means of submitting the form to update the widget’s state in the preview whenever a field in the control is updated: the Update button was hidden and the spinner appears when a change is being synced to the preview.

    The logic which does this live submission of the widget form as you interact with it, depends on the fields in the widget form to be the same fields which get returned when the widget form is sanitized. This is so that the fields can be aligned for being updated with their sanitized values. We couldn’t go the route of the widget forms on the widgets admin page, which actually get fully replaced with the newly-sanitized form, because this would interfere with the user quickly inputting into these fields.

    So if a widget form dynamically adds or changes which input fields are included, the live-as-you-type-them updates will stop and the Update button will re-appear. When you click this button, the form will replace itself with the sanitized version just like on the widgets admin page. We also introduced new jQuery events to help handle these form changes…

    New widget-added and widget-updated jQuery events

    In the widgets admin page, when you add a new widget to a widget area, a widget template element gets cloned and then inserted into the selected widget area. This widget template is cloned in a way that any event handlers initially added to the widget template do not persist on any newly-added widgets. Any widgets previously-added to the widget areas would have these event handlers attached, as well as any dynamically-created fields (e.g. jQuery Chosen), but again, newly-added widgets fail to retain these. The same problem exists, however, whenever you update a widget: since the newly-sanitized widget form replaces the old one, any dynamic elements get lost. (This is why event delegation is often required.)

    The same challenges here for the widgets admin page are also challenges for widgets in the customizer. And so in #19675 and #27491, we’ve introduced widget-added and widget-updated jQuery events which pass along the widget container as the second argument for the event handler. So to initialize and re-initialize a widget’s dynamic UI, you can now use these events in something like this:

    jQuery( function ( $ ) {
    
    	function init( widget_el, is_cloned ) {
    
    		// Clean up from the clone which lost all events and data
    		if ( is_cloned ) {
    			widget_el.find( '.chosen-container' ).remove();
    		}
    
    		widget_el.find( 'select.dynamic-field-chosen-select' ).chosen( { width: '100%' } );
    	}
    
    	/**
    	 * <a href='http://profiles.wordpress.org/param' class='mention'>@param</a> {jQuery.Event} e
    	 * <a href='http://profiles.wordpress.org/param' class='mention'>@param</a> {jQuery} widget_el
    	 */
    	function on_form_update( e, widget_el ) {
    		if ( 'dynamic_fields_test' === widget_el.find( 'input[name=&quot;id_base&quot;]' ).val() ) {
    			init( widget_el, 'widget-added' === e.type );
    		}
    	}
    
    	$( document ).on( 'widget-updated', on_form_update );
    	$( document ).on( 'widget-added', on_form_update );
    
    	$( '.widget:has(.dynamic-field-chosen-select)' ).each( function () {
    		init( $( this ) );
    	} );
    
    } );

    This is admittedly still not ideal, but it is much better than hacking the jQuery Ajax events to detect when a form update happens. In the future, I’m keen to see the widgets be revamped to use Backbone extensively.

    Configuring widgets during a theme switch

    We had a surprise late in the release (#27767) when it was reported that when you activate a new theme via the customizer, any changes made to the widget areas get lost when the theme is activated. This issue has been fixed, so now you can preview a theme and fully configure all of the widget areas before going live.

    Beware of widgets and caching

    We had another challenge in #27538 where widget changes previewed in the customizer would leak outside the preview and on the live site if the widget cached the output for performance. The core widgets Recent Posts and Recent Comments both cache their outputs in the object cache, and if a persistent object cache plugin is enabled (e.g. Memcached or APC) then the cache would get poisoned with the previewed widget, even though the widget’s changes weren’t saved. The same behavior would be experienced for widgets that use transients to cache the rendered output.

    To help widgets do the right thing in regards to caching, we introduced a WP_Widget::is_preview() method which widgets should always check before they interact with the cache. For example, a widget’s widget()method which caches its output should do something like this:

    if ( ! $this->is_preview() ) {
        $cached = wp_cache_get( 'foo-widget' );
        if ( ! empty( $cached ) ) {
            echo $cached;
            return;
        }
        ob_start();
    }
    
    extract( $args );
    echo $before_widget;
    // ...
    echo $after_widget;
    
    if ( ! $this->is_preview() ) {
        $cached = ob_get_flush();
        wp_cache_set( 'foo-widget', $cached );
    }

    Look forward to more improvements to widgets and the customizer in future releases!

     
  • Weston Ruter 11:52 pm on January 28, 2014 Permalink
    Tags: widgets   

    Widget Customizer Feature-as-Plugin Merge Proposal 

    Widgets in WordPress provide an easy way to add functionality to predefined areas of your theme templates. However, once you add a widget to a sidebar you have to leave the WordPress admin to go back to the frontend to actually see how the updated widget appears in the sidebar on your site’s public frontend. While you are making these changes and experimenting with a widget, it could be completely broken and everyone visiting your site will see this broken widget since there is no core way to preview changes made to widgets. But WordPress also provides an excellent way to preview changes to various settings on your site via the (Theme) Customizer. Changes made when using the Customizer are not visible to site visitors until you hit Save & Publish. So what if widgets could be edited in the Customizer? That’s what the Widget Customizer plugin makes possible. No longer do you have to edit your widgets blind!

    A widget control open the customizer

    Each registered sidebar on your site gets its own section in the Customizer panel. Within each section, widgets appear in their sidebar order. The widget controls appear there just as they appear when editing widgets in the widgets admin page. Upon making a change to the widget control, pressing the form’s Update button causes the changes to appear in the preview window; no changes to the widgets are saved permanently for others to see until you hit the Customizer’s Save & Publish button. This goes for whether you’re adding a new widget, editing existing widgets, reordering widgets, dragging widgets to other sidebars, or even removing widgets from the sidebars entirely: all of these actions are previewable.

    Adding a widget to a sidebar slides open a panel for browsing the available widgets, complete with the usual names and descriptions, but also featuring widget icons to help quickly identify widgets. The list of available widgets can also be filtered down with a search input.

    When you remove a widget from a sidebar, it is not deleted. Instead, it is moved from an active sidebar to the “Inactive Widgets” sidebar which can currently be seen on the widgets admin page. As such, removing a widget now is the same as trashing a widget.

    Adding a widget

    Customizer control sections for sidebars are shown and hidden dynamically when the preview window is initially loaded or when navigating the site within the preview window, based on whether or not the sidebar gets rendered in the previewed URL. (You may not know this, but you can navigate your site by clicking links in the preview window.) Only sidebars which can be previewed will be shown in the customizer panel. Likewise, widgets that are not rendered in the preview (for example, by means of Jetpack’s Widget Visibility module) will appear in the Customizer as semi-transparent.

    Accessibility has also been a key concern for Widget Customizer. The current keyboard navigation on the widgets admin page feels cumbersome, having to open screen options to enable a separate accessibility mode. We wanted to make re-ordering with widgets as seamless as possible. So now when any sidebar section is open, you can invoke a reorder mode to reveal up/down arrows to reorder widgets, as well as a subpanel to open for moving the widget to another sidebar entirely. (This feature is nearing completion in pull request #21.)

    Here’s an older walkthrough of the plugin:

    Live Previews

    (This did not make it into WordPress 3.9 — that also means themes do not need to indicate support for the widgets customizer. Read more about Live Widget Previews: Widget Management in the Customizer in WordPress 3.9.)

    While all themes and widgets should work with Widget Customizer, for the best experience the themes and widgets need to indicate they support live previews of sidebars and widgets. Without such support added, each change to a sidebar or widget will result in the preview window being refreshed, resulting in a delay before the changes can be seen (settings default to transport=refresh). To enable a much more responsive preview experience, themes and widgets should indicate that they support Widget Customizer live previews; this will update the relevant settings to use transport=postMessage, the updated widgets will be loaded via Ajax, and the widgets will be re-ordered via DOM manipulation.

    All core widgets and themes distributed with WordPress core are supported by default. For other themes, simply include add_theme_support('widget-customizer') in your theme’s functions.php to opt-in. If your theme does some dynamic layout for a sidebar (like Twenty Thirteen uses jQuery Masonry), you’ll also need to then enqueue some JavaScript to listen for changes to the sidebar and reflow them when that happens; see the bundled support for Twenty Thirteen to see an example of what is required.

    Along with themes needing to indicate support for live-previewable sidebars, widgets must also indicate that they support being live-previewed with Widget Customizer. When updating a widget, an Ajax call is made to re-render the widget with the latest changes, and then the widget element is replaced in the sidebar inside the preview. If a widget is purely static HTML with no associated script behaviors or dynamic stylesheets (like all widgets in core), then they can right-away indicate support for live previews simply by including 'customizer_support' => true in the array passed to WP_Widget::__construct(). As with sidebars, if a widget has dynamic behaviors which normally only get added when the page first loads (such as a widget which includes a carousel), then a script needs to be enqueued in the Customizer preview which will re-initialize the widget when a widget is changed.

    The sidebar-updated and widget-updated events get triggered on wp.customize when sidebars and widgets get updated, each being passed the sidebar ID and the widget ID respectively as the first argument in the callbacks. For a full example demonstrating how to add theme support for live-previewing dynamic sidebars and how to add support for JS-initialized widgets, see this annotated Gist.

    Core Tickets

    A few Core tickets have been opened with patches to generally improve widgets and the customizer, and also to improve Widget Customizer itself:

    • #26633: Customizer form submission prevention impairs accessibility of links in customizer controls
    • #26061: Customizer settings with non-scalar values incorrectly trigger as changed
    • #26569: URLs exported to JavaScript in Customizer settings get double-encoded
    • #25368: Add temp hooks for Widgets UI Refresh plugin-as-feature
    • #26661: Add before/after hooks to override output of wp_widget_control()
    • #25419: Add support to widgets for icons and screenshots

    User Tests

    A couple user tests have been done, both of which went pretty well. More user testing is being queued up. Here’s the first user test video, though note it reflects an early rendition of the plugin:

    Remaining Issues

    In addition to wrapping up the keyboard-accessible widget reordering (#21), there is the dilemma of how to handle wide widget form controls (#18); various solutions have been proposed for how to display a widget control which does not fit within the customizer panel.

    The other open issues are enhancements or open questions which may or may not need actioning.

    Contributors

    While the plugin was first conceived by me (@westonruter) and I’ve been the lead developer, a ton of valuable input and contributions have come from @shaunandrews, @michael-arestad, from my X-Team colleagues (@johnregan3, @akeda, @topher1kenobe), and from others in the community (@bobbravo2, @topquarky, @ricardocorreia).

    Development on the plugin has been done on GitHub, with the WordPress.org repo serving as a read-only mirror.

    See Also

     
    • Scott Taylor 12:04 am on January 29, 2014 Permalink | Log in to Reply

      This is really cool. Since all this widget refresh activity has been going on, I have seen the light on how great they are. It would be cool if we could find a way to rename the unfortunately base-named “sidebars.” I have no recommendation for something better, but it seems like widgets would really get their due if they were named appropriately as “one of many in a theme area” or “widget collection” or belong to a “module container.”

      Anyways, great work so far.

      • PeterRKnight 12:18 am on January 29, 2014 Permalink | Log in to Reply

        In hindsight I think just ‘widget area’ would have been the simplest name. I wonder how much trouble it would be to rename it.

      • Andrew Nacin 3:27 am on January 29, 2014 Permalink | Log in to Reply

        For what it’s worth (and it isn’t worth much), while this post uses the word “sidebar” repeatedly and while core code uses it extensively in the API, it’s nowhere in the UI. When we need to refer to one, we call it a “widget area” (such as in the help tabs).

        • Jen Mylo 4:27 am on January 29, 2014 Permalink | Log in to Reply

          Yes, we started actively saying widget area instead of sidebar when it was the controversy of the day several years back.

      • tomdryan 4:32 am on January 29, 2014 Permalink | Log in to Reply

        Scott I agree with you — the term “Sidebar” is outdated and should be retired, except when referring to containers that are actual (left/right) sidebars. The term that I’ve taken a liking to is “Container”. I’m hoping to see the entire widget functionality morphs into something more universal within WordPress, so you could have widgets, text, html, etc within a container. Page templates are made up of containers and containers can have widgets, media, text, html or other containers and other content within them.

        If you look at it that way, a menu is essentially a container (with a menu widget), as is the page header, as is the login dialog, etc, etc. Eventually, everything that is displayed by a WP site could be easily accessible and modifiable by the user without the need to edit any code or text files (unless they want to of course).

      • Weston Ruter 4:48 am on January 29, 2014 Permalink | Log in to Reply

        Yes, my bad everyone. s/sidebar/widget area/g :-)

    • Todd Lahman 12:13 am on January 29, 2014 Permalink | Log in to Reply

      Nice work Weston and contributors.

    • Jose 12:20 am on January 29, 2014 Permalink | Log in to Reply

      Awesome work! Been using the .org repo but will try and make the github transfer in the next couple of days.

      I truly love the integration of the genericons. :)

    • PeterRKnight 12:22 am on January 29, 2014 Permalink | Log in to Reply

      Are there any new approaches to the wide widget controls issue (#18) to test?

      • Weston Ruter 12:34 am on January 29, 2014 Permalink | Log in to Reply

        @PeterRKnight: no, we were talking about it over Skype today some more. Still really challenged by this. @michael-arestad did some more mocks: https://cloudup.com/iqH4tGUbQPn

        I think the idea I like the most is if wide widget controls opened over the preview as draggable areas. But it is a jarring user experience for some widgets to have controls sliding down within the panel, with others appearing in these floating windows.

        • Michael Arestad 12:57 am on January 29, 2014 Permalink | Log in to Reply

          We were also considering a flyout as an option as well that operates similar to the current wide widget controls on the widgets page.

        • PeterRKnight 2:01 am on January 30, 2014 Permalink | Log in to Reply

          Ah! Is there a reason why wide *and* normally sized controls couldn’t both enjoy the draggable-over-the-preview format? It would be consistent that way.

          Nice mockup, is it pushing the width of the preview section into a smaller frame though or does it hover over the preview? Hard to tell from the mockup, but it looks like it pushed the page layout into a narrow tablet/mode layout, I think that might be less intuitive when configuring widgets.

    • Syed Balkhi 2:27 am on January 29, 2014 Permalink | Log in to Reply

      This is pretty neat.

    • sterex 4:17 am on January 29, 2014 Permalink | Log in to Reply

      This is a really cool idea. This could probably replace the current widget settings page. Unless there is something that the customizer does not support.

    • Mike Schinkel 3:46 pm on January 29, 2014 Permalink | Log in to Reply

      Super nice Weston; two thumbs up!

    • Travis Northcutt 4:01 pm on January 29, 2014 Permalink | Log in to Reply

      Weston (or others): if using a child theme, does the child theme need to `add_theme_support(‘widget-customizer’)`, or is it sufficient for the parent theme to do so?

    • mrwweb 5:34 pm on January 29, 2014 Permalink | Log in to Reply

      Some thoughts.

      1) It looks good and it’s fun to use. Nice job!

      2) If this gets into core, it seems that a bit more consistency between the backend admin and Customizer would be useful. Particularly, if the widget icons are used in the Customizer, I’d expect them to be used in core.

      3) I think it’s important to consider how these would interact with the various “Widget Visibility” plugins (Jetpack’s Widget Visibility, Widget Logic, Widget Logic Visual, Conditional Widgets, Display Widgets, Dynamic Widgets, etc.). Right now, that can result to a widget appearing in the customizer but not in the preview.

      4) My biggest concern about including this in core is that it shifts the purpose of the Customizer from one intended for modifying the visual presentation of every page on a site, to one that handles content that may change from page to page (based on widget visibility mentioned in #3 or sidebars only appearing on certain pages). The discussion over including this in core should start by clarifying the purpose of the Customizer and whether or how much it should address editing content.

      As I addressed in an article expressing concerns about front-end editing where the focus is on the display of content, I think there’s a risk that users think they’re only changing the specific instance of the widget they’re looking at. This could be learned over time, but I think there’s a chance that it could lead to a bad first experience for many.

      5) If not all widgets can be supported when the feature is launched and not all themes can fully support the customizer, I worry that this will lead to further confusion for beginning users. What does it say if there are two places to administer widgets but some widgets can only be edited in one of the two? I think that segmentation could prove very very very confusing and frustrating to users.

      6) An alternative, much simpler change to widget administration could be similar to the front-end module edit link added to Joomla 3.2. I made a pass at this in the WP Inline Access plugin as you can see in the first screenshot on the plugin’s page. I think this comes down to what the most important feature of this plugin is. Is it to show how a widget looks (advantage: Customizer) or is it to help users quickly administer widgets from the front end (advantage: Link to Admin, in my mind).

      • Weston Ruter 5:46 pm on January 29, 2014 Permalink | Log in to Reply

        3) I think it’s important to consider how these would interact with the various “Widget Visibility” plugins (Jetpack’s Widget Visibility, Widget Logic, Widget Logic Visual, Conditional Widgets, Display Widgets, Dynamic Widgets, etc.). Right now, that can result to a widget appearing in the customizer but not in the preview.

        @mrwweb Actually, support for such Widget Visibility plugins has been added. When a widget is not rendered in the preview, it gets a semi-transparent indicator in the customizer. See https://github.com/x-team/wp-widget-customizer/issues/65

      • Weston Ruter 5:55 pm on January 29, 2014 Permalink | Log in to Reply

        5) If not all widgets can be supported when the feature is launched and not all themes can fully support the customizer, I worry that this will lead to further confusion for beginning users. What does it say if there are two places to administer widgets but some widgets can only be edited in one of the two? I think that segmentation could prove very very very confusing and frustrating to users.

        @mrwweb actually, all widgets and themes should be supported already (except for widgets with wide controls, as noted above). The piece that widgets and themes have to explicitly opt-in support for is live previews. Without that support indicated, then changes to widgets and their areas will cause the preview to refresh. This is in-line with other settings exposed in the customizer: by default they cause a refresh. Themes already have to add explicit support for live previews of settings (transport=postMessage), and so too the widgets need to indicate they support being updated without a page refresh. So themes and widgets that don’t indicate support for Widget Customizer will get a less responsive preview experience, but it all should still work.

    • Weston Ruter 5:42 pm on January 29, 2014 Permalink | Log in to Reply

      2) If this gets into core, it seems that a bit more consistency between the backend admin and Customizer would be useful. Particularly, if the widget icons are used in the Customizer, I’d expect them to be used in core.

      @mrwweb Yes, icons are being worked on for the Widgets admin page as well; see #25419. Also, @shaunandrews has been incorporating them into the Better Widgets plugin, which is also targeting core inclusion. See http://make.wordpress.org/core/2013/12/16/better-widgets/

    • Gregory Cornelius 8:40 pm on January 29, 2014 Permalink | Log in to Reply

      I think this would be a nice addition to the customizer. A few ideas:

      1) The widget block should be lower in the set of customizer components
      2) When selecting a sidebar, it would be nice if it was highlighted.
      3) I think it might be nice to keep the highlighting of the selected widget so that the user can orient themselves when making adjustments
      4) I wonder if it would be better if there weren’t update buttons and instead the preview auto-refreshed like the other settings do.

      In terms of the customizer as a whole, it would be nice if we could deep link to a specific component and incorporated some pushState() functionality in so that a plugin could experiment with removing the corresponding /wp-admin/ pages and still provide menu items that pointed directly to the component.

      • Weston Ruter 9:23 pm on January 29, 2014 Permalink | Log in to Reply

        1) The widget block should be lower in the set of customizer components

        It currently uses the default priority of 10 from WP_Customize_Section but a different priority maybe supplied via the customizer_widgets_section_args filter. Is there a better default priority?

      • Weston Ruter 9:26 pm on January 29, 2014 Permalink | Log in to Reply

        2) When selecting a sidebar, it would be nice if it was highlighted.

        That’s a great point. I had considered that, but the problem is that there is not guaranteed to be a single element container for the widgets in a sidebar widget area. I suppose the highlight could be added to the element that is the common parent element to all of the widgets. Or all widgets in the area could be highlighted together.

      • Weston Ruter 9:31 pm on January 29, 2014 Permalink | Log in to Reply

        3) I think it might be nice to keep the highlighting of the selected widget so that the user can orient themselves when making adjustments

        ?

        Agreed. The red glow is more of a placeholder. @shaunandrews has done some very interesting work on the widget highlighting front. There is an open pull request that needs to further build upon his prototype, which involves an innovative use of canvas to fade-out other parts of the page: https://github.com/x-team/wp-widget-customizer/pull/16

        Also, something which will help orientation is making sure that the widget stays scrolled into view: https://github.com/x-team/wp-widget-customizer/issues/56

      • Weston Ruter 9:36 pm on January 29, 2014 Permalink | Log in to Reply

        4) I wonder if it would be better if there weren’t update buttons and instead the preview auto-refreshed like the other settings do.

        Yes, this is something we’ve discussed, and there is an issue open for it: https://github.com/x-team/wp-widget-customizer/issues/45

        The problem with this is that widget controls may vary well have form validation in place (e.g. the RSS widget) which will cause a error message to appear in the form if it gets submitted before all of the fields are populated. Also, the widget update handlers may do some processing on the instance data (e.g. sanitizing or reformatting), so the content the user entered into the field may come back different when the form is submitted.

        If such field-by-field live previews were to be supported, it would require an additional level of support from each of the widgets.

    • Rindy Portfolio 3:57 am on January 30, 2014 Permalink | Log in to Reply

      This is a great leap forward for the customizer. Nice work!

    • Patrick Hesselberg 11:22 pm on January 30, 2014 Permalink | Log in to Reply

      Looks very cool! Gettings my plugin ready for this update!
      http://wordpress.org/plugins/pco-image-widget-field/

    • Weston Ruter 12:43 am on January 31, 2014 Permalink | Log in to Reply

      Released 0.14 of Widget Customizer, adding keyboard-accessible widget reordering and moving widgets to other sidebars (#21) (props @michael-arestad). /cc @arush @jorbin @accessiblejoe

  • shaunandrews 2:59 pm on December 16, 2013 Permalink
    Tags: widgets   

    Better Widgets 

    The Widgets team has been busy. :) Outside of the Widget Customizer plugin (posted about previously), we’re also working on some updates to the main wp-admin widgets screen through the Better Widgets plugin. This plugin does a bunch of things:

    • Available widgets have moved to the right side of the screen. The idea is that your widget areas (a.k.a. sidebars) should be the real focus of the screen — these are the things you can edit and manage. This may be a controversial change, as its the opposite of the menu screen (widgets closest cousin.)
    • Brings the widget icons from the Widget Customizer plugin to wp-admin.
    • Available widgets are now contained in a separately scrollable area. The goal is to help reduce to drag-and-scroll-and-scroll-and-scroll-and-drop problem that is so common from our initial research.
    • Widget descriptions are displayed in a single line, and truncated if they are too long. Clicking/Tapping on a widget expands the description (along with the area chooser from 3.8.)
    • Inactive Widgets are displayed below your active widget areas. This may be problematic as you have to drag-and-drop inactive widgets to active widget areas, but its an area we’d like to improve — maybe they should get an “area chooser”-like UI?
    • When editing a widget, the title is highlighted (using your current color scheme).
    • Clicking/Tapping on the “Save” button inside a widget now closes the widget and gives a quick confirmation message that the settings have been saved. This is based on some of our earlier user tests.
    • You’ve always been able to drag an active/inactive widget over the list of available widgets to deactivate it (yes, really!), but its been ugly. We’ve made it a little more tolerable. Give it a try.

    The plugin is still very young, but we’re looking to the community to get some interested from designers, developers, and testers. Please, install the plugin and play around. If you’d like to help us improve widgets, please join us every Monday at 20:00 UTC in #wordpress-ui — you can also drop your Skype nick below and we’ll add you to our ongoing chat.

    Some things to keep in mind when testing the Better Widgets plugin:

    • Responsive styles are essentially broken. Its on our short list, but we haven’t gotten to it yet.
    • The code is quick and dirrty — I’ve been the only developer committing code. Please, lets change this!
    • Some of this may look familiar to early MP6 adopters — this code comes from an earlier version of MP6, and was removed before the MP6 merge into 3.8.
    • We need accessibility help! Keyboard navigation is a must. I’d love to ditch the separate “accessibility mode” altogether and make it accessible out of the box.
     
    • PeterRKnight 3:26 pm on December 16, 2013 Permalink | Log in to Reply

      These improvements are really good!

      Better Widgets 0.2 gives me a php fatal error PHP Fatal error: Cannot redeclare wp_widget_control()
      (wp 3.8, no mp6 activated)

      • shaunandrews 3:44 pm on December 16, 2013 Permalink | Log in to Reply

        Ah shoot. This is why I shouldn’t be the sole developer on a plugin!

        I ended up modifying a core file so that I could make wp_widget_control() “pluggable” — hopefully someone knows a better way of doing this: https://gist.github.com/shaunandrews/7989121

        • Jose Castaneda 4:52 pm on December 19, 2013 Permalink | Log in to Reply

          jQuery would be one way. Remove then append. Not entirely ideal but can get it done. Unless we can make wp_widget_control filterable/pluggable in core.

      • shaunandrews 4:37 pm on December 16, 2013 Permalink | Log in to Reply

        For now, I’ve removed that “pluggable” function and bumped the plugin to v0.3. Unfortunately this means we lose the widget icon and the fancy styling of the widget descriptions.

    • DownHouse00 3:45 pm on December 16, 2013 Permalink | Log in to Reply

      Fatal error: Cannot redeclare wp_widget_control() (previously declared in domains\red.test\wp-content\plugins\better-widgets\widgets.php:24) in domains\red.test\wp-admin\includes\widgets.php on line 241

      • shaunandrews 5:40 pm on December 16, 2013 Permalink | Log in to Reply

        Grab the latest version (0.3) of the plugin — it should resolve this fatal error, but comes at the cost of some of the design/functionality. I’m hoping someone more knowledgable than me can help “fix” the issue at hand.

    • neojp 4:27 pm on December 16, 2013 Permalink | Log in to Reply

      I would love to see a built-in feature to choose what widgets show up depending on the page template / page url, like on Widget Context.

      http://wordpress.org/plugins/widget-context/

      • Weston Ruter 5:41 pm on December 16, 2013 Permalink | Log in to Reply

        @neojp In terms of sidebars, this is a feature of the Widget Customizer. The sidebar sections in the customizer will show/hide based on which sidebars are used on a given page. You can click around inside of the customizer to navigate to a page, and if that page template uses different sidebars, you’ll see the sections in the customizer change while navigating.

        It doesn’t, however, hide widgets from the sidebar sections if they aren’t currently rendered in the sidebar (e.g. via Widget Context or Jetpack’s Widget Visibility). Perhaps the widget controls could be made opaque or minimized, for example:

        I opened a Widget Customizer issue for this: https://github.com/x-team/wp-widget-customizer/issues/65

    • tomdryan 5:23 pm on December 16, 2013 Permalink | Log in to Reply

      Better Widgets is a great improvement already! The active widgets should definitely be front and center instead of off to the right as they have been historically — it makes much more sense.

      Is there a way to display which plugin created each widget? That would be very helpful info. Perhaps there could be a filter at the top of the available widgets column. It’s often difficult to figure this out from the name of the widget, especially if you are evaluating a number of plugins with similar functionality.

      • shaunandrews 5:39 pm on December 16, 2013 Permalink | Log in to Reply

        Filtering of available widgets is on my shortlist. Look at the live search-like filter UI available in the Widget Customizer plugin for a start. Sorting available widgets by their creator (think “default/core,” “Jetpack,” “theme name,” etc) could be useful as well. The icons may help with this, too.

    • Weston Ruter 5:32 pm on December 16, 2013 Permalink | Log in to Reply

      re:

      We need accessibility help! Keyboard navigation is a must. I’d love to ditch the separate “accessibility mode” altogether and make it accessible out of the box

      See @michaelarestad‘s work on adding a keyboard-accessible way to reorder widgets: https://github.com/x-team/wp-widget-customizer/issues/21#issuecomment-30152142

    • Mike Schinkel 7:15 pm on December 16, 2013 Permalink | Log in to Reply

      +1 on having the widgets on the right. I’d like to see menus reorganized in that manner, actually.

      Any thoughts given to targeting? For example, coming up with a “query language” based on resultant query vars from URL routing that would allow targeting specific pages or a group of pages. The query language could be used behind the scenes, of course, and give users nice and easy drop-downs. This was something I thought about doing a while back but then had to focus on other issues for clients.

    • Zoe Rooney 2:23 am on December 17, 2013 Permalink | Log in to Reply

      Just sent you (@shaunandrews) a pull request that improves the responsiveness via Github, so that at least it isn’t totally broken. Are you planning to use the issue tracker there for suggestions as well or do you want to keep commentary here mainly?

      • Zoe Rooney 3:16 am on December 17, 2013 Permalink | Log in to Reply

        Actually, I’ve noticed that the github repo is out of date. Would be happy to send you my suggestions for improving the responsiveness another way, as/ when it’s helpful!

    • David A. Kennedy 2:05 am on December 19, 2013 Permalink | Log in to Reply

      Hi all (and @shaunandrews)!

      I’m with the WP Accessibility team, and today during our team chat while discussing some of the needs of the plugin teams, I volunteered to help you all out. I love me some widgets, so I’m excited that they’re getting some love and look forward to helping bring accessibility into the fold. :)

      I’m leaving for vacation Friday and will be out of pocket for most of the Christmas holiday, but will spend some time catching up on the plugin goals and past posts. I’ll definitely install the plugin and play around with it from an accessibility standpoint. I’ll try to make the chat Monday (assuming there is one), and definitely those following the holiday.

      Let me know if you’ve tested anything from an accessibility standpoint or what questions you might have. I figure I’ll audit the plugin from all points accessibility, with a focus on keyboard navigation. I would love if we could remove the accessibility mode too.

      Where is primary development happening? Github? Somewhere else? I couldn’t find that in my brief scan of things. Where should I post feedback or contribute code?

      Thanks for thinking about accessibility and asking for help! Looking forward to making widgets a better experience for all!

  • shaunandrews 7:25 pm on November 4, 2013 Permalink
    Tags: , widgets   

    Widgets Area Chooser – 3.8 Proposal 

    Placing widgets with drag-and-drop can be tedious and annoying — especially if you have lots of sidebars on which to drop widgets. The Widgets team has been working on a few solutions (for this problem, and more), including redesigning the wp-admin widgets interface and adding the ability to manage widgets from within the customizer. These projects are still ongoing, and not ready for 3.8. However, along the way we’ve found a few incremental changes which improve the overall experience of working with widgets. Some of these improvements have made their way into MP6. Others involve more functional changes which don’t belong in MP6. This plugin is one of those improvements.

    The Widgets Area Chooser is available at: http://wordpress.org/plugins/widget-area-chooser/

    The Problem
    Dragging widgets from the available widgets in the top-left, to a sidebar “below the fold” is hard. Almost impossible. Dragging widgets on a touch screen device is also difficult.

    The Solution
    Clicking (or tapping) on an available widget brings up a list of available sidebars that you can place the widget in to — its pretty simple, and works great on touch devices.

    Accessibility
    There’s also the accessibility problems that drag-and-drop introduces, which necessitates the need for the separate (and often neglected) Accessibility Mode. This plugin provides a much easier way for those with screen readers to add new widgets without having to drag-and-drop. In fact, this could be the first step towards removing the need for an Accessibility Mode for widgets.

    Demonstration
    Here’s what the chooser looks like:

    Here’s a quick video of the plugin in action:

    Please let us know what you think!

     
    • william.deangelis 7:37 pm on November 4, 2013 Permalink | Log in to Reply

      Not bad. I assume that on mobile each of those two panels would be its own screen? If that’s the case then I say wicked. Go for it!

    • Jeff Behnke 8:20 pm on November 4, 2013 Permalink | Log in to Reply

      I like it. Solves the problems that need solving in the widget admin.

    • Bryan Petty 8:20 pm on November 4, 2013 Permalink | Log in to Reply

      Just wanted to say that I’m excited that you’re working on this @shaunandrews, and it’s coming along nicely.

      I’m still curious how well this UI handles with 3-5 widget areas, and maybe 50+ available widgets, and what happens with the stored/saved widget settings, but this really is a great start.

      • shaunandrews 1:43 am on November 5, 2013 Permalink | Log in to Reply

        Hey Bryan, thanks for the kind words — I’m super excited to be working on this!

        I think you may be getting the Widgets Area Chooser (WAC) plugin confused with the general layout updates as part of MP6 and the separate widgets project. This post is focused solely on the WAC plugin, which lets you click-to-add a new widget.

    • and0r1995 8:25 pm on November 4, 2013 Permalink | Log in to Reply

      I don’t know, I like the idea and stuff, but I personally prefer the drag and drop, Although when there are a lot of widget areas it’s a bit annoying.

    • Marcus 8:36 pm on November 4, 2013 Permalink | Log in to Reply

      I like this, already an improvement, nicely done!

      Aside from @bpetty ‘s point, another (minor) idea/tweak also is for UX just clicking on the area to place a widget instead of click area > add widget will save a click for non-default widget areas. The cancel button should probably still remain.

      • shaunandrews 1:47 am on November 5, 2013 Permalink | Log in to Reply

        …just clicking on the area to place a widget…

        I thought about that initially, primarily because it was one less new UI element to show on the screen — the widget areas are already there, just let the user click on them to add the selected widget. This caused two problems:
        1) It wasn’t immediately obvious what to click.
        2) It didn’t really solve the problem of the widget area being off the screen.

        If you have an idea on how to make this all better, please don’t hesitate to sketch it out and/or attend our chat on Monday at 20:00 UTC. Your thoughts and feedback is greatly appreciated. Thanks!

        • Luke McDonald 6:25 pm on November 8, 2013 Permalink | Log in to Reply

          My initial thought when trying this out for the first time was I would click on the widget area I wanted and the widget would be added to that area. I was testing on a theme that had 7 or 8 widget locations, which is why I didn’t see the “Add Widget” button below the chooser list.

          That said, for me it was *obvious* what to click, and I think it would be for many others too. It seems this functionality should replicate that of a select menu or your typical drop-down menu. In both cases, once you select an item, an action takes place.

          If it’s not immediately obvious for users the first time, it will be the next time they do it. I think after someone knows how it works, it would be preferred not to have to make an extra click or even scroll down to the “Add widget” button in cases where there are many widget areas.

    • mbootsman 9:17 pm on November 4, 2013 Permalink | Log in to Reply

      Major UI improvement. Thanks for developing this!

      • shaunandrews 1:49 am on November 5, 2013 Permalink | Log in to Reply

        Thanks for trying it — hope you like it. Please let me know if you find any problems, or have any suggestions for improvements.

    • Dan Milward 2:59 am on November 5, 2013 Permalink | Log in to Reply

      Awesome work man. I don’t know why but on one of my test sites the list of available widgets is on the right hand side of the screen instead of the left hand side of the screen. Its pretty weird.

      Also I hope the menus screen gets a similar overhaul.

      • shaunandrews 3:16 am on November 5, 2013 Permalink | Log in to Reply

        Perhaps you’re using an older version of MP6? Can you provide version details for WordPress, MP6, and the Widgets Area Chooser plugin? Also, what browser and OS? A screenshot would go a long ways as well.

    • Grant Palin 5:17 am on November 5, 2013 Permalink | Log in to Reply

      I like it. I’ve found the drag and drop setup a bit finicky before, and the click, click, click seems a usability improvement, especially when multiple widget areas are involved. Plus the UI fits nicely with the MP6 theme.

    • HerrLlama 11:19 am on November 6, 2013 Permalink | Log in to Reply

      I don’t like it. The UI is nice tough, but the usability is … well how could I say it neat? … a piece of crap. Now I drag and drop the widget on the wanted position in the wanted widget area. With this “improvment” I have to click on the widget, then I have to choose the area and than click I have to click the add button. But after all that I have to drag and drop the widget on the right position. Seriously, that makes it more complicate than it could be.

      • shaunandrews 2:51 pm on November 6, 2013 Permalink | Log in to Reply

        You can still drag-and-drop widgets in to place. You don’t have to click.

        • HerrLlama 3:57 pm on November 6, 2013 Permalink | Log in to Reply

          Yes, I already read this, but your proposal is a way more to confuse the users. WordPress itself said that they wanted to implement decisions, not options. It would help if we don’t work on the frontend for the widgets and create an API (e.g. add_widget_to_sidebar( $widget_type, $sidebar ) or stuff like that) which actually works.

          I agree, that the UI needs some improvements, but there are plenty of different screens of editing things (tags, posts, menus, widgets, options, etc) which also confuses the users. I think we should focus on a consistent backend before we implement new things. If not, I think that is a major problem of WordPress. Have you ever been to a Typo3 backend? Everything looks like it is in one pour.

          And also: Sorry for beeing rude, but I’m german ;)

      • Helen Hou-Sandi 3:20 pm on November 6, 2013 Permalink | Log in to Reply

        As @shaunandrews noted, this does not replace drag and drop; it provides an alternate method for those who can’t or don’t want to drag and drop for whatever reason. Also, you are being rude, and that is unnecessary.

      • Matt Thomas 6:19 pm on November 7, 2013 Permalink | Log in to Reply

        I would recommend re-reading the original proposal. Managing widgets is currently not possible on a mobile device because drag-and-drop is the only supported method of adding or removing widgets.

      • PeterRKnight 4:17 am on November 8, 2013 Permalink | Log in to Reply

        drag and dropping a position vertically is easy (on desktop), the issue with the current widgets screen that this improvement solves is about making it much easier to add widgets to widget areas without having to do acrobatics. Try dragging and dropping a widget on a screen that requires scrolling because there’s so many widgets and so many widget areas. This however is a major usability improvement for desktop as well as mobile.

    • bfintal 2:08 pm on November 11, 2013 Permalink | Log in to Reply

      I like it. This would solve the drag and drop problem in mobile versions also.

      This is just me, but a method of duplicating a widget would be helpful.

      • shaunandrews 2:46 pm on November 11, 2013 Permalink | Log in to Reply

        Yup, part of the goal with this was to improve the experience of adding widgets on mobile.

        This is just me, but a method of duplicating a widget would be helpful.

        This isn’t the first time I’ve heard this request, so you are not alone. :)

      • Weston Ruter 6:20 pm on November 11, 2013 Permalink | Log in to Reply

        Regarding duplicating a widget, there is this Duplicate Widget plugin and there is the Clone Widgets plugin. The former does a shallow-copy/symlink/reference for the widget, and the latter seems to do a clone or deep copy of the widget. Which use case are you interested in? Do these plugins do what you want?

  • shaunandrews 3:32 pm on August 14, 2013 Permalink
    Tags: , , widgets   

    Howdy everyone! There’s been a lot of discussion over the last week or two around widgets for 3.8. Inspired by @lessbloat, I’ve made a short survey with a few basic questions about widgets and how you use them. It you could, please take a few minutes to share your thoughts:

    Take the Widgets Survey

    Thanks!

     
    • pekz0r 5:21 pm on August 14, 2013 Permalink | Log in to Reply

      I think we should rethink the whole widget and rewrite of the whole widget API, not just the hot up the widgets screen.
      I want widgets to be a lot more flexible and pluggable. First of all, it should be extremely easy to create a widgets. Everything that should be needed should be a function/file/hook for the configuration form and one function/file/hook for the presentation. It would also be cool to have a widget repository like the repositories for plugins and themes so you can install new widgets with a simple click right in wp-admin.

      I would also like a simple solution for using these Widgets in the content areas, not just the sidebars. Maybe by using shortcodes to add a widet to a content area or, even better, just use them as objects(like videos and images) that you can resize and drag around. Widgets would be more like pluggable views than inflexible sidebar boxes.

    • Nashwan Doaqan 5:42 pm on August 14, 2013 Permalink | Log in to Reply

      Survey Completed :)

    • Sallie Goetsch 6:18 pm on August 14, 2013 Permalink | Log in to Reply

      The question about the number of sidebars is problematic. First, actual sidebars or widgetized areas? Second, which theme on which site?

  • Andrew Ozz 4:43 am on April 22, 2009 Permalink
    Tags: widgets   

    Widgets redesign 

    All of the redesigned widgets functionality is in place in trunk. Only remaining is some improvement to the visual design for the widgets screen in admin.

    The new way to add widgets to WordPress is by extending WP_Widget. All widgets created that way have support for multiple instances.

    Also all existing widgets will have to be converted to this system as the previous API functions will (most likely) be removed in 2.9. This is quite easy and any of the default widgets can be used as an example.

    A typical widget is constructed as follows:

    class WP_Widget_Archives extends WP_Widget {
    	function WP_Widget_Archives() {
    		$widget_ops = array('classname' => 'widget_archive', 'description' => __( "A monthly archive of your blog's posts") );
    		$this->WP_Widget(false, __('Archives'), $widget_ops);
    	}
    
    	function widget( $args, $instance ) {
    		// displays the widget on the front end
    	}
    
    	function update( $new_instance, $old_instance ) {
    		// update the instance's settings
    	}
    
    	function form( $instance ) {
    		// displays the widget admin form
    	}
    }
    
    // register the widget
    add_action('widgets_init', 'my_super_widget_init');
    function my_super_widget_init() {
    	register_widget('WP_Widget_Archives');
    }
    

    For more details and examples check wp-includes/widgets.php and wp-includes/default-widgets.php.

     
  • Ryan Boren 6:42 pm on March 27, 2009 Permalink
    Tags: widgets   

    Soliciting feedback on new Widgets API

     
    • amfprod 5:57 pm on April 3, 2009 Permalink | Log in to Reply

      Not related to the API, but I really hope when the new widgets page is updated it comes OUT of the Appearance tab and becomes its own tab. This really should’ve happened from the start. Widgets are too hidden away.

    • Charles 11:06 am on April 7, 2009 Permalink | Log in to Reply

      It’s good for WordPress, but not for me. The new Widgets API means I need update more than 10 widgets in the near future… …

    • Denis de Bernardy 6:51 pm on May 3, 2009 Permalink | Log in to Reply

      Apart from trac ticket #9703, which is deadly, it’s working well so far.

      One missing feature would be a WIDGET_DEBUG mode, that would place the server’s feedback in a special div tag at the bottom of the page — without needing to edit the WP code base and use a js debugger. Debugging a new widget’s upgrade scripts is mostly impossible without such a thing.

      Also, last I checked anyway, it broke old style multi-widgets. If it still does, it would be sweet that it didn’t — else, quite a few plugins will need to be rewritten. But that might be asking for the moon. :-P

  • Ryan Boren 5:51 am on March 18, 2009 Permalink
    Tags: widgets   

    Converting default widgets to the new widgets API.

     
  • Michael Adams (mdawaffe) 11:59 pm on March 13, 2008 Permalink
    Tags: , widgets   

    Nice – widgets are running into some integer overflow bug.

     
  • Michael Adams (mdawaffe) 1:07 am on March 1, 2008 Permalink
    Tags: widgets   

    Going to clean up the new widget interface so that cancel buttons really mean cancel.

    [5886]

     
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