I have a situation where I need to be able to see changes before they are in the status of Open.  I was thinking about going down the road of a “Live Look” implementation, but given the server setup that I’m dealing with I think the best way to handle it will be to modify the core php code to change the default status that show the data “live”.  I have an admin instance (web) which shares the same db with the actual production server (3 servers load balanced.).  Each of the servers has their own web tree so I can modify the “admin” server to show Open|Draft entries by default and entries which are still in Draft mode will not show up “live” in the production environment until someone with the correct privs (in the right EE group) changes the status of the entry to Open.  Where in the core code is the check made to default the select to only bring back Open entries??
Thanks

precision - 01 October 2008 01:21 PM

I think the best way to handle it will be to modify the core php code to change the default status that show the data “live”.

To be frank, I don’t think hacking EE files that is the best way. Why don’t you use a custom status of, say, “Draft”, and use that by default? You can then use a template to show you such “Draft” entries, and change the status to “Open” once you are satisfied with it.

... so I can modify the “admin” server to show Open|Draft entries by default and entries which are still in Draft mode will not show up “live” in the production environment until someone with the correct privs (in the right EE group) changes the status of the entry to Open.

Yes, but that is pretty much built-in, you only need to specify it in the template, no need to hack EE.

I thought about going the “duplicate” template route, but there are already a large number of templates and they are growing.  That approach just won’t work in this situation; it will be too cumbersome.  I would agree that hacking the EE core isn’t the best solutions in most cases, but in this case I think it is given the separate instance for the admin server and the fact that it shares the DB with the production servers, but the production servers have their own copy of the EE core code.  The only change would be on the admin (staging) server and it really looks like that would be the best approach in this case. Modifying the templates won’t work very well in that they are rsynced (when modified) to the production servers.  If I rsync the templates and the templates show draft entries on the admin server…. as soon as they are rsynced the production servers will show draft entries…. that’s definitely not what I need here…

precision - 01 October 2008 01:55 PM

I thought about going the “duplicate” template route, but there are already a large number of templates and they are growing.  That approach just won’t work in this situation; it will be too cumbersome.

Just use one template, then, but show different content based on member groups: Superadmins (or some other admin group) get to see all statuses, general members and the regular public only get to see “Open” entries. Hacking EE is not supported, and would be much more cumbersome.

Ok,
I’m back to this thread….
I hacked the EE code to show Open|Draft entries on the prodAdmin instance and added the Draft status to the default group.  I having the same kind of issues that others have with trying to manage dev/test/production on a site which multiple persons need to enter content ... and there needs to be some workflow control.. Dumping the DB isn’t an option as the Db is shared between the “ProdAdmin” and “production” instances of the site as well as data being entered on production site by users…  I have everything working except one case….

  When a user within the “Editor” group (this group cannot set status to Open….) creates an entry it will default to Draft mode, but because of the EE hack Draft will show on the productionAdmin version of the site….  that’s cool… exactly what we want… The data can be previewed on the prodAdmin site, but the “live” production site will not see it as it’s not in “Open” status…nice….except for edits (non creates).  As soon as a user in the Editor group edits an entry it will revert to Draft and disappear from the site… not good….  The one issue that I haven’t been able to get to work could possibly be solved by using the last “Open” revision of the entry (versioned within the db…does the “status” of the version get stored with the version??)  so while an edited version is in draft mode a previous “Open” version could be used for viewing on the site… The option to enable this feature would have to be in config.php or somewhere similiar as the db is shared between the prodAdmin and “live” servers and the prodAdmin would not enable the feature as it would show the Draft version and the production servers would show the “last” open version…..
Ok back to banging my head against the wall….

precisions, I am sorry I still do not think that hacking EE’s files is a viable solution. Furthermore we cannot support such modifications. Why did you find my last suggestion, using a single template and differentiating by user group, impractical?

We have 100s of templates involved… it’s just not feasible.  In addition it doesn’t solve my problem.  If certain groups couldn’t see entries with non-Open status within the prodAdmin environment, then users in the production (live) environment wouldn’t be able to see them either…

Hi precision - as far as users opening entries and the status changing, you need to make sure that a status group is assigned to that weblog and that the membership group has access to the given status.

I’m quickly coming to the conclusion that EE just isn’t designed for a dev/test/prod environment.  Everything that I’m reading on the forums about workflow basically points to that.  Others are having the same issues and I just don’t see a way around it at this point.  If you have separate databases you’ll need to duplicate your effort to get the data from one environment to another.  If you have one DB you can’t make data show in one environment and not show in another… just doesn’t seem to be designed for the type of environment that I’m working in…

I think it depends on the exact needs.  Having draft statuses requiring approval and viewable to only certain groups frontend or backend is easy.  What gets tricky is with editing those.  So- if it’s open, and Joe Smith with low level permissions needs to edit it- does it revert back to closed to public?  Or make a second ‘copy’ that must be approved and then flipped out for the current live one.

There’s almost always a way to do these things, but the second example I’m glad I’ve never needed to setup, as it is tricky.  But I’ve thought about how I would.

Anyhoo- if you like, I could shift to ‘How to’ for brainstorming on the topic.  I think it starts getting site specific fast once you get into the details.

Go head and shift it to “How To”
Thanks

Will do- and the more details you give on the site needs, the more folks may have ideas on how to set things up.

A description of the environment can be seen in the initial post.

I’ve basically given up trying to get this to work for the time being. 
For the environment I have (shared DB) I would need to modify the EE core code for the production boxes to pull the actual entry (when an entry is in ‘Draft’ or ‘Released’ mode) to show “live” from the exp_entry_versioning table.  This is doable, but not really a good choice as it requires major mods to the mod.weblog.php and some pretty complex changes to the way in which the queries for entries are handled. 

I think it would be nice to have the ability to save entries as files (much like templates).  This would allow easier management of workflow from one instance to another (staging->production, etc.)  Since those web instances would have different web trees entries would be visible in one and not the other until the files were moved to the second instance (separate web tree)......

Just my thoughts…..