----- "Rob Miller" <robm@...> wrote:

> Rob Miller wrote:
> > Jim Baack wrote:
> >> Thanks, Rob.
> >>
> >> I simplified the test case a little and used the remember type 
> >> directly. Same problem.
> >>
> >> The debug shows that the the new membrane_tool catalog contains
> both 
> >> the original and new members. Perhaps the catalog needs to be
> cleared 
> >> as it's cloned.
> >>
> >> Clearly, we can tell which of the two objects is the correct one by
> 
> >> comparing to the tool itself (last line). Probably not the ideal
> fix.
> >>
> >> Any thoughts? Thanks.
> > 
> > not yet... i'll try to reproduce myself, see if i can't figure
> something 
> > out.  hopefully i'll be able to get to this later today.
> 
> okay, i've made some progress here.  first, i changed membrane so that
> it 
> won't barf on the pathological catalog state that importing or pasting
> a Plone 
> site produces.  you can see what i did in r67772 in the collective...
> i was 
> going to link to the changeset on dev.plone.org, but it's not
> responding ATM.
> 
> there was still a problem w/ copy/paste, however.  the member objects
> were 
> trying to perform schema validation before the newly pasted site had 
> completely wired up the portal_skins acquisition.  this was failing,
> b/c AT's 
> validate_vocabulary method needs access to the 'unicodeEncode' skin
> script.  i 
> added a unicodeEncode method to remember's member implementation that
> works 
> around this issue.  you can see this in r67773 in the collective.
> 
> now i can both copy/paste and export/import a remember-based Plone
> site w/ a 
> single member, whereas before i couldn't.  things still seem a bit
> whack, 
> though..  in a pasted site, the front-page comes up as 'private' for
> me, when 
> it's not private on the source site.  i'm guessing that content is
> being set 
> back to the default workflow state instead of that information being
> carried 
> across like it's supposed to.  if this is the case, then it's likely
> to impact 
> the member objects as well.
> 
> this doesn't seem like a membrane or remember issue, though, so for
> now i'm 
> gonna consider this resolved.  hope it works out for you!
> 
> -r

Thanks, Rob. I'll pull it down and check it out. I had noticed that when removing the assert for a temporary workaround, the resulting copied site would have both old and new entries for each member in membrane_tool - the uncatalog fix you put it in should take care of that too. 

I saw the unicodeEncode error (and several others not related to membrane/remember) on copy/paste so have moved to export/import instead which seems to have none of these issues and works fine for me now.

Thanks.

Jim