Version control / Publish workflow

[Bruno Reis]

Our client is asking for some kind of version control or, at least, publish workflow. 

Do you have something ready? In the near roadmap? 

Maybe we can contribute to it. 

[Lukas Kahwe Smith]

With Jackrabbit you get versioning, which you can easily enable on the document level, though you would then of course need to implement some restore functionality.

We do however already have something for the publish workflow:
http://symfony.com/doc/master/cmf/bundles/core/publish_workflow.html

regards,
Lukas Kahwe Smith
sm...@pooteeweet.org

[Bruno Reis]

Nice. But, I don't know if I used the right terminology. 

What I need is:

1 To have some kind of preview for a new content that is visible by some roles but not by everybody. 

2 A way to edit a document and save a candidate for a new 'release'. A copy of that document that can be previewed and, if approved, can be published.  

Number 2 seems more complicated because I will need two existing documents on the tree, the actual one and the candidate one. 

Is anything like that in your roadmap? I'd like to elaborate something that will be helpful for the project, not only for us. 

Also, there are other two options to think: 

1 - to put some versioning/restore functionality on the sonata admin. Do you intend to keep with the sonata admin? 

2 - also to implement versioning in the doctrine odm. Do you have a cost estimate for this? 

--
You received this message because you are subscribed to the Google Groups "symfony-cmf-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to symfony-cmf-us...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Lukas Kahwe Smith]

> On 23 Apr 2015, at 13:36, Bruno Reis <bruno....@gmail.com> wrote:
>
> Nice. But, I don't know if I used the right terminology.
>
> What I need is:
>
> 1 To have some kind of preview for a new content that is visible by some roles but not by everybody.
>
> 2 A way to edit a document and save a candidate for a new 'release'. A copy of that document that can be previewed and, if approved, can be published.
>
> Number 2 seems more complicated because I will need two existing documents on the tree, the actual one and the candidate one.
>
> Is anything like that in your roadmap? I'd like to elaborate something that will be helpful for the project, not only for us.
>
> Also, there are other two options to think:
>
> 1 - to put some versioning/restore functionality on the sonata admin. Do you intend to keep with the sonata admin?
>
> 2 - also to implement versioning in the doctrine odm. Do you have a cost estimate for this?

CMS like AEM etc solve this by basically running a staging server and a production server. Publishing content then means moving new/updated content from the staging repository to the production repository.

I am not sure but sulu.io might have already implemented this approach.

[David Buchmann]

> 1 To have some kind of preview for a new content that is visible by some
> roles but not by everybody.

this is exactly what publish workflow is about.

> 2 A way to edit a document and save a candidate for a new 'release'. A
> copy of that document that can be previewed and, if approved, can be
> published.
>
> Number 2 seems more complicated because I will need two existing
> documents on the tree, the actual one and the candidate one.
>
> Is anything like that in your roadmap? I'd like to elaborate something
> that will be helpful for the project, not only for us.

as lukas says, one way to do this would be an authoring instance (or
subtree) and a publish instance/subtree and copying documents between
them. the phpcr versioning is implemented (also with phpcr-odm) but that
is more of a changelog than useful to track which version is the
published one.

> Also, there are other two options to think:
>
> 1 - to put some versioning/restore functionality on the sonata admin. Do
> you intend to keep with the sonata admin?

we try to build things as decoupled from sonata admin as possible, but
have the necessary glue code to trigger things in sonata.

> 2 - also to implement versioning in the doctrine odm. Do you have a cost
> estimate for this?

the versioning is already supported in phpcr-odm. but as said above, its
not enough for your usecase. i don't see phpcr-odm being able to provide
more of that, we would need to think of some
copy-content-on-button-click functionality imho.

cheers,david

[Bruno Reis]

Thanks Lukas and David. 

Where can I find some info about the versioning that is already supported? 

I think that using a "copy-content-on-button-click" together with a "let-me-see-who-changed-this" will fulfil their expectations.

[David Buchmann]

> Where can I find some info about the versioning that is already supported?

http://doctrine-phpcr-odm.readthedocs.org/en/latest/reference/versioning.html

if i remeber correctly, there are some open issues about how PHPCR and
jackrabbit are supposed to treat descendant nodes of the node being
versioned.

jackalope-doctrine-dbal does not support versioning yet. but daniel
rotter started working on that. don't expect this to be stable very soon
however, afaik its a work for university and he hopes to finish this summer.

> I think that using a "copy-content-on-button-click" together with a
> "let-me-see-who-changed-this" will fulfil their expectations.

the copy-on-button-click would be an interesting general functionality.
the tricky part will be to decide what should be included in the copy
and what not. maybe we could use a jms serializer group on the document
for that. this will still be tricky with references for example: if my
document contains a reference block, that block should be copied along,
but with the reference on the other thing, not a copy of the referenced
thing (hope you see what i mean)

if you can come up with a concept i would be glad to help seeing where
we can fit this. it seems to me to be out of scope of phpcr-odm itself,
but likely a library / bundle of its own.

cheers,david

[Daniel Rotter]

Sadly we didn't have time yet to implement the versioning capabilities in Sulu :(

[Bruno Reis]

Hi 

Thanks for all the answers. I'll discuss with the team here and see what we choose. 

I'm inclined to the "copy-on-button-click" solution. It seems the most reasonable solution to me. 

I'll tell you about our decision and would like to please count with your guidance to implement it. 

[Bruno Reis]

Another idea that emerged here is a export/import button. I know there is such functionality on the console, but I haven't seen it on the admin interface. 

We feel that the client might like it a lot because he would have a sense of control. "Let me save this part here today...". 

Also, it would be an easy to implement and good way to create something on one env/server, export, and import on another server. 

What do you think? 

[David Buchmann]

hi bruno,

indeed i occasionally used the cli import/export for clients when they
had prepared a complex page on the staging server and did not want to
redo it...

the problem with the direct export is that you have no control which
children to export, you export the whole subtree. if a page has child
pages underneath but you only want the parent page (and blocks and
whatever custom children of that document type), and also want to
migrate the route and menu entry referencing it, you need something on
application level to control which nodes to export and which not...

i can totally see such a button e.g. on sonata admin, like the export to
csv, but it will not always work for content copying scenarios, and
could lead to considerable confusion. when importing, the target node
must not exist yet, so you can not merge a page into a tree, only append it.

cheers,david

On 29.04.2015 01:07, Bruno Reis wrote:
> Another idea that emerged here is a export/import button. I know there
> is such functionality on the console, but I haven't seen it on the admin
> interface.
>
> We feel that the client might like it a lot because he would have a
> sense of control. "Let me save this part here today...".
>
> Also, it would be an easy to implement and good way to create something
> on one env/server, export, and import on another server.
>
> What do you think?
>
>
> 2015-04-27 12:13 GMT-03:00 Bruno Reis <bruno....@gmail.com

> <mailto:bruno....@gmail.com>>:

>
> Hi
>
> Thanks for all the answers. I'll discuss with the team here and see
> what we choose.
>
> I'm inclined to the "copy-on-button-click" solution. It seems the
> most reasonable solution to me.
>
> I'll tell you about our decision and would like to please count with
> your guidance to implement it.
>
> 2015-04-24 6:12 GMT-03:00 Daniel Rotter

> <daniel...@massiveart.com <mailto:daniel...@massiveart.com>>:

>
> Sadly we didn't have time yet to implement the versioning
> capabilities in Sulu :(
>
> Am Donnerstag, 23. April 2015 13:43:10 UTC+2 schrieb Lukas Kahwe
> Smith:
>
>
> > On 23 Apr 2015, at 13:36, Bruno Reis <bruno....@gmail.com> wrote:
> >
> > Nice. But, I don't know if I used the right terminology.
> >
> > What I need is:
> >
> > 1 To have some kind of preview for a new content that is visible by some roles but not by everybody.
> >
> > 2 A way to edit a document and save a candidate for a new 'release'. A copy of that document that can be previewed and, if approved, can be published.
> >
> > Number 2 seems more complicated because I will need two existing documents on the tree, the actual one and the candidate one.
> >
> > Is anything like that in your roadmap? I'd like to elaborate something that will be helpful for the project, not only for us.
> >
> > Also, there are other two options to think:
> >
> > 1 - to put some versioning/restore functionality on the sonata admin. Do you intend to keep with the sonata admin?
> >
> > 2 - also to implement versioning in the doctrine odm. Do you have a cost estimate for this?
>
> CMS like AEM etc solve this by basically running a staging
> server and a production server. Publishing content then
> means moving new/updated content from the staging repository
> to the production repository.
>

> I am not sure but sulu.io <http://sulu.io> might have

> already implemented this approach.
>
> regards,
> Lukas Kahwe Smith
> sm...@pooteeweet.org
>
>
>
> --
> You received this message because you are subscribed to the
> Google Groups "symfony-cmf-users" group.
> To unsubscribe from this group and stop receiving emails from
> it, send an email to
> symfony-cmf-us...@googlegroups.com

> <mailto:symfony-cmf-us...@googlegroups.com>.

> For more options, visit https://groups.google.com/d/optout.
>
>
>

> --
> You received this message because you are subscribed to the Google
> Groups "symfony-cmf-users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to symfony-cmf-us...@googlegroups.com

> <mailto:symfony-cmf-us...@googlegroups.com>.

> For more options, visit https://groups.google.com/d/optout.

--
Liip AG // Agile Web Development // T +41 43 500 39 80
CH-8005 Zurich // PGP 0xA581808B // www.liip.ch

[Bruno Reis]

Thanks David. 

I've finally talked to my client today and considering all the information you all gave me and their needs, we have decided on the following: 

When creating a content, have a "draft" status that will allow only some roles to see it. Maybe, all I need is to allow some roles to see what is not publishable yet. 

When editing a content, save a copy of the content as a "draft editing" or "proposed change". This would have to have a way to be previewed and published. 

The editing, by far, seems the most complex part. It seems that copying the content would be part of the process, but I will need some more interface functionality on that.

This are my first thoughts on that... please tell me what you think. I'll have to have a way to: 

- save a candidate version. As far as I can see, this would have to be a copy of the actual version. The best place I can think is inside of the actual version. The questions you brought are also evident here: what to do with children and references.  

- to preview the "candidate version". The best way I can think of is to display it in a route similar to the original one. Or, even better, to have a notice on the page allowing the user to change between the actual version and the candidate one. 

- to update the candidate version. I think that I could always show the candidate version in the editing page in the case that it (the candidate) exists. 

- to discard the candidate version. I see a button on the editing page for that discarding.

- to actually publish it and replace the actual version with it. I also see a button on the editing page for that. And maybe one on the preview page too.  

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

[David Buchmann]

hi bruno,

i think you can indeed achieve this with the publishable feature. you
could create your own publishable voter that checks if the document is a
draft or the real thing. or you could have your editing force the
publisheable boolean field to false for people not allowed to publish
(and not show the flag in the frontend).

using child documents sounds like a feasable idea. you can then map that
to the normal document, and have

- the backend generate preview links with something like a ?preview=true
flag
- create a route enhancer that comes last, that checks for the preview
flag and if its present replaces the normal document with its draft child.
- access is checked with the publish workflow checker which afaik comes
after the routing.

if you say that any child that starts with eg "draft_" as nodename is a
draft, and the preview flag identify the individual draft, you could
even have multiple parallel drafts.

if you go this way, one thing you would need to figure out as well is
how to generate the route for that document - as it will not have a
route of its own but its parent document has. either extend the normal
document for the draft and make its getRoute return
$this->parent->getRoute() or do something in the route generator. if you
have several different documents, the generate might be the better place...

let us hear how it works out. at the very least, this should be a
cookbook entry in the cmf documentation. maybe we can even add it in one
of the bundles.

cheers,david

> <mailto:da...@liip.ch>>:

> > <mailto:bruno....@gmail.com <mailto:bruno....@gmail.com>>>:

> >
> > Hi
> >
> > Thanks for all the answers. I'll discuss with the team here and see
> > what we choose.
> >
> > I'm inclined to the "copy-on-button-click" solution. It seems the
> > most reasonable solution to me.
> >
> > I'll tell you about our decision and would like to please count with
> > your guidance to implement it.
> >
> > 2015-04-24 6:12 GMT-03:00 Daniel Rotter
> > <daniel...@massiveart.com
> <mailto:daniel...@massiveart.com>

> <mailto:daniel...@massiveart.com

> <mailto:daniel...@massiveart.com>>>:
> >
> > Sadly we didn't have time yet to implement the versioning
> > capabilities in Sulu :(
> >
> > Am Donnerstag, 23. April 2015 13:43:10 UTC+2 schrieb Lukas Kahwe
> > Smith:
> >
> >
> > > On 23 Apr 2015, at 13:36, Bruno Reis <bruno....@gmail.com <mailto:bruno....@gmail.com>> wrote:
> > >
> > > Nice. But, I don't know if I used the right terminology.
> > >
> > > What I need is:
> > >
> > > 1 To have some kind of preview for a new content that is visible by some roles but not by everybody.
> > >
> > > 2 A way to edit a document and save a candidate for a new 'release'. A copy of that document that can be previewed and, if approved, can be published.
> > >
> > > Number 2 seems more complicated because I will need two existing documents on the tree, the actual one and the candidate one.
> > >
> > > Is anything like that in your roadmap? I'd like to elaborate something that will be helpful for the project, not only for us.
> > >
> > > Also, there are other two options to think:
> > >
> > > 1 - to put some versioning/restore functionality on the sonata admin. Do you intend to keep with the sonata admin?
> > >
> > > 2 - also to implement versioning in the doctrine odm. Do you have a cost estimate for this?
> >
> > CMS like AEM etc solve this by basically running a staging
> > server and a production server. Publishing content then
> > means moving new/updated content from the staging repository
> > to the production repository.
> >
> > I am not sure but sulu.io <http://sulu.io>
> <http://sulu.io> might have
> > already implemented this approach.
> >
> > regards,
> > Lukas Kahwe Smith

> > sm...@pooteeweet.org <mailto:sm...@pooteeweet.org>

> >
> >
> >
> > --
> > You received this message because you are subscribed to the
> > Google Groups "symfony-cmf-users" group.
> > To unsubscribe from this group and stop receiving emails from
> > it, send an email to
> > symfony-cmf-us...@googlegroups.com

> <mailto:symfony-cmf-users%2Bunsu...@googlegroups.com>
> > <mailto:symfony-cmf-us...@googlegroups.com
> <mailto:symfony-cmf-users%2Bunsu...@googlegroups.com>>.

> > For more options, visit https://groups.google.com/d/optout.
> >
> >
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "symfony-cmf-users" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> > an email to symfony-cmf-us...@googlegroups.com

> <mailto:symfony-cmf-users%2Bunsu...@googlegroups.com>
> > <mailto:symfony-cmf-us...@googlegroups.com
> <mailto:symfony-cmf-users%2Bunsu...@googlegroups.com>>.

> > For more options, visit https://groups.google.com/d/optout.
>
> --
> Liip AG // Agile Web Development // T +41 43 500 39 80

> <tel:%2B41%2043%20500%2039%2080>
> CH-8005 Zurich // PGP 0xA581808B // www.liip.ch <http://www.liip.ch>

>
> --
> You received this message because you are subscribed to the Google
> Groups "symfony-cmf-users" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to symfony-cmf-us...@googlegroups.com

> <mailto:symfony-cmf-users%2Bunsu...@googlegroups.com>.

[Bruno Reis]

Thanks David. For now, only one draft is needed. On monday I'll further refine this.

If you see any part of this that can be done as a separate bundle or feature to contribute with the project, please let me know. 

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