Can’t use plugin inside a widget

Hmmm, this is not clear at all. The plugin adds a widget and I am not aware that you can use a widget inside a widget. Maybe you should describe your actual problem and maybe we will be able to help you with it?

@loiruca We described to use our widget with page builder plugins in all faq pages we know:

https://tiptoppress.com/faqs/
https://www.ads-software.com/plugins/category-posts/

Please search on this two faq pages for: “How Category Posts Widget work with SiteOrigin Page Builder“, “How Category Posts Widget work with Divi Builder” and “How our widgets works with other page builder plugins like Elementor, Thrive Architect etc.“

When I added the widget from the SiteOrigin Page Builder the options weren’t clickable, so I couldn’t set the options to what I wanted to show and it had a message to buy the premium plugin. I assumed these options would only work if I bought the plugin. I already deleted this plugin and using another one. Thanks!

• This reply was modified 6 years, 11 months ago by loiruca.

Hi loiruca,

I work for SiteOrigin and I saw your review so I wanted to reach out to lend a hand. Unfortunately, I can’t seem to replicate this issue. I know you really don’t want to, but can you please elaborate on what you weren’t able to click on specifically? We would really appreciate it. I was able to click on all of the available options in the widget and I don’t have the premium version of this plugin. Maybe I overlooked a specific setting.

Hi kometschuh,

We’re definitely willing to work with you guys to fix and any all issues. We’re really sorry about this review.

@alexgso There is a special improvement we wish for you SiteOrigin Page Builder plugin. At your ‘rows’ you can add widgets like in the widget area admin (Appearance > Widgets > Sidebar), but the SiteOrigin Page Builder ‘rows’ don’t add all HTML elements and CSS styles like the widget area admin it do. Than why our widget admin UI don’t work at your ‘rows’.
The workaround is to add a editor widget at your ‘rows’ and place our widget as shortcode.

That behavior is the same with the free version here, this is not the point free or pro.

If you are interested, we can have a short Skype session for showing you this few steps. Please write us here: https://tiptoppress.com/blog/

Hi kometschuh,

That’s odd. Specifically, what CSS is not outputting that otherwise does when using the standard widget area? Does it work as desired when you enable the Sidebar Emulator (or disable it if it’s already enabled)? You can find this setting by navigating to WP Admin > Settings > Page Builder and open the General tab.

The issue is still adding our widget directly to our ‘rows’ our JS and CSS is not loaded because some ‘trigger’ are different or lack, e.g. for JS ‘widget-added widget-updated’ or do_action( ‘admin_print_scripts-widgets.php’ ); is not called. Than Select2 doesn’t work in our widget admin UI … I don’t know why ??

If disable Sidebar Emulator and get the same result as enabled.

Anyway with my test all options can be clicked also at the SiteOrigin Page Builder ‘rows’.
The options can be clicked, but it does not look so pretty.
How to get it to bring our widget completely to a standstill, I can not say.

So it is better for us if the users use the workaround, as we describe it on our site or on YouTube, in the FAQs, etc.

Hi Daniel,

Did you receive an email from us? For reference, the email I used was [email protected].

Ah, sorry, my bad – I had thought you were talking about frontend related changes which is why I suggested changing the Sidebar Emulator.

To allow other plugins to include page builder specific scripts, we don’t trigger admin_print_scripts-widgets.php. Instead, we recommend adding an action for siteorigin_panel_enqueue_admin_scripts. If you don’t plan on using different scripts, simply use the same function you’re currently using widgets.php.

I would recommend giving this compatibility article a quick read.

I’ve put in a request for widget-added and widget-updated. We do however offer alternatives. user_edit is equivalent to widget-added and close_dialog is kind of like widget-update although data is only saved once the user saves the page itself – close_dialog is triggered when the user closes the widget itself.

The good news is we implement the native triggers and actions. Thank you @alexgso.

Anyway we would like to share with you our view of your concept of triggers and actions that we do not fully understand.

If we implement some native code from you, we’ll release this code untested, because we couldn’t test all versions of your plugin and don’t know if you will change anything in your code.

And the bad thing is, you give us no other chance!

You would expand WordPress functionality, there for you have to ‘copy’ an equivalent widget area or the customizer. But don’t support all trigger and actions which WordPress do.

As I know, your aim with your SiteOrigin Page Builder isn’t that developer expand your SiteOrigin Page Builder or write some add-ons. Your aim will be that your SiteOrigin Page Builder works with widgets from other developers? That’s a big difference!

We don’t want write add-in code only for your SiteOrigin Page Builder, we want write code which works with WordPress (widget admin and the customizer), your SiteOrigin Page Builder and with all widgets and plugins.

Why do you implement ‘WordPress functionality’ for other widgets and implement only the half or do it native? ??

For us it will be much clearer you add all WordPress trigger and actions and have additional SiteOrigin specific trigger and actions, for developer which want to develop specific add-ons only for your SiteOrigin Page Builder?

Greetings
Daniel

Hi Daniel,

I can’t personally answer those questions (as it was before my time), but I can however state I’ve logged this as an issue on our GitHub. The current issue is specific to your plugin but it’ll expand to be more general down the line.

Based on the suggested hooks in my previous reply, your code will likely be compatible with 2.4 to the latest version.

Yes, we implement your suggestion and release a patch version and it works now.

But this is really the point, I don’t know if it work because I have to test our widget against your widget.

We will very happy, if we can get rid of this not secure code within our widget code!

Here is the commit we solve and implement your native trigger and actions. It’s not much changed code only the mentioned three places: https://github.com/tiptoppress/category-posts-widget/commit/6162862e4a85a721342f2ad8fb17228e2a9ad84b