goldenapples

Should be. I haven’t heard any reports of plugin conflicts which aren’t fixed by setting that conflict flag.

The only reason we don’t do that by default is because it means loading an additional ~75K of javascript on admin pages.

Oh.

We recently updated the version of select2 that we use in order to maintain compatability with some related projects (like Customize Posts) that use the latest version. In doing so, we inadvertantly broke compatability with plugins like WooCommerce that are still using the older version.

To work around this, we’ve added an option to load our version completely separate from the version loaded for other plugins and not try to share code. You can enable this option by adding the following line to your wp-config.php file:

define( ‘SELECT2_NOCONFLICT’, true );

More information here.

Closing this as a duplicate, but please reopen if the update has not resolved the conflicts.

(Sorry, just working through the open support tickets.)

Have you tried setting the SELECT2_NOCONFLICT flag? If you still see conflicts with that flag enabled, I will reopen this as a bug report, but I have not seen any cases of plugin conflicts that aren’t resolved by that fix in the latest version of Shortcake.

Yes, the problem as far as it’s been reported to me has been fixed in Shortcake 0.7.1.

If you are using Shortcake and other plugins which depend on the ‘select2’ script, the fix for it is to make sure you’re updated to 0.7.1 of Shortcake, and add the following line to your wp-config.php file:

`
define( ‘SELECT2_NOCONFLICT’, true );
`

This will load the version of select2 which Shortcake depends on using a different name, so that it doesn’t conflict with any other plugins that need it.

That is terrible.

Have you tried the 0.7.1 update with the SELECT2_NOCONFLICT option? As far as I’ve seen, that should fix all the compatability issues which I’ve seen reported.

This was held up for a while. However, with the recent update to use Select2 4.0, this should be possible, at least for the fields that are implemented using select2. I believe (though I haven’t delved into it yet) that overriding the field’s templateSelection and/or templateResults methods should be all that’s required.

Curious what you mean by “pulling those styles”? If a theme has editor styles registered, then those styles should cascade down to the mce-view iframe housing the shortcode preview.

@ladybird12 Yes, it is possible to register Shortcake UI for shortcodes that take inner content as a parameter. There’s an example in the Shortcake Demo plugin showing how to register inner content as an attribute with Shortcake.

Hi!

With the latest version (0.7.0), there’s an “Add Post Element” button added to the media buttons, which brings up the Insert Post Element panel in the media frame. We think this will address this issue for most cases.

If you want to disable this button for any reason, this code will do the trick:

remove_action( 'media_buttons', array( Shortcode_UI::get_instance(), 'action_media_buttons' ) );

How did you install the plugin? The version on Github (but not the version in the plugin directory) includes an example plugin (it will show up in the shortcode-ui folder as dev.php).

You can safely delete that file, as it’s only intended to be used as an example for developers to build shortcodes with.

Sorry, development was slow for a while, but the plugin is actively being maintained. A new version (0.7.0) was just released and should be available in the plugin directory.

Never mind. The packed code is fine. Didn’t remember how easy it was to run it through jsBeautify and see the original source.

I still think that including the source would be a good idea.

I came across that same issue, and would like to add a request for an option to remove the linebreaks.

What I did to work around it was to remove the wpautop filter from the content and add a modified version which doesn’t add those linebreaks. Here’s some code that should work:

remove_filter( 'the_content', 'wpautop'          );
add_filter   ( 'the_content', 'wpautop_nobreaks' );

function wpautop_nobreaks( $text ) {
	return wpautop( $text, false );
}

I just pushed up a new version that fixes this problem – try updating to Version 0.3 and see if it works for you?

The problem was a deprecated jquery function which apparently no longer worked after WP upgraded its core version of jQuery. Its kind of strange that it even worked in Firefox…