Observations on Disabling and Renaming Toolbox Widgets

Posted by Community Admin on 03-Aug-2018 17:56

Observations on Disabling and Renaming Toolbox Widgets

Sitefinity - General Discussions

All Replies

Posted by Community Admin on 24-Mar-2012 00:00

I am interested in further discussion / documentation / pointers to blog posts on this topic.
I have observed the following about configuring Toolbox Widgets*

- You can disable a widget in the toolbox config and it will remove it from the toolbox, but not from any existing pages where it was used. This appears to be a decent way to depreciate a widget from your site as it will prevent any new uses of the widget.

<!-- In ToolboxesConfig.config -->
<!-- Disabled this widget from the toolbox by setting enabled to false -->
<add enabled="False" type="~/Custom/Foo.ascx" title="Foo" description="Displays all Foo automatically" cssClass="widFooIcn" layoutTemplate="~/Custom/Foo.ascx" visibilityMode="None" name="FooControl" />


- You can rename a widget (name and/or title) and it will rename it in the toolbox, and on any future uses of it, but not on any prior uses of it. Example: If I rename a widget called "FOO" to "BAR", it will still be called "FOO" anywhere I used it prior to the change.

<!-- In ToolboxesConfig.config -->
<!-- Updated Foo to Bar in name and title -->
<add enabled="True" type="~/Custom/Foo.ascx" title="Bar" description="Displays all Bar automatically" cssClass="widFooIcn" layoutTemplate="~/Custom/Foo.ascx" visibilityMode="None" name="BarControl" />


- To this end, you can have a page with the "FOO" widget, rename the widget in the toolbox config to "BAR" and then add "BAR" to the page and have both "FOO" and "BAR" on the same page...which are essentially the same thing. However, once you remove "FOO", you cannot re-add it as it is no longer available in the Toolbox. (well it IS, but it is now called, "BAR")

I assume all of this stems from the fact that the widget config is in an XML file - it defines the object. But once the widget is used on a page - an instance is created and the relevant settings are moved over to the Sitefinity database. The widget instance lives in the database for the rest of its lifespan on the site.

We are looking at renaming a poorly named early release custom widget on a big installation. Likewise, I will be investigating the quirks of upgrading or replacing the custom control (widget) code, and the documentation doesn't yet cover maintenance issues such as this. Any thoughts? other observations?

=====================
* To configure toolbox widgets either edit the toolboxesConfig.config or use the web GUI  via Administration > Settings > Advanced > Toolboxes > Toolboxes > Page Controls > Sections > ...  In both cases the toolboxesConfig.config XML file is adjusted, but the database is not.

Posted by Community Admin on 24-Mar-2012 00:00

So what I don't know at this time is:

- Is there a safe way to rename all existing instances of a widget? I assume it will require a SQL statement or OpenAccess command to update the database.

- Is there a way to determine all the pages a widget is used on? (we have 250 pages, and I don't relish the thought of manually checking/testing each one)

- Is there a safe way to remove all existing instances of a widget? Let's say I have a widget called "Really Bad Idea - CPU hog" that was used on 200 of my pages. Can I pull it without a lot of manual work? I assume this one is challenging as page changes generally need to be 'published'. And I'm not sure how pulling it will affect old page revisions. (Thankfully my widget is more along the lines of "really ugly menu" ;-)

In any case, I appreciate comments to this thread to help the general understanding of long term widget maintenance. Regardless, I'll be updating it as I find out the answers.

Posted by Community Admin on 25-Mar-2012 00:00

I have observed the following while investigating whether I can replace or update a user control mapped to an existing widget:

- You CAN update an existing user control registered as a toolbar widget, both its logic and its public properties as long as it keeps the same type in the Toolbox Config. The changes will appear on existing instances of the widget in your published pages. Logic changes will go into effect immediately. Added properties will be available if you click 'edit' to view widget properties, but will use your default value or blank until you set a value in each instance. I have not tested to see if I can remove public properties, but I assume that would be problematic.

<!-- In ToolboxesConfig.config -->
<!-- Foo.ascx was updated with improved logic and public props and recompiled, but we ARE NOT changing this config file -->
<add enabled="True" type="~/Custom/Foo.ascx" title="Foo" description="Displays all Foo automatically" cssClass="widFooIcn" layoutTemplate="~/Custom/Foo.ascx" visibilityMode="None" name="FooControl" />


- If you redirect an existing toolbox widget in your toolbox config to a new/different user control (type), it will NOT update any existing instances of that widget on published pages. This behavior is closely related to the ability to rename a widget as mentioned in my initial post. Since you can rename a title or name on a widget, the unique key used to map the database instance to the configuration is the type. Therefore, if you need to change the type, you will actually depreciate the old type by removing it from the toolbox and create a new type by registering your new control - even if you use the same name and title. No new instances of the old widget will be created, but any existing ones will remain until you remove or replace them on your pages.

<!-- In ToolboxesConfig.config -->
<!-- Foo.ascx was replaced with Bar.ascx, but we are keeping the same name, title -->
<!-- While this will still appear as Foo in the widget toolbar, Sitefinity will treat it as a brand new widget since the type has changed -->
<add enabled="True" type="~/Custom/Bar.ascx" title="Foo" description="Displays all Foo automatically" cssClass="widFooIcn" layoutTemplate="~/Custom/Bar.ascx" visibilityMode="None" name="FooControl" />

Posted by Community Admin on 25-Mar-2012 00:00

This is not something I've tested specifically, but I thought you might find this helpful. In the SDK is a sample Sitemap module, where I needed to get all pages that had a specific control (newsview) on them. Using the Fluent API I was able to run the following Query:

var NewsPages = App.WorkWith().Pages().Where(p => p.Page != null && p.ShowInNavigation && p.Page.Controls.Where(c => c.ObjectType.StartsWith(typeof(NewsView).FullName)).Count() > 0).Get();

Perhaps if you replace the ObjectType with the path (for user control) it will return the pages with that control. From there you can retrieve the individual controls (newsview in this case)

var newsView = page.Page.Controls.Where(c => c.ObjectType.StartsWith(typeof(NewsView).FullName)).First();

and remove it from the collection or make changes to it. Just remember that properties need to be retrieved in a special manner because of the way Sitefinity stores control properties. Here I'm accessing the ProviderName of that newsView control

var controlDefinition = newsView.Properties.Where(p => p.Name == "ControlDefinition").FirstOrDefault();
var providerNameProperty = controlDefinition.ChildProperties.Where(p => p.Name == "ProviderName").FirstOrDefault();

again, I haven't tested this with user controls, but I thought it might give you a place to start. Please let me know if you have any luck, or if you have issues as I'd love to explore this further!

This thread is closed