Actually this is only partially true. There are “hot areas” on a page being customized and there is nothing that forces any setting for those area to be opened in the navigation menu. In theory you can have a “lightbox” in which you will display the relevant settings form once the “hot area” is triggered.
The customizer menu is just for navigation, and it is obviously not the best UX, but that is not the only way to open the relevant settings.
A full replacement of the widgets admin in the customizer context just requires a smart UX, it is not something that has some unsolvable technical constraints.
It is worth keeping in mind that the widgets admin has a UX that is barely usable when you have many sidebars, and D&D is always a horrible thing when the targets are so small.
This is not quite true. If the widget has settings, you can put the widget into a sidebar without it showing on the site. As soon as you hit Save on the widget, it will show. I consider this an advantage over the Customizer, not something that is broken.
In my book anything for which there is no way to undo an operation is broken. When you have a widget with 20 options there is just no way you are going to remember what were the original settings.
Managing 20 options without seeing the result on the front end (which requires a save) is not fun at all.
(imagine a rant here about how instead of getting features to perfection core is busy chasing new buzzwords)
Widgets don’t automatically transfer to a new theme for some reason, so I always have to search for them under “Inactive.” And then drag and drop each one individually, which is a pain, especially since it’s such a long way from the “inactive” section up to the sidebars. I’d like to be able to just select and clip all at once, then paste them in the proper places.
Also, I have to use a third-party plugin to use a widget in the middle of a page. It’s not something I do often, but I’ve used it for blog archives pages with archive and “top post” type widgets.
The reason for this is because themes implement sidebars differently i.e. theme 1 might have sidebar-1 as the main Sidebar but theme 2 has sidebar-main or sidebar-top before sidebar-1 while Core has no way of figuring out where to place the widgets on change over.
The safe options is for Core to register a non visible sidebar (Inactive Widgets) and place the widgets there as a holding place without loosing their settings.
1: Categorize the widgets on the Widgets screen i.e. “Default” or “Core Widgets” will list the built in widgets. At the moment all widgets are listed under a single (category?) as “Available Widgets”
2: A plugin will list its own widgets under its own defined category.
3: The Categories should be collapsible i.e. an up/down arrow to show/hide available widgets ~ same as how the “Available Widgets” works now.
4: Allow themes to declare support via the add_theme_support( ‘list-of-supported-widgets’ ) function what widgets they wish to support.
5: Allow a way to filter which widgets are made available on the widgets screen.
6: An option to set widgets as available in the Customizer or not (a check box/switch on a widget itself for this would be awesome)
7: Default widgets should be revisited and revised to be more “CMS/Business” oriented rather than “Blog” oriented. The blog oriented widgets could be listed under the “Blog” category!
8: Make “Inactive” Sidebars/Widgets available in the Customizer. One list for each.
9: Design (A wish): Move the widget-description div inside the widget-top div so it sits under the widget-title. An icon could then be declared for Title using the ::before pseudo-element.
10: Pushing my luck here…A settings screen to allow grouping of “Favorite/Most used” widgets to override all other categorized sections ~ No more clutter and only what I have favored is listed on both the Widgets screen and the Customizer.
The “Inactive Sidebars/Widgets” should not be affected by #10. Also this might nullify some of the suggestions above
#9 is more for sprucing up the widget screen ~ make it more aesthetically pleasing
Additionally, shouldn’t the Inactive Sidebars be listed on the right under the Available Sidebars? This would make for a separation of Widgets on the left and Sidebars on the right.
This all sounds like it could be implemented in a core feature plugin to me, a new “Widget Manager” with a completely redone UI… This way the standard interface will still be available for accessibility, while allowing the new changes and improvements could go ahead on an optional (and experimental) management page.