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