xwp / wp-widget-customizer Goto Github PK

We have addressed this for hiding sidebars which aren't rendered in the customizer preview, but what about widgets that get skipped from being rendered in a sidebar by means of some plugin action? The forms for these widgets should be hidden.

Instead of having to look up the widget's control in the customizer, what if the widget's form could be brought in alongside the widget itself in the preview? There could be a Edit button that appears next to a widget when hovering over it, and when clicking it could make the widget form appear.

Most of the code in https://github.com/x-team/wp-widget-customizer/blob/1e3883f27811703bb252ab32c7f148cbbed6494e/widget-customizer.js#L112-L131 should be handled in the widget_form, e.g. overriding the link text and adding the tooltip. The deletion event should be handled by sidebar_widgets with delegation.

This will facilitate #3

Right now, if you remove a widget it will get moved to the Inactive Widgets “sidebar”. This also goes for widgets that you add but don't ever publish, like if you add a widget to a sidebar and then immediately remove it. This will probably result in the Inactive Widgets sidebar getting filled up with a lot of fragmented widgets which the user would not expect to be saved in the trash, since they were never properly saved to begin with.

For maximum compatibility with plugins, we need to ensure the templates are rendered inside of div#widgets-right as well. Or is that div#widgets-left?

See conversation at https://twitter.com/joemcasta/status/414937640970878976

The question here will be how plugins will indicate their icon. Currently we're filtering widget_icon_url so that plugins can indicate the path to a PNG image. But if we're using icon fonts, would this all be handled in CSS instead? Would a plugin just need to enqueue a stylesheet to appear on the widgets admin page and in the customizer?

See also http://core.trac.wordpress.org/ticket/25419

Builds on #58

Widget form controls are able to specify their widget, like if a widget's form needs extra space to be able to fit the fields inside of it. We should allow customize widget form controls in the customizer panel to expand outside of the sidebar area when they are expanded.

But how can a wide widget control expand over the preview?

When dragging a widget on top of another sidebar section, it should expand so that it can then be dropped inside (or there should be a minimum height).

Right now a new widget instance is not sent to the preview until it gets saved for the first time. This works well for widgets that depend on values being supplied, but for others it adds a needless extra Update step.

If an instance is updated for a widget which is not in an active sidebar, then the setting should get updated with the postMessage transport since there is no widget which needs to be rendered.

There is a alt_option_name fallback apparently for accommodating widgets that used option names that were not consistent with their IDs: https://github.com/WordPress/WordPress/blob/master/wp-includes/widgets.php#L293-L294

When loading widgets, do we need to account for this?

Addendum for #37

When you invoke wp_enqueue_media() it will:

add_action( 'admin_footer', 'wp_print_media_templates' );
add_action( 'wp_footer', 'wp_print_media_templates' );

But it won'tadd the action for customize_controls_print_footer_scripts as well. So we need to do it manually with something like:

add_action('customize_controls_init', function () {
    add_action( 'wp_enqueue_media', function () {
        add_action(
            'customize_controls_print_footer_scripts', 
            'wp_print_media_templates' 
        );
    } );
} );

Detection for whether or not a widget has a form defined may need to use the Reflection API to detect if the form method on the widget object is defined on the base class or if it has been overridden by the widget subclass.

When first loading the customizer, all sidebar sections are visible and then the ones not applicable to the current URL loaded into the preview are hidden once the preview loads. This is not the best experience. It would be better if all sidebar sections were initially hidden and then when the preview loads, they can animate to reveal.

Related to #9.

Allow updating of a widget without having to press Update. Will require opt-in by the widget, as only the widget itself knows when it is able to be sufficiently previewed (e.g. the RSS widget will error if the fields aren't all supplied). Maybe some JS to detect when the widget control form is populated enough to be submitted. Filter for opting-in to postMessage should be segmented into opt-in for live editing of all fields, not just when hitting Update.

Depends on #37

See http://core.trac.wordpress.org/ticket/25368#comment:6

See #15

When typing in a widget, if enter/return is hit, then the widget should get submitted.

Reported by @shaunandrews:

I'm getting an error. Looks like something happening with Jetpack: Warning: Invalid argument supplied for foreach() in /Users/shaunandrews/Sites/WordPress/wp-content/plugins/jetpack/modules/widget-visibility/widget-conditions.php on line 249

Either the Jetpack plugin is not extending widgets properly, or the Widget Customizer is not adequately setting up the environment for rendering widget controls in the customizer.

Just as there is a Delete link in the Widgets admin page for eliminating a widget from a sidebar, this same link should be in the widget form customizer control.

Relates to #3 (adding widgets)

Note that the widget control form currently hides the Delete button since it is not currently implemented:

When the preview window loads, it communicates to the host page to show only the customizer sections for sidebars that were rendered on the page. We're doing this just accessing jQuery in the parent frame and not using postMessage or the Customize Messenger library. I couldn't see quickly how to access the Preview instance to send more message from the window, because it is protected inside a closure.

Via FAQ:

How do I make one of those cool banners for my plugin page?
Start by creating an assets/ directory in the root of your SVN checkout. This will be on the same level as tags/ and trunk/, for example.

Inside that assets/ directory, you can make a file named "banner-772x250.png" or "banner-772x250.jpg". The image must be exactly 772 pixels wide and 250 pixels tall. No GIFs.

To support high-DPI (aka "retina") displays, you can additionally make a file named "banner-1544x500.png" or "banner-1544x500.jpg". The image must be exactly 1544 pixels wide and 500 pixels tall. No GIFs. This image, if present, will only be served when the website detects that the viewing browser is on a high-DPI display. Read this feature's announcement post for more details and special notes about creating this image.

After you check in your new banner(s), it will appear the next time the plugin refreshes itself in the directory. This may take a few minutes.

For development and testing, you can add a URL parameter to your plugin's URL of "?banner_url=A_LINK_TO_YOUR_IMAGE" to preview what the page will look like with your own image. This will only work with your own plugins, you can not use this parameter on anybody else's plugins.

See comment in #3, from @bobbravo2:

love the drop down for adding new widgets - that's what I was hoping for. What do you think about adding the Chosen jQuery plugin to enhance it with search (search a widget's description / title / possible alternate keywords for new users)?

It turns out that the customizer preview has a copy of the settings just like the customizer panel (parent frame), but if you change the setting in the preview window, it does not sync those changes to the settings in the parent frame. So when changing settings within preview they should propagate up to the parent customizer iframe settings. This will enable inline widget controls inside of the preivew.

Relates to #17.

Related to #73 (Factor out common customizer/preview functionality to widget-customizer-base.js)

The current scrollIntoView is woefully inadequate.

Builds on and #5 and #13

See #25

The standard .travis.yml should be updated to support Ajax unit tests automatically if they are available.

Change button from Primary to Secondary.

The facility for Options Transactions was introduced to add support for old single widgets, whose rendering functions also do updates. For new multi WP_Widgets, the render method does not do any saving to the DB, nor does the update method which just validates the input. If we can eliminate support for old single widgets, then we can simplify the logic for previewing widget changes.

See:
http://core.trac.wordpress.org/ticket/25368
http://core.trac.wordpress.org/changeset/25580

With these temp hooks, we can now reliably detect if a sidebar is used on a template, whereas before it would fail if the sidebars were empty.

Right now the method is:

add_filter( 'customizer_widget_live_previewable_{id_base}', '__return_true' );

But it would be nice if there was a way to supply this in the arguments supplied to the widget constructor:

class Lightbox_Widget extends WP_Widget {
    function __construct() {
        parent::__construct(
            'lightbox',
            __( 'Lightbox', 'lightbox-widget' ),
            array( 
                'description' => __( 'Displays a button which opens a lightbox to show the supplied content.', 'lightbox-widget' ),
                'customizer_support' => true,
            )
        );
...

See also comment on wordpress-dev by Nacin.

• First widget can't be added
• Clicking on the right side of widgets dropdown after hovering over dropdown options will add the last hovered option (not happening in Firefox Nightly)

Right now we're getting assertion warnings at https://github.com/x-team/wp-widget-customizer/blob/1b3f87e98631fda33f3dfb8966044a1aae64bdfd/widget-customizer.php#L261

Right now a widget's update callback gets fired (e.g. to ensure values are sanitized) when a widget form is updated and that update is previewed in the customizer. However, the updated widget instance is then not sent through the widget's update callback again when the customizer is saved. This means that there is currently a way for users to hack a widget's instance (bypass the update callback) by manipulating the widget's setting in JavaScript, since all the settings are stored in memory. This could be a security issue. I believe the widget update callback should be added to the customize_sanitize_* filter for each widget, if this is where the setting is filtered before saving to the DB. Each instance of the customizer control for widget forms can supply the update callback as the WP_Customize_Setting::$sanitize_callback parameter.

If a sidebar section is open and the Preview frame changes its URL to one on which the sidebar is not rendered, the section would abruptly toggle. It would be nice if the section would toggle with sliding animation, similar to the accordion for the sections. So the logic for hiding a section should first trigger the animation to close the section, and then should follow with collapsing the accordion tab.

Relates to #7

If a customizer section is empty of any controls, it will not get rendered. This causes problems for empty sidebars, since each sidebar is currently represented with a customizer section. This problem would be alleviated if we had a control which was added to each and every sidebar which was for the sidebars_widgets[sidebar_id] setting. This control could also be used for adding new widgets to the sidebar.

Relates to #15, #3

Since all widget form controls are shown in full when the customizer section is expanded, it can take up a lot of room and make it difficult to navigate to the desired widget. So they should all be presented in a minimized state, though not like an accordion since we want to be able to have multiple widget controls open at a time.

Currently the sidebar sections in the customizer will show/hide based on which sidebars are used on a given page (see #2). 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:

See also: http://make.wordpress.org/core/2013/12/16/better-widgets/#comment-12125

This is an extension of #29. When you click the link to Customizer from the admin notice, it should include a query string parameter like ?expand_sidebar_section=1 which would then be looked for in Widget Customizer JS, after the preview has loaded and has hidden any sidebars not located there (see #2), it should then auto-expand the accordion for the first sidebar appearing in the customizer panel.

Title sums it up - using the #3 "add new custom menu", doesn't add it to the view until you press save (or update, soon).

The labels are getting a white text color when they should be black:

After the plugin has been enabled, users may not be aware that widgets can be edited in the customizer. So there should be a prominent link to open the customizer, placed somewhere on the page.

Hello,

The Plugin is showing following warning when we load customzer and displaying everything fine.

Warning: assert() [function.assert]: Assertion failed in wp-content/plugins/wp-widget-customizer-new-widget-addition/widget-customizer.php on line 298

It's showing same for master file too.

thanks