So yesterday a user accidentally deleted a pagetree containing 160 pages. The question was, how to restore all of those pages without having to click "Restore" and "OK" 160 times.
The answer? The venerable @Bob Swift _Appfire_'s Confluence CLI!
CLI does not have a function to restore a deleted page, but if you look at a confirmation page's source (example: https://YOURATLASSIANSITE/pages/restoretrashitem.action?key=MS&contentId=139634347), you'll see it is just making a POST request. Reading HTML source and finding POST requests is an old-school web stuff, which thankfully Atlassian has chosen to not make overly complicated with Javascript and things I don't understand. I'll include some resources about this at the end.
https://YOURCONFLUENCESITE/pages/dorestoretrashitem.action
CLI has an incredibly useful action called renderRequest which can make that POST request using the same credentials you are using with CLI. It's kind of like using curl but without having to mess with any authentication stuff.
The full command looks like this:
acli wiki --action renderRequest --request "/pages/dorestoretrashitem.action" --requestType POST --type FORM_URL_ENCODED --requestParameters="key=MS&contentId=139634347"
That command would restore the single page in the MS space with an ID of 139634347.
So we've figured out how to use renderRequest to replace a single page. But as you might recall our user accidentally deleted 160 pages. We want to restore all of those.
For that, we will use CLI's runFromTrashList allows you to iterate through every single page in the Trash, and run a given action against each one. In our case, it will be the renderRequest action that does the restore.
Here is the command:
acli wiki --action runFromTrashList --space MS --common '-a renderRequest --request "/pages/dorestoretrashitem.action" --requestType POST --type FORM_URL_ENCODED --requestParameters=key=MS&contentId=@contentId@'
So then, we are looking for all trashed pages in the MS space, and running the same renderRequest command, replacing contentId with each page in turn.
Sharp-eyed readers will notice that the requestParameters are not double-quoted in the this command. It's... a quoting thing. I don't fully understand it, but at least on a Mac, it seems to have worked. You may need to play around with different quoting mechanisms if you run into problems, which leads us to this last bit:
You really should TEST THIS ON A DEVELOPMENT SYSTEM before trying it on Production. (Although this is a restore operation, so the worst thing that happens is you don't restore the page and have to go and figure out what went wrong.)
One bummer about restoring pages from the trash is that they end up at the root level of the space. As the documentation advises, you or the user will need to go to Space Tools > Reorder Pages to drag all of the restored pages back into the hierarchy, which yeah, will not be fun with 160 pages.
Waaay back in 2018, @Jonathan Smith suggested:
you could also just view the hierarchy from DEV and recreate the structure in PROD.
That's good advice, if you have a DEV instance handy.
I tested this on Confluence Server and Cloud, and was happy to see that it worked on both platforms! Yay for Atlassian not changing this mechanism when they moved it to the Cloud.
Also - I just gotta say again, thank you to @Bob Swift _Appfire_ for the truly amazing tool he and his team have created.
Darryl Lee
Sr. Systems Engineer
Roku, Inc.
San Jose, CA
180 accepted answers
6 comments