Article history/revisions

Ideas
1

I got my blog rolling and saw the team feature. I was more than happy to know that I could include people in the mix and invite them on to the platform it self to start editing. But I noticed one huge feature discrepancy:

There is no article history/revisions.

Seemingly what one would have to do is set up either a private github repo or use Google Docs to then copy paste… which completely defeats the purpose of having an “editor” role in the first place. I guess you could say that the editors job is to fix spelling errors, grammatical errors, etc, content that will be replaced and that won’t be missed. But that’s actually just one part of it (depending upon what field of writing we’re talking about here). An editor (in my particular genre) requires not only rephrasing, fact-checking, etc, but also framing. How one frames a certain situation, individual, group, organization, etc, is as important and without article history it’s hard to reference previous edits in the editorial discussion. The editor will make a change, ping the author about it and “the discussion” will start. When I say “discussion” I mean the authoer makes a draft, the editors edits, the author reviews, makes changes, the editor reviews, makes changes, etc, etc, etc, untill the final draft - at which point it will be published.

As it stands now the editorial process will have to happen outside of the admin panel, something that’s kind of ineffective. The result is that my friend, who will serve as an editor, setup an account for no reason. Now I have to mock up articles in Google Docs and when finished copy-paste the article once it’s done. This does not include photos or other shared content. Links will have to be put in brackets, or my friend will have to learn Markdown (which is easy, yes, but he will not be learning it any time soon).

It seems to me that this feature should have been implemented some time ago and that it will most likely won’t be implemented outside of a future milestone update. But I beg you: Ghost is pretty awesome. If we could see the editorial process from beginning to end in the form of a timeline and the differences made in that process it would make a huge impact on not only productivity, but also content delivery and editorial integrity.

Thanks for reading!

2

I’m still relatively new to Ghost and this is by far the most missed feature. My biggest problems is that if you make a mistake, once the mistake is saved, it’s impossible to revert back. We already managed to destroy a few articles that way and we had to rewrite them from scratch.

2 Likes
3

Step 1 of this was shipped in Ghost 2.2.1 - we now store 10 revisions of every post in the database, protecting against accidental overwrites meaning content is lost forever (which was the really awful thing).

Step 2 will be to add a UI for switching between revisions / restoring them

Step 3 will be to extend revisions beyond 10 and handle the whole thing more comprehensively

5 Likes
4

The version control features sound great!

John, do you have a recommended approach for providing editorial feedback/comments on a draft post? Is that a feature Ghost is working on or are there integrations that one could use to achieve a similar result?

5

It’s something I’d like to see in Ghost for sure. Not something we have on the core-team roadmap atm, but definitely open to contributions from others who are interested in working on it.

6

Today, one contributor had edit one of my post with Microsoft Edge and all images, Markdown were lost… All of my post is broken. Several days of work lost :scream:

A historic of versions is not useful! It is primordial!

2 Likes
7

I lost a long, and very well written post today. I unfortunately paniced and clicked around a bit too much trying to get it back.

Now I know that I can go into the table “mobiledoc_revisions” and see the most recent 10 versions of a post.

Unfortunately I clicked around more than 10 times. Maybe my next write up will be better.

1 Like
8

I was really sad to see this not included in Ghost 3.0. It’s literally the thing our team is waiting for and may force us to move away. Massive oversight for a blogging platform.

9

This would have been a great feature (not sure why this was removed from 3.0).

I was going through a very old post (saved as a draft) which was written in Markdown (Since I am a Ghost user since 2015). Accidentally, I pressed enter while I was in markdown editor, Instead of creating a new line, it completely erased all of the markdown content (which is very weird since I saw the cursor blinking in markdown area).

Since all of the draft content was saved in markdown, I pretty much lost entire blogpost :frowning_face: :cry:

Not sure what my mistake was, but when it comes to a blogging/CMS platform, a history of drafts is an absolute must-have when the Autosave is turned on by default.

1 Like
10

@John

Please, please, pretty please . . . how can I help nudge this along?

I really need this . . .

Do we need some funding?

I would contribute . . .

11

It’s not on the core roadmap, it’s certainly available to be worked on by open source contributors. You’re welcome to look at it, or fund someone to look at it, if it’s important to you :slight_smile:

1 Like
12

I might be willing to fund it if someone capable comes with a plan.

13

In the meantime, I’ve documented here one way to access the 10 revisions that are currently stored in the SQLite database . . .
https://ghost-o-matic.com/revisions-in-ghost/

2 Likes
14

Hei @John

Can we see the core roadmap on ghost.org/roadmap or something like that? It will be nice.

3 Likes
15

For our usage this is a huge gap in Ghost and one that requires a lot of workaround. I tried to clone the repository to poke around adding support in the Admin interface but unfortunately I’m unable to get Ghost to run in a development environment :frowning:. Posted a new topic about getting the contribution instructions updated in the hopes I can try tinkering with this!

16

If there is someone on the forum who knows their way around node applications / handlebars, then the recipe for implementing this seems rather straight forward: the tagging system.

17

Article Version Control: Glue the Tagging and Webhooks System with Github

Is this a terrible idea? There is already a webhook system in place for triggering POST requests when a tag is added to a post. So to get version control, we could:

  1. In ghost-headless add a new column in the sql table called revisions. This would be structured/behave like the tags columns because that is essentially what this is.
  2. In ghost-admin gh-post-settings-menu.hbs add an input field for revisions which is populated from the column created in step 1 above. Modify this input so that it can only have one or zero values (rather than multiple values as originally needed for tags). As a result, ghost-admin would look like this:
    image
    image1366×642 25.3 KB
  3. In ghost-headless clone the logic for the post.tag.attached webhook and tweak it to register against the revisions column created in step 1. The event would become post.revisions.attached. When this webhook is fired, send a post message to the Github Commit API where the message of the commit is the name of the revision. The POSTed message would be the same payload produced by the post.tag.attached event. Only difference is we would save the commit-id returned by github to our database.
  4. When a different revision is selected from the ghost admin ui, a callback would fetch the undiffed post content from github using the corresponding commit-id saved earlier, save it as the current draft, then re-load the page for it to appear in the editor.

In this sense, only the latest draft would be saved in Ghost while the diff of all revisions are stored in Github.

Am I missing a mark / underestimating the complexity of such an endeavor? This would seem to get us what we want, no?

1 Like
18

Hi @John, are you still interested in the development of this feature?

I am interested in an integration with Ghost via Zapier and I believe that I can contribute to the development of this feature.

We are currently creating (and modifying) posts on another service and we want to send creations (and updates) through Zapier. A part of the content is written in the first service and we use Ghost to finalize the post before publishing (adding images, title, subtitle, tags, canonical, …).

For content creation, what already exists is sufficient. We send the posts in draft mode and make the necessary changes before publishing. However, after the content update process in the first tool, we cannot directly publish the content in production before completing the content. Publishing as draft mode is also not an option as this would take the current article down.

I believe that we can add an option to work on articles (which are already published) without reflecting the change in production after saving changes (something similar to Medium). In this case, instead of Zapier publishing directly for production, he would be sending a new “history revision” of the article for editing.

What do you think? Can I develop this on top of Ghost@3? Is it interesting for you to add this functionality?

19

We’d definitely be interested in any contributions to flesh out post revisions and support more usecases, yes. I’d say best place to start would be to open a GitHub issue (or PR) with an outline of your ideas for implementation, and a member of the core team will definitely be able to give some feedback / idea of what it would take to get it into core

1 Like
20

Just adding my voice to others here. In addition to protecting me against screwing up (which has been known to happen :slight_smile: ), I frequently send drafts to people to review before publishing, and then update my posts in place afterwards . I could potentially use archive.org for the post-publishing article history but that doesn’t help with the draft scenario.