Update page without changing its contents?
Asked by Niall McCaffrey:

Hi,

I would like to use the REST API to update a page, but without changing the pages title or contents. I just want to bump the version number. My code works if I add a change to the page contents, but if the contents are unchanged the API call does nothing.

(I am doing this as a new version in Scroll Versions inherits pages from the previous version, but they don't truly exist as a page in the new version until edited. I intend to run a script to touch each page in a version and make them 'real' instead of just an inheritance instance. If there is another way to do this, I am also curious! )


Answers:
author: Christian Schlaefcke
body: Hi Niall,

did you manage to solve this challenge somehow yet? We have quite a similar scenario - one working version, with a lot of Snapshots that should not be updated, when working version gets updated.

I developed an idea about how to update a page without changing the (visible) content, based on [this Atlassian Community question (How to display content only in 'edit' mode (and so, not visible in 'read' mode)?](https://community.atlassian.com/t5/Confluence-questions/How-to-display-content-only-in-edit-mode-and-so-not-visible-in/qaq-p/701884)). So the plan would be to perform a "real" update on the new version of the pages by adding a placeholder macro at the end:

```
<ac:placeholder>AUTOMATIC UPDATE FOR VERSION XXX.XXX</ac:placeholder>
```

Having this, the visible content of the pages would not be changed!

But now I have trouble with performing this update. I found out that each version of a page that was edited after version creation gets a new pageId where the page title would be something like ".My Page Title vXXX.XXX" with the pageId of the published version of the parent page as ancestor.

So I tried a regular Confluence Rest API POST request for creating a new page with the specific title, parent pageId as ancestor and original body extended by the placeholder macro as new content. But all I get is a new page that appears to be another new page but not a new version of the versioned page connected to the desired version.

It looks like there is some additional magic behind the Scroll Versions plugin that solves this when doing it in the UI. Unfortunately I was not able to find anything sufficient in the Scroll Versions Rest API for updating versioned pages.

I am aware that the new Scroll Documents product of K15t might solve this issue completely. We are currently evaluating this in parallel but there seem to be other features (like Variant) that are not complete in the new product at the moment.

Any help or hint about how to solve this challenge would be very much appreciated!

Thank you in advance \& Best Regards,

Christian


author: Matthias Gaiser _K15t_
body: Hi [@Niall McCaffrey](/t5/user/viewprofilepage/user-id/4635704),

welcome to the Atlassian Community.

What [@Ravi Sagar _Sparxsys_](/t5/user/viewprofilepage/user-id/853596) suggested, might be a feasible workaround.

Since my colleagues build the Scroll Versions app, I'm somewhat familiar with its concept of inherited pages. May I ask why you want to create real pages and not rely on the inheritance mechanism?

I personally like the inheritance mechanism a lot so that I can e.g. fix a typo for many versions at once instead of adapting every single version.

Cheers,  
Matthias.

comments: author: Niall McCaffrey
body: The problem with the inheritance is that we want to create a mostly read-only branch as a sort of snapshot to do review work on, while we continue to work on a main branch. Changes to the main branch currently show up in the inherited snapshot one, so to avoid that we also branch from the main, creating a new main. Any changes then do not appear in the snapshot, however all our inline comments remain on the old main. Since these are tracking the to-do work, it's really annoying. My plan is to run a script on the snapshot branch, which updates every page and so creates a new version of that page. This leaves us free to alter the existing main and not have to branch it and lose our comments.

Hope that makes sense :)


author: Anshuman Dash _K15t_
body: Hi Niall,

Welcome to the Atlassian Community :)

I am Dash, a Product Manager at K15t (the team who built Scroll versions).

The challenge that you have brought up with the inheritance is something we have tried to solve with our new generation documentation app - Scroll Documents for Confluence.

In Scroll Documents, when you save a new version, we create a physical copy of your main version (we call it the 'working version'). You can then work on the main version and the snapshot versions independently.

Will that be something of interest to you? If yes, I would be more than happy to have a chat with you to understand your requirements and use case.

Cheers!

Dash.


author: Niall McCaffrey
body: Thanks Dash, I am a little curious about your coming products, but I do think I can solve this particular use case with my script. It's nice to see that k15t are interested in discussing with their users!

My personal wishlist item is more control with the variants and attributes. Setting up NOT and XOR logic between attributes is very clumsy.


author: Ravi Sagar _Sparxsys_
body: Hi [@Niall McCaffrey](/t5/user/viewprofilepage/user-id/4635704)

Why not just update the page with some text and remove it in the next call?

Ravi

comments: author: Niall McCaffrey
body: Because this is double the traffic to the server, and creates two updates and entries in the page history when I only want one?

I don't understand why Confluence would reject an update just because the page content is the same. It's a PUT request with a new version number, after all.


Tags: confluence-server

rest-api

server