Thread

I’ve been doing some thinking about workflow in EE, since it’s really the only missing piece of the puzzle for me (well, that and LDAP connectivity, but that’s for another time), and think I might have come up with something.

Say I want my writers to use only one main text field for all posts. If I were to use a custom field (call it EDIT) in the backend, and show them only that field instead of all the others, could I then set EE to run a script or an action, once that post’s status is changed to ‘open’, that would copy the contents of EDIT to the contents of the Body field? If so, I could set all of my public templates to ignore the EDIT field entirely and only show the common Title and Body fields, leaving my writers free to switch back to another custom status and edit all they like in the background while the previous version remains live.  Is an action like this easily possible in EE? If not, can anyone suggest a better way?

I know a bit about custom statuses, but for some reason they seem to be a little out of fit for what I’m trying to do - namely, leave the current revision of a post available to the public while the new revision is going through the workflow process (from writer, to director, to me).

I suppose I could run a cron job at various times throughout the day to mimic this behavior, but I’m hoping one of you will be able to tell me an easier way to do this, or point me in a better direction altogether.

Thanks! 😊

That is a fantastic idea!! Not sure how it could be achieved but sounds great in theory.

That is a fantastic idea!! Not sure how it could be achieved but sounds great in theory.

Good to hear I’m not totally off course (unless it’s both of us, of course 😉). The cool thing is that the idea could be taken out further with a little work. I imagine that you could map as many custom fields as you wanted to ‘real world’ counterparts and let your writers go to town. It would be like a mini staging area built into the site itself. The idea came from some sketches I drew up for a custom Filemaker solution that I was hoping would do essentially the same thing.

Hopefully this will catch the attention of someone a little more proficient in EE’s inner workings than I.

Will a combination of versioning and status work? Then you could look at entries with either status and if the status = closed then publish the previous version, otherwise show the latest.

Will a combination of versioning and status work? Then you could look at entries with either status and if the status = closed then publish the previous version, otherwise show the latest.

I thought about that, but I don’t think it would. all you would need for someone to hose up the whole system is to post multiple revisions, one right after another. It would be completely insecure.

What about just setting up two separate weblogs one for the “live” pages and one for “development” pages. Writers would only have access to the “development” weblog. An admin would have to approve their edits, and then change the weblog setting in the options tab to make it go live. I haven’t tried this, but you could probably even use the same templates for both groups, maybe using a conditional and url segments to determine whether to show live or dev. content.

What about just setting up two separate weblogs one for the “live” pages and one for “development” pages. Writers would only have access to the “development” weblog. An admin would have to approve their edits, and then change the weblog setting in the options tab to make it go live. I haven’t tried this, but you could probably even use the same templates for both groups, maybe using a conditional and url segments to determine whether to show live or dev. content.

That’s not a bad idea for posting of content, but I don’t think it does much for revisions. That is, If they can’t get to the ‘live’ weblog, then they can’t pull an item back down for revision. I could copy their new posts over to the old entries, I suppose, but then I’d have to be able to remember what they posted previously, and also gauge intent - which opens up its own can of worms, and creates more work for me (and the other admins). Since revisions aren’t possible in that scheme, it’s easier to just continue using custom statuses.

Thanks for bringing this thread back to life, fellas.