Since we introduced the new widget editor and developer mode about a week ago, we've gotten some good internal and public feedback. We wanted to identify a few key changes to this functionality that resulted from that feedback.
Easier filtering within widget studio
Telligent Community 9.0 introduces the ability for plugins to render text using widgets. Most of the new management user experience is implemented this way. Each widget defined by a plugin can be enabled for editing and, in developer mode, all local-developer widgets are enabled for editing regardless of the plugin's configuration for the widget. Seeing front UI (traditional) widgets and plugin-defined widgets in a single list within the widget editor was confusing (especially in developer mode in preview 3). To better separate front-UI-targeted- from plugin-defined- widgets, the list and filters within the widget editor have changed.
Now, by default, only front UI widgets will be shown in the widget editor. The first filter within the editor will be changed to provide options to view:
- All front-UI widgets
- All user-defined / custom front-UI widgets
- All default front-UI widgets (widgets defined as part of the platform or an extension)
- All edited default front-UI widgets (customizations on widgets defined as part of the platform or an extension)
- Plugin-defined widgets (listed individually by the plugin that defines the widget)
This makes it much easier to find widgets associated to specific functionality while also uncluttering the filter when working within developer mode.
Developer mode factory default accessibility
Factory default widgets are used to provide the "out of the box" experience for core Telligent Community functionality as well as the base experience for 3rd party developers that wish to redistribute their extensions to the Telligent Community platform. Prior to the introduction of developer mode, the definition of factory default implementations required direct text file editing. Developer Mode is intended for developers to manage their factory default widgets using the widget editor within Telligent Community to make development, previewing, and integration with source control systems easier.
Preview 3 enabled factory default editing for all factory defaults, not just the factory defaults owned by the local developer. A problem could occur if a developer edited a factory default that had a deployment process that may conflict with the deployment process of the developer. Specifically, core Telligent Community widgets are installed from embedded resources in the Telligent Community assemblies. Any edits to these factory default widgets by 3rd party developers could be overwritten by the platform installation process.
To prevent this issue and better clarify developer mode as a tool for developers to manage their own factory default widgets, now only widgets that are defined via factory default widget providers within assemblies compiled in debug mode are available for direct saving (as a factory default). This will prevent developers from accidentally editing a factory default widget associated to a deployment process that may cause the local developer's edits to be overwritten.
Additionally, developer mode should never be enabled in a production environment. By editing factory default implementations of widgets in production, a site will have no available backup of the source implementation to revert to when edits introduce breaking bugs. To help prevent developer mode from being enabled in production sites, the developer mode enablement flag in web.config is now ignored if the active license is identified as a production license.
Deploying changes
There has been some confusion about best practices for promoting changes from development to QA/production environments. We'll be working on more complete developer training documentation soon, but, in the meantime, I'd like to highlight a few general notes:
Deploying factory defaults
Because factory default widgets, whether part of a plugin to implement custom UI or just for the benefit of source control when managing front-UI widgets, requires the implementation of a plugin, we recommend deploying widget files using an IInstallablePlugin (see the 8.5 example here). In 9.0, the recommendation remains to use an IInstallablePlugin, however, the widget files themselves can be edited within the platform widget editor and the installation process can make use of the Telligent.Evolution.Extensibility.UI.Version1.ContentFragments.UpdateScriptedContentFragments() API to automatically version and provide a review workflow for upgrades.
The UpdateScriptedContentFragments() API enables widget files, either embedded or deployed alongside an assembly, to be installed using the same process used by the platform for upgrades. This process automates:
- Incremental updates. Only files changed since the last deployment are installed.
- Widget versioning. When a widget is affected by a file update, the widget is versioned to be a custom widget and the underlying factory default is updated.
- Widget review. If any widgets are affected, the method provides a string message that can be presented to site administrators to review the modified widgets using the upgrade workflow:
- For platform upgrades, we send this message to the administrators of the site via the SystemNotification API.
- The message provides a link that enables an administrator to stage a reversion of all of the affected widgets.
- Once staged, the administrator can visually review the changes (if they are front-UI changes) and/or review the implementation changes via diffing within Widget Studio.
- Each widget is individually approved/denied and can then be committed to the site (or in this case, reverted on the site) by site owners.
This approach enables the deployment of updates (widgets and code) to a single or multiple customers by copying the release-built DLL into the production environment web and job server nodes without installation steps specific to individual file storage mechanisms. We'll have a complete example of implementing a deployment of factory default widgets using this technique soon after Telligent Community 9.0 is released.
Deploying other customizations
Other customizations should be limited to theme and page edits. Telligent Community 9.0 has improved support for migrating changes to a theme. Within each theme type and context, all changes can be exported as a single file. When importing into a QA or production environment, there are a few changes to note in version 9.0:
- All imports are staged. Staging imported changes enables previewing and the approve/deny workflow before committing changes to the site.
- Only changes are imported. To prevent reviewing items that haven't changed, only changes detected in imports are staged for previewing. If there are no differences, Telligent Community will identify that.
Note: Automating the deployment of customizations in bulk or group layouts requires a custom deployment process that is dependent on synchronizing databases and files between multiple environments -- this type of automation is environment specific and is not handled directly by the platform.
Other widget editor improvements
We've also incorporated improvements to the widget editor's user interface, including:
- Preview mode support from within Widget Studio
- Widget attachment uploading
- Widget Duplication via Save-As
- Widget Exporting
- Widget Theme Variants via Save-For-Theme
- Widget multi-select actions
- Diffing between edited defaults and defaults
- Widget-widget diffing overview, along with more developer-facing details on the overview
- Expandable detailed search results
- Language resource diffing
- More/improved keyboard shortcuts
- Alt-tab-style tab switching
- Performance improvements
- Many bug fixes
I hope that you've had a changes to install and try Telligent Community 9.0 Preview 3. If you have questions, please ask them in the preview forum.