New PW Project - notification and approving page changes?

[FuturShoc]

We've got another upcoming website project with a client who wants to manage site updates in an approval style workflow.

User roles would be generally normal, but they'd like to have the sit generate emails to super users who then "approve" site changes before publishing them.

I don't expect anyone to write the code for me, of course, but I'm interested in general feedback on what parts of PW to exploit to achieve this goal.

I'm guessing from other posts I've read about user roles that a PW hook might be the best answer here... But I also want to make sure I'm considering any and all native features that PW might provide to help.

[Pete]

Version control is on the roadmap, but in the meantime a way you could theoretically go about it is to write a module that dies something like this:

1) If the user has permissions to edit without approval, page saves as normal

2) If they need approval due to user group, a module creates a child page (so hook before page save to stop saving the real page), mark child page as hidden & unpublished and email whoever you need

3) You would then need a button oj the child page where the authorising user can click to merge changes back to the parent - this would again trigger before page save, replace the parent page with the value of the child page and delete the child page

Problem is you've not really created a useful version control system but rather just a simplified approval system plus there's no comparison in there (you would probably want a diff function in there that opens the content side by side in a modal window highlighting the changes).

Soooo... it's a complicated prospect to say the least with many ways if approaching it

[FuturShoc]

Thanks for your input, Pete.

Yes, I was afraid of that. I'm really pushing ProcessWire adoption in my shop, but we just landed a big new contract with a municipal client who specifically asked for version control of pages and approvals. I may have to use SilverStripe (our previous shop standard CMS) for this one as I won't likely have time to work out the details of our own PW module in the timeline I have.

[ryan]

ProcessWire will do all of this, but Pete is right that you'd have to do it from the API side rather than click to setup. Probably what I will do is build some more formal workflow modules in upcoming versions of PW that do it out of the box but also give you a good starting point to modify from. Currently it's fairly trivial in ProcessWire to setup a workflow for approval of new pages to be published. But setting up the workflow for approval of modifications to already-published pages takes much more on the API code side. 

[FuturShoc]

Thanks for your feedback on this, Ryan. Your active involvement here on the forums is a major factor in my adoption of PW personally and in my day job.

[ceberlin]

Approval of changed content (text) becomes an issue on my current project, too.

Right now I am thinking about something simple and elegant to make things not too complicated.

I was thinking of having a role as editor (writer, marketing, seo-guy) and one as a supervisor (legal department, boss...).

I had the idea to have every text field double, one is the displayed field (e.g. I call it "FIELD_LIVE")  and one is a field for the changed content (e.g. "FIELD_NEXT").

FIELD_LIVE has no write access for editors but there is a button which would fill the empty FIELD_NEXT with the content of FIELD_LIVE for editing.

(If there was no change, FIELD_NEXT is emptied after saving the page - as a clean-up,

and if there is already changed content in FIELD_NEXT the copying would not work and would have to be done manually - as a precaution.)

Supervisor sees a list of all pages that has a FIELD_NEXT with (unique) content for approval. He/she can then can edit this further and can

press a button to copy over the content from FIELD_NEXT to FIELD_LIVE (which would empty the FIELD_NEXT) or dismiss the changes (clear FIELD_NEXT).

Editor would have only the one button to dismiss the changes (clear NEXT_FIELD).

For assistance of the supervisor and the editor I would try to make a diff available, using something like the jQuery plugin PrettyTextDiff:

https://github.com/arnab/jQuery.PrettyTextDiff

The whole thing would work only with simple text fields but that is a start. (What can't be shown with this probably is highlighting of pure style changes and other html changes by TinyMCE?)

 

And, obviously, the FIELD_NEXT should not turn up in any search results.

Is this the right thinking or is there a better way (or already a module in the works I should wait for)?

[ceberlin]

a note: I just saw this topic (had searched with the wrong keywords and did not find it earlier) dealing with the (kind of) same issue:

http://processwire.com/talk/topic/1499-module-proposal-page-version-control/

Version control is different from a moderation/approval system: Obviously one is done by a supervisor before going live and one after.

Maybe both concepts could work well together...

[MatthewSchenker]

Greetings,
Glad to see this discussion, because I need this for a couple of projects as well. I've been playing with a couple of ways to do this, which I describe below in plain (non-code) language.

There are two parts here, each with their own solutions. As Ryan explained, these ideas require creating and editing pages via the API:

1. Approval to Publish
I am currently handling this is by adding a simple "published" checkbox that is only visible to people with certain rights. When searching for pages to display, I only find those that are approved (checkbox = "1").

2. Approval to Edit
For this, I think ceberlin and I are fairly close. First, we need to use the API to create an edit page for our content. Inside that edit page, there are two forms: the "live" form, which contains the currently published material; and an "edit" form, whose fields simply repeat those in the "live" form. Initially, the values in each form are identical. When someone without enough rights changes the "edit" form and hits "submit," the page then contains different information in the "edit" form and the "live" form. But the "live" form continues to be the currently published material. When someone with higher rights visits the edit page, and submits changes in the "edit" form, the changes overwrite the "live" form and that is what now appears in the live site. In this case, the page is saved using the values in the "edit" form using the normal page-creation/page-editing routines of the API.

How does this sound?

Thanks,
Matthew

EDIT:
A couple of things I forgot to mention above... First, the "edit" form should be the way that everyone submits changes, no matter what your approval rights are. The difference is, people without approval rights would only see a "Submit Draft" button (only changes the "edit" form), but people with higher approval rights see a "Submit Draft" and a "Publish Changes" button. Next, we need to handle the initial pre-population of the "edit" form. There would be logic in the edit page to detect if the "live" and "edit" forms have the same data, or if they have different data. If they are different, we don't want the "edit" form to be overwritten. That way, proposed changes are preserved until approval is made. When the "Publish Changes" button is clicked, it would overrwite both the "live" and "edit" form fields. If the "Submit Draft" button is clicked, only the "edit" form is changed. This allows edits to be "discussed" until approval is made.

[renobird]

Resurrecting this topic.

I need to establish an approval process for both publish and edit — it also needs a comparison feature like Pete mentioned. I'm looking into building an in-house module(s) to handle this — perhaps using something like PrettyTextDiff for the comparison.

I'm wondering if anyone else has already developed anything that they wouldn't mind sharing. Save myself a little work.

[Joss]

Just thinking about one of Ryan's sites where he used two installations - one for input and the other for output (as far as I can remember).

Might be overkill, but perhaps worth looking into that approach? Not sure how he did it!

[apeisa]

One option to evaluate is Teppo's version history module, and it's snapshot feature in particular. Maybe having latest approved date -field and then use that together with snapshot?

I am sure that no matter route you will take, it won't be simple. But that would be interesting to investigate.

[Pete]

This was a neat PHP diff library that I found when thinking about the same thing some time ago: https://github.com/chrisboulton/php-diff

The demo looked quite nice (requires download to see the example).