----- "Rob Miller" <[EMAIL PROTECTED]> 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 -- Archive: http://www.openplans.org/projects/remember/lists/remember/archive/2008/07/1215117921553 To unsubscribe send an email with subject "unsubscribe" to [EMAIL PROTECTED] Please contact [EMAIL PROTECTED] for questions.
