Feature Request: Version Control for Templates

[JoshTango]

Is there a plan to bring in version control for the templates? @sebastienros

[dodyg]

Oh that would be so sweet. Orchard Core CMS is a development environment.

[JoshTango]

well somebody did bring it up in one of the videos.

[sebastienros]

No plan, but that could be done without breaking anything easily as they are stored in db, we could at least store a draft, if not all versions.

How would you use it? To save changes before "going live"? Also I don't remember we mentioned that in the meetings, do you have a reference?

[JoshTango]

I will try and find the video but I thought someone asked if you could save a copy of each template after a save so you could roll back a template.

All you need is a simple drop down list which has a list of all the saved copies and allows you to rollback to the version you selected. Or something like that. Maybe even preview the copies.

[dodyg]

@sebastienros it's even more basic than that. There's a lot of trial and error in developing templates especially for items that do not have preview. So if I am making making changes, I usually copy the current version to notepad and publish latest change to see if it works or not.

[JoshTango]

@sebastienros well on the template page there could be a "version history" button. When you press this button it takes you to a version control page for that template. This code could be put inside a new version control module for templates. It could start off simple and over time you can evolve this module.

[deanmarcussen]

Can we revive this for some design?

It's the biggest blocker for us in using database liquid templates, as without some version control, it's too risky.

Design options

• Should this just be part of audit trail - it has the extension points, and diff functionality.
• Alternative is to create a version database document for each template, which can contain it's versions. (perhaps limited to the quantity of versions held)
• Or ?

Creating all versions for all templates in the same document is going to run into document size issues quickly.

Same principles would want to be applied to shortcode templates, and some other UI based documents.

/cc @Piedone @domonkosgabor @sebastienros

[sebastienros]

We don't need audit trail for that, but at the same time audit trail might need to store the changes in any case. So then why not integrate with it, and then add the UI from the templates to be able to restore previous versions. Just have to think about permission access. And audit trail would provide automatic pruning I assume, and maybe diffs.

Or to accelerate the development, it can also be done specifically, should be very simple to do, and then later remove the feature when it's implemented with audit trail.

Something to think about is that we might also use temporal compression on documents (storing the delta) and this way the whole history could be kept in a single document (over-engineering but I did that by the past for a document management system and it worked beautifully).

[Piedone]

I'd definitely handle this with Audit Trail. However, Templates being stored in a single document will become an issue in any case, both the document growing continuously and both having to implement custom Audit Trail events as opposed to just relying on content events for example. This bothered me before too but probably it's a separate discussion.

That being said, I think with Templates this can be only useful if there is a preview feature too, otherwise you can't experiment around without breaking the site (or otherwise you'd do that on a dev/test site but then versioning is less of a necessity as well).

[sebastienros]

Agreed it's better to have single documents, maybe a custom table (for anything that handles versions, low access, and custom index, maybe even a custom feature to reuse these services), but it won't rely on content events since it's not a content item. But it doesn't mean there shouldn't be custom event for the audit trail feature to work with it.

[Skrypt]

I've seen also the usage of Git directly in a CMS to handle Version Control of templates. Somehow you have the choice to create templates from the Admin UI but also from the file system. Having them in the database allows to have a single source of truth for all tenants in a distributed system but having them stored in a common private Git repository could also work.

[deanmarcussen]

For me, it's looking for something simple, that is a respectable enough pattern, that has way less features than audit trail might, but would allow audit trail to replace it.

Audit trail is heavier, both in feature set, and general feel.

Whereas for the basic site, there is just a need to be able to click a button, see a list of the previous versions (from before the customer broke the template), and restore one.

My thought was one version document, for each template name, indexed, but not memory cached. Only ever requested when you click to view versions.

A delta sounds interesting as well.

[deanmarcussen]

p.s. we need to unblock the yessql pr so we can start looking at custom tables ;)

[sebastienros]

Single document per version, with Published/Latest just like content items. In a separate collection. Still a single query to load and cache all the templates.