diff --git a/_includes/header.html b/_includes/header.html
index 54890c64..2dc86d28 100644
--- a/_includes/header.html
+++ b/_includes/header.html
@@ -10,12 +10,12 @@
-
-
-
-
-
-
+
+
+
+
+
+
{% if page.layout == 'blog' %}
diff --git a/_posts/2020-06-30-version-1-1-released.md b/_posts/2020-06-30-version-1-1-released.md
new file mode 100644
index 00000000..836472c1
--- /dev/null
+++ b/_posts/2020-06-30-version-1-1-released.md
@@ -0,0 +1,233 @@
+---
+layout: blog
+title: Version 1.1 released
+author: nick
+---
+
+Node-RED 1.1 is now available to [install](https://npmjs.org/package/node-red).
+
+If upgrading, please read the [upgrade instructions](http://nodered.org/docs/getting-started/upgrading.html).
+
+---
+
+
+
+---
+
+
+- [Editor Updates](#editor-updates)
+ - [Information sidebar redesign](#information-sidebar-redesign)
+ - [New Help sidebar](#new-help-sidebar)
+ - [Grouping nodes](#grouping-nodes)
+- [Runtime features](#runtime-features)
+ - [node-red-admin built-in](#node-red-admin-built-in)
+ - [Overriding individual settings](#overriding-individual-settings)
+ - [`httpAdminMiddleware` setting](#httpadminmiddleware-setting)
+ - [Custom `adminAuth` token handling](#custom-adminauth-token-handling)
+ - [Installing nodes from other locations](#installing-nodes-from-other-locations)
+ - [Refreshing HTTPS certificates](#refreshing-https-certificates)
+- [Node updates](#node-updates)
+ - [JSONata `$moment` support](#jsonata-moment-support)
+ - [Inject node properties](#inject-node-properties)
+ - [Function node lifecycle](#function-node-lifecycle)
+ - [Debug node status](#debug-node-status)
+ - [Trigger node](#trigger-node)
+
+
+
+## Editor Updates
+
+### Information sidebar redesign
+
+The info sidebar now includes a tree-view of your flows - we call it the outliner.
+This gives another way to navigate your flows and quickly find things.
+
+{:width="40%"}
+
+Each node has a button that takes you to it in the workspace, a button to
+enable/disable it and, in the case of the Inject and Debug nodes, a button to
+trigger their action. Double-clicking on a node will bring up its edit dialog.
+
+[more...](/docs/user-guide/editor/sidebar/info)
+
+### New Help sidebar
+
+To make room for the outliner, the help section of the sidebar has now moved
+to its own sidebar tab. The added benefit of putting the help in its own tab
+is you can now browse all of the available help topics without having to select
+a node of the right type in the workspace.
+
+It will also give us a space to add other help topics in the editor in the future.
+
+[more...](/docs/user-guide/editor/sidebar/help)
+
+### Grouping nodes
+
+To help organise your flows you can now group your nodes in the editor.
+The group can have a custom border and background colour and an optional label.
+
+
+
+Groups are added to the flow as a new type of node. As people start using them,
+it will make it harder to share flows with users who haven't yet upgraded.
+To help out, we've published [`node-red-node-group`](https://flows.nodered.org/node/node-red-node-group)
+which registers a `group` node type but does absolutely nothing. Installing this
+module will allow older versions of Node-RED to import flows that include a
+group - although they won't see the groups in the editor. And the module knows
+not to register itself when it isn't needed, so there's no issue upgrading to 1.1
+with it installed.
+
+[more ...](/docs/user-guide/editor/workspace/groups)
+
+## Runtime features
+
+### node-red-admin built-in
+
+The `node-red-admin` command-line tool has existed since the start of the project,
+but it isn't something widely known about or used. It can be used to remotely
+administer a Node-RED runtime.
+
+To make it more useful, it is now integrated into the `node-red` command. You run it with:
+
+```
+node-red admin
+```
+
+One of the useful commands it provides is a way to hash passwords suitable for
+`adminAuth`. It prompts you for the password you want to use and it gives you
+back the hash you can paste into your settings file.
+
+```
+$ node-red admin hash-pw
+Password:
+$2b$08$sjxLvq8MmycyWJpxPLyweuw/WlYt1MX56eG5Q5nlyxJs2fASGm2jm
+```
+
+The other commands let you list what nodes are installed, enable/disable them,
+install new ones or remove old ones. You can also search the flow library.
+
+[more...](/docs/user-guide/node-red-admin)
+
+### Overriding individual settings
+
+The `node-red` command now supports the `-D` option to override individual settings.
+For example, to temporarily run with a different level of logging you can use:
+
+```
+node-red -D logging.console.level=trace
+```
+
+[more...](/docs/getting-started/local#override-individual-settings)
+
+
+### `httpAdminMiddleware` setting
+
+We've had the `httpNodeMiddleware` option for a while now - allowing a custom
+middleware to be added to the HTTP In node routes. This release adds
+`httpAdminMiddleware` that does the same thing for all of the admin routes,
+which includes the editor itself. This can be used, for example, to add custom
+http headers to all admin requests. Not something most end users need, but has
+been a requirement from those who embed the editor into their own applications.
+
+[more...](/docs/user-guide/runtime/securing-node-red#custom-middleware)
+
+### Custom `adminAuth` token handling
+
+`adminAuth` now supports a custom `tokens` function that can be used to validate any auth token passed to the admin api. This opens up some more flexible options to integrate Node-RED admin security with other authentication systems.
+
+[more...](/docs/user-guide/runtime/securing-node-red#custom-authentication-tokens)
+
+### Installing nodes from other locations
+
+The admin api for installing new nodes has been extended to support a 'url'
+parameter - which should be a full url to a `tgz` containing the node to install.
+
+This hasn't been written up in the docs yet, but for now, you can read the original
+[design note](https://github.com/node-red/designs/tree/master/designs/node-installation)
+
+### Refreshing HTTPS certificates
+
+The runtime can now be configured to periodically refresh its https certificates.
+This feature requires Node.js 12 or later.
+
+The default [settings file has been updated](https://github.com/node-red/node-red/blob/c048b1a25b36040f169f443701b9a0dde2f57914/packages/node_modules/node-red/settings.js#L139-L171) with examples for how to configure this.
+
+[more...](/docs/user-guide/runtime/securing-node-red#refreshing-https-certificates)
+
+## Node updates
+
+### JSONata `$moment` support
+
+We've added support for the Moment date/time library within JSONata expressions via the `$moment` function.
+
+This adds some long needed timezone awareness into the core of Node-RED. For example, you can get the current time in Auckland with the expression:
+
+```
+$moment().tz("Pacific/Auckland")
+```
+
+If you wanted to get the time 2 hours from now, you can do:
+
+```
+$moment().add(2, "hours")
+```
+
+It can also do a much better job of parsing dates:
+
+```
+$moment($.payload, "YYYY-MM-DD")
+```
+
+We're considering making the Moment library available as a default built-in of the Function node as well, but that will
+be a future release.
+
+### Inject node properties
+
+The Inject node can now set any properties on the message it sends - you aren't limited to just `topic` and `payload`.
+
+
+
+### Function node lifecycle
+
+The Function node now lets you provide code that should be run when the node is
+deployed and when it is being stopped. This lets you initialise any state in the
+node before it starts handling any messages. Note that each piece of code is in
+a separate scope - you cannot declare variables in one and access them in the others.
+You need to use `context` to pass things between them.
+
+The main Function has also been made a proper async Function so you can use `await` at the top level, if that's your sort of thing.
+
+
+
+### Debug node status
+
+The Debug node can now set its status message independently of what it passes
+to the Debug sidebar. Useful if you want to Debug a shorter summary to status,
+whilst showing more complete information in the sidebar where there is more space.
+
+Whilst talking about the Debug node, we've added a number of actions in the editor
+to help activate/deactive lots of nodes in one go.
+
+You can searching for them in the Action List (`Ctrl/Cmd-Shift-P` or `View -> Action List`)
+and you can assign keyboard shortcuts to them:
+
+ - `core:activate-selected-debug-nodes`
+ - `core:activate-all-debug-nodes`
+ - `core:activate-all-flow-debug-nodes`
+ - `core:deactivate-selected-debug-nodes`
+ - `core:deactivate-all-debug-nodes`
+ - `core:deactivate-all-flow-debug-nodes`
+
+
+### Trigger node
+
+The Trigger node can now optionally send its 'second message' on a separate output.
+
+If you want it to handle separate streams of messages, you are no longer tied
+to using `msg.topic` to identify the streams - you can use any message property.
+
+
+
+
+
+
diff --git a/_posts/2020-07-01-release-plans.md b/_posts/2020-07-01-release-plans.md
new file mode 100644
index 00000000..9d568ea9
--- /dev/null
+++ b/_posts/2020-07-01-release-plans.md
@@ -0,0 +1,95 @@
+---
+layout: blog
+title: Going beyond Node-RED 1.x
+author: nick
+description: With the 1.1.0 release done, its time to think about what comes next for the project. Find out how we're proposing to approach future releases of Node-RED and what that means for longer term support.
+---
+
+With the 1.1.0 release done, our attention turns to the next release. But before
+we push ahead with the next item on the backlog, it's a good moment to think about
+the bigger picture
+
+We reached our 1.0 milestone last October. This was a major point for us to reach
+and it took quite a while to get there. And it has taken us 9 months to get to the
+this latest release. That delay was not ideal as it has meant many new features
+have been sat around for months, waiting to be released.
+
+This is an unfortunate result of being an open-source project that cannot take
+for granted anyone's involvement. Whilst I am in a fortunate position to be able
+to dedicate a very large part of my day job working on the project, that is not
+the case for many of the other contributors who help out.
+
+Our approach to scheduling releases has been fairly relaxed. We haven't set
+target dates too far in advance and at some point we would decide we have 'enough'
+new content to warrant publishing a new release.
+
+Prior to the 1.0 release, we would also, on occasion, make a change that shouldn't
+be made in a minor-version number release. For example, dropping support for older
+versions of Node. You can just about get away with that when you are a 0.x versioned
+project, but now we are a 1.x versioned project, we need to take more care.
+
+As it stands, we still technically support running on Node.js 8.x - even though
+that version of Node stopped being maintained at the start of this year. And we certainly
+have an eye on the fact that Node 10.x drops out of maintenance at the end of April
+next year.
+
+Whilst we certainly wouldn't recommend it, we understand some users are stuck on
+older versions, and we don't want to needlessly break them if we can avoid it.
+
+But nor can we continually hold ourselves back from being able to make use of new
+Node.js features in the core runtime.
+
+We also recognise that for the companies who have adopted Node-RED into their own
+commercial solutions, they need a degree of confidence in how long any particular
+version of Node-RED will be supported.
+
+So with all of that in mind, here is the current *proposal* for how we manage
+releases in the future.
+
+
+
+At the bottom, the chart shows the [published dates](https://nodejs.org/en/about/releases/)
+for the current Node.js releases. If you are using Node-RED in any sort of production
+environment, you need to be aware of these dates.
+
+The top shows the proposed release schedule for Node-RED.
+
+In summary, we aim to do a minor version release (for example, 1.1 → 1.2)
+every three months. Maintenance releases (for example 1.1.0 → 1.1.1) will continue
+to happen as and when they are needed.
+
+At the end of April 2021, when Node 10.x reaches its end-of-life, we will publish
+Node-RED 2.x that will *drop* support for both Node 8.x and Node 10.x.
+
+The 1.x stream will then enter maintenance mode. It will only receive bug fixes
+and security updates, but with room for new features to be back-ported from 2.x
+if there is a very good reason to do so.
+
+The 2.x stream will continue in active development with a minor release every
+three months or so until April 2022 when Node 12.x reaches its end-of-life. We
+then publish Node-RED 3.x and the cycle continues. The 1.x stream will reach its
+end-of-life after the 3.x release.
+
+This proposal means:
+
+ - We have a regular cycle of releases - getting new features into the hands of users.
+ - We have a schedule to help us prioritise and plan backlog items.
+ - We can provide longer-term stable releases with a well-known end of life.
+ - We have a plan that enables us to make potentially breaking changes once a year.
+
+It is important to remember this plan is not risk-free. It assumes that the project
+has enough contributors to help deliver it. This becomes particularly important when
+we have multiple streams to maintain.
+
+We're hopeful that having a published schedule of releases will help encourage
+people to contribute, whether in code, documentation, testing or just general feedback.
+
+We will see how it goes over the next few months - we have until April before we
+will have multiple active streams. If something isn't working and we have to
+rethink this plan, then we will.
+
+But for now, we make a start on getting 1.2 ready for the end of September.
+
+
+
+
diff --git a/blog/content/images/2020/06/func-lifecycle.png b/blog/content/images/2020/06/func-lifecycle.png
new file mode 100644
index 00000000..5cf50498
Binary files /dev/null and b/blog/content/images/2020/06/func-lifecycle.png differ
diff --git a/blog/content/images/2020/06/groups-one.gif b/blog/content/images/2020/06/groups-one.gif
new file mode 100644
index 00000000..cf653711
Binary files /dev/null and b/blog/content/images/2020/06/groups-one.gif differ
diff --git a/blog/content/images/2020/06/info-sidebar.png b/blog/content/images/2020/06/info-sidebar.png
new file mode 100644
index 00000000..eb3349ab
Binary files /dev/null and b/blog/content/images/2020/06/info-sidebar.png differ
diff --git a/blog/content/images/2020/06/inject-props.png b/blog/content/images/2020/06/inject-props.png
new file mode 100644
index 00000000..bf12fac6
Binary files /dev/null and b/blog/content/images/2020/06/inject-props.png differ
diff --git a/blog/content/images/2020/06/release-plan.png b/blog/content/images/2020/06/release-plan.png
new file mode 100644
index 00000000..10a0d147
Binary files /dev/null and b/blog/content/images/2020/06/release-plan.png differ
diff --git a/docs/user-guide/node-red-admin.md b/docs/user-guide/node-red-admin.md
index f09be973..609537c8 100644
--- a/docs/user-guide/node-red-admin.md
+++ b/docs/user-guide/node-red-admin.md
@@ -13,13 +13,15 @@ instance.
Since Node-RED 1.1.0, `node-red-admin` is now built into the `node-red` command -
you do not need to install it separately.
-To run it, you use `node-red admin` instead of `node-red-admin`.
+To use the version included with `node-red`, use the command `node-red admin`.
+
+If you install it separately, you would use the command `node-red-admin`.
### Installation
-Install this globally to make the `node-red-admin` command available on
-your path:
+If you want to install `node-red-admin` separately, you can install it as a global
+module with:
npm install -g --unsafe-perm node-red-admin
diff --git a/index.html b/index.html
index c0412c3f..f1390b2e 100644
--- a/index.html
+++ b/index.html
@@ -7,7 +7,7 @@
Node-RED
Low-code programming for event-driven applications