Edit detail for #991 wiki pages leave ghosts in portal_catalog revision 1 of 1

1
Editor: simon
Time: 2005/09/30 11:43:34 GMT+0
Note: links updated

changed:
-
ZWikiPage overrides manage_beforeDelete() (in the __init__.py module... ugh!) and then calls its own unindex_object() method.  it fails, however, to call the unindexObject() method, which it inherits (indirectly) from CMFCatalogAware.  this means that there are ghost entries that are lingering in the catalog, returning bogus search results.

i'd very much appreciate a change here to call unindexObject() when appropriate to do so.

From unknown Thu Dec 16 12:07:28 -0800 2004
From: 
Date: Thu, 16 Dec 2004 12:07:28 -0800
Subject: Seems to correspond to my problem
Message-ID: <[email protected]>

I'm not an expert but it seems to me that this bug making another problem: the titles of Zwiki pages appear in the "properties" forms of Plone objects among the keywords. See my remark in GeneralDiscussion. Samotnik.

From simon Sat Jan 29 14:49:23 -0800 2005
From: simon
Date: Sat, 29 Jan 2005 14:49:23 -0800
Subject: 
Message-ID: <[email protected]>

> ZWikiPage overrides manage_beforeDelete() (in the __init__.py module... ugh!)

What would be better ?

Zwiki uses it's own CatalogAwareness mixin. As far as I can see this and CMFCatalogAwareness and CatalogTool all index and unindex in exactly the same way. I'll simplify our mixin a bit, after next release so it can get more testing.

From simon Sat Jan 29 15:45:11 -0800 2005
From: simon
Date: Sat, 29 Jan 2005 15:45:11 -0800
Subject: 
Message-ID: <[email protected]>
In-Reply-To: <[email protected]>

My mistake, I see we do inherit CMFCatalogAwareness as well. I've checked in some cleanups, but we still don't call unindexObject because it's CMF-specific and it seems to only call uncatalog_object anyway. 

From simon Sat Jan 29 15:47:34 -0800 2005
From: simon
Date: Sat, 29 Jan 2005 15:47:34 -0800
Subject: PS
Message-ID: <[email protected]>
In-Reply-To: <[email protected]>

So I think your stray catalog entries were caused by something else. Perhaps you can check your event log for catalog errors. A full catalog update in the ZMI should get rid of them. Please let me know if you can reproduce the problem after that.

From simon Sat Jan 29 17:05:12 -0800 2005
From: simon
Date: Sat, 29 Jan 2005 17:05:12 -0800
Subject: property change
Message-ID: <[email protected]>

Status: open => pending 


From simon Fri Feb 4 14:32:03 -0800 2005
From: simon
Date: Fri, 04 Feb 2005 14:32:03 -0800
Subject: property change
Message-ID: <[email protected]>

Status: pending => closed 


Submitted by : 127.0.0.1 at: 2004-12-14T19:25:28+00:00 (16 years ago)
Name :
Category : Severity : Status :
Optional subject :  
Optional comment :

ZWikiPage overrides manage_beforeDelete() (in the __init__.py module... ugh!) and then calls its own unindex_object() method. it fails, however, to call the unindexObject() method, which it inherits (indirectly) from CMFCatalogAware?. this means that there are ghost entries that are lingering in the catalog, returning bogus search results.

i'd very much appreciate a change here to call unindexObject() when appropriate to do so.

Seems to correspond to my problem --Thu, 16 Dec 2004 12:07:28 -0800 reply

I'm not an expert but it seems to me that this bug making another problem: the titles of Zwiki pages appear in the "properties" forms of Plone objects among the keywords. See my remark in GeneralDiscussion. Samotnik.

... --simon, Sat, 29 Jan 2005 14:49:23 -0800 reply

> ZWikiPage overrides manage_beforeDelete() (in the __init__.py module... ugh!)

What would be better ?

Zwiki uses it's own CatalogAwareness? mixin. As far as I can see this and CMFCatalogAwareness? and CatalogTool? all index and unindex in exactly the same way. I'll simplify our mixin a bit, after next release so it can get more testing.

... --simon, Sat, 29 Jan 2005 15:45:11 -0800 reply

My mistake, I see we do inherit CMFCatalogAwareness? as well. I've checked in some cleanups, but we still don't call unindexObject because it's CMF-specific and it seems to only call uncatalog_object anyway.

PS --simon, Sat, 29 Jan 2005 15:47:34 -0800 reply

So I think your stray catalog entries were caused by something else. Perhaps you can check your event log for catalog errors. A full catalog update in the ZMI should get rid of them. Please let me know if you can reproduce the problem after that.

property change --simon, Sat, 29 Jan 2005 17:05:12 -0800 reply

Status: open => pending

property change --simon, Fri, 04 Feb 2005 14:32:03 -0800 reply

Status: pending => closed