Aurora: Text/HTML widget configuration

sleslie99 think of each widget (regardless of html, handlebars, or react) as its own black box. The widget can then be placed onto a page template. If you add a widget to the header / footer template, it will appear on every page like a global announcement. If you place the widget on a forum board template, that widget will appear on every forum board page across the app. If you place the widget on a page template for a specific set of forum boards only, then the widget should only appear only when viewing those specific forum boards. 

HTML widgets are meant for non developers to easily use the editor to get some rich text message out there quickly. They do not support any dynamic logic or coding. 

Handlebars and react components do support logic, configuration variables, and coding. This means a single widget could have multiple options or permutations that load dynamically based on the configuration variables an admin can set when adding / configuring the widget or based on other properties like the node id or the user. This means you could create one widget and add it to all forum board pages but the logic in the widget could determine to show only for specific users, on speicific boards, only when the forum board is public vs private or any other custom field / variable you’d want to specify as part of the configuration of the widget. 

If you want to create a list of recommended documents you could look at using the featured content widget which can be configured per node. You'd simply add the featured content widget to the template, and then each node admin could edit the list and control their own list of recommended documents.

We had a similar idea for the HTML widget, right now we only support static HTML widgets, but we have a concept where you could place an empty html widget on the template and allow each group owner / node owner to edit the HTML themselves. They couldn't change the template or where the widget appears but they could have control to edit the text for group specific announcements, etc. This could kind of be done today using node specific page templates but that would be burdonsome to do for each and every place, which is why this dynamic html widget idea was introduced.

The featured content and places widget works this way today. We still need to develop the dynamic HTML option.

NickH chimed in while I was typing. 

"Dynamic HTML" widget is what I will be building ASAP on my community.

I did that by adding just a basic Featured Content widget in the Group Dashboard template and another one in the Forum discussion template.

Pros:

• The Group Dashboard page is natively segregated in that widget for each Group location - so the featured content can be specific to that Group.
• It works for ANY content records in the entire community.
• It works for the GroupHub owner permission

Cons:

• It ONLY works for content links (not external URLs or other text).
• In the right hand nav all of the default styles are huge (dominating the page) - doesn't give a good small "list" of links.
• You can only do this really for the GroupDashboard template - because Forum Templates (Dashboard and Discussion) are global templates...so adding a featured content widget into the Forum in a Group adds it to every Forum dashboard (or discussion).

So far, I've only got that running in private groups - if this doesn't make sense, or if it does and you wanna see it in person - I'm happy to show you 1x1 what I mean. PM me to chat.

AND - adding more dynamic widgets on the GroupHub template is one of the first customizations I have planned once React becomes publicly available (in 24.6).
Group Dashboard pages NEED more flexibility than they have OOTB - in my opinion.

Are there any more details about what HTML/code is supported? Requirements, formatting, anything like that? 

Does this widget support any template markup comparable to Freemarker so we can access contextual information? Or is it plain HTML only?

GlennD and Claudius – I'm looking into these questions and will update you both when I have more information!

There are three ways to build a custom widget that can be added to PageBuilder.

The first is the one documented here, which is the simple HTML widget that you can create from the UI. This enables folks to use the RTE to create text based announcements, images, embedded videos, bullet lists, links to content, external links, etc. The restrictions are similar to what you can do in content with the RTE / HTML mode. This can leverage the new link previews feature for richer HTML previews for over 700+ sites.

The next option, if you have web dev skills, is to use the SDK to create a Handlebars component. Handlebars is a template language similar to Freemarker that we use for email templates and more complex web components. Handlebars supports full HTML, script tags, GraphQL API queries, custom css, etc.

The final option is a much more advanced option to build and compile custom react components. This will enable you to build components in react and leverage our library of shared react components to make it easier to render forms, trigger modals, generate lists of content, users, etc. This will be the preferred method for build more advanced integrations or dynamic web views. 

Once a widget is developed, it appears in the list of components in page builder, so you can easily add / move / remove and even configure parameters for the widget via the configuration tools just like OOTB widgets.

HTML and Handlebar components are available now. The react components are in development and planned for delivery in Q1.

We have an issue where a custom html/text edit widget is replicating across different areas even though we had customized different widgets for different purposes. What are we doing wrong? NickH 

sleslie99 - if you mean the previous classic "custom content" capability?

Where you add an HTML Text field to the template and then at each node you can have different HTML displayed via the "variables" in the custom content fields?

If that is what you mean...then my understanding is "Not Possible" until option three from NickH above comes to fruition (React Components) currently scheduled, according to the roadmap, for July 2024; this month.