Skip to content

initial sortables implementation#14

Closed
bobbravo2 wants to merge 12 commits into
xwp:developfrom
bobbravo2:develop
Closed

initial sortables implementation#14
bobbravo2 wants to merge 12 commits into
xwp:developfrom
bobbravo2:develop

Conversation

@bobbravo2

Copy link
Copy Markdown
Contributor

No description provided.

@bobbravo2

Copy link
Copy Markdown
Contributor Author

Some of the @todo items I have questions about:
What's the best way of refreshing the customizer after sorting (wp.customize.trigger('refresh'))?
What's the best place to initialize the sortables (see WidgetCustomizer.InitalizeSortables()) ?

Also, Need to test with multiple sidebars, as I'm sure the jQuery selectors are not specific / name-spaced enough.

Comment thread widget-customizer.php Outdated

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bobbravo2 can you explain how plugins_url is being used here? I don't understand the duplicated self::PLUGIN_DIR. Also, here's another symlink-friendly method for obtaining the plugin URL:

    /**
     * Not using plugin_dir_url because it is not symlink-friendly
     */
    function get_plugin_path_url( $path = null ) {
        $plugin_dirname = basename( dirname( __FILE__ ) );
        $base_dir = trailingslashit( plugin_dir_url( '' ) ) . $plugin_dirname;
        if ( $path ) {
            return trailingslashit( $base_dir ) . ltrim( $path, '/' );
        } else {
            return $base_dir;
        }
    }

Perhaps that could just be added to the Widget_Customizer class as a static method, and then we could just use self::get_plugin_path_url( 'widget-customizer-preview.js' )

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm fine with adding the static method. To be honest - I just added a wp() API function to get the proper path to get it up & running.

@bobbravo2

Copy link
Copy Markdown
Contributor Author

What's next team? I'm new to working on a team 👍

@bobbravo2 bobbravo2 mentioned this pull request Sep 27, 2013
13 tasks
@bobbravo2

Copy link
Copy Markdown
Contributor Author

Ok - my initial reactions on adding a new class that extends WP_Customize_Control, is that it feels a bit overkill. Also, since we're not using the control's renderer (render_content() callback) to display any user facing interface.

Although - I haven't looked too deeply into the API in terms of adding data to a control, and having the control handle the customize(d) view. That may outweigh my perceived drawbacks.

What about storing a temporary option in the wp_options table - and then filtering the display_sidebar order when the customizer is active? That approach would also allow us to add "sidebar" locking to prevent 2 users from customizing the sidebar at the same time.

@westonruter

Copy link
Copy Markdown
Contributor

@bobbravo2 sorry for the delay. I've just pulled in your commits to the issue (#1) and created a branch (issue-1-reordering) dedicated for that issue, so that we can use that branch to collaborate; so I'm closing this PR. You can continue pushing commits up to your develop branch and I'll merge them in along with commits that I add. I'll follow up with some commits on the issue-1-branch about what I have in mind for using a Customize Control for storing the widget order and then you can take a look and we can evaluate it together. I'm technically on vacation this week, so I've been less able to be on my computer 😄

fnakstad added a commit to knishiura-lab/wp-widget-customizer that referenced this pull request Feb 5, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants