Hook on "Save"/"Publish" event?

[Fredrik Bergljung]

My team needs to improve the version handling a bit for our client. We need to have a persistent storage of both the current public version and of saved but not published version. As I understand the current situation, when I press "Save" the existing version is replaced by the new version in the db and when I press "Publish" the (in memory) cached existing version is wiped completely.

Our take on this is to hook in to the "save"/"publish" events so we can prevent existing content versions to be overwritten in the db when someone press "Save" on a new version. Is there a recommended way of doing this?

Besides, we'll also have to make it clearer to the editor on what version he/she is working, for example by changing the icon/text in the "Save" and "Publish" buttons - any ideas on how to do this without breaking upgradeability?

Of course, we are willing to commit this work back if you think it's good stuff.

Cheers,

Fredrik

[Thomas von Deyen]

Hi Fredrik. 

We recently thought about the same feature. Would love to see this in the next version of Alchemy! 

We even have a open issue on GitHub (https://github.com/magiclabs/alchemy_cms/issues/141). 

This ticket describes the idea we had. 

The basic idea is to copy the page to a drafts branch of the page tree. 

We already have Page.copy(@page). 

This could be done with a before_filter in the Admin::PagesController#edit action. So before a user edits the page, we could copy it and the user edits the draft. On #publish we copy the page over and invalid the cache. 

So far for the basic idea behind it. 

Best Thomas

[Fredrik Bergljung]

Hello!

Thanks for the fast response.

If you guys think that that's the way to do it, then we'll have a go at it in my project now and make a pull request when we think we've solved it.

Regarding the UI: we'll add a better indicator of what version of the content "you" are currently working with (public or draft) and also a button for reverting to the public version.

Cheers,

Fredrik

[Thomas von Deyen]

Thanks.

If you need any help. 

Don't hesitate to ask. 

Best

Thomas

--
You received this message because you are subscribed to the Google Groups "Alchemy CMS" group.
To unsubscribe from this group, send email to alchemy-cms...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Fredrik Bergljung]

Thanks!

We will indeed do this, probably within the next two-three weeks.

Cheers,

Fredrik

[Jesper Petersson]

Hi,

I'm working on the same team as Fredrik, and we've had some discussions regarding the implementation of this functionality.

Just to give you guys a heads up, our proposed solution is as follows:

Each row in the page table is associated with a version of the page. An editor always works with the lastest version (the draft), meanwhile the second lastest version is the published version. When an editor presses the "publish" button, the draft version is copied into a new version. This will implicitly make the "old draft" the published version and the newly created version to the new draft. Initially when a page is created it'll have version 1, which would correspond to the draft since this is the lastest available version of that page. A published version for that page would at first not exist, but it would be created as soon as an editor choose to publish the page. The uniqueness of a page would be identified by its URL, language and version. All page properties (such as name, title, visible in navigation, etc.) would be the same for each and every version of the page.

The reason of storing all old versions is to make it possible for a future implementation of side-by-side comparison. For example, it would be nice to be able to see how a page has envolved over time. The reason we didn't go with the proposed solution with a separate page tree is that we came to the conclusion that the data model with this approach is simpler. We don't have to worry about syncing the two page trees for example if a page is moved. The data model is more simple to understand too, when each page having one or more versions, instead of the drafts being in a separate tree which still requires some association between the pages.

What do you think about this approach, can you see any obvious problems? Would you guys be interested of accepting a pull request if we would implement it this way?

/Jesper 

[Thomas von Deyen]

Hi Jesper,

sounds good. We would love to see a pull request since this is a long awaited feature. 

Here is the Github issue:

https://github.com/magiclabs/alchemy_cms/issues/277

Thanks for your contribution,

and keep me updated if you need any help.

Best

Thomas

[pat...@stenmark.io]

Hi!

I'm working with Jesper and Fredrik on this project. We've so far managed to get most of the admin UI to work with versioning and started working on the presentation part. You can have a look at https://github.com/peterssonjesper/alchemy_cms/ on the page_versioning branch if you're interested in our progress.

I have a questiong regarding the update script. There are lots of stuff in https://github.com/peterssonjesper/alchemy_cms/blob/master/lib/alchemy/upgrader.rb which seems to be part of the upgrade process to 2.5. Should this file be emptied for 2.6? Or should I add some checks to my update_pages_for_versioning method that only runs it if it's already been run? Or am I misunderstanding something?

Best regards
Patrik Stenmark

[Thomas von Deyen]

Hi Patrik.

1. I checked your branch

I don't have the time to go into too much detail, but here is a first feedback:

a.) The element auto generator runs after releasing a new version. I am not shure, if this is a good idea. But let's discuss this.

b.) If I edit a already published page, the page status stays on published.
It would be nicer that, if a page, or to be more precise, an element gets altered, the page would be put in a draft state automatically. Just like in WordPress.

c.) I have some concerns with your approach to have the versions of a page in the same page tree.
IMO This no good idea. Please consider this scenario:

Having a page with children. On an page a developer iterates over all children to display some kind of index.
Now publishing a new version of one of the child pages, the index shows this new version of a already existing page.

Although you have to alter the navigation renderer.

You could add a scope, that handles this, but then every developer has to be aware of this. This breaks backwards compatibility and
is very error prone.

One solution would be to override the children and all other `awesome_nested_set` collection methods
A second approach would be to copy the versions over into its own page tree.

I don't know for now what solution I like more.

Do you have any idea?

Lets discuss pros and cons.

2. Regarding the upgrader

No, it will not be emptied out on 2.6, just add your method into the class and check if the page already has versions.
Only upgrade if not. Thats how we created all other upgraders.

Have a nice day.


Thomas

[tvdeyen]

Hi.

I read a little bit on scopes for awesome_nested_set. There is one option, called :scope (obviously) that can be set to an attribute of the page model.

So, adding :scope => 'version' and altering the pages table to have a default of 1 for version (you set this in a before filter on the page model anyway) it works like expected.

Could you please add this scope and report any feedback, if this works for you?

Thanks

Thomas

[tvdeyen]

I really must say, that I don't like the approach to use the pages for drafts.

Lets realize what pages are in Alchemy, just nodes in the navigation tree. 

Nothing more, they don't hold any content. Looking at all the monkey patching you already made in the page model, 

one has to realize that this can't be the right approach. And this will get even worse, the deeper you run into problems. 

Navigation rendering, etc.

In stead the drafts/versions feature should be on the element level. Much easier to implement and a powerful feature. 

You could have versioned content on already published pages.

Please add this feature at the element level. That's where it belongs.

Just ping me if you need any help.

[Patrik Stenmark]

Hi

Yeah, we've realized that there are issues with the approach we started on and have given it up. We will make another attempt later, maybe next week.

Putting versioning on elements is interesting, we'll look into that in more detail.

/Patrik

--

You received this message because you are subscribed to the Google Groups "Alchemy CMS" group.

To unsubscribe from this group and stop receiving emails from it, send an email to alchemy-cms...@googlegroups.com.