July 2003 - Zope-Dev

Re: [Plone-developers] problem upgrading from 1.0.1 to 1.0.3
by Gilles 18 Jul '03

18 Jul '03

Hello The problem I have is that I am using only standard plone installation: and I now use only 'stable' release. - plone 1.0.b1 - plone 1.0.1 - plone 1.0.3 I install or update nothing at all into my plone instance: I don't want to do it . I just use it. I am not able to fix a faulty plone site... To play around I use a zope installations. I was expecting that by using standard plone delivery I would be able to upgrade without to much problems. For some reason it's not all the time the case. So I am using: - CMFCore (Installed product CMFCore (1.3.1)) - CMFPlone (Installed product CMFPlone (1.0.3)) - CMFWiki (Installed product CMFWiki (0.1)) - CMFPhoto (Installed product CMFPhoto (0.2)) It is not possible to check the 'skin_paths in potal_skins -> Properties tab', because this render a plone page showing the error: > > Error Details > > Error Type > > AttributeError > > Error Value > > photo_content Is it possible that this CMFPhoto product (which is new for me: it is coming inside the 1.0.3 upgrade) is not registered correctly inside my installation?? Is there a way to move my old site data (the /Menber folder?) into a fresh new plone 1.0.3 installation? I try this already from a 1.0.b1 to 1.0.1, but copying (export/import) the /menber folder was not enougth. Thanks anyway for your suggestions Gilles ----- Original Message ----- From: "alan runyan" <runyaga(a)runyaga.com> To: <Gilles.Lavaux(a)esa.int>; <plone-developers(a)lists.sourceforge.net> Sent: Thursday, July 17, 2003 10:03 AM Subject: Re: [Plone-developers] problem upgrading from 1.0.1 to 1.0.3 > > > > > > 1) with the 'manage plone' interface: the left frame render my plone site > > with an error message: > > Site error > > This site encountered an error trying to fulfill your request. The errors > > were: > > > > Error Details > > Error Type > > AttributeError > > Error Value > > photo_content > > does photo_content exist in portal_skins? what about the > skin_paths in potal_skins -> Properties tab? > > > > > > > 2) I can not edit anymore a wiki page: the error is: > > > > Error Type > > TypeError > > Error Value > > edit() got an unexpected keyword argument 'log' > > > > ascii traceback is: > > Traceback (innermost last): > > Module ZPublisher.Publish, line 98, in publish > > Module ZPublisher.mapply, line 88, in mapply > > Module ZPublisher.Publish, line 39, in call_object > > Module Products.CMFCore.FSPythonScript, line 90, in __call__ > > Module Shared.DC.Scripts.Bindings, line 252, in __call__ > > Module Shared.DC.Scripts.Bindings, line 283, in _bindAndExec > > Module Products.CMFCore.FSPythonScript, line 124, in _exec > > - __traceback_info__: ({'script': <FSPythonScript at > > /Plone/wikipage_editcomment_handler used for > > /Plone/Members/admin/Folder.2002-10-21.3652>, 'context': <PloneFolder > > instance at 01D42020>, 'container': <CMFSite instance at 01D0AF08>, > > 'traverse_subpath': []}, (<HTTPRequest, > > URL=http://asgard/Members/admin/Folder.2002-10- > > 21.3652/wikipage_editcomment_ > > handler>, ZServerHTTPResponse('')), {}, None) > > Module Script (Python), line 18, in wikipage_editcomment_handler > > TypeError: edit() got an unexpected keyword argument 'log' > > look on line 18 in wikipage_editcomment_handler. > are you using CMFWiki? ZWiki? Look at the edit method of > the content object you are calling wikipage_editcomment_handler > in the context of and see whats going on. > > > Note: I had no error when I have done the 1.0.1 to 1.0.3 migration. > > There were no migration errors. But you are having this error. > > ~runyaga > > > > ------------------------------------------------------- > This SF.net email is sponsored by: VM Ware > With VMware you can run multiple operating systems on a single machine. > WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the > same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 > _______________________________________________ > Plone-developers mailing list > Plone-developers(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/plone-developers >

1 0

Zope 2.6.2 b4 & final
by Brian Lloyd 18 Jul '03

18 Jul '03

Hi all - We're planning to cut 2.6.2 b4 today, since there have been a few fixes committed since b3. I'd like to plan to cut the final next week with no changes from b4. Brian Lloyd brian(a)zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com

1 0

Suggestion for DT_In
by Johan Carlsson 18 Jul '03

18 Jul '03

Hi, I found a small change that can solve a problem with sort_expr in dtml-in. There is no way to let the dtml-in not sort when using sort_expr. This would be a good thing if you want to be able to choose the default order of the sequence: A small patch to DT_In enables the dtml-in to ignore sorting if the result of the expression is None. if self.sort_expr is not None: self.sort=self.sort_expr.eval(md) - sequence=self.sort_sequence(sequence, md) - elif self.sort is not None: + if self.sort is not None: sequence=self.sort_sequence(sequence, md) This patch needs to be done in to places: renderwb and renderwob as far as I can see. -- Johan Carlsson Tel: + 46 8 31 24 94 Colliberty Mob: + 46 70 558 25 24 Torsgatan 72 Email: johanc(a)easypublisher.com SE-113 37 STOCKHOLM

1 0

New zope.org rollout and transition plan
by Brian Lloyd 17 Jul '03

17 Jul '03

Hi all - At long last, we are preparing to 'go live' with a new and improved zope.org. The new site will put an architecture in place that will make it easier to maintain and improve the site. We're planning to make the new site live as www.zope.org at the end of July. The current site will still be accessible as old.zope.org. We plan to keep the old site available for a reasonable amount of time to ensure that important content that may have been missed by the migration can be hand-moved, etc. We'll give plenty of notice before decommissioning the old instance. Q: What does this mean for zope.org members? Generally, all membership info and most content will be transitioned to the new site automatically. Due to the amount of content and the 'organic growth' of the current zope.org over time however, there may be some bits of content that are either missed or get broken in some subtle way during transition. If you maintain product releases, articles or other content on zope.org, it would be a good idea to check on it after the transition. If you find things missing, you should be able to find it on the old.zope.org site and add it manually to the new site. If you find something broken and you don't know why, let us know so we can fix it. Q: Will there be some kind of 'public beta' period? Not per se. Experience has shown that it is hard to drum up the critical mass of usage required to really uncover non-obvious issues using a separate 'beta' site. In addition, zope.org presents a challenge in that you really need a short and choreographed 'switchover' window due to the community- contribution nature of the site. Members generally don't want to contribute their content twice (once on a beta site and once on the 'real' site), and we also need to go live quickly after a final content migration to minimize the inconvenience for people who might contribute content in the window between final migration and the launch of the new site. Q: Will the transition be quick, painless and invisible? Ha ha - silly human. :) We know from experience during the last zope.org transition that there will a period of hand-fixing after the new site goes live. Leaving the old site accessible during the transition will help with any pain we experience. I'll send another note when we finalize the dates for the final content migration and go-live date. I want to keep the window between these down to a day if possible to minimize disruptions. Brian Lloyd brian(a)zope.com V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com

1 0

Access Rule
by Hubert Muller 17 Jul '03

17 Jul '03

Wyciśnięte cytrusyHello, Anybody knows how to restore acces to folder with bad written site access rule ? Versioning works fine for me, but is any simplier/alternative solution ? regards Hubert Muller

2 1

ZCatalog indexes tab - which Index Types are guilty?
by Chris Withers 17 Jul '03

17 Jul '03

> The problem is caused by calling len() on the indexes btrees. Instead > a counter implemented btree.Length should be used in the future. Which Index types are currently guilty of this? How about re-naming the column to "Number of Documents Indexed" and making sure this is actually what the indexes return. I have a feeling that not all index types actually return the number of objects indexed. Can anyone confirm this? cheers, Chris

2 1

Two small ZPT suggestions
by Toby Sargeant 17 Jul '03

17 Jul '03

Hi, I must preface by saying that I'm relatively new to ZPT, and haven't been using it in the context of Zope. Having said that, however, I think that what follows is still applicable. Two things that have struck me as potentially useful additions have been a syntax for expressing case statements and arguments to macros (slots are useful, but aren't applicable when, for instance, you want to write a macro to mark up an arbitrary object). Both of these are essentially syntactic sugar, but (imho) improve readability and aid brevity. The syntax I have come up with (and have an implementation for) is as follows: case statements: two new attributes are added: tal:switch and tal:case. as an example: <table tal:repeat="row rows" tal:switch="row/rowtype"> <tr tal:case="string:group">...</tr> <tr tal:case="string:user">...</tr> <tr tal:case="string:files">...</tr> </table> compare: <table tal:repeat="row rows"> <tal:block tal:define="casevar row/rowtype"> <tr tal:condition="python:casevar='group'">...</tr> <tr tal:condition="python:casevar='user'">...</tr> <tr tal:condition="python:casevar='files'">...</tr> </tal:block> </table> This is essentially the same as using tal:define and multiple tal:condition blocks, except for the fact that the case values aren't part of the visible variable space. Missing at the moment are: * ways to change the type of comparison used in the case test. * a sensible definition of how a default case should work. (this is actually pretty obvious, but would require more work, as the case statements can't be simply treated like conditionals) macro arguments: metal:use-macro tags allow metal:arguments="define_list" which defines a set of variables in a new local scope in which the macro is executed. if tal:define could be used in conjunction with metal:use-macro in such a way as to have the define executed first, then the additional tag wouldn't be required. My reading of the docs suggests that there's reason for the ordering of excution of tal: and metal: tags, so the new tag may well be the only way. <tal:block metal:use-macro="a_macro" metal:arguments="obj path/to/an/object; verbose python:1" \> compare: <tal:block tal:define="obj path/to/an/object; verbose python:1"> <tal:block metal:use-macro="a_macro" \> </tal:block> Toby.

2 1

stopping the Version DoS
by Leonardo Rochael Almeida 16 Jul '03

16 Jul '03

Hi, I didn't check the sources to see what solution was finally given to the Version DoS attack, but I have a suggestion. The problem, IIUC, is that Zope needs to decide whether the Version informaton it's receiving is valid without having access to ZODB data. My suggestion is to disable Versions unless Zope is started with the ENVVAR (or ZConfig var) VERSION_KEY, which is a password used to hash the Version info. In this case, the version cookie would be generated like this Zope-Version = <version>:MD5(<version>:VERSION_KEY) This way the connection machinery doesn't need to open the connection in order to verify that Zope-Version was generated from a real version object. The only way to abuse the Version system is by knowing VERSION_KEY. Looking at the cookie itself will only allow an attacker to open the same version, but even this can be avoided if we put an expiration time in the cookie value and encode it in the signature part as well: Zope-Version = <version>:<expiration>:MD5(<version>:<expiration>:VERSION_KEY) Variants of this include putting the auth info in a different cookie (Zope-Version-Auth), using SHA instead of MD5 to make it stronger, base64 encoding the binary flavor of the digest digest instead of using the hexdigest to make the cookie smaller, etc. Cheers, Leo PS: I can help coding this if anyone can help me get my subscription to zope-coders going (I tried subscribing but nothing happened) and checking why my public key isn't working to get a Zope checkout (my zope.org login is LRA) :-)

2 1

WebDAV interoperability event
by Paul Winkler 16 Jul '03

16 Jul '03

I just stumbled across this... I think it would be really cool if there was a zope presence. http://www.webdav.org/other/interop03/ -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's PORPOISE MADE OF BUTTER! (random hero from isometric.spaceninja.com)

1 0

broken dtml document security
by Jamie Heilman 15 Jul '03

15 Jul '03

The security on DTML Documents seems to be hosed, see http://collector.zope.org/Zope/865 for way to reproduce it. -- Jamie Heilman http://audible.transient.net/~jamie/ "Paranoia is a disease unto itself, and may I add, the person standing next to you may not be who they appear to be, so take precaution." -Sathington Willoughby

1 0