New widgets interface

[mdawaffe]

Attached is a patch for the new widgets interface.

Features

1. Can filter widgets by simple search and/or whether or not you're currently using them.
2. Widgets can now be given descriptions (all core widgets have descriptions in this patch).
3. Addition/Removal via mouse clicks rather than drag and drop.
4. Sorting via drag and drop.
5. More or less friendly to those without JS: you can still add, remove, and update widgets without JS. You cannot currently change their order without JS.

Issues

1. Each widget has a save button, but it doesn't actually save the data. You need to click the "global" "Save Changes" button. The individual save buttons should maybe be relabeled "OK" buttons.
2. Cannot drag a widget from one sidebar to another.
3. The CSS for this page was kept separate from wp-admin.css do reduce conflicts during "The great redesign of fiscal year 2008". It's in wp-admin/includes/widgets.php:temp_widget_css() and should be unified and merged with wp-admin.css at some point.
4. The CSS is rough cut. It will need some polish.

Widgets can be written so that an arbitrary number of instances of that widget may appear in your sidebars. There is no longer a need for the hacky "How many text widgets do you want" UI.

Replacing that hack is another: widgets that want to allow multiple instances should accept a 'number' argument, provide an 'id_base' (so that unique widget ids can be constructed from {id_base}-{number}, and have a widget_control form that can be used as a template for generating control forms for each instance (and for new instances during JS on-the-fly).

Included in this patch are several examples (the text widget, the categories widget, the rss widget) of such "many instance widgets". Also included are some docs that:

1. Detail what a "many instance widget" control form should look like.
2. Offer a pattern for creating your own "many instance widgets".

These docs are located in a comment block at the end of wp-includes/widgets.php.

Things to note:

1. Widget id#s are no longer persistent across multiple updates. In order to prevent duplication or poisoning within or between different sidebars, widgets that allow mulitple instances will have widget ids that look like {id_base}-{timestamp . incrementor}.
2. The JS is not yet internationalized.

Everything should work cleanly, but please back any important widget data before testing this just in case.

[mdawaffe]

big

[ryan]

(In [6556]) Widget admin redesign from mdawaffe. see #5583

[ryan]

(In [6557]) Widget admin redesign from mdawaffe. see #5583

[zamoose]

GULP -- No worky, array errors all over the place. (Lines 650 and 1171 in particular)

[zamoose]

Warning: Invalid argument supplied for foreach() on 650, Warning: array_keys() [function.array-keys]: The first argument should be an array on 1171.

[zamoose]

Lines 650 and 1171 in widgets.php, that is.

[mdawaffe]

fix array marnings

[mdawaffe]

Replying to zamoose:

GULP -- No worky, array errors all over the place. (Lines 650 and 1171 in particular)

Try 5583b.diff above.

[darkfate]

That patch works. Just waiting for it to be commited.

[ryan]

(In [6560]) Fix some array warnings. Props mdawaffe. see #5583

[ryan]

interface.js is no longer maintained and has some incompatibilities with jQuery 1.2, which we're now using. Can we move to jQuery UI?

​http://docs.jquery.com/UI/Sortables

[ryan]

For sortables patch, see:

​http://trac.wordpress.org/ticket/5492#comment:21

[mdawaffe]

I've looked at jQuery UI, but have not had any success with it so far.

Its 1.0 release is not compatible with noConflict. Its trunk is broken. I haven't seen any working jQuery UI Sortable demos.

[zamoose]

@mdawaffe:
I guess the question then needs to be asked: is it worth continuing to operate in noConflict mode, given the fact that we're (ostensibly) removing all need for Prototype in the admin interface?

Is there any utility in forcing jQuery to work around a namespace that isn't in use?

[Nazgul]

Replying to zamoose:

Is there any utility in forcing jQuery to work around a namespace that isn't in use?

Maybe not in core, but what about all those plugins out there that still depend on Prototype?

[zamoose]

Replying to Nazgul:

Maybe not in core, but what about all those plugins out there that still depend on Prototype?

Hmmmm. Good point. Here I was, thinking that we were only concerned with the admin, but if the bundled jQuery we include stomps on $(), then I could indeed see that causing issues. Shazbot.

Has anyone filed a "make it work with noConflict" bug with the UI folk? *grin*

[mdawaffe]

I think trunk jQuery UI works with noConflict. Or would if it worked at all :)

[DD32]

Replying to Nazgul:

Replying to zamoose:

Is there any utility in forcing jQuery to work around a namespace that isn't in use?

Maybe not in core, but what about all those plugins out there that still depend on Prototype?

It would be possible to only set noConflict() mode if Prototype was loaded too perhaps?, But even then, That would mean we couldnt rely on $ being jQuery...

Unfortunately i think most plugins which load Prototype load it for the entire admin interface rather than just for their plugin page, I had that problem quite often when using jQuery's $() in my plugin interface. In the end i specifically deregistered the Prototype script on my plugins admin page and that fixed that.

[mdawaffe]

We definitely need to keep noConflict around for plugins.

The jQuery people themselves recommend using jQuery rather than $ most places: ​http://docs.jquery.com/Plugins/Authoring#Custom_Alias

Their recommendation on how to do that easily is a great one:

(function($) {
  // plugin code here, use $ as much as you like
})(jQuery);

That method also automatically makes it harder to contaminate the global JS namespace.

[ryan]

(In [6571]) Fix for widget sort with IE7. Props filosofo. see #5292 #5583

[filosofo]

Fix interface bug in IE7 and jQuery 1.2+

[filosofo]

I've attached some patches to fix the bug in IE7 in which Interface sortables don't work.

interface-fix.js is the actual fix, compressed

interface-fix2.diff reverts the hack in wp-admin/js/widgets.js, and it changes script-loader so that whenever someone queues Interface, the fix is queued afterwards.

interface-repacked.diff is just the fix applied to Interface directly, then Interface is repacked. This is an alternate solution to queuing the fix script.

[filosofo]

The actual fix for interface

[filosofo]

Alternative to the fix above: Interface fixed and repacked

[nbachiyski]

I18n for the new widgets interface. In the patch.

[ryan]

(In [6679]) Widget i18n from nbachiyski. see #5583

[ryan]

I forgot about the interface fixes. I'm fine with the fix and repack of interface.

[nbachiyski]

I have forgotten the changes in script-loader.php in the i18n patch. They are in the new patch.

[nbachiyski]

The part, which was left out in the previous i18n patch

[ryan]

(In [6692]) Widget i18n from nbachiyski. see #5583

[mdawaffe]

remove second set of link

[ryan]

(In [6719]) Remove eextra set of links. Props mdawaffe. see #5583

[ryan]

(In [6728]) Fix interface sortables for IE7. Props filosofo. see #5583

[mdawaffe]

5583d.diff

1. Move css to own file (replacing old widgets.css).
2. CSS and markup tweaks
3. Some changes to wp-admin.css for new design.
4. RTL it up.

[ryan]

(In [6754]) Widget interface updates from mdawaffe. see #5583

[bryan868]

Please add a "Save Changes" button at the TOP of the Widgets page, in addition to the bottom.