Jim Baack wrote:
----- "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.
yes, although it's still a bit wonky. when you do a copy/paste, the assertion
gets hit during the paste, so all of the duplicates in the catalog will be
purged. this will make the paste take longer, however.
when you do an export/import, the assertion doesn't seem to get hit at import
time, and you WILL end up w/ duplicates all over the catalog. but when you
log in as a user for the first time, it will discover the problematic entry
and will delete it. having duplicate entries is a pathological state,
however; i'd strongly recommend doing a full membrane_tool reindex after the
import to clear things up completely.
and while you're at it, you probably want to do the same for the
portal_catalog... it looks like there are duplicates for each item in there,
as well. i haven't checked the reference_catalog or uid_catalog, but i'd
guess they suffer from the same problem.
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.
yup, that matches what i've seen.
-r
--
Archive:
http://www.openplans.org/projects/remember/lists/remember/archive/2008/07/1215118682146
To unsubscribe send an email with subject "unsubscribe" to [EMAIL PROTECTED]
Please contact [EMAIL PROTECTED] for questions.
