Review process and MMWIP directory

[Iowa Boy]

I'm running into two significant issues with Contribute deployment. I would
really appreciate any feedback! 1) Reviewing drafts: Here's the situation: if
you have three pages in a linear process. The first two pages are form pages
and the final page is a processing page that saves the information to the
database and e-mails the user that the form has been submitted. If an editor
wants to change the thank-you message on the third page in the process,
Contribute can easily allow that. However, that page is not available in the
review process and fails of course because it is expecting information from the
previous two pages. Now, with error checking you might just forward the person
back to the starting page, but that defeats the review process as well. Any
ideas on how to work around this? 2) We've had several users that are editing
pages and then publishing pages that have the directory /MMWIP/ embedded in
them. That's bad. The MMWIP directory should at the most show up in pages
that are being reviewed, but should never show up in a published page from my
understanding. Is there a fix for this? Has anyone else had this problem?
Thanks! Derek

[skozey]

We just ran into the same problem with Contribute 3.x (still haven't figured
out if its 3.0 or 3.1, or both) that you outlined in your item #2. It appears
that occasionally when edits are made to a page by someone with editing but not
publishing privileges, then reviewed and published by a publisher, that the
include paths for the CFINCLUDES that pull in header, footer and nav includes
files get re-written. For example:

cfinclude template="../includes/"

to

cfinclude template="../MMWIP/includes"

the published pages are then broken (note the paths in the templates they are
based on aren't affected).

Did you figure this one out or get any help from Macromedia? Which version of
Contribute were you using?

[Iowa Boy]

No, we never received a response. We've had quite a few difficulties.
Originally we purchased Publishing Services as well, but we had so many
problems (including the corrupting of sitewide permissions during a training
session) that we uninstalled Publishing Services. At any rate, we eventually
have just limited access to Contribute down to only those individuals that we
want to give full publishing permission to (which really defeats the purpose of
one of main features: reviews). We ocassionally still hit issue 2, but I just
delete the page and a start over or restore from a backup. These aren't the
best solutions. I think the entire system is has some great capabilities, but
we are going to have to wait for the next release (of both Contribute and
Publishing Services) to see if these an other issues are fixed.

[skozey]

Hey Iowa, did you open up a support incident with Macromedia on this? I ask
because we did so for another Contribute issue and the Macromedia product
engineers were very helpful and went to considerable lengths to diagnose the
problem and come up with a workaround (the contents of cfinclude files were
being written directly into pages when editing pages with cfincludes in
Contribute). As it turned out the problem we had wasn't reproducable on other
servers except our development box (weird), but by removing http access
permissions in IIS to the template folder (as suggested by the product
engineers) we were able to "solve" the issue. And because it was a bug support
incident it didn't require us to purchase support services.

I might open up an incident on this issue if we see it come up again. Or, if
you do decide to open up a support case, post back to this thread and I'll make
a point of doing so as well. It might help escalate the problem!