#27112 closed task (blessed) (fixed)
Add widget management to the customizer
Reported by: | nacin | Owned by: | |
---|---|---|---|
Milestone: | 3.9 | Priority: | normal |
Severity: | normal | Version: | |
Component: | Widgets | Keywords: | |
Focuses: | Cc: |
Description
As decided last week, we're going to give the Widget Customizer plugin a go in core. This ticket is to track its initial merge, which ocean90 and I are heading up.
We're going to use the "Widgets" component for this.
Attachments (6)
Change History (60)
#2
in reply to:
↑ 1
@
11 years ago
Replying to nacin:
- What's liveFilter for? Is it needed? Can we do our own thing? The Themes page already has live searching.
Its what powers the widget search filter. If it can be replaced with something simpler, or similar to THX, then by all means...
#3
@
11 years ago
Important quick note: we have the 0.15 release for the plugin queued for releasing today. This has a bunch of fixes and features, including support for wide widget controls and live previews for widget changes as you type them (no need to click Update). Here's the current changelog: https://github.com/x-team/wp-widget-customizer/compare/0.14...master
#4
@
11 years ago
Version 0.15 has been released: https://github.com/x-team/wp-widget-customizer/compare/0.14...0.15
- Add support for wide widget controls by sliding them out horizontally over the preview. Props westonruter.
- Eliminate Update button and so preview updates with each input change for widgets that support live previews. Props westonruter.
- Make widget form controls more compact on smaller screen resolutions. Props michael-arestad.
- Improve styling of widget search field. Props shaunandrews.
- Rename "Update" button to "Apply". Props arnoesterhuizen.
- Prevent error when initializing sidebar containing unregistered widget. Props westonruter.
- Only show one widget form control expanded at a time. Props westonruter.
- Eliminate use of filter_input(). Props westonruter.
- Add live preview support for Twenty Fourteen Ephemera Widget.
#5
@
11 years ago
Does widget-customizer-preview.js share a lot of code with widget-customizer.js?
No. There are a couple little functions like widget_id_to_setting_id
which are duplicated, but otherwise they are unique. But I was thinking of creating a widget-customizer-base.js
that had these few common functions, and then make it a dependency for widget-customizer-panel.js
and widget-customizer-preview.js
.
#6
follow-up:
↓ 7
@
11 years ago
I'm curious whether the options transaction component is necessary. We built the customizer originally by simply storing values and passing them through option_* filters on the fly. I've looked at this a few times now, and I'm not sure what I'm missing?
As per our wordpress-dev chat today, I've reworked the Options Transactions into an Option Capture functionality. With the patch above applied to core, the following change to the plugin can be applied: https://github.com/x-team/wp-widget-customizer/compare/eliminate-options-transactions
Note that it does not currently support add_option
, for which there may be instances of a single widget declaring the option it saves into up front.
#7
in reply to:
↑ 6
@
11 years ago
Replying to westonruter:
Note that it does not currently support
add_option
, for which there may be instances of a single widget declaring the option it saves into up front.
On the other hand: since these are single-instance widgets, if the widget is already in use, then capturing update_option() is enough. If the widget is not in use, we don't care strongly if add_option() gets used. I see two potential side effects: if an option is conditionally (and oddly) initialized (low severity), and that it has the potential to mess with future defaults (low severity but probably pretty weird if you encountered it).
#8
@
11 years ago
That said, as long as we tracked and deleted add_option() calls, we could delete them after. That would solve our future defaults issue and would allow for a rollback for the conditional initialization issue. It would be muuch simpler than the older transaction methods, at least.
This ticket was mentioned in IRC in #wordpress-dev by nacin. View the logs.
11 years ago
#10
@
11 years ago
We discussed on IRC the removal of the current partial preview refreshing of widgets in favor of generalizing the functionality so that any customize control can add support for doing so; this partial preview refresh is key to keeping things DRY by eliminating the current requirement that all setting updates via postMessage
transport re-implement all rendering logic in JavaScript for components that are normally written out in PHP—but even when the render logic is attempted to be written in JS, it will never be able to account for any filters added in PHP.
For instance, with such partial preview refreshes, the Navigation Menu control needn't do a full refresh of the preview: the menu's container could be targeted for a partial refresh, where the new menu gets rendered via an Ajax request and the response replaces the old menu.
@nacin: I've created a branch for Widget Customizer and have ripped out the partial preview refreshing: https://github.com/x-team/wp-widget-customizer/compare/without-partial-previews
Hopefully this is helpful to you. Let me know if there's anything I can do to help with the merge.
#11
@
11 years ago
A few related tickets, some of which are dependencies:
- #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
- #25419: Add support to widgets for icons and screenshots
#13
follow-ups:
↓ 17
↓ 36
@
11 years ago
See bug #27291 related to this merge.
I also saw what I believe to be an unrelated issue: if I make a change to a widget, say its title, leaving focus in the input and then immediately click "Save & Publish" the setting does not get saved, even though I can see it in the preview. If I first click out of the input (blur) and then click "Save & Publish", the setting gets updated as expected. It sticks. I'll do more investigation.
#14
follow-ups:
↓ 15
↓ 16
@
11 years ago
This implementation for themes with a lot of widget sidebars adds too much to the customizer at the top of the list, if it can be prioritized to show after the rest are added that would be better otherwise it's a lot of scrolling to get to what people want to really use.
#15
in reply to:
↑ 14
@
11 years ago
Replying to Frumph:
This implementation for themes with a lot of widget sidebars adds too much to the customizer at the top of the list, if it can be prioritized to show after the rest are added that would be better otherwise it's a lot of scrolling to get to what people want to really use.
It makes more sense to me if the widgets come just before the menu section, considering that the Appearance Menu orders them Customize, Widgets, then Menus.
#16
in reply to:
↑ 14
;
follow-up:
↓ 42
@
11 years ago
Replying to Frumph:
This implementation for themes with a lot of widget sidebars adds too much to the customizer at the top of the list, if it can be prioritized to show after the rest are added that would be better otherwise it's a lot of scrolling to get to what people want to really use.
They should be moved to the bottom; it just didn't happen in the initial commit.
Please upload only SFW and appropriate screenshots, please.
#17
in reply to:
↑ 13
@
11 years ago
Replying to westonruter:
I also saw what I believe to be an unrelated issue: if I make a change to a widget, say its title, leaving focus in the input and then immediately click "Save & Publish" the setting does not get saved, even though I can see it in the preview. If I first click out of the input (blur) and then click "Save & Publish", the setting gets updated as expected. It sticks. I'll do more investigation.
See #27338
#20
follow-up:
↓ 21
@
11 years ago
Live widget updates don't seem to be functioning in Twenty Fourteen as of beta 1. The page appears to be refreshing after a delay rather than updating live.
#21
in reply to:
↑ 20
;
follow-up:
↓ 31
@
11 years ago
Replying to ScottSmith:
Live widget updates don't seem to be functioning in Twenty Fourteen as of beta 1. The page appears to be refreshing after a delay rather than updating live.
This is expected. All widget changes now trigger a preview refresh. See comment above: https://core.trac.wordpress.org/ticket/27112?replyto=20#comment:10
For now, if your server is slow, or your site is very front-end heavy, you will notice a preview refresh.
This ticket was mentioned in IRC in #wordpress-dev by DrewAPicture. View the logs.
11 years ago
#24
follow-up:
↓ 25
@
11 years ago
Tested it with Twenty Twelve and Twenty Fourteen by adding add_theme_support('widget-customizer');
but that didn't work.
#25
in reply to:
↑ 24
;
follow-up:
↓ 27
@
11 years ago
Replying to puneetsahalot:
Tested it with Twenty Twelve and Twenty Fourteen by adding add_theme_support('widget-customizer');
but that didn't work.
What specifically does not work? The add_theme_support( 'widget-customizer' )
call is not used by the Widget Customizer merged into core. It was used only by the plugin, and the features that this would have enabled have been captured in #27355.
#26
@
11 years ago
Hi,
I think will be fine to add the possibility to order widgets or to keep the same order like on widgets section. The widgets should be after the navigation section.
#27
in reply to:
↑ 25
;
follow-up:
↓ 43
@
11 years ago
Replying to westonruter:
Replying to puneetsahalot:
Tested it with Twenty Twelve and Twenty Fourteen by adding add_theme_support('widget-customizer');
but that didn't work.
What specifically does not work? The
add_theme_support( 'widget-customizer' )
call is not used by the Widget Customizer merged into core. It was used only by the plugin, and the features that this would have enabled have been captured in #27355.
Sorry. Must have been an issue with my WP version.
It works fine now.
@victortihai : I agree, widget order should be same as on widgets page.
+ There should be a way to access widgets under "inactive widgets"
#28
follow-up:
↓ 29
@
11 years ago
Page reloads while adding content to a widget and then widget doesn't expand.
E.g. : added a text widget and while I was typing (pretty fast), the page reloaded and here's how it appears when I expand the widget
Next, I tried to test Archives Widget, while I was adding a title for the widget the same thing happened.
#29
in reply to:
↑ 28
;
follow-up:
↓ 30
@
11 years ago
Replying to puneetsahalot:
Page reloads while adding content to a widget and then widget doesn't expand.
E.g. : added a text widget and while I was typing (pretty fast), the page reloaded and here's how it appears when I expand the widget
Next, I tried to test Archives Widget, while I was adding a title for the widget the same thing happened.
This issue was reported in #27291. I have a patch there attached to the ticket which resolved the issue related to adding new widgets to the customizer.
#30
in reply to:
↑ 29
@
11 years ago
Replying to westonruter:
Replying to puneetsahalot:
Page reloads while adding content to a widget and then widget doesn't expand.
E.g. : added a text widget and while I was typing (pretty fast), the page reloaded and here's how it appears when I expand the widget
Next, I tried to test Archives Widget, while I was adding a title for the widget the same thing happened.
This issue was reported in #27291. I have a patch there attached to the ticket which resolved the issue related to adding new widgets to the customizer.
Thanks @westonruter
I am new to Trac. Sorry for any inconvenience caused.
#31
in reply to:
↑ 21
;
follow-up:
↓ 32
@
11 years ago
Replying to westonruter:
Replying to ScottSmith:
Live widget updates don't seem to be functioning in Twenty Fourteen as of beta 1. The page appears to be refreshing after a delay rather than updating live.
This is expected. All widget changes now trigger a preview refresh. See comment above: https://core.trac.wordpress.org/ticket/27112?replyto=20#comment:10
For now, if your server is slow, or your site is very front-end heavy, you will notice a preview refresh.
Should rearranging widgets in the sidebar trigger a preview refresh? Apparently everything I do with the widget section requires the site to refresh—local and remote server alike.
#32
in reply to:
↑ 31
;
follow-up:
↓ 33
@
11 years ago
Replying to ScottSmith:
Should rearranging widgets in the sidebar trigger a preview refresh? Apparently everything I do with the widget section requires the site to refresh—local and remote server alike.
Yes. Everything would cause a refresh of the preview currently. The refresh requirement will be addressed in #27355. But what do you mean "local and remote server alike"? Local how?
#33
in reply to:
↑ 32
@
11 years ago
Replying to westonruter:
Replying to ScottSmith:
Should rearranging widgets in the sidebar trigger a preview refresh? Apparently everything I do with the widget section requires the site to refresh—local and remote server alike.
Yes. Everything would cause a refresh of the preview currently. The refresh requirement will be addressed in #27355. But what do you mean "local and remote server alike"? Local how?
By "local," I meant on a MAMP server since you mentioned that a noticeable preview refresh could be because of a slow server. I wasn't saying that the preview was slow though. I was under the impression that when widgets are re-ordered the sidebar should update without a preview refresh. It's hard to find the latest information on this.
#34
follow-up:
↓ 35
@
11 years ago
Questions regarding this.
- If the widget area does not have any active widgets in the widget area, does it show that widget area in the customizer?
- Say your home page template has widgets dedicated to that template page. If you are viewing another page in the customizer (i.e. blog), does it show all widget areas in the customizer. For example: the home page dedicated widget areas.
I don't think much of this could happen, based on how I believe the customizer works, but thought i'd ask.
#35
in reply to:
↑ 34
@
11 years ago
Replying to adampickering:
- If the widget area does not have any active widgets in the widget area, does it show that widget area in the customizer?
Yes, if the widget area is used in the template being previewed (i.e. the widget area is rendered with a dynamic_sidebar()
call), then the customizer section for that widget area would be displayed, even if the sidebar is empty (depending on #25368) or if all of the widgets in the sidebar are not active for the currently previewed URL. If a widget is not rendered in the template (e.g. it is turned off via Jetpack's Widget Visibility) then the widget control will have a translucent appearance. (I just noticed Widget Visibility doesn't work currently, but I see the fix.)
Replying to adampickering:
- Say your home page template has widgets dedicated to that template page. If you are viewing another page in the customizer (i.e. blog), does it show all widget areas in the customizer. For example: the home page dedicated widget areas. I don't think much of this could happen, based on how I believe the customizer works, but thought i'd ask.
If only the front-page.php
template, for example, uses a dynamic_sidebar( 'home' )
then the customizer section for that widget area will only appear in the customizer when the home page is being previewed in the customizer. Note that you can navigate around the site within the customizer, or you can navigate to an arbitrary page and then enter the customizer from that page to then open the customizer previewing that URL. As you navigate around the site in the customizer, the widget area sections will show/hide based on which widget areas are used in the template.
@
11 years ago
Enqueue customize-widget.js in footer for compat with Jetpack Widget Visibility, and remove overrides for that specific plugin. Patch is also located on a branch on GitHub: https://github.com/x-team/wordpress-develop/compare/master...customizer-widget-visibility A corresponding Jetpack patch has also been submitted via https://github.com/Automattic/jetpack/pull/349
#36
in reply to:
↑ 13
@
11 years ago
Replying to westonruter:
See bug #27291 related to this merge.
I also saw what I believe to be an unrelated issue: if I make a change to a widget, say its title, leaving focus in the input and then immediately click "Save & Publish" the setting does not get saved, even though I can see it in the preview. If I first click out of the input (blur) and then click "Save & Publish", the setting gets updated as expected. It sticks. I'll do more investigation.
@nacin: This has been addressed in #27390. @ocean90 please review, as it introduces some new plumbing to the customizer. I believe this to be a very important patch to include, as right now it is very easy for the race condition to result in a failure to save the widget settings as the user expects.
#37
@
11 years ago
By the way, for each ticket related to Widget Customizer, I have a feature branch on our GitHub clone of develop.git.wordpress.org: https://github.com/x-team/wordpress-develop/branches
Each commit (patch) added to any of these feature branches (tickets) I'm also merging into a common widget-customizer-patches
branch so that the patches can be seen in relation to each other and so that conflicts can be discovered: https://github.com/x-team/wordpress-develop/compare/widget-customizer-patches
#38
follow-up:
↓ 39
@
11 years ago
There's some debug cruft in customize-widgets.js, see 27112.2.diff.
#39
in reply to:
↑ 38
@
11 years ago
Replying to kovshenin:
There's some debug cruft in customize-widgets.js, see 27112.2.diff.
Debug cruft also removed in patch on #27291: https://core.trac.wordpress.org/attachment/ticket/27291/27291.2.diff
This ticket was mentioned in IRC in #wordpress-dev by westonruter. View the logs.
11 years ago
#42
in reply to:
↑ 16
@
11 years ago
Replying to nacin:
Replying to Frumph:
This implementation for themes with a lot of widget sidebars adds too much to the customizer at the top of the list, if it can be prioritized to show after the rest are added that would be better otherwise it's a lot of scrolling to get to what people want to really use.
They should be moved to the bottom; it just didn't happen in the initial commit.
Addressed in #27401
#43
in reply to:
↑ 27
@
11 years ago
Replying to puneetsahalot:
@victortihai : I agree, widget order should be same as on widgets page.
Addressed in #27401
Replying to puneetsahalot:
+ There should be a way to access widgets under "inactive widgets"
Addressed in #27404
This ticket was mentioned in IRC in #wordpress-dev by westonruter. View the logs.
11 years ago
@
11 years ago
Add pre_update_option filter, replace Options_Transaction with Option_Update_Capture. https://github.com/x-team/wordpress-develop/pull/1/files
Some particular things we've noticed so far:
Where things should be merged: