diff --git a/docs/.vitepress/config.js b/docs/.vitepress/config.js
index 743b0dfb2..6e6bf6f00 100644
--- a/docs/.vitepress/config.js
+++ b/docs/.vitepress/config.js
@@ -107,6 +107,14 @@ export default ({ mode }) => {
           collapsed: false,
           items: [
             { text: 'Introduction', link: '/contributing/' },
+            {
+              text: 'Building Widgets',
+              collapsed: false,
+              items: [
+                { text: 'Adding Core Widgets', link: '/contributing/widgets/core-widgets' },
+                { text: 'Third Party Widgets', link: '/contributing/widgets/third-party' }
+              ]
+            },
             {
               text: 'Guides',
               collapsed: false,
@@ -114,7 +122,7 @@ export default ({ mode }) => {
                 { text: 'Repo Structure', link: '/contributing/guides/repo' },
                 { text: 'Events Architecture', link: '/contributing/guides/events' },
                 { text: 'Layout Managers', link: '/contributing/guides/layouts' },
-                { text: 'Adding Widgets', link: '/contributing/guides/adding-widgets' }
+                { text: 'Registering Widgets', link: '/contributing/guides/registration' }
               ]
             }
           ]
diff --git a/docs/contributing/guides/registration.md b/docs/contributing/guides/registration.md
new file mode 100644
index 000000000..a5f720981
--- /dev/null
+++ b/docs/contributing/guides/registration.md
@@ -0,0 +1,179 @@
+# Widget Registration
+
+Every `ui-base`, `ui-page` and `ui-group` has a `.register` function. The core registration function can be found in `ui-base`.
+
+This function is used by all of the widgets to inform Dashboard of their existence, and allows the widget to define which group/page/ui it belongs too, along with the relevant properties that widget has and any event handlers (e.g. `onInput` or `onAction`).
+
+The function is called within the node's Node-RED `.js` file, and in th case of a widget registering as part of a group (the most common use case), wuld look something like this:
+
+```js
+module.exports = function (RED) {
+    function MyNode (config) {
+        // create node in Node-RED
+        RED.nodes.createNode(this, config)
+        // store reference to our Node-RED node
+        const node = this
+
+        // which group are we rendering this widget
+        const group = RED.nodes.getNode(config.group)
+
+        // an object detailing the events to subscribe to
+        const evts = {}
+
+        // inform the dashboard UI that we are adding this node
+        group.register(node, config, evts)
+    }
+
+    RED.nodes.registerType('ui-mywidget', MyNode)
+}
+```
+
+## Arguments
+
+The registration function inputs differ slightly depending on whether being called on the `ui-group`, `ui-page` or `ui-base`:
+
+- `group.register(node, config, evts)`
+- `page.register(group, node, config, evts)`
+- `base.register(page, group, node, config, evts)`
+
+Note though, they do all have 3 inputs in common:
+
+### `node`
+
+This is the `this` of your node's constructor, and can be used directly from the value provided from Node-RED.
+
+### `config`
+
+This is made available by Node-RED as the input to the constructor, and can generally passed straight into the `.register` function without modification, it will be an object that maps all of the properties and values that have been described in the node's `.html` definition.
+
+### `evts`
+
+We expose a range of different event handlers as part of the `register` function. All of these handlers run server (Node-RED) side.
+
+In some cases, it is possible to define full functions (that will run at the appropriate point in the event lifecycle), in other occassions, it's only possible to define a `true`/`false` value that informs Dashboard that you wish for the widget to send or subscribe to that event.
+
+A full breakdown of the event lifecycle can be found [here](../../contributing/guides/events.md).
+
+```js
+const evts = {
+    onAction:   // boolean
+    onChange:   // boolean || function
+    beforeSend: // function
+    onInput:    // function
+    onError:    // function
+    onSocket    // object
+}
+```
+
+## Events
+
+All of these event handlers define behaviour that is run server-side (i.e. within Node-RED). If you're looking for client-side event handlers see [here](../widgets/third-party.md#configuring-your-node).
+
+### `.onAction` (`boolean`)
+
+When set as `true`, this flag will trigger the default handler when the Dashboard widgets sends an `widget-action` event.
+
+1. Assigns the provided value to `msg.payload`
+2. Appends any `msg.topic` defined on the node config
+3. Runs `evts.beforeSend()` _(if provided)_
+4. Sends the `msg` onwards to any connected nodes using `node.send(msg)`
+
+An example of this is with `ui-button`, where the widget's `UIButton` contains an `@click` function, containing:
+
+```js
+this.$socket.emit('widget-action', this.id, msg)
+```
+
+This sends a message via SocketIO to Node-RED, with the topic of the widget's ID. Because the `ui-button` has `onAction: true` in it's registration, it will consequently run the default handler detailed above.
+
+### `.onChange` (`boolean` || `function`)
+
+Similar to `onAction`, when used as a boolean, this flag will trigger the default handler for an `onChange` event. 
+
+#### Default `onChange` Handler
+
+1. Assigns the provided value to `msg.payload`
+2. Appends any `msg.topic` defined on the node config
+3. Runs `evts.beforeSend()` _(if provided)_
+4. Store the most recent message on the widget under the `._msg` property which will contain the latest state/value of the widget
+5. Sends the `msg` onwards to any connected nodes
+
+#### Custom `onChange` Handler
+
+Alternatively, you can override this default behaviour by providing a custom `onChange` function. An example of this is in the `ui-switch` node which needs to do `node.status` updates to in order for the Node-RED Editor to reflect it's latest status:
+
+```js
+onChange: async function (value) {
+    // ensure we have latest instance of the widget's node
+    const wNode = RED.nodes.getNode(node.id)
+    const msg = wNode._msg || {}
+
+    node.status({
+        fill: value ? 'green' : 'red',
+        shape: 'ring',
+        text: value ? states[1] : states[0]
+    })
+
+    // retrieve the assigned on/off value
+    const on = RED.util.evaluateNodeProperty(config.onvalue, config.onvalueType, wNode)
+    const off = RED.util.evaluateNodeProperty(config.offvalue, config.offvalueType, wNode)
+    msg.payload = value ? on : off
+
+    wNode._msg = msg
+
+    // simulate Node-RED node receiving an input
+    wNode.send(msg)
+}
+```
+
+### `.beforeSend(msg)` (`function`)
+
+This middleware function will run before the node sends any `msg` to consequent nodes connected in the Editor (e.g. in `onInput`, `onAction` and `onChange` default handlers). 
+
+The function must take `msg` as an input, and also return `msg` as an output.
+
+In `ui-button`, we use `beforeSend` evaluate the `msg.payload` as we have a `TypedInput` ([docs](https://nodered.org/docs/api/ui/typedInput/). The `TypedInput` needs evaluating within Node-RED, as it can reference variables outside of the domain of the button's node (e.g. `global` or `flow`). The default `onInput` handler then takes the output from our `beforeSend` and processes it accordingly.
+
+### `.onInput(msg, send)` (`function`)
+
+Defining this function will override the default `onInput` handler. 
+
+#### Default `onInput` Handler
+
+1. Store the most recent message on the widget under the `node._msg`
+2. Appends any `msg.topic` defined on the node config
+3. Checks if the widget has a `passthru` property:
+    - If no `passthru` property is found, runs `send(msg)`
+    - If the property is present, `send(msg)` is only run if `passthru` is set to `true`
+
+#### Custom `onInput` Handler
+
+When provided, this will override the default handler.
+
+We use this in the core widgets in Dashboard with `ui-chart`, where we want to be storing the history of recent `msg` value, rather than _just_ the most recent value as done in the default handler. We also use it here to ensure we don't have too many data points (as defined in the `ui-chart` config).
+
+Another use case here would be if you do not want to pass on any incoming `msg` payloads onto connected nodes automatically, for example, you could have a bunch of command-type `msg` payloads that instruct your node to do something, that are then not relevant to any preceding nodes in the flow.
+
+### `.onError(err)` (`function`)
+
+This function is called within the handlers for `onAction`, `onChange` and `onInput`. If there is ever an issue with these handlers (including those custom handlers provided), then the `onError` function will be called.
+
+### `.onSocket` (`object`)
+
+This is a somewhat unique event handler, that is only used by externally developed widgets (i.e. not part of core Dashboard widgets detailed in this documentation). It is provided so that developers can `emit`, and consequently subscribe to, custom SocketIO events that are transmitted by their custom widgets.
+
+You can see a more detailed example in our documentation [here](../widgets/third-party.md#custom-socketio-events).
+
+The general structure of `onSocket` is as follows:
+
+```js
+const evts = {
+    onSocket: {
+        'my-custom-event': function (id, msg) {
+            console.log('my-custom-event', id, msg)
+        }
+    }
+}
+```
+
+Note that these events are emitted from the Dashboard, and so, these handlers are run within Node-RED.
\ No newline at end of file
diff --git a/docs/contributing/guides/adding-widgets.md b/docs/contributing/widgets/core-widgets.md
similarity index 85%
rename from docs/contributing/guides/adding-widgets.md
rename to docs/contributing/widgets/core-widgets.md
index c3f2de30b..cbd132839 100644
--- a/docs/contributing/guides/adding-widgets.md
+++ b/docs/contributing/widgets/core-widgets.md
@@ -1,6 +1,8 @@
-# Adding New Widgets
+# Adding New Core Widgets
 
-When adding a new widget, you will need to follow the steps below to ensure that the widget is available in the Node-RED editor and renders correctly in the UI.
+We are always open to Pull Requests and new ideas on widgets that can be added to the core Dashboard repository.
+
+When adding a new widget to the core collection, you will need to follow the steps below to ensure that the widget is available in the Node-RED editor and renders correctly in the UI.
 
 ## Checklist
 
diff --git a/docs/contributing/widgets/third-party.md b/docs/contributing/widgets/third-party.md
new file mode 100644
index 000000000..d91771cb0
--- /dev/null
+++ b/docs/contributing/widgets/third-party.md
@@ -0,0 +1,290 @@
+# Building Third Party Widgets
+
+If you have an idea for a widget that you'd like to build in Dashboard 2.0 we are open to Pull Requests and ideas for additions to the [core collection](../../nodes/widgets.md) of Widgets.
+
+We do also realise though that there are many occassions where a standalone repository/package works better as was very popular in Dashboard 1.0.
+
+## Basic Folder Structure
+
+The following explanation of how to build your own third party widgets will reference the [Example Node](https://github.com/FlowFuse/node-red-dashboard-example-node) that we've open sourced, showing various integration examples of features available.
+
+As with any Node-RED nodes, you'll need to start with two files:
+
+- `/nodes/ui-example.html` - defines the node’s properties, edit dialog and help text.
+- `/nodes/ui-example.js` - defines the node's server-side behaviours
+
+Each Widget in Dashboard also consists of a `.vue` file to define how a widget is rendered in the Dashboard front-end.
+
+- `/ui/UIExample.vue` - Defines the contents the `<template>` of a Vue component
+
+Finally, any functions that you want to define, that will run as part of your client-side Vue component, can be defined in a standalone module.
+
+- `/ui/methods.js` - Defines a collection of client-side Vue/JS functions.
+
+## Registering your Node & Widget
+
+_More details: [Registration](../guides/registration.md)_
+
+Traditionally with Node-RED, you have to register your node using `RED.nodes.registerType("ui-example", UIExampleNode)`, this is still the case with Dashboard, but you must _also_ register the widget with Dashboard too.
+
+Dashboard registration is built upon is a `.register()` function (see [docs](../guides/registration.md)). This function is available to any `ui-base`, `ui-page` or `ui-group`. For `ui-group` and `ui-page`, it brokers the function up to the `ui-base` where a store is maintained of all widgets in the Dashboard.
+
+Your widget should define one of these as a property in your Node-RED node, most likely, it'll be `ui-group`, if you want your widget to render _inside_ a Group in the Dashboard.
+
+In your `/nodes/ui-example.js` file:
+
+```js
+module.exports = function(RED) {
+    function UIExampleNode(config) {
+        RED.nodes.createNode(this, config);
+        var node = this;
+
+        // which group are we rendering this widget
+        const group = RED.nodes.getNode(config.group)
+
+        config.type = 'ui-example'     // provide a relevant widget type 
+        config.templateScope = 'local' // required by ui-template
+
+        /**
+         * Further config & setup to go here
+         */
+
+        // register the widget with Dashboard
+        group.register(node, config, evts)
+    }
+    // Register the node with Node-RED
+    RED.nodes.registerType("ui-example", UIExampleNode);
+}
+```
+
+## Configuring your Node
+
+The following is a summary of the the Node-RED node configuration parameters (`config`) available, when registering your widget with Dashboard's `.register` function:
+
+```js
+group.register(node, config, evts)
+```
+
+You can extend this as much as you need to in order to add further customisation to your widget. All of these options are then made available in your widget's `.vue` file via the `this.props` object.
+
+### Essential Config Options:
+
+You must choose _one_ of these properties to include such that your Widget has a direct owner. Whichever you choose, you'll then use that owner's `.register()` function to register your widget.
+
+You must expose this option in your node's `.html` file too so that users can define which instance (of `ui-group`, `ui-page`, `ui-base`) your widget will be bound to.
+
+|property |  description |
+|--|--|
+| `group`  | The most common use case, where your widget will render as part of a Group in the Dashboard. |
+| `page`   | If your widget should be constrained to a full/single page, then this is appropriate. |
+| `base`   | If your widget performs independant of any page/group, then bind it to the `ui-base`. |
+
+The following properties should then _all_ be defined, and can be done so in your node's `.js` file constructor.
+
+|property | example | description |
+|--|--|--|
+| `type`           | `ui-example`   | A suitable, lowercase, kebab-case type for your widget |
+| `templateScope`  | `local`        | Required by `ui-template` that all third=party widgets extend |
+| `format`         | `<p>Hello</p>` | A string of HTML to render for your widget |
+| `head`           | see [example](#injecting-head-tags-dependencies)    | An object detailing the relevant `script`, `meta`, `style` or `link` tags to add. |
+
+### Optional Config Options:
+
+These options, whilst defined server-side, are passed to the client-side Vue component, and are used to customise the client-side behaviour of your widget.
+
+|property | example | description |
+|--|--|--|
+| `onMounted`  |     | Stringified function to run when your widget loads in Dashboard. |
+| `onInput`    | see [example](#defining-oninput-functionality) | Stringified function that will run client-side, whenever your node receives an input in Node-RED. |
+| `methods`    | see [example](#custom-functionality) | An object, where each key is the method name, and the value is a stringified function. These methods will then be exposed to your widget via the widgets's Vue component. |
+
+
+## Example Configurations
+
+Here, we go into detail about how to define the various config options available to you.
+
+### Injecting `<head>` Tags & Dependencies
+
+A likely scenario is that you'll want to inject some `<script>` tags into the `<head>` of your Dashboard's UI, in order to load dependencies for your custom widget. To do this, you can set `config.head`, for example:
+
+```js
+config.head = {
+    script: [
+        { type: 'text/javascript', defer: 'defer', src: 'https://code.jquery.com/jquery-3.7.1.min.js' },
+        { type: 'text/javascript', defer: 'defer', src: 'https://cdnjs.cloudflare.com/ajax/libs/d3/7.8.5/d3.min.js' }
+    ]
+}
+```
+
+This will then be rendered into the head as follows:
+
+```html
+<script
+    defer="defer" src="https://cdnjs.cloudflare.com/ajax/libs/d3/7.8.5/d3.min.js"
+    data-template-name="My Widget"  data-template-id="e1sa12jwc"
+    data-template-scope="local">
+</script>
+```
+
+Note that Dashboard will also inject `data-` attributes to detail the source of any tag added dynamically so that you have full visibility on _where_ the tag came from when needing to debug, etc.
+
+With this same mechanism, you can also define `<meta>` (for site description and meta data) or `<link>` tags (for custom CSS and fonts), e.g:
+
+```js
+config.head = {
+    meta: [
+        { name: 'description', content: 'A custom description of the page' }
+        { name: 'viewport', content: 'width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no' },
+    ],
+    link: [
+        { rel: 'stylesheet', type: 'text/css', href: 'https://fonts.googleapis.com/css?family=Roboto' }
+    ]
+}
+```
+```
+
+
+### Defining HTML to Render
+
+The `ui-template` (which your third-party widget will extend) relies on a `format` property to define the relevant HTML to render, as a result, we can inject our own content with something like:
+
+
+```js
+fs.readFile(path.join(__dirname, '../ui', 'UIExample.vue'), 'utf8', (err, html) => {
+    config.format = html
+})
+```
+
+This will read our `UIExample.vue` as a string, and then bind it to the node.
+
+### Defining `onInput` Functionality
+
+Here we can define functionality that runs client-side (in the Dashboard) whenever the node receives a `msg` in Node-RED.
+
+The contents of `onInput` are written as if contained within a `.vue` file, this means that you can use `this` freely and access any relevant `data`, `props` or `methods` as you wish, and even manipulate the widget's HTML e.g:
+
+```js
+function onInput (msg) {
+    // because this will get evaluated client-side, we have access to vue/this
+    const vue = this
+    // get an elemnt of the DOM inside this widget with a ref="my-widget", and update it's innerHTML
+    vue.$refs['my-widget'].innerHTML = msg.payload
+    // call Dashboard's built-in .send() function
+    vue.send({
+        payload: 'Created onInput'
+    })
+}
+```
+
+Note the use of VueJS's `$refs` for DOM selection - you can read more about this [here](https://vuejs.org/guide/essentials/template-refs.html).
+
+In our `ui-example.js` file, we can append this to our `config` with:
+
+```js
+// import our client-side functions
+const methods = require('../ui/methods')
+
+// methods that will be available to the widget in the Dashboard
+config.onInput = methods.onInput
+```
+
+### Custom Functionality
+
+We can extend VueJS's [methods](https://vuejs.org/api/options-state.html#methods) by using `config.methods`:
+
+```js
+// methods that will be available to the widget in the Dashboard
+config.methods = {
+    test: methods.test
+}
+```
+
+These functions can be called directly from your `.vue` file too, e.g:
+
+```vue
+<p @click="test()">
+    This is a 3rd Party Widget
+</p>
+```
+
+As with the [Defining onInput Functionality](#defining-oninput-functionality) you also have access to the full `vue` object, e.g:
+
+```js
+function test () {
+    // because this will get evaluated client-side, we have access to vue/this
+    const vue = this
+    
+    // log the Widget's ID & name
+    console.log(this.id, this.props.name)
+}
+```
+
+## Custom SocketIO Events
+
+It is also possible to extend our own [Events Framework](../guides/events.md) with your own events traffic, sending events from the Dashboard UI back into your node.
+
+Definition needs to happen in two places:
+
+- Client - where you need to `emit` the event
+- Node-RED - where you need to listen to those events, and define appropriate handlers
+
+### Emit from Dashboard
+
+You can `emit` an event from within any of your [Custom Functionality](#custom-functionality) using the in-built `vue.$socket.emit()` function, e.g:
+
+```js
+// emit 'my-custom-event' with a topic of the widget's id, and msg of { payload: "Test" } 
+vue.$socket.emit('my-custom-event', this.id, {
+    payload: "Test"
+})
+```
+
+### Handle Event in Node-RED
+
+The event handlers can be added to our `evts` object passed into the `.register` function, like so:
+
+
+```js
+const evts = {
+    onSocket: {
+        'my-custom-event': function (id, msg) {
+            console.log('my-custom-event', id, msg)
+        }
+    }
+}
+group.register(node, config, evts)
+```
+
+## UI Template Functionality
+
+Because we wrap third party widgets in a `ui-template` node, you have access to the same properties & functions.
+
+### Properties
+
+- `id` - The Widget's ID, assigned by Node-RED
+- `props` - Properties defined in Node-RED, e.g. `this.props.name` or `this.props.group`
+
+For example, we could loop over all properties and render their respective property key:
+
+```vue
+<h1>Widget ID: {{ id }}</h1>
+<ul>
+    <li v-for="(value, key, index) in props">
+        <label>{{ key }}</label>
+    </li>
+</ul>
+```
+
+### Functions
+
+- `send` - Send a `msg` (defined by the input to this function call) from this node in the Node-RED flow.
+
+Let's consider:
+
+```vue
+<p @click="send({'payload': 'Hello World'})">
+    This is a 3rd Party Widget
+</p>
+```
+
+This, when clicked, will send a `msg` in Node-RED to any nodes connected to the output of this node.
\ No newline at end of file
diff --git a/docs/getting-started.md b/docs/getting-started.md
index 22a2bd4bf..e9c1ba958 100644
--- a/docs/getting-started.md
+++ b/docs/getting-started.md
@@ -52,3 +52,5 @@ The sidebar offers you a central place to manage your pages, groups and widgets.
 ## Contributing
 
 If you would like to run this set of nodes locally, and specifically to help contribute to the development efforts, you can read the [Contributing](./contributing/index.md) documentation.
+
+If you'd like to build your own standalone nodes & widgets that integrate seamlessly with Dashboard 2.0, you can read our guide on that [here](./contributing/widgets/third-party.md).
\ No newline at end of file
diff --git a/docs/nodes/config/ui-base.md b/docs/nodes/config/ui-base.md
index 1caae7963..c8ad0004b 100644
--- a/docs/nodes/config/ui-base.md
+++ b/docs/nodes/config/ui-base.md
@@ -12,4 +12,4 @@ Some details here about the ui-base config node
 
 ## Properties
 
-<PropsTable/>
\ No newline at end of file
+<PropsTable/>
diff --git a/nodes/config/ui_base.js b/nodes/config/ui_base.js
index 4ff128bb5..cf7d4ed42 100644
--- a/nodes/config/ui_base.js
+++ b/nodes/config/ui_base.js
@@ -238,6 +238,18 @@ module.exports = function (RED) {
                 try {
                     socket.removeListener('widget-load', onLoad.bind(null, socket))
                 } catch (_error) { /* do nothing */ }
+
+                // check if any widgets have defined custom socket events
+                // remove their listeners to make sure we clean up properly
+                node.ui?.widgets?.forEach((widget) => {
+                    if (widget.hooks?.onSocket) {
+                        for (const [eventName, handler] of Object.entries(widget.hooks.onSocket)) {
+                            try {
+                                socket.removeListener(eventName, handler)
+                            } catch (_error) { /* do nothing */ }
+                        }
+                    }
+                })
             }
             // clean up then re-register listeners
             cleanup()
@@ -245,6 +257,16 @@ module.exports = function (RED) {
             socket.on('widget-change', onChange.bind(null, socket))
             socket.on('widget-load', onLoad.bind(null, socket))
 
+            // check if any widgets have defined custom socket events
+            // most common with third-party widgets that are not part of core Dashboard 2.0
+            node.ui?.widgets?.forEach((widget) => {
+                if (widget.hooks?.onSocket) {
+                    for (const [eventName, handler] of Object.entries(widget.hooks.onSocket)) {
+                        socket.on(eventName, handler)
+                    }
+                }
+            })
+
             // handle disconnection
             socket.on('disconnect', reason => {
                 cleanup()
@@ -271,8 +293,8 @@ module.exports = function (RED) {
             // get widget node and configuration
             const { wNode, widgetConfig, widgetEvents } = getWidgetAndConfig(id)
 
-            // ensure we can get the requested widget from the runtime
-            if (!wNode) {
+            // ensure we can get the requested widget from the runtime & that this widget has an onAction handler
+            if (!wNode || !widgetEvents.onAction) {
                 return // widget does not exist (e.g. deleted from NR and deployed BUT the ui page was not refreshed)
             }
 
@@ -453,6 +475,7 @@ module.exports = function (RED) {
                 },
                 hooks: widgetEvents
             }
+
             delete widget.props.id
             delete widget.props.type
             delete widget.props.x
@@ -467,6 +490,22 @@ module.exports = function (RED) {
                 widget.props.height = null
             }
 
+            // loop over props and check if we have any function definitions (e.g. onMounted, onInput)
+            // and stringify them for transport over SocketIO
+            for (const [key, value] of Object.entries(widget.props)) {
+                // supported functions
+                const supported = ['onMounted', 'onInput']
+                if (supported.includes(key) && typeof value === 'function') {
+                    widget.props[key] = value.toString()
+                } else if (key === 'methods') {
+                    for (const [method, fcn] of Object.entries(widget.props.methods)) {
+                        if (typeof fcn === 'function') {
+                            widget.props.methods[method] = fcn.toString()
+                        }
+                    }
+                }
+            }
+
             // map dashboards by their ID
             if (!node.ui.dashboards.has(n.id)) {
                 node.ui.dashboards.set(n.id, n)
diff --git a/nodes/widgets/ui_template.html b/nodes/widgets/ui_template.html
index 85a39c674..b3d0812d7 100644
--- a/nodes/widgets/ui_template.html
+++ b/nodes/widgets/ui_template.html
@@ -32,6 +32,7 @@
                     }
                 },
                 height: { value: 0 },
+                head: { value: '' },
                 format: { value: '<div>{{ msg.payload }}</div>' },
                 storeOutMessages: { value: true },
                 fwdInMessages: { value: true },
diff --git a/ui/src/App.vue b/ui/src/App.vue
index b72af87dd..934db4ff1 100644
--- a/ui/src/App.vue
+++ b/ui/src/App.vue
@@ -53,7 +53,8 @@ export default {
             // map their respective Vue component for rendering on a page
             Object.keys(payload.widgets).forEach(id => {
                 const widget = payload.widgets[id]
-                widget.component = markRaw(widgetComponents[widget.type])
+                // allow for types not defined in code Dashboard, but assume they're utilising ui-template foundations as recommended
+                widget.component = markRaw(widgetComponents[widget.type] || widgetComponents['ui-template'])
             })
 
             // store this data in our VueX store for access across the app
diff --git a/ui/src/widgets/ui-template/UITemplate.vue b/ui/src/widgets/ui-template/UITemplate.vue
index dcd2036c2..00a87f4ba 100644
--- a/ui/src/widgets/ui-template/UITemplate.vue
+++ b/ui/src/widgets/ui-template/UITemplate.vue
@@ -15,22 +15,65 @@ export default {
         props: { type: Object, default: () => ({}) }
     },
     setup (props) {
+        // check if we have any addiitonal methods defined
+        // commonly used by 3rd party widgets
+        const methods = {}
+        if (props.props.methods) {
+            Object.entries(props.props.methods).forEach((entry, index) => {
+                // eslint-disable-next-line no-unused-vars
+                const key = entry[0]
+                const value = entry[1]
+                // eslint-disable-next-line no-eval
+                eval('methods[key] = ' + value)
+            })
+        }
+
         useDataTracker(props.id)
         return () => h({
             props: ['id', 'props'],
+            inject: ['$socket'],
             errorCaptured: (err, vm, info) => {
                 console.error('errorCaptured', err, vm, info)
                 return false
             },
             head () {
+                console.log('head', this.props)
                 let _props = this.props || props
                 if (_props.props) { _props = _props.props }
+
+                const setup = {}
+
                 if (!_props || _props.templateScope === 'local') {
-                    return {} // this is a "widget template" so we don't need to do anything
+                    if (!_props.head) {
+                        return {}
+                    } else if (Array.isArray(_props.head) && _props.head.length > 0) {
+                        // loop through the head items and add them to the setup config
+                        _props.head.forEach((item) => {
+                            // check that we have a data object defining the properties of the tag
+                            if (item.data) {
+                                // types supported by @unhead/vue:
+                                //      script, link, meta, style
+                                setup[item.type] = setup[item.type] || []
+
+                                // add meta data for debugging and auditing
+                                item.data['data-template-name'] = _props.name
+                                item.data['data-template-scope'] = _props.templateScope
+                                item.data['data-template-id'] = this.id
+
+                                setup[item.type].push(item.data)
+                            }
+                        })
+                    }
                 }
-                const setup = {}
                 if (_props.format && (_props.templateScope === 'page:style' || _props.templateScope === 'site:style')) {
-                    setup.style = [{ innerHTML: _props.format, 'data-template-name': _props.name, 'data-template-scope': _props.templateScope, 'data-template-id': _props.id }]
+                    setup.style = [
+                        {
+                            innerHTML: _props.format,
+                            'data-template-name': _props.name,
+                            'data-template-scope': _props.templateScope,
+                            'data-template-id': this.id
+                        }
+                    ]
                 }
                 // future?
                 // if (_props.format && (_props.templateScope === 'page:script' || _props.templateScope === 'site:script')) {
@@ -60,6 +103,25 @@ export default {
                 },
                 submit ($evt) {
                     this.$parent.submit(this, $evt)
+                },
+                ...methods
+            },
+            mounted () {
+                // if we have an onInput event handler, setup a subscription on SocketIO to ensure we catch the events
+                if (this.props.onInput) {
+                    // eslint-disable-next-line no-eval
+                    eval(`this.$socket.on('msg-input:${this.id}', ${this.props.onInput})`)
+                }
+                if (this.props.onMounted) {
+                    // eslint-disable-next-line no-eval
+                    eval(`const onMounted = ${this.props.onMounted}; onMounted();`)
+                }
+            },
+            unmounted () {
+                // if we have an onInput event handler, remove the subscription on SocketIO
+                if (this.props.onInput) {
+                    // eslint-disable-next-line no-eval
+                    this.$socket.off(`msg-input:${this.id}`)
                 }
             }
         }, {