Maintaining multiple versions of pages and providing anonymous users with a choice of version
Asked by SB:

Hello.

I'm currently playing around with a trial, self-hosted version of Confluence for the past week and it's been very intuitive so far.

I'm considering utilizing it for a public facing documentation website, that would have several public anonymous users referring to my created page tree. Now I'm aware that Confluence automatically archives older versions of a page once it's been updated.

But is there a way that users can be presented with a choice (dropdown or similar) to choose between which versions of the document they'd like to see? Additionally would there be a way to 'version' these documents personally?

An example of a use case scenario would be PAGE ABC that pertains to version 1.5 of a product; the version of that page would also be ABC 1.5 since it relates to 1.5 of the product.

When version 1.6 of the product releases, the page would be updated with new features and subsequently be versioned ABC 1.6 as well; however I'd like ABC 1.5 to still be available to users that prefer to work with version 1.5 of the product.

Users would ideally choose from dropdown on the page, the version of ABC they'd like to view.

Is this possible on Confluence? A plugin perhaps to maintain multiple versions of a document that users can choose from?

Thanks.


Answers:
author: David _K15t_
body: Hello Sean,

what you describe is a textbook use case for [Scroll Versions](https://marketplace.atlassian.com/apps/1210818/scroll-versions-for-confluence?hosting=server&tab=overview) and [Scroll Viewport](https://marketplace.atlassian.com/apps/1211636/scroll-viewport-for-confluence?hosting=datacenter&tab=overview).

We at K15t use them ourselves to manage and present [our own documentation.](https://help.k15t.com/scroll-versions/3.11/scroll-versions-documentation-110528202.html) If you look at it, you will find the dropdown version picker you described, which lets you look at the page content as they were in past versions. All of the content is managed in and pulled directly from Confluence.

Scroll Versions is the versioning part of what you have described and allows you to manage multiple versions of page content in one space, along with a number of other features that are useful for the creation and management of documentation.

Scroll Viewport is what we use to display Confluence content as a website and implement the dropdown version picker.

Cheers,

David

comments: author: SB
body: Thanks David, and Tarun for suggesting Scroll Versions.

David, the Scroll Versions and Viewport apps do seem to offer what I want; I'm playing with trial copies of both.

I like how Scroll Versions lets me maintain multiple versions of a document, however I'd like for Anonymous users visiting the document to view and switch between versions as well.

I understand Scroll Viewport lets me do that, but it also requires me to develop an entire theme if I understand it correctly?

I'd like for the standard confluence theme to remain (with the header/top bar especially), and essentially only want public users to be given the choice of navigating between different versions of the same space.

Even the default viewport theme seems to open the top nav bar.

Is there an easy configuration for this?

Thanks. :)


author: David _K15t_
body: Scroll Viewport comes packaged with the Scroll Webhelp theme, which is very similar to the Confluence theme, but does not have the top bar. Here is a screenshot of this theme without any additional development or customization:

![WebHelpTheme.png](https://community.atlassian.com/t5/image/serverpage/image-id/39986i7C1D8CBABC66254E/image-dimensions/596x336?v=v2 "WebHelpTheme.png")

By itself, Scroll Versions introduces the version picker in the authoring space only and is built with publishing in mind. This means, a version is supposed to be made accessible to the reader only upon publishing, whether that is to the same space, a new or an existing space.

What you technically could do is to make you authoring space accessible to anonymous users and not do any publishing at all, but this would also reveal pages which may be in progress. We do not recommend this, but it depends on what your requirements are.

Cheers,

David


author: SB
body: David.

Thanks for your quick response.

And how would I go on to make the authoring space accessible to anonymous user groups?

I understand this means that WIP pages might be revealed as well, but perhaps viewability of these WIP pages could be influenced by user groups and permissions?

Sean.


author: David _K15t_
body: Hey Sean,

so I have spent some time replicating this setup with an authoring space that is accessible to anonymous. I must admit, I was mistaken about the version picker being accessible to anonymous users, this is only true for the variant picker.

The only roles that can see the version picker are authors, doc-admins and reviewers. For security reasons it is not possible to assign these roles to anonymous users.

Unfortunately, this means that the version picker is only available with Scroll Viewport. Scroll Versions would enable you to publish each version in a dedicated space for example, but publishing to versioned spaces is not possible as of now.

Cheers,

David


author: SB
body: David.

Yes, I seemed to gather that as well from my experiments yesterday which is why I was waiting for your response to see if I was indeed missing something.

So it seems like the best alternative for now is configuring Scroll Viewport to mimic the standard Confluence UI visually; is this doable?

Can I tweak the layout of the sidebar as well as set up a top nav-bar similar to Confluence's nav-bar etc.?

Thank you again.

Sean.


author: David _K15t_
body: Recreating the Confluence UI would certainly be doable, but not simple.

Just out of curiosity, why is it important to you to have the standard Confluence UI on a public-facing documentation space? Also, which are the more important elements that you need? Is it the visual appearance or the functionality?

Cheers,

David


author: SB
body: Thanks for your continued patience, David.

You're right, it's not so important for me to have a layout mimicking Confluence's UI at the moment; I've been intent on keeping the UI since I've configured its top nav bar etc. to contain custom links.

But I suppose that would be doable by customising the Viewport as well. Ideally, I'd like to include within my Viewport --

* A custom styled navigation bar similar to Confluence UI's (with a replaceable logo at the left), and various menu items.
* A search bar that provides the same search interface as Confluence within this nav-bar.
* A list of associated labels at the bottom of every page.

That's all I can think of for now, so yes, my needs are primarily visual appearance pertinent.

I'm searching the Scroll Viewport documentation for help in styling, but can't seem to find anything. I'd like to see what's possible with the styling before committing to a purchase of both Scroll Versions and Viewport. :)

Sean.


author: David _K15t_
body: Sean,

I am not exactly an expert on Scroll Viewport, but I can confirm that all of those three points you mentioned are definitely doable. If you would like to see what else is possible with Scroll Viewport, you can have a look at [Atlassian's own documentation](https://confluence.atlassian.com/alldoc/atlassian-documentation-32243719.html), which is using both Versions and Viewport, or have a look at this [Atlassian Blog Post listing 5 examples](https://www.atlassian.com/blog/add-ons/5-real-life-examples-beautiful-technical-documentation) of docs managed in Confluence and presented with Viewport.

If you would like some more practical information about how to use Viewport, you can join a short webinar on Scroll Viewport tomorrow at 9.30 (German time). [You can sign-up here.](https://www.k15t.com/software/scroll-viewport)

Cheers,

David


author: SB
body: David.

I've just written in to the K15t professional services team to find out more of its theme development assistance; hoping I'm met with an affordable solution. :)

I love and understand what can be done with Scroll Viewport; it's just that I lack the HTML/CSS know-how to do so. Which is also why I was trying to stick to the confluence UI as an easy way out.

Anyhow you've been of immense help; I'm hoping I can make Scroll Viewport work with my particular requirements.

Thanks again,

Sean.


author: SB
body: David.

Looking at stuff with a fresh pair of eyes this morning.

I understand that Scroll Versions is compatible with Confluence's Refined Theme add-on and it seems to work well; what I'm looking to find out is if I could get Scroll Viewport to display the options for version choices to anonymous users with the theme?

Is Scroll Viewport compatible with the Refined theme that way, so that I have to do do minimal configuration and pretty much derive the Refined Theme's template?

Thanks.

Sean.


author: Tarun Sapra
body: Hello [@SB](/t5/user/viewprofilepage/user-id/2286479)

Working with Versions in Confluence is not very intuitive or user-friendly, but there is a popular \*paid\* plugin which you can use to work with versions.

[https://marketplace.atlassian.com/apps/1210818/scroll-versions-for-confluence?hosting=server\&tab=overview](https://marketplace.atlassian.com/apps/1210818/scroll-versions-for-confluence?hosting=server&tab=overview)


author: Varunish Garg
body: I read the entire thread. Most of it made sense to me. However, I do have some questions.  

Let's say, I have a Space named DocSp. An month after month I keep publishing versions, is there is a limitation to the number of versions that can be published simultaneously/concurrently.   

Also, will links between two versions work?


Tags: app

confluence-server

server

version