Note: HTML5 widgets theme support in 4.2 has been reverted pending a decision about the correct container to use

With the upcoming WordPress 4.2 release, widgets have been added to the growing list of HTML5 supported markup. Once you’ve added HTML5 support for widgets, WordPress will use the <aside> element, instead of the generic list markup.

To declare that your theme supports HTML5 widgets, add the following call to your theme’s functions.php file, preferably in a callback to the after_setup_theme action:

add_theme_support( 'html5', array( 'widgets' ) );

For forward compatibility reasons, the second argument cannot be omitted when registering support. Otherwise, a theme would automatically declare its support for HTML5 features that might be added in the future, possibly breaking it visually.

If there are any questions about the current implementation, feel free to leave a comment below.

Wrote a plugin a few years back that did this quite well. https://wordpress.org/plugins/html5-widgets/. The only thing I’m seeing here that is missing that is quite easy to add is assignment of the what html5 wrapper is used. For instance a nav menu should likely be wrapped in the tag rather than an.

Just a quick heads up. We’re going to be changing the markup to sections instead of asides. The reason is because there are accessibility concerns that come into play by proliferating ARIA landmarks. This change should happen soon, and I’ll update the post once a changeset exists.

In my themes I’ve used section for widgets, and the sidebar is an aside element. So I like this idea. However wouldn’t there be semantic issues using sections without an appropriate wrapper? Should this feature come with such a recommendation?

Yes, some mention of using an aside or another sectioning element to wrap your widget sections should be added to the docs. I believe the semantically correct markup would also include adding a title to the aside for the document outline, but is not strictly required.

I agree, it would be nice, though is out of the scope of the current patch. As well, there already exists a Trac issue for this at https://core.trac.wordpress.org/ticket/10976 Granted it’s more that a little old. I’ll look into refreshing that patch for 4.3, as the 4.2 enhancement deadline has passed.

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:

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:

I am getting a lot of negative feedback in my onlin ecommunity about things being broken in 3.9, new features are one thing but breaking millions of sites just to add some whizzbang feature that nobody asked for is dumb.

It would be better to require such feature to require activation, that way you do not screw up the display or function of existing wordpress sites.

I’m using 3.9, but I’m not sure all of the above widgets fixes are live. Even when I do a LivePreview of a theme (without activating it), it seems to remove the widgets from the presently active theme (e.g. TwentyFourteen). Has anyone else experienced this or have a fix?

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!

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.

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

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:

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.

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

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

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

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.

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.

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.

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

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.

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.

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.

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.

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.

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

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.

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.

Overview

Drag to Deactivate

Expanded Description

Saved Feedback

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.

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

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.

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.

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

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?

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!

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

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.

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.

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!

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.

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.

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.

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.

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.

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.

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.

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?

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:

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.

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.

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.

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