Article history/revisions

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.

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

@John

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

I really need this . . .

Do we need some funding?

I would contribute . . .

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

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

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

Hei @John

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

3 Likes

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!

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.

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:
  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

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?

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

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.

Thanks @John, I’m not sure if I need to open an “bug issue”. The “Features and Ideas” is linking to Ideas - Ghost Forum

What do you recommend?

You can use the bug report button there as long as it’s something you’re planning to work on / contribute to. We to keep GitHub as a place for things getting worked on, rather than just requests - so that’s why the UI is framed the way it is. In this case you’re fine to open an issue even if it’s not technically a bug

1 Like

@markstos has provided another method here:

1 Like

brilliant! thank you!

1 Like

this is an interesting approach and seems like it would be faster - if anybody can describe clearly what language competencies might be required to create this or an alt versioning system, it sounds like it would be an amazing solution for users.

it also sounds like some people are not using ghost because of this missing revisions/versioning feature, so i’d love to help make it happen because i could really use it (for commenting! it would also solve for editorial feedback, then deletions and new versioning, etc)

In recent releases, I see mentions of a «Post History Feature» Fixed visibility of the post history feature in v5.47.2

Is this related to this feature that is discussed here?