-
☆ A M B ☆
- 326 Posts
Hi everyone,
I know workflow and versioning have been talked to death around here, but I haven’t seen a lot in regards to Revolution (other than the promise of it being built into 3.0 -- hallelujah!), and some back-and-forth on Twitter yesterday persuaded me to start a thread. If you’ll indulge one more conversation on the topic, I’m starting a project that needs a fairly basic (I think) but crucial workflow system, and because of the size of the site (5000+ docs at launch and doubling 1-2 times a year), I think Revo is the smarter choice here.
Basically, I have one person who enters content -- and there’s a LOT of it. Luckily, it’s all text blocks entered into Rich Text TVs. I’ve allotted 20 TVs per page. Then there’s a second level of editors (about 20 of them) who need to receive notification that these blocks are ready for editing, view them, make changes in a WYSIWYG, and save/notify the main editor that the changes have been committed. Archived changes (aka versioning) beyond one level back would be awesome, but not essential. Once the main editor has seen the changes, she needs to be able to edit them and send them back to one of the 20 editors again if necessary. Two factors that simplify the process: only she can move content out of the editing loop, and all of the content is non-public and will go live as a whole (publish/unpublish set on the main containing resource).
With that concept in mind...any ideas? My current plan of attack is to use separate tables in the DB and build a custom front-end editor using Revo roles, and somehow tie the editing into the main DB. I welcome any and all feedback or suggestions, as this is definitely going to push my programming boundaries.
Thanks!
So, I’ve been starting to think about this myself. About to start the process of moving our main site from Evo to Revo and would love versioning....
It’s all very amorphous right now since I’m several weeks away from really even thinking about laying any code down, but there are a few points that I THINK make sense.
1) The onBeforeDocFormSave event seems pretty important to tie a plugin to. Before a document is saved, grab the current fields this document (i.e. the fields that you probably just changed in the editor), compare them to that doc in the database.... if it’s different grab the record in the database, drop IT in a archive table and then continue with the save as normal.. The plugin would also handle the number of "archived" copies to keep... if you want 5 and there already is 5, throw out the oldest. This actually seems relatively easy to do.
A custom manager page would need to handle restoring prior versions.
But I think all of this is a little different from what you’re looking for.....
2) Multiple Editors
We talked about something similar a little at the MODxpo. At that time we threw around the idea of having check boxes that were available to the various roles - so dept A checks for approval, dept B, and dept C, and when all three have given approval, then the publish flag gets thrown and the page goes live. You’re going a little further still it seems, but it honestly seems like most of the necessary functions are available via the api and some creative php.
For the main editor to send it back..... I see a plugin tied to a save event and a drop down template variable with a list of people or roles to send this document back to (i.e. to send a notification that this needs to be edited).... so the simplified plugin would be something like onSave, if not published and if sendBackAddress selected, send message to x user.....
Does that make sense?
Honestly, I’d love to collaborate with you on something like this if you’re up for it. I’ve been wanting to set up something similar on a smaller scale for a while so this would be a good way to knock it out.
Des
webandflowdesign.com
-
MODX Staff
- 730 Posts
I began to outline some thoughts on this after MODxpo, but like 100 other code ideas, it remains unstarted.
My thoughts were constrained to an editing/publishing workflow where an editor could work on updates to a resource while it remained published on the site. A publisher would have the power to review, edit and push the change live. And it was initially focused around the [*content*] field only.
Versioning would be more complex to do, and dealing with the entire document would also add complexity. Not saying that it shouldn’t be done though.
I’ll review my notes again after reading this thread and see what comes up. I’d love to help out and the idea of getting a number of us focused on a project seems like a great idea.