', #self.logo(), self.searchform(d), I've tried uncommenting self.logo() but that doesn't make a difference. Can anyone tell why logo_string works in themes other than Balanced in our wiki? The resulting problem is that while I can show a logo if I call the logo headerlogo.png, the logo currently isn't clickable as a link to the front page of the wiki. thanks, George From georgeolivergo at yahoo.com Thu Sep 4 03:42:22 2008 From: georgeolivergo at yahoo.com (George Oliver) Date: Thu, 4 Sep 2008 00:42:22 -0700 (PDT) Subject: [Moin-user] logo_string not working with balanced theme? Message-ID: <837655.93419.qm@web52005.mail.re2.yahoo.com> I found my own answer, sorry ;). The culprit was in balanced's screen-standard.css, where it was overriding the logo. I should have realized this when I saw that the html source was indeed displaying the correct html, the page just wasn't displaying it. From tw-public at gmx.de Thu Sep 4 05:28:54 2008 From: tw-public at gmx.de (Thomas Waldmann) Date: Thu, 04 Sep 2008 11:28:54 +0200 Subject: [Moin-user] Small problem with mail-import In-Reply-To: <20080903173759.GA1742@darkover.inka.de> References: <20080903173759.GA1742@darkover.inka.de> Message-ID: <1220520534.9092.4.camel@black.firma.waldmann-edv.de> Hi Mela, > 2008-09-03 16:26:26,316 WARNING MoinMoin.log:120 using logging > configuration read from > built-in fallback in MoinMoin.log module! Hmm, I have to look into that. Maybe it is due to the moin cli command not configuring logging. What you can do until a better solution is known, is to edit MoinMoin/log.py and remove that warning (or shift its level to DEBUG). > Logging itself is configured also. I guess it is only configured for moin.cgi (or whatever adapter script you use). Cheers, Thomas From szybalski at gmail.com Thu Sep 4 13:53:15 2008 From: szybalski at gmail.com (Lukasz Szybalski) Date: Thu, 4 Sep 2008 12:53:15 -0500 Subject: [Moin-user] prevent write access only on one page if user not logged in Message-ID: <804e5c70809041053p4927b1e9wc62fd536715a0635@mail.gmail.com> Hello, How can I prevent anonymous user from writing to only one page? I have a page that I need all users modifying it to log in, but I don't want to force login on the rest of the pages? How can this be done with acl? Thanks, Lucas From fpiat at klabs.be Thu Sep 4 16:14:27 2008 From: fpiat at klabs.be (Franklin PIAT) Date: Thu, 04 Sep 2008 22:14:27 +0200 Subject: [Moin-user] Secure login to moinmoin (http and https). Message-ID: <1220559267.20973.291.camel@solid.paris.klabs.be> Hello, I have enabled https on a moinmoin wiki, so password aren't transferred in clear text over the Internet. My problem was to make sure that editors actually use https to login. On the other way around, we need genuine visitor to use plain http (even if someone published and https URL on the Internet). I have made a wiki page with the solution I'm currently beta-testing : http://moinmo.in/FranklinPiat/UsingHttps Do you have comments ? How do you address this problem ? Thanks for you feed back. Franklin -- P.S. Clease CC me, since I'm not subscribed to this list. From szybalski at gmail.com Thu Sep 4 16:15:20 2008 From: szybalski at gmail.com (Lukasz Szybalski) Date: Thu, 4 Sep 2008 15:15:20 -0500 Subject: [Moin-user] proxy internal moin wiki to external site Message-ID: <804e5c70809041315n22c67867pd1667639de96f003@mail.gmail.com> Hello, I am trying to proxy one internal wiki page to the outside world. I have setup proxy and reverse proxy but I run into one problem. I cannot map edit gui button. I am using ProxyHTMLURLMap /mywiki/myspecialpage /myspecialpage Above works for all other links but edit gui is some var filed that proxyhtmlurlmap doesn convert to proper link. Any ideas how to proxy java script links using apache2 mod proxy? from this page: example.com/company/myspecialpage edit text links to: example.com/company/myspecialpage?action=edit&editor=text but edit gui links to example.com/company/mywiki/myspecialpage?action=edit&editor=text Anybody knows how to fix this? Lucas -- OpenOffice and Python http://lucasmanual.com/mywiki/OpenOffice Commercial Grade Backup with Bacula http://lucasmanual.com/mywiki/Bacula From fpiat at klabs.be Thu Sep 4 17:25:58 2008 From: fpiat at klabs.be (Franklin PIAT) Date: Thu, 04 Sep 2008 23:25:58 +0200 Subject: [Moin-user] proxy internal moin wiki to external site In-Reply-To: <804e5c70809041315n22c67867pd1667639de96f003@mail.gmail.com> References: <804e5c70809041315n22c67867pd1667639de96f003@mail.gmail.com> Message-ID: <1220563558.5404.10.camel@solid.paris.klabs.be> Hello lucasz, On Thu, 2008-09-04 at 15:15 -0500, Lukasz Szybalski wrote: > I am trying to proxy one internal wiki page to the outside world. I > have setup proxy and reverse proxy but I run into one problem. > > I cannot map edit gui button. > I am using > ProxyHTMLURLMap /mywiki/myspecialpage /myspecialpage > > Above works for all other links but edit gui is some var filed that > proxyhtmlurlmap doesn convert to proper link. > > Any ideas how to proxy java script links using apache2 mod proxy? The problem is that, on your wiki server, you have two namespace : /mywiki/* -> for actual wiki page. /wiki (or /moin_static) -> for static contents. But your proxy configuration [seems] to only handle the first ones. You need something similar to "Configuring root wiki" in : http://moinmo.in/HelpOnInstalling/ApacheWithModPython > Anybody knows how to fix this? Hope this helps, Franklin From szybalski at gmail.com Thu Sep 4 18:02:11 2008 From: szybalski at gmail.com (Lukasz Szybalski) Date: Thu, 4 Sep 2008 17:02:11 -0500 Subject: [Moin-user] proxy internal moin wiki to external site In-Reply-To: <1220563558.5404.10.camel@solid.paris.klabs.be> References: <804e5c70809041315n22c67867pd1667639de96f003@mail.gmail.com> <1220563558.5404.10.camel@solid.paris.klabs.be> Message-ID: <804e5c70809041502p1ac65d5eu1c34233178164475@mail.gmail.com> On Thu, Sep 4, 2008 at 4:25 PM, Franklin PIAT wrote: > Hello lucasz, > > > On Thu, 2008-09-04 at 15:15 -0500, Lukasz Szybalski wrote: >> I am trying to proxy one internal wiki page to the outside world. I >> have setup proxy and reverse proxy but I run into one problem. >> >> I cannot map edit gui button. >> I am using >> ProxyHTMLURLMap /mywiki/myspecialpage /myspecialpage >> >> Above works for all other links but edit gui is some var filed that >> proxyhtmlurlmap doesn convert to proper link. >> >> Any ideas how to proxy java script links using apache2 mod proxy? > > The problem is that, on your wiki server, you have two namespace : > /mywiki/* -> for actual wiki page. > /wiki (or /moin_static) -> for static contents. > But your proxy configuration [seems] to only handle the first ones. I have proxied the the wiki static content as well. I think that edit text is an html url which gets proxied edit gui seem to be javascript variable which doesn't get proxied for some reason. Unless what you are telling me is that the link is somewhere in a /wiki/ part of it? Lucas From gunter.matella at catenic.com Fri Sep 5 12:26:31 2008 From: gunter.matella at catenic.com (Matella, Gunter) Date: Fri, 5 Sep 2008 18:26:31 +0200 Subject: [Moin-user] Playing shockwave flash animations (.swf) in MoinMoin 1.6 Wiki page Message-ID: Hallo, we are using MoinMoin 1.6.3 and wonder how to integrate swf files into a wikipage. For version 1.5 an Action 'FlashManager' is working, but not for 1.6 or later ?? Has anyone a solution for this? Maybe anyone has adapted the 'FlashManager' to version 1.6? Any help is welcome! Gunter -------------- next part -------------- An HTML attachment was scrubbed... URL: From gunter.matella at catenic.com Fri Sep 5 12:39:03 2008 From: gunter.matella at catenic.com (Matella, Gunter) Date: Fri, 5 Sep 2008 18:39:03 +0200 Subject: [Moin-user] PDF creation of whole subtree with RenderAsPDF action missing Message-ID: Hello, we are using MoinMoin 1.6.3 and are really missing the 1.5 Action ' RenderAsPDF'. Unfortunatly this Action was one of the key feature we expect from the MoinMoin Wiki. As we started with Version MoinMoin 1.5.3 all was fine. After the update to 1.6 we lost this very usefull PDF creator. The actual available Action 'PDFAction' is no substitution. This action only render the actual page not all pages of the whole subtree. Has anyone ported the 1.5.3 action ' RenderAsPDF' to Version 1.6.x? Any help is welcome! Gunter -------------- next part -------------- An HTML attachment was scrubbed... URL: From rick.vanderveer at gmail.com Fri Sep 5 13:31:01 2008 From: rick.vanderveer at gmail.com (Rick Vanderveer) Date: Fri, 5 Sep 2008 12:31:01 -0500 Subject: [Moin-user] Playing shockwave flash animations (.swf) in MoinMoin 1.6 Wiki page In-Reply-To: References: Message-ID: <5c39e1ca0809051031y222b64ddr9a5ca76adbf4de8e@mail.gmail.com> Hello Gunter, We were never successful in reliably getting .swf or other movies to work using any Moin-macro solution. Some things work, others don't, you never know what results you'll get. So, consequently, we're resorted to simply escaping to raw html and and pasting in the code that way, and it works every time. Please note, this is an internal wiki. If yours is externally facing, or not access-protected, you need to be very, very careful about allowing raw html (dangerous). {{{ #!raw

}}} -Rick On Fri, Sep 5, 2008 at 11:26 AM, Matella, Gunter wrote: > Hallo, > > > > we are using MoinMoin 1.6.3 and wonder how to integrate swf files into a > wikipage. > > For version 1.5 an Action 'FlashManager' is working, but not for 1.6 or > later ?? > > > > Has anyone a solution for this? Maybe anyone has adapted the 'FlashManager' > to version 1.6? > > > > Any help is welcome! > > > > Gunter > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Moin-user mailing list > Moin-user at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/moin-user > > From rjt-moin at thegrindstone.me.uk Sun Sep 7 13:50:01 2008 From: rjt-moin at thegrindstone.me.uk (Richard Taylor) Date: Sun, 07 Sep 2008 18:50:01 +0100 Subject: [Moin-user] TextCha failure message Message-ID: <48C41449.2060507@thegrindstone.me.uk> Hi We have a problem using the TextCha feature. We use moinmoin to run the PyConUK conference wiki and we ask attendees to edit pages as a means of registering for various parts of the conference programme . We also have a spam problem. So we turned on the TextCha feature to stop the spam. However, we have many people who are now confused that their edits do not work because they miss the error message that TextCha returns because the text is too small. Is there some way to make the failed TextCha error message more obvious? Regards Richard From mohacsi at niif.hu Mon Sep 8 07:21:21 2008 From: mohacsi at niif.hu (Mohacsi Janos) Date: Mon, 8 Sep 2008 13:21:21 +0200 (CEST) Subject: [Moin-user] http-auth problems Message-ID: <20080908130036.D30730@mignon.ki.iif.hu> Dear All, I have some issues deploying the http-auth under moinmoin 1.6.x (It will be upgraded to 1.7 after converting to http-auth). The HTTP Authentication is working in principle, but: 1. I set up in the config the user_autocreate, but it does not creates users: config snippet: " # autocreation user_autocreate = True " When moinmoin should create the user? After first editing? After editing I don't see any user under the user directory: root at mmachine# ls -la moin_instance/data/user total 6 drwxr-xr-x 2 www www 512 Sep 8 12:40 . drwxr-xr-x 7 www www 512 Sep 8 11:16 .. -rw-r--r-- 1 www www 239 Sep 8 11:16 README 2. I have some issues with the Trusted macro in ACL also. The ACL setup is the following: acl_enabled = 1 acl_rights_default = 'Trusted:read,write,delete,revert All:' acl_rights_before = u"mohacsi at niif.hu:read,write,delete,revert,admin" If I setup this way the acl I cannot access the pages. Does "Trusted" working according the help? " Trusted is a special group containing all authenticated users who used HTTP-Basic-authentication. " 3. With a workaround I have some problem with the "signature" on the pages. The workaround is basically use "All:" instead of "Trusted:" Earlier I had log: NIIFwiki: FrontPage (last edited 2008-05-30 11:20:12 by mohacsi) Now I have: NIIFTESZTWiki: FrontPage (last edited 2008-09-08 10:38:29 by 2001:738:0:401:21b:63ff:fe9c:3327) So currently I see IP addresses, which is not very helpful tracking the users.... Any way to go back to user tracking? Thanks in advance. Janos Mohacsi Network Engineer, Research Associate, Head of Network Planning and Projects NIIF/HUNGARNET, HUNGARY Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 From tw-public at gmx.de Mon Sep 8 18:48:56 2008 From: tw-public at gmx.de (Thomas Waldmann) Date: Tue, 09 Sep 2008 00:48:56 +0200 Subject: [Moin-user] moin 1.7.2 released! Message-ID: <1220914136.6090.24.camel@black.firma.waldmann-edv.de> See http://moinmo.in/MoinMoinDownload for the release archive and the change log. We only fixed bugs, most importantly a file handle leak (leaking 1 file handle per request) that affects all users of long running server processes (everything except cgi). We didn't notice that bug here, because mod_wsgi is configured to run our daemons just for 500 requests and then terminate them and start fresh ones (linux has about 1024 file handles per process). So, if you have a similar setup, you can use this as workaround until you update. Some system text translations and help pages still need improvement - if you know a non-english language, you can also help translating and/or fixing stuff. As we want to concentrate on moin 1.8 from now on, please translate on master18 wiki, see: http://moinmo.in/MoinDev/Translation - your work will get into 1.8.0 release then. From rb.proj at gmail.com Tue Sep 9 06:28:59 2008 From: rb.proj at gmail.com (R.Bauer) Date: Tue, 09 Sep 2008 12:28:59 +0200 Subject: [Moin-user] Playing shockwave flash animations (.swf) in MoinMoin 1.6 Wiki page In-Reply-To: References: Message-ID: Matella, Gunter schrieb: > Hallo, > > > > we are using MoinMoin 1.6.3 and wonder how to integrate swf files into a > wikipage. > > For version 1.5 an Action 'FlashManager' is working, but not for 1.6 or > later ?? > > > > Has anyone a solution for this? Maybe anyone has adapted the > 'FlashManager' to version 1.6? > > > > Any help is welcome! > > > > Gunter > Hi Gunter that should work by <> or {{attachment:file.swf}} Of course you need to enable the flash format because it is listed in mimetypes_xss_protect and not in mimetypes_embed. see http://master16.moinmo.in/HelpOnMacros/EmbedObject cheers Reimar > > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > > > ------------------------------------------------------------------------ > > _______________________________________________ > Moin-user mailing list > Moin-user at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/moin-user From rb.proj at gmail.com Tue Sep 9 06:41:47 2008 From: rb.proj at gmail.com (R.Bauer) Date: Tue, 09 Sep 2008 12:41:47 +0200 Subject: [Moin-user] problem with acl In-Reply-To: <48BC1956.3040304@dodin.org> References: <48BA4B14.9090203@dodin.org> <48BB84D3.7080508@dodin.org> <48BC1956.3040304@dodin.org> Message-ID: jdd schrieb: > james bardin a ?crit : >> >> On Mon, Sep 1, 2008 at 1:59 AM, jdd > > wrote: >> >> >> it's a bare install, standalone (no apache, only moin in the server). >> Is there some sort of "restart" needed to take account of the config >> midifs? I looks like no wikiconfig.py modif is seen! >> >> >> >> Yes, the service needs to be restarted to load the new wikiconfig (cgi >> is the only method that does not require a restart). > > any clue about the way it's done? I'm zero about python. The server > runs debian and I see no /etc/init.d/ script :-( > > thanks > jdd > many ways, decide on your own what's the best. restart the web server process /etc/init.d# ./apache2 restart or kill the wikiserver process or just reboot the server machine cheers Reimar From jdd at dodin.org Tue Sep 9 09:55:48 2008 From: jdd at dodin.org (jdd) Date: Tue, 09 Sep 2008 15:55:48 +0200 Subject: [Moin-user] problem with acl In-Reply-To: References: <48BA4B14.9090203@dodin.org> <48BB84D3.7080508@dodin.org> <48BC1956.3040304@dodin.org> Message-ID: <48C68064.1020705@dodin.org> R.Bauer a ?crit : > many ways, decide on your own what's the best. > > restart the web server process /etc/init.d# ./apache2 restart no apache :-( and I didn't understand how the admin setup the wiki exactly. I couldn't afford to let the server out of use too long :-) but now the admin is back and the acl's works thanks jdd -- http://www.dodin.net http://valerie.dodin.org http://www.youtube.com/watch?v=t-eic8MSSfM From KrisR at online.de Tue Sep 9 10:15:51 2008 From: KrisR at online.de (Kris(R)) Date: Tue, 09 Sep 2008 16:15:51 +0200 Subject: [Moin-user] bash parser - some help with python? Message-ID: <48C68517.9080309@online.de> dear all, I'm using moinmoin to documentate installation of our cluster and I wanted to contribute with bash parser. Unfortunately I'm absolute newbie to python (and actually I can't spend to much time learning python). I used as example some other parsers (mostly sci) and looked on web after string editing with python but I've still got some questions. I defined in my modern/common.css file div.codearea pre span.BuiltIns { color: #0000ff; } div.codearea pre span.LoopCond { color: #ff9c00; font-weight: bold; } div.codearea pre span.LinuxBin { color: #b040d0; } div.codearea pre span.LinuxSbin { color: #f02020; } div.codearea pre span.Services { color: #20b020; } div.codearea pre span.Varia { color: #6080ff; } div.codearea pre span.Variables { color: #ff8060; } This last one should "lighten" the variables defined in bash ( ie $var1) however the following pair-rule wasn't working self.addRulePair("Variables",'\$','[0-9a-zA-Z]*') even if theres is no problem with smth like this: builtins_cmd = [ 'alias', 'bg', 'bind', ......] self.addWords(builtins_cmd,'BuiltIns') When I looked into the html code generated by moinmoin, instead of I found . What is the reason? Did I make smth wrong? I used then "default" name Preprc self.addRulePair("Preprc",'\$','[0-9a-zA-Z]*') and everything went smooth. I know that it's better to use standardized names (ie one of: ID, Operator, Char, Comment, Number, String, SPChar, ResWord, ConsWord, Error, ResWord2, Special, Preprc) but then I'm restricted with number of different items(colors). Another question. I wanted to define (as you can see it css-definition) services as separate color. It should nicely show if one use command like services httpd start Now, I added services = [ 'acpid', .... 'httpd', .....] self.addWords(services,'Services') The problem is, that word httpd is also colored in egrep "^User|^Group" /etc/httpd/conf/httpd.conf Simple exchange of 'httpd' to 'httpd ' lead to no color at all. Any hint how to overcome this behavior would be welcomed. thanks in advance kris From mjmatthews1 at rcn.com Tue Sep 9 15:31:23 2008 From: mjmatthews1 at rcn.com (Michael Matthews) Date: Tue, 09 Sep 2008 15:31:23 -0400 Subject: [Moin-user] moin 1.7.2 released! setup.py ? In-Reply-To: <1220914136.6090.24.camel@black.firma.waldmann-edv.de> References: <1220914136.6090.24.camel@black.firma.waldmann-edv.de> Message-ID: <48C6CF0B.1020504@rcn.com> I just downloaded it and I don't see the setup.py script. How does it install? thanks Thomas Waldmann wrote: > See http://moinmo.in/MoinMoinDownload for the release archive and the > change log. > > We only fixed bugs, most importantly a file handle leak (leaking 1 file > handle per request) that affects all users of long running server > processes (everything except cgi). > > We didn't notice that bug here, because mod_wsgi is configured to run > our daemons just for 500 requests and then terminate them and start > fresh ones (linux has about 1024 file handles per process). So, if you > have a similar setup, you can use this as workaround until you update. > > Some system text translations and help pages still need improvement - if > you know a non-english language, you can also help translating and/or > fixing stuff. > > As we want to concentrate on moin 1.8 from now on, please translate on > master18 wiki, see: http://moinmo.in/MoinDev/Translation - > your work will get into 1.8.0 release then. > > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Moin-user mailing list > Moin-user at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/moin-user > > From mjmatthews1 at rcn.com Tue Sep 9 16:31:21 2008 From: mjmatthews1 at rcn.com (Michael Matthews) Date: Tue, 09 Sep 2008 16:31:21 -0400 Subject: [Moin-user] moin 1.7.2 released! setup.py ? In-Reply-To: <48C6CF0B.1020504@rcn.com> References: <1220914136.6090.24.camel@black.firma.waldmann-edv.de> <48C6CF0B.1020504@rcn.com> Message-ID: <48C6DD19.7050305@rcn.com> Used unix tar. Had to use gnu tar. sorry. Michael Matthews wrote: > I just downloaded it and I don't see the setup.py script. How does it > install? > > thanks > > Thomas Waldmann wrote: > >> See http://moinmo.in/MoinMoinDownload for the release archive and the >> change log. >> >> We only fixed bugs, most importantly a file handle leak (leaking 1 file >> handle per request) that affects all users of long running server >> processes (everything except cgi). >> >> We didn't notice that bug here, because mod_wsgi is configured to run >> our daemons just for 500 requests and then terminate them and start >> fresh ones (linux has about 1024 file handles per process). So, if you >> have a similar setup, you can use this as workaround until you update. >> >> Some system text translations and help pages still need improvement - if >> you know a non-english language, you can also help translating and/or >> fixing stuff. >> >> As we want to concentrate on moin 1.8 from now on, please translate on >> master18 wiki, see: http://moinmo.in/MoinDev/Translation - >> your work will get into 1.8.0 release then. >> >> >> >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge >> Build the coolest Linux based applications with Moblin SDK & win great prizes >> Grand prize is a trip for two to an Open Source event anywhere in the world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> _______________________________________________ >> Moin-user mailing list >> Moin-user at lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/moin-user >> >> >> > > > From rb.proj at gmail.com Tue Sep 9 17:04:10 2008 From: rb.proj at gmail.com (R.Bauer) Date: Tue, 09 Sep 2008 23:04:10 +0200 Subject: [Moin-user] prevent write access only on one page if user not logged in In-Reply-To: <804e5c70809041053p4927b1e9wc62fd536715a0635@mail.gmail.com> References: <804e5c70809041053p4927b1e9wc62fd536715a0635@mail.gmail.com> Message-ID: Lukasz Szybalski schrieb: > Hello, > How can I prevent anonymous user from writing to only one page? Hi you can add an acl line on that page #acl Known:read,write,delete,revert then anonymous user can't write on that page cheers Reimar > > I have a page that I need all users modifying it to log in, but I > don't want to force login on the rest of the pages? > > How can this be done with acl? > > Thanks, > Lucas > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ From zoom.quiet at gmail.com Tue Sep 9 19:59:58 2008 From: zoom.quiet at gmail.com (Zoom.Quiet) Date: Wed, 10 Sep 2008 07:59:58 +0800 Subject: [Moin-user] [error 28] No space left on device Message-ID: <9dad9f0a0809091659n7616c8abre94c248881406a96@mail.gmail.com> when i visit: http://moinmo.in/ReimarBauer error as atta. pls. cover it,,, ---------- Forwarded message ---------- From: Date: Wed, Sep 10, 2008 at 04:12 Subject: New attachment added to page ReimarBauer on MoinMoin To: wiki at moinmo.in Dear Wiki user, You have subscribed to a wiki page "ReimarBauer" for change notification. An attachment has been added to that page by ReimarBauer. Following detailed information is available: Attachment name: autos1.png Attachment size: 121089 Attachment link: http://moinmo.in/ReimarBauer?action=AttachFile&do=get&target=autos1.png Page link: http://moinmo.in/ReimarBauer -- http://zoomquiet.org''' ??????????????????! PE keeps evolving organizations which promoting people be good!''' -------------- next part -------------- A non-text attachment was scrubbed... Name: 2008-09-10-075735_535x312_scrot.png Type: image/png Size: 21491 bytes Desc: not available URL: From mjmatthews1 at rcn.com Tue Sep 9 22:36:18 2008 From: mjmatthews1 at rcn.com (Michael Matthews) Date: Tue, 09 Sep 2008 22:36:18 -0400 Subject: [Moin-user] update migration form 1.5.8 to 1.7.2 fails, please help Message-ID: <48C732A2.2070903@rcn.com> My wikiconfig.py uses a cookie function based on contrib/auth_externalcookie but I had to take out the auth part to get the migration script to run. However it still fails. Please help. webhsps> moin --config-dir=/home/www/wiki --wiki-url=www.nsf.att.com/ migration data 2008-09-09 21:45:05,521 WARNING MoinMoin.log:120 using logging configuration read from built-in fallback in MoinMoin.log module! 2008-09-09 21:45:06,573 INFO MoinMoin.config.multiconfig:124 using wiki config: /home/www/wiki/wikiconfig.py Traceback (most recent call last): File "/home/www/moin/bin/moin", line 6, in ? run() File "/home/www/moin/lib/python2.4/site-packages/MoinMoin/script/moin.py", line 15, in run MoinScript().run(showtime=0) File "/home/www/moin/lib/python2.4/site-packages/MoinMoin/script/__init__.py", line 138, in run self.mainloop() File "/home/www/moin/lib/python2.4/site-packages/MoinMoin/script/__init__.py", line 255, in mainloop plugin_class(args[2:], self.options).run() # all starts again there File "/home/www/moin/lib/python2.4/site-packages/MoinMoin/script/__init__.py", line 138, in run self.mainloop() File "/home/www/moin/lib/python2.4/site-packages/MoinMoin/script/migration/data.py", line 44, in mainloop curr_rev = meta['data_format_revision'] File "/home/www/moin/lib/python2.4/site-packages/MoinMoin/wikiutil.py", line 475, in __getitem__ return dict.__getitem__(self, key) KeyError: 'data_format_revision' From rb.proj at gmail.com Wed Sep 10 02:33:52 2008 From: rb.proj at gmail.com (R.Bauer) Date: Wed, 10 Sep 2008 08:33:52 +0200 Subject: [Moin-user] update migration form 1.5.8 to 1.7.2 fails, please help In-Reply-To: <48C732A2.2070903@rcn.com> References: <48C732A2.2070903@rcn.com> Message-ID: Michael Matthews schrieb: > My wikiconfig.py uses a cookie function based on > contrib/auth_externalcookie but I had to take out the auth part to get > the migration script to run. However it still fails. Please help. > > webhsps> moin --config-dir=/home/www/wiki --wiki-url=www.nsf.att.com/ > migration data > 2008-09-09 21:45:05,521 WARNING MoinMoin.log:120 using logging > configuration read from built-in fallback in MoinMoin.log module! > 2008-09-09 21:45:06,573 INFO MoinMoin.config.multiconfig:124 using wiki > config: /home/www/wiki/wikiconfig.py > Traceback (most recent call last): > File "/home/www/moin/bin/moin", line 6, in ? > run() > File > "/home/www/moin/lib/python2.4/site-packages/MoinMoin/script/moin.py", > line 15, in run > MoinScript().run(showtime=0) > File > "/home/www/moin/lib/python2.4/site-packages/MoinMoin/script/__init__.py", > line 138, in run > self.mainloop() > File > "/home/www/moin/lib/python2.4/site-packages/MoinMoin/script/__init__.py", > line 255, in mainloop > plugin_class(args[2:], self.options).run() # all starts again there > File > "/home/www/moin/lib/python2.4/site-packages/MoinMoin/script/__init__.py", > line 138, in run > self.mainloop() > File > "/home/www/moin/lib/python2.4/site-packages/MoinMoin/script/migration/data.py", > line 44, in mainloop > curr_rev = meta['data_format_revision'] > File > "/home/www/moin/lib/python2.4/site-packages/MoinMoin/wikiutil.py", line > 475, in __getitem__ > return dict.__getitem__(self, key) > KeyError: 'data_format_revision' Hi Michael. this sounds like a missing meta file in data the content of the meta file for the 1.5.8 version should be data_format_revision: 01050800 The reason can be that you missed to run an older migration scripts in the past. cheers Reimar From tw-public at gmx.de Wed Sep 10 03:20:41 2008 From: tw-public at gmx.de (Thomas Waldmann) Date: Wed, 10 Sep 2008 09:20:41 +0200 Subject: [Moin-user] [error 28] No space left on device In-Reply-To: <9dad9f0a0809091659n7616c8abre94c248881406a96@mail.gmail.com> References: <9dad9f0a0809091659n7616c8abre94c248881406a96@mail.gmail.com> Message-ID: <1221031241.11410.9.camel@black.firma.waldmann-edv.de> I fixed it already. You don't believe how fast those logs grow when in DEBUG mode. X) From rb.proj at gmail.com Wed Sep 10 10:39:04 2008 From: rb.proj at gmail.com (R.Bauer) Date: Wed, 10 Sep 2008 16:39:04 +0200 Subject: [Moin-user] update migration form 1.5.8 to 1.7.2 fails, please help In-Reply-To: References: <48C732A2.2070903@rcn.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 e.g. http://hg.moinmo.in/moin/1.5/file/87a083ceb1b7/wiki/data/ cheers Reimar -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFIx9wF5aOc3Q9hk/kRAhicAKCmuFJ9TRodgdFWgN8gVD8mRG7/YACfZ1lZ Y5/fvq/Op/2c/aA97udhonY= =+fzu -----END PGP SIGNATURE----- From mohacsi at niif.hu Wed Sep 10 10:45:27 2008 From: mohacsi at niif.hu (Mohacsi Janos) Date: Wed, 10 Sep 2008 16:45:27 +0200 (CEST) Subject: [Moin-user] http-auth problems In-Reply-To: <20080908130036.D30730@mignon.ki.iif.hu> References: <20080908130036.D30730@mignon.ki.iif.hu> Message-ID: Dear All, I did not get any help form the mailing list. Can you tell me what way I can get some helpful debugging or logging information to investigate problem. I tried writing to the stderr, but I did not see entries in the apache error_log.... Please help! Janos Mohacsi Network Engineer, Research Associate, Head of Network Planning and Projects NIIF/HUNGARNET, HUNGARY Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 On Mon, 8 Sep 2008, Mohacsi Janos wrote: > Dear All, > I have some issues deploying the http-auth under moinmoin 1.6.x > (It will be upgraded to 1.7 after converting to http-auth). The HTTP > Authentication is working in principle, but: > > 1. I set up in the config the user_autocreate, but it does not creates > users: > > config snippet: > " > # autocreation > user_autocreate = True > " > > > When moinmoin should create the user? After first editing? > > After editing I don't see any user under the user directory: > root at mmachine# ls -la moin_instance/data/user > total 6 > drwxr-xr-x 2 www www 512 Sep 8 12:40 . > drwxr-xr-x 7 www www 512 Sep 8 11:16 .. > -rw-r--r-- 1 www www 239 Sep 8 11:16 README > > > 2. I have some issues with the Trusted macro in ACL also. > The ACL setup is the following: > > acl_enabled = 1 > acl_rights_default = 'Trusted:read,write,delete,revert All:' > acl_rights_before = u"mohacsi at niif.hu:read,write,delete,revert,admin" > > > If I setup this way the acl I cannot access the pages. > > Does "Trusted" working according the help? > " Trusted is a special group containing all authenticated users who used > HTTP-Basic-authentication. > " > > > 3. With a workaround I have some problem with the "signature" on the > pages. The workaround is basically use "All:" instead of "Trusted:" > > Earlier I had log: > > NIIFwiki: FrontPage (last edited 2008-05-30 11:20:12 by mohacsi) > > Now I have: > > > NIIFTESZTWiki: FrontPage (last edited 2008-09-08 10:38:29 by > 2001:738:0:401:21b:63ff:fe9c:3327) > > So currently I see IP addresses, which is not very helpful tracking the > users.... > > Any way to go back to user tracking? > > Thanks in advance. > > Janos Mohacsi > Network Engineer, Research Associate, Head of Network Planning and Projects > NIIF/HUNGARNET, HUNGARY > Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Moin-user mailing list > Moin-user at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/moin-user > From mjmatthews1 at rcn.com Wed Sep 10 11:09:44 2008 From: mjmatthews1 at rcn.com (Michael Matthews) Date: Wed, 10 Sep 2008 11:09:44 -0400 Subject: [Moin-user] New attachment implementation 1.5 -> 1.7 Message-ID: <48C7E338.6070409@rcn.com> Understand there is a new attachment implementation. Attachments get 'rendered' instead of downloaded. Our wiki is a document repository of MS type documents. How are they rendered? Is there an example I see on the web? Not sure my users are going to want that aspect changed. thanks From rb.proj at gmail.com Sun Sep 14 17:57:31 2008 From: rb.proj at gmail.com (R.Bauer) Date: Sun, 14 Sep 2008 23:57:31 +0200 Subject: [Moin-user] http-auth problems In-Reply-To: <20080908130036.D30730@mignon.ki.iif.hu> References: <20080908130036.D30730@mignon.ki.iif.hu> Message-ID: Mohacsi Janos schrieb: > Dear All, > I have some issues deploying the http-auth under moinmoin 1.6.x > (It will be upgraded to 1.7 after converting to http-auth). The HTTP > Authentication is working in principle, but: Hi > > 1. I set up in the config the user_autocreate, but it does not creates > users: > > config snippet: > " > # autocreation > user_autocreate = True > " > > > When moinmoin should create the user? After first editing? After a user calls http_auth entering his credentials. The http_auth password dialogue is loaded when someone points his browser on the url of the wiki if the dir of that url was added to a http_auth realm. > > After editing I don't see any user under the user directory: > root at mmachine# ls -la moin_instance/data/user > total 6 > drwxr-xr-x 2 www www 512 Sep 8 12:40 . > drwxr-xr-x 7 www www 512 Sep 8 11:16 .. > -rw-r--r-- 1 www www 239 Sep 8 11:16 README > > > 2. I have some issues with the Trusted macro in ACL also. > The ACL setup is the following: > > acl_enabled = 1 > acl_rights_default = 'Trusted:read,write,delete,revert All:' > acl_rights_before = u"mohacsi at niif.hu:read,write,delete,revert,admin" Is this your username ohacsi at niif.hu or your email address? acl_enabled = 1 isn't a config var in 1.7 > > > If I setup this way the acl I cannot access the pages. > > Does "Trusted" working according the help? > " Trusted is a special group containing all authenticated users who used > HTTP-Basic-authentication. and others yes, but the users need to be created first. > " > > > 3. With a workaround I have some problem with the "signature" on the > pages. The workaround is basically use "All:" instead of "Trusted:" > > Earlier I had log: > > NIIFwiki: FrontPage (last edited 2008-05-30 11:20:12 by mohacsi) > > Now I have: > > > NIIFTESZTWiki: FrontPage (last edited 2008-09-08 10:38:29 by > 2001:738:0:401:21b:63ff:fe9c:3327) > > So currently I see IP addresses, which is not very helpful tracking the > users.... > Do you see your name on top of the page. If not you are likly not logged in. It is quite difficult to help you if you only show snippet of lines from wikiconfig.py. It can become easier if you discuss your problem on #moin at chat.freenode.net and have prepared a pastebin with wikiconfig.py (of course you can remove lines you won't like to show to us) Maybe it is only an indenting problem, do you have used evil tabs? cheers Reimar From mjmatthews1 at rcn.com Sun Sep 14 18:09:11 2008 From: mjmatthews1 at rcn.com (Michael Matthews) Date: Sun, 14 Sep 2008 18:09:11 -0400 Subject: [Moin-user] Upgrade 1.5.7 > 1.7.2 external cookie problem Message-ID: <48CD8B87.6040500@rcn.com> I was using my own authentication and external cookie routine for my wiki. It was working fine. However after upgrade it is working, but top of page heading doesn't look right and apache/logs/error_log is full of error messages. The problem is that I create my own cookie and add it to response. Now this causes a problem, see setHttpHeader below ... from Cookie import SimpleCookie c = SimpleCookie() c[cookiename] = urllib.quote('|'.join(cookievalue)) c[cookiename]['domain'] = request.cfg.cookie_domain c[cookiename]['path'] = request.cfg.cookie_path c[cookiename]['expires'] = request.httpDate(when=expires, rfc='850') # from setCookie request.setHttpHeader(c.output()) ################## line 107 of wikiconfig.py # Update the saved cookie, so other code works with new setup request.saved_cookie = c.output() error_log: 2008-09-14 15:32:28,658 WARNING MoinMoin.log:120 using logging configuration read from built-in fallback in MoinMoin.log module! 2008-09-14 15:32:30,683 INFO MoinMoin.config.multiconfig:124 using wiki config: /home/www/wiki/config/wikiconfig.pyc 2008-09-14 15:32:31,075 WARNING MoinMoin.request:1383 Duplicate http header: 'Set-Cookie: MOIN_SESSION=y7ym4j6kmckngraloomzj0wvceh5n1sz; Domain=.nsf.att.com; expires= Wednesday, 12-Sep-18 19:32:30 GMT; Max-Age=315359999; Path=/tdev;' (ignored) 2008-09-14 15:32:31,076 WARNING MoinMoin.request:1384 Header added first at: File "/home/www/wiki/cgi-bin/moin.cgi", line 52, in ? run(Config) File "/home/www/moin2/lib/python2.4/site-packages/MoinMoin/server/server_cgi.py", line 57, in run File "/home/www/moin2/lib/python2.4/site-packages/MoinMoin/request/request_cgi.py ", line 29, in __init__ File "/home/www/moin2/lib/python2.4/site-packages/MoinMoin/request/__init__.py", line 218, in __init__ File "/home/www/moin2/lib/python2.4/site-packages/MoinMoin/request/__init__.py", line 632, in _handle_auth_form File "/home/www/moin2/lib/python2.4/site-packages/MoinMoin/request/__init__.py", line 686, in handle_auth File "/home/www/wiki/config/wikiconfig.py", line 107, in request request.setHttpHeader(c.output()) 2008-09-14 15:32:31,076 WARNING MoinMoin.request:1385 Header added again at: File "/home/www/wiki/cgi-bin/moin.cgi", line 52, in ? run(Config) File "/home/www/moin2/lib/python2.4/site-packages/MoinMoin/server/server_cgi.py", line 57, in run File "/home/www/moin2/lib/python2.4/site-packages/MoinMoin/request/request_cgi.py ", line 29, in __init__ File "/home/www/moin2/lib/python2.4/site-packages/MoinMoin/request/__init__.py", line 220, in __init__ File "/home/www/moin2/lib/python2.4/site-packages/MoinMoin/session.py", line 433, in after_auth File "/home/www/moin2/lib/python2.4/site-packages/MoinMoin/session.py", line 335, in set File "/home/www/moin2/lib/python2.4/site-packages/MoinMoin/session.py", line 329, in _set_cookie Any help would be appreciated. How do I get MoinMoin to use my cookie. From tw-public at gmx.de Mon Sep 15 07:06:07 2008 From: tw-public at gmx.de (Thomas Waldmann) Date: Mon, 15 Sep 2008 13:06:07 +0200 Subject: [Moin-user] Upgrade 1.5.7 > 1.7.2 external cookie problem In-Reply-To: <48CD8B87.6040500@rcn.com> References: <48CD8B87.6040500@rcn.com> Message-ID: <1221476767.31692.24.camel@black.firma.waldmann-edv.de> Hi Michael, when going from 1.5 to 1.7, you'll have to upgrade your auth stuff, see the code in MoinMoin.auth package (we use auth objects now, not functions any more). > 2008-09-14 15:32:31,075 WARNING MoinMoin.request:1383 Duplicate http > header: 'Set-Cookie: MOIN_SESSION=y7ym4j6kmckngraloomzj0wvceh5n1sz; > Domain=.nsf.att.com; expires= > Wednesday, 12-Sep-18 19:32:30 GMT; Max-Age=315359999; Path=/tdev;' (ignored) Seems like the duplicate header check is either not appropriate or incorrect for this case. I introduced that code quite some time ago to help with cleaning up the http headers mess that moin had back then (many http headers that shoud be there only once like status, content-type, cache control were duplicate in some cases, sometimes it emitted all the headers twice, ...). But I guess for setting multiple cookies, we need to either merge the set-cookie header values into one or introduce some special treatment in case this is not allowed. Please have a look at MoinMoin/request/__init__.py:emit_http_headers. if lkey in ['vary', 'cache-control', 'content-language', ]: These are the headers we allow multiple times and just merge their values into a single header. Please add 'set-cookie' to that list and try if that works (it won't give exceptions any more, but you have to check if BOTH cookies work correctly). If that doesn't work, we need to add some special treatment (non-trivial as the current code uses a dict headername -> headervalue). Cheers, Thomas From tw-public at gmx.de Mon Sep 15 07:18:02 2008 From: tw-public at gmx.de (Thomas Waldmann) Date: Mon, 15 Sep 2008 13:18:02 +0200 Subject: [Moin-user] moin 1.8.0beta1 released Message-ID: <1221477482.31692.33.camel@black.firma.waldmann-edv.de> See http://moinmo.in/MoinMoinDownload for the release archive and the change log. The most visible changes are: An upgraded GUI editor (and many bug fixes in related code) - this was the Summer of Code 2008 project of Moon Byeongweon, mentored by Alexander Schremmer. There is also a new theme called "modernized" done by Radomir Dopieralski (aka TheSheep) with improved CSS, icons and header rendering. Aside from these, there are also some smaller / more internal changes, see docs/CHANGES. Some system text translations and help pages still need improvement - if you know a non-english language, you can also help translating and/or fixing stuff. Please translate on master18 wiki, see: http://moinmo.in/MoinDev/Translation - your work will get into 1.8.0 release then. From tw-public at gmx.de Mon Sep 15 07:48:36 2008 From: tw-public at gmx.de (Thomas Waldmann) Date: Mon, 15 Sep 2008 13:48:36 +0200 Subject: [Moin-user] New attachment implementation 1.5 -> 1.7 In-Reply-To: <48C7E338.6070409@rcn.com> References: <48C7E338.6070409@rcn.com> Message-ID: <1221479316.31692.49.camel@black.firma.waldmann-edv.de> > Understand there is a new attachment implementation. Not yet, just some minor changes. The big change will be done after the new storage code gets merged (likely next year). A while ago I wrote some more detailed mail here with some of the reasonings, maybe you can find it in the archives. I know that the recent change looks strange from a user perspective, but there were good reasons (maybe not obvious now, but after we do the big change). > Attachments get > 'rendered' instead of downloaded. Our wiki is a document repository of > MS type documents. How are they rendered? They can't be rendered as there is no code in moin or in the browser to render them (and AFAIK there is no code freely available for this anyway). What moin does in such cases is just show the attachment page and a big download button at the top. In some future version, this will be enhanced by showing some metadata for the file and also a bit more pretty than now. > Is there an example I see on the web? You can try on http://moinmo.in/WikiSandBox > Not sure my users are going to want that aspect changed. For direct downloads, you can use [[attachment:foo.doc|Foo Bar| &do=get]]. From mjmatthews1 at rcn.com Tue Sep 16 08:26:33 2008 From: mjmatthews1 at rcn.com (Michael Matthews) Date: Tue, 16 Sep 2008 08:26:33 -0400 Subject: [Moin-user] Upgrade 1.5.7 > 1.7.2 external cookie problem Message-ID: <48CFA5F9.30908@rcn.com> Thomas Waldmann wrote: >>> >>> when going from 1.5 to 1.7, you'll have to upgrade your auth stuff, see >>> >>> the code in MoinMoin.auth package (we use auth objects now, not >>> >>> functions any more). >>> >>> >>> > > > > Did you do that? > > > I used the contrib/authexternalcookie as template > > > >>> >>> Please have a look at MoinMoin/request/__init__.py:emit_http_headers. >>> >>> >>> >>> if lkey in ['vary', 'cache-control', 'content-language', ]: >>> >>> >>> >>> These are the headers we allow multiple times and just merge their >>> >>> values into a single header. Please add 'set-cookie' to that list and >>> >>> try if that works (it won't give exceptions any more, but you have to >>> >>> check if BOTH cookies work correctly). >>> >>> >>> > > > > Did you do that? > > > > > yes >> >> Thanks for the response. I believe set-cookie can be used multi times >> >> but not sure. >> >> >> > > > > Yes, I also guess it can. But the main question is if it can be merged > > into a single set-cookie line (see above). > > > > > >> >> I will look into code change. Actually the cookie >> >> mechanism is working other than the error messages. I made the change >> >> and most of the error messages are gone. >> >> >> > > > > You mean you added that to the list of keys for which headers get > > merged, like I proposed above? > > > yes > > > >> >> However still get this in error_log: >> >> >> >> 2008-09-15 09:05:04,221 ERROR MoinMoin.failure:159 An exception occured. >> >> Traceback (most recent call last): >> >> File >> >> "/home/www/moin2/lib/python2.4/site-packages/MoinMoin/request/request_cgi.py", >> >> line 29, in __init__ >> >> File >> >> "/home/www/moin/lib/python2.4/site-packages/MoinMoin/request/__init__.py", >> >> line 218, in __init__ >> >> self.user = self._handle_auth_form(user_obj) >> >> File >> >> "/home/www/moin/lib/python2.4/site-packages/MoinMoin/request/__init__.py", >> >> line 632, in _handle_auth_form >> >> stage=stage, openid_identifier=oid) >> >> File >> >> "/home/www/moin/lib/python2.4/site-packages/MoinMoin/request/__init__.py", >> >> line 686, in handle_auth >> >> user_obj, cont = authmethod.request(self, user_obj, **extra) >> >> TypeError: unpack non-sequence >> >> >> > > > > This is a bug in some auth class implementation. How does your auth > > configuration look like? If that happens in the auth class you > > implemented for external cookies, you have to check your request > > method's return value whether it returns user_obj, continue_flag tuple. > > > My auth method returns user_obj and flag not extra. I have attached wikiconfig.py. Any help would be appreciated. > > > >> >> Also The pagetrail section is not being built. It only has the current >> >> page in it. >> >> >> > > > > That just means sessions don't work. > > > > > > > > > ------------------------------------------------------------------------ # -*- coding: iso-8859-1 -*- # IMPORTANT! This encoding (charset) setting MUST be correct! If you live in a # western country and you don't know that you use utf-8, you probably want to # use iso-8859-1 (or some other iso charset). If you use utf-8 (a Unicode # encoding) you MUST use: coding: utf-8 # That setting must match the encoding your editor uses when you modify the # settings below. If it does not, special non-ASCII chars will be wrong. """ MoinMoin - Configuration for a single wiki If you run a single wiki only, you can omit the farmconfig.py config file and just use wikiconfig.py - it will be used for every request we get in that case. Note that there are more config options than you'll find in the version of this file that is installed by default; see the module MoinMoin.multiconfig for a full list of names and their default values. Also, the URL http://moinmoin.wikiwikiweb.de/HelpOnConfiguration has a list of config options. @copyright: 2000-2005 by Juergen Hermann @license: GNU GPL, see COPYING for details. """ import time, os from MoinMoin.config.multiconfig import DefaultConfig from MoinMoin.auth import BaseAuth # -*- coding: iso-8859-1 -*- # This is some sample code you might find useful when you want to use some # external cookie (made by some other program, not moin) with moin. # See the XXX places for customizing it to your needs. You need to put this # code into your farmconfig.py or wikiconfig.py. # ... decode ='/usr/bin/java -classpath /home/www/java/classes/gateKeeper.jar:/home/www/java/classes/PSE_Lite.jar esGateKeeper.CmdGateKeeper %s QLAN PROD >%s' hrloginurl = 'https://www.e-access.att.com/empsvcs/hrpinmgt/pagLogin/?retURL=' hrlogouturl = 'https://www.e-access.att.com/empsvcs/hrpinmgt/pagLogout/' #class FarmConfig(DefaultConfig): class ExternalCookie(BaseAuth): name = 'external_cookie' def request(self,request,user_obj, **kw): """ authenticate via external cookie """ import Cookie cookiename = "NSFLAB" # XXX external cookie name you want to use try: cookie = Cookie.SimpleCookie(request.saved_cookie) except Cookie.CookieError: # ignore invalid cookies cookie = None import urllib if cookie and cookie.has_key(cookiename): cookievalue = cookie[cookiename].value cookievalue = urllib.unquote(cookievalue) cookievalue = cookievalue.decode('iso-8859-1') cookievalue = cookievalue.split('|') elif cookie and cookie.has_key('attESHr'): cookievalue = cookie['attESHr'].value cookievalue = urllib.unquote(cookievalue) cookievalue = cookievalue.decode('iso-8859-1') cookievalue = cookievalue.split('|') userid = cookievalue[2] cookievalue.append(userid.split('@')[0]) # f = open("cookie.log", "a") # f.write("\n") # f.write(repr(cookie)) # f.write(repr(cookievalue)) # f.write("\n") # f.close() else : #------ no cookies url = hrloginurl + 'http://' + request.http_host + request.request_uri request.http_redirect(url) return request.finish() # XXX now we decode and parse the cookie value - edit this to fit your needs. # the minimum we need to get is auth_username. aliasname and email is optional. auth_username = aliasname = email = '' try: auth_username = cookievalue[12] # having this cookie means user auth has already been done! aliasname = "%s %s" % (cookievalue[0], cookievalue[1]) # aliasname is for cosmetical stuff only email = cookievalue[2] except IndexError: # XXX this is for debugging it, in case it does not work if 0: f = open("cookie.log", "a") f.write("\nIndexError\n") f.write(repr(cookie)) f.write(repr(cookievalue)) f.write("\n") f.close() pass lifetime = int(request.cfg.cookie_lifetime) * 3600 now = time.time() expires = now + lifetime from Cookie import SimpleCookie c = SimpleCookie() c[cookiename] = urllib.quote('|'.join(cookievalue)) c[cookiename]['domain'] = request.cfg.cookie_domain c[cookiename]['path'] = request.cfg.cookie_path c[cookiename]['expires'] = request.httpDate(when=expires, rfc='850') # from setCookie request.setHttpHeader(c.output()) # Update the saved cookie, so other code works with new setup request.saved_cookie = c.output() from MoinMoin.user import User # giving auth_username to User constructor means that authentication has already been done. user = User(request, name=auth_username, auth_username=auth_username) try_next = False # never try again changed = False if aliasname != user.aliasname: # was the aliasname externally updated? user.aliasname = aliasname ; changed = True # yes -> update user profile if email != user.email: # was the email addr externally updated? user.email = email ; changed = True # yes -> update user profile if user: user.create_or_update(changed) if user and user.valid: # did we succeed making up a valid user? try_next = False # stop processing auth method list return user, try_next class Config(DefaultConfig): from MoinMoin.auth import MoinAuth # first try the external_cookie, then http basic auth, then the usual moin_cookie #auth = [MoinAuth()] auth = [ExternalCookie(),MoinAuth()] cookie_domain = '.nsf.att.com' cookie_lifetime = 24 # ... (rest of your config follows here) ... # Wiki identity ---------------------------------------------------- # Site name, used by default for wiki name-logo [Unicode] sitename = u'HSPS Wiki' # Wiki logo. You can use an image, text or both. [Unicode] # For no logo or text, use '' - the default is to show the sitename. # See also url_prefix setting below! logo_string = u' ATT Logo

' # name of entry page / front page [Unicode], choose one of those: # a) if most wiki content is in a single language page_front_page = u"TechnologyDevelopmentDelivery" # b) if wiki content is maintained in many languages #page_front_page = u"FrontPage" # The interwiki name used in interwiki links #interwikiname = 'UntitledWiki' # Show the interwiki name (and link it to page_front_page) in the Theme, # nice for farm setups or when your logo does not show the wiki's name. #show_interwiki = 1 page_footer1 = '

AT&T - RESTRICTED
Use pursuant to Company instructions

' # Critical setup --------------------------------------------------- # Misconfiguration here will render your wiki unusable. Check that # all directories are accessible by the web server or moin server. # If you encounter problems, try to set data_dir and data_underlay_dir # to absolute paths. # Where your mutable wiki pages are. You want to make regular # backups of this directory. data_dir = '/home/www/wiki/data/' # Where read-only system and help page are. You might want to share # this directory between several wikis. When you update MoinMoin, # you can safely replace the underlay directory with a new one. This # directory is part of MoinMoin distribution, you don't have to # backup it. data_underlay_dir = '/home/www/wiki/underlay/' # This must be '/wiki' for twisted and standalone. For CGI, it should # match your Apache Alias setting. #url_prefix = '/wiki' # The URL prefix we use to access the static stuff (img, css, js). url_prefix_static = '/wiki' # Security ---------------------------------------------------------- # This is checked by some rather critical and potentially harmful actions, # like despam or PackageInstaller action: superuser = [u"mjmatthews", ] # IMPORTANT: grant yourself admin rights! replace YourName with # your user name. See HelpOnAccessControlLists for more help. # All acl_rights_xxx options must use unicode [Unicode] acl_rights_before = u"mjmatthews:read,write,delete,revert,admin" acl_rights_default = u"All:read,write,delete,revert" # Link spam protection for public wikis (Uncomment to enable) # Needs a reliable internet connection. #from MoinMoin.util.antispam import SecurityPolicy # Mail -------------------------------------------------------------- # Configure to enable subscribing to pages (disabled by default) # or sending forgotten passwords. # SMTP server, e.g. "mail.provider.com" (None to disable mail) mail_smarthost = "mailhost.att.com" # The return address, e.g u"J?rgen Wiki " [Unicode] mail_from = u"%(DEVTEST WIKI) " # "user pwd" if you need to use SMTP AUTH mail_login = "" # User interface ---------------------------------------------------- # Add your wikis important pages at the end. It is not recommended to # remove the default links. Leave room for user links - don't use # more than 6 short items. # You MUST use Unicode strings here, but you need not use localized # page names for system and help pages, those will be used automatically # according to the user selected language. [Unicode] navi_bar = [ # If you want to show your page_front_page here: u'%(page_front_page)s', u'RecentChanges', u'FindPage', u'HelpContents', ] # The default theme anonymous or new users get theme_default = 'AttBlue' # Language options -------------------------------------------------- # See http://moinmoin.wikiwikiweb.de/ConfigMarket for configuration in # YOUR language that other people contributed. # The main wiki language, set the direction of the wiki pages language_default = 'en' # You must use Unicode strings here [Unicode] #page_category_regex = u'^Category[A-Z]' #page_dict_regex = u'[a-z]Dict$' #page_form_regex = u'[a-z]Form$' #page_group_regex = u'[a-z]Group$' #page_template_regex = u'[a-z]Template$' page_category_regex = ur'(?PCategory(?P(?!Template)\S+))' page_dict_regex = ur'(?P(?P\S+)Dict)' page_group_regex = ur'(?P(?P\S+)Group)' page_template_regex = ur'(?P(?P\S+)Template)' # Content options --------------------------------------------------- # Show users hostnames in RecentChanges show_hosts = 1 # Enable graphical charts, requires gdchart. #chart_options = {'width': 600, 'height': 300} #show_section_numbers = 1 From colm.connolly at tcd.ie Tue Sep 16 10:56:25 2008 From: colm.connolly at tcd.ie (Colm G. Connolly) Date: Tue, 16 Sep 2008 15:56:25 +0100 Subject: [Moin-user] moin 1.8.0beta1 released In-Reply-To: <1221477482.31692.33.camel@black.firma.waldmann-edv.de> References: <1221477482.31692.33.camel@black.firma.waldmann-edv.de> Message-ID: <4967AFD4-BA0D-47A4-AE62-E111AA7A7A70@tcd.ie> Hi all, On 15 Sep 2008, at 12:18, Thomas Waldmann wrote: > See http://moinmo.in/MoinMoinDownload for the release archive and the > change log. I've downloaded and installed this today and have hit one small problem. When trying to login to a newly created a/c I get the following error (cut'n'pasted from the end of the web page): /usr/local/lib/python2.3/site-packages/MoinMoin/user.py in _validatePassword (self=, data={u'aliasname': u'', u'bookmarks': {}, u'css_url': u'', u'date_fmt': u'', u'datetime_fmt': u'', u'disabled': u'0', u'edit_on_doubleclick': u'0', u'edit_rows': u'20', u'editor_default': u'text', u'editor_ui': u'freechoice', ...}, password='xxxxxxxx') 1. 522 2. 523 if epwd[:6] == '{SSHA}': 3. 524 data = base64.b64decode(epwd[6:]) 4. 525 salt = data[20:] 5. 526 hash = sha.new(password) * data = {u'aliasname': u'', u'bookmarks': {}, u'css_url': u'', u'date_fmt': u'', u'datetime_fmt': u'', u'disabled': u'0', u'edit_on_doubleclick': u'0', u'edit_rows': u'20', u'editor_default': u'text', u'editor_ui': u'freechoice', ...} * global base64 = * base64.b64decode undefined * epwd = u'xx' AttributeError 'module' object has no attribute 'b64decode' * args = ("'module' object has no attribute 'b64decode'",) System Details * Date: Tue, 16 Sep 2008 14:43:33 +0000 * Platform: Linux xxxxxxxxxxxxx 2.6.9-67.0.7.ELsmp #1 SMP Fri Mar 14 09:24:11 CDT 2008 x86_64 * Python: Python 2.3.4 (/usr/bin/python) * MoinMoin: Release 1.8.0beta1 (release) (Username, password, ssha encoded password and hostname are redacted.) I'm running this on Scientific Linux SL release 4.7 which is a recomplied RHEL 4 with mod_python 3.1.3-5.1. Is 1.8.0 not compatible with python 2.3? Upgrading the box is not an option. Thanks, -- Dr Colm G. Connolly School of Psychology and Institute of Neuroscience The Lloyd Building University of Dublin Trinity College, Dublin 2, ?ire Fax: +353-1-671-3183 Please note that electronic mail to, from or within the Trinity College Dublin, may be the subject of a request under the Freedom of Information Act. From tw-public at gmx.de Tue Sep 16 12:04:28 2008 From: tw-public at gmx.de (Thomas Waldmann) Date: Tue, 16 Sep 2008 18:04:28 +0200 Subject: [Moin-user] Upgrade 1.5.7 > 1.7.2 external cookie problem In-Reply-To: <48CFA5F9.30908@rcn.com> References: <48CFA5F9.30908@rcn.com> Message-ID: <1221581068.12118.22.camel@server.firma.waldmann-edv.de> Just some hints: > I used the contrib/authexternalcookie as template Take this stuff with a grain of salt. It is not in current use by any of the moin developers, so the code might need some work (and it would be nice to get improved code contributed back :). > >>> >>> Please have a look at MoinMoin/request/__init__.py:emit_http_headers. > >>> >>> > >>> >>> if lkey in ['vary', 'cache-control', 'content-language', ]: > >>> >>> > >>> >>> These are the headers we allow multiple times and just merge their > >>> >>> values into a single header. Please add 'set-cookie' to that list and > >>> >>> try if that works (it won't give exceptions any more, but you have to > >>> >>> check if BOTH cookies work correctly). > > > > > > Did you do that? > > > yes OK, if that worked (you got both cookies), I can commit that to the moin repo. > >> >> TypeError: unpack non-sequence I bet this comes from the "return request.finish()" you have in there. > class ExternalCookie(BaseAuth): > name = 'external_cookie' > def request(self,request,user_obj, **kw): > """ authenticate via external cookie """ > import Cookie > cookiename = "NSFLAB" # XXX external cookie name you want to use > try: > cookie = Cookie.SimpleCookie(request.saved_cookie) > except Cookie.CookieError: > # ignore invalid cookies > cookie = None > import urllib > if cookie and cookie.has_key(cookiename): > cookievalue = cookie[cookiename].value > cookievalue = urllib.unquote(cookievalue) > cookievalue = cookievalue.decode('iso-8859-1') > cookievalue = cookievalue.split('|') > elif cookie and cookie.has_key('attESHr'): > cookievalue = cookie['attESHr'].value > cookievalue = urllib.unquote(cookievalue) > cookievalue = cookievalue.decode('iso-8859-1') > cookievalue = cookievalue.split('|') > userid = cookievalue[2] > cookievalue.append(userid.split('@')[0]) > # f = open("cookie.log", "a") > # f.write("\n") > # f.write(repr(cookie)) > # f.write(repr(cookievalue)) > # f.write("\n") > # f.close() > else : #------ no cookies > url = hrloginurl + 'http://' + request.http_host + request.request_uri > request.http_redirect(url) > return request.finish() THIS! ^^^ BTW, you can use logging.debug("...") instead of writing your own files. With 1.7.x moin's logging configuration is very flexible and you can enable debug logging for specific modules. For temp. stuff, you can also use logging.warning("...") which likely comes through without changing the logging configuration. > auth = [ExternalCookie(),MoinAuth()] > cookie_domain = '.nsf.att.com' Is the . at the beginning correct? From tw-public at gmx.de Tue Sep 16 13:55:47 2008 From: tw-public at gmx.de (Thomas Waldmann) Date: Tue, 16 Sep 2008 19:55:47 +0200 Subject: [Moin-user] moin 1.8.0beta1 released In-Reply-To: <4967AFD4-BA0D-47A4-AE62-E111AA7A7A70@tcd.ie> References: <1221477482.31692.33.camel@black.firma.waldmann-edv.de> <4967AFD4-BA0D-47A4-AE62-E111AA7A7A70@tcd.ie> Message-ID: <1221587747.12118.48.camel@server.firma.waldmann-edv.de> > 3. 524 data = base64.b64decode(epwd[6:]) > * global base64 = python2.3/base64.pyc'> > * base64.b64decode undefined > * Python: Python 2.3.4 (/usr/bin/python) > * MoinMoin: Release 1.8.0beta1 (release) Oops. > Is 1.8.0 not compatible with python 2.3? Well, it SHOULD be. Problem is that no developer uses Py2.3 any more, so such problems creep into the code. >From the base64 module docs: """The modern interface, which was introduced in Python 2.4, provides:""" Gah. OK, I'll try to make something compatible that works with 2.3. Thanks for the bug report. BTW, as long term option, maybe think about a /usr/local/ or /opt python 2.5 install. If you use make altinstall that should be completely painless and no-risk and won't touch the system python stuff. "python" will still call the 2.3 stuff, but if code explicitely requests python2.5, it'll get that. From tw-public at gmx.de Tue Sep 16 14:50:51 2008 From: tw-public at gmx.de (Thomas Waldmann) Date: Tue, 16 Sep 2008 20:50:51 +0200 Subject: [Moin-user] moin 1.8.0beta1 released In-Reply-To: <4967AFD4-BA0D-47A4-AE62-E111AA7A7A70@tcd.ie> References: <1221477482.31692.33.camel@black.firma.waldmann-edv.de> <4967AFD4-BA0D-47A4-AE62-E111AA7A7A70@tcd.ie> Message-ID: <1221591051.6174.1.camel@black.firma.waldmann-edv.de> Please try this patch for the base64.b64decode python2.3 compatibility problem: http://hg.moinmo.in/moin/1.8/rev/a1858613ea4f From net.sourceforge.lists.moin-user at pooryorick.com Tue Sep 16 16:23:18 2008 From: net.sourceforge.lists.moin-user at pooryorick.com (Poor Yorick) Date: Tue, 16 Sep 2008 16:23:18 -0400 Subject: [Moin-user] rst and "what links here" functionality in moin-1.6.3 Message-ID: <48D015B6.9070609@pooryorick.com> I recently sent a concise email to this list describing how links in the rst format `this is a link <../SomePage>`_ don't get picked up by the "what links here" functionality. This is such a fundamental feature for Wiki's that I was expecting to be quickly corrected on how restructured text could be used while keeping "what links here" functionality intact. but didn't get any response. Is it true that restructured text breaks "what links here", or is it because the link is a relative sub-page? Could someone describe how they use restructured text links without breaking "what links here?" -- Yorick From mjmatthews1 at rcn.com Tue Sep 16 19:49:18 2008 From: mjmatthews1 at rcn.com (Michael Matthews) Date: Tue, 16 Sep 2008 19:49:18 -0400 Subject: [Moin-user] Upgrade 1.5.7 > 1.7.2 external cookie problem In-Reply-To: <1221581068.12118.22.camel@server.firma.waldmann-edv.de> References: <48CFA5F9.30908@rcn.com> <1221581068.12118.22.camel@server.firma.waldmann-edv.de> Message-ID: <48D045FE.4010105@rcn.com> Thomas Waldmann wrote: > I bet this comes from the "return request.finish()" you have in there. > So what should I do there? Basically I want to the request/process to end. The authenticator will redirect back with cookie and request is re-invoked. I guess I saw this method as an exit strategy or someone advised me. I wrote this awhile ago. All this used to work in 1.5.x > >> class ExternalCookie(BaseAuth): >> name = 'external_cookie' >> def request(self,request,user_obj, **kw): >> """ authenticate via external cookie """ >> import Cookie >> cookiename = "NSFLAB" # XXX external cookie name you want to use >> try: >> cookie = Cookie.SimpleCookie(request.saved_cookie) >> except Cookie.CookieError: >> # ignore invalid cookies >> cookie = None >> import urllib >> if cookie and cookie.has_key(cookiename): >> cookievalue = cookie[cookiename].value >> cookievalue = urllib.unquote(cookievalue) >> cookievalue = cookievalue.decode('iso-8859-1') >> cookievalue = cookievalue.split('|') >> elif cookie and cookie.has_key('attESHr'): >> cookievalue = cookie['attESHr'].value >> cookievalue = urllib.unquote(cookievalue) >> cookievalue = cookievalue.decode('iso-8859-1') >> cookievalue = cookievalue.split('|') >> userid = cookievalue[2] >> cookievalue.append(userid.split('@')[0]) >> # f = open("cookie.log", "a") >> # f.write("\n") >> # f.write(repr(cookie)) >> # f.write(repr(cookievalue)) >> # f.write("\n") >> # f.close() >> else : #------ no cookies >> url = hrloginurl + 'http://' + request.http_host + request.request_uri >> request.http_redirect(url) >> return request.finish() >> > > THIS! ^^^ > > BTW, you can use logging.debug("...") instead of writing your own > files. > > With 1.7.x moin's logging configuration is very flexible and you can > enable debug logging for specific modules. For temp. stuff, you can also > use logging.warning("...") which likely comes through without changing > the logging configuration. > > >> auth = [ExternalCookie(),MoinAuth()] >> cookie_domain = '.nsf.att.com' >> > > Is the . at the beginning correct? > > > Not sure. Cookie authentication IS working. That is not the problem. But something is wrong with MoinMoin after authentication cycle is completed and pagetrail is mangled for some reason. From tw-public at gmx.de Thu Sep 18 05:00:59 2008 From: tw-public at gmx.de (Thomas Waldmann) Date: Thu, 18 Sep 2008 11:00:59 +0200 Subject: [Moin-user] rst and docbook parsers In-Reply-To: <48D015B6.9070609@pooryorick.com> References: <48D015B6.9070609@pooryorick.com> Message-ID: <1221728459.24211.30.camel@server.firma.waldmann-edv.de> On Tue, 2008-09-16 at 16:23 -0400, Poor Yorick wrote: > I recently sent a concise email to this list describing how links in the rst format > > `this is a link <../SomePage>`_ > > don't get picked up by the "what links here" functionality. This is such a > fundamental feature for Wiki's that I was expecting to be quickly corrected on > how restructured text could be used while keeping "what links here" > functionality intact. but didn't get any response. Maybe this is due to no active moin developer is using the rst parser (or not even using rst anywhere else). So the RST parser could definitely get some more love by a maintainer using it and caring for it. [the same is true for docbook, btw] Nowadays, this is usually just checking and fixing bugs (as the one you mentioned above [BTW, please check if there is a bug report on the wiki for that, otherwise this bug does not exist formally]). In the future, there might be bigger work to be done relating to RST: we had a summer of code 2008 project that rewrote the moin wiki and creole wiki parser to work differently, using an internal DOM-tree-like representation. This will fix lots of problems we had with the old parser/formatter approach (e.g. we will be able to generate xhtml, have good working TOC and Include etc.). This work will likely get merged at some time next year (after the storage api/backend work) and it would be nice to have a rewritten RST parser then. From victorlei at gmail.com Thu Sep 18 10:12:23 2008 From: victorlei at gmail.com (Victor) Date: Thu, 18 Sep 2008 16:12:23 +0200 Subject: [Moin-user] Using IFRAME Message-ID: I tried using IFRAME with moin 1.7.1 as follows #format html But I get empty page. If instead I put the same directive in a macro, it works fine. Is that so by design, or I don't understand the right way to use it? Thanks, Victor -- Calligraphy of geese / Against the sky / The moon seals it / (Buson/Hass) From tw-public at gmx.de Thu Sep 18 10:36:23 2008 From: tw-public at gmx.de (Thomas Waldmann) Date: Thu, 18 Sep 2008 16:36:23 +0200 Subject: [Moin-user] Using IFRAME In-Reply-To: References: Message-ID: <1221748583.24211.34.camel@server.firma.waldmann-edv.de> > #format html > > > But I get empty page. Note that the html parser is a "safe" html parser (to avoid abuse of the wiki / security risks), so it does not allow all html tags. Maybe iframe is not in the allowed set of tags. From victorlei at gmail.com Thu Sep 18 11:58:14 2008 From: victorlei at gmail.com (victorlei at gmail.com) Date: Thu, 18 Sep 2008 18:58:14 +0300 Subject: [Moin-user] Using IFRAME In-Reply-To: <1221748583.24211.34.camel@server.firma.waldmann-edv.de> References: <1221748583.24211.34.camel@server.firma.waldmann-edv.de> Message-ID: A propos IFRAME in moin 1.7.1 Inside a macro, the following works: The following results in an empty page: The only difference is in the height value: "400" works, but "100%" doesn't. Is this a bug or a feature? Victor On 9/18/08, Thomas Waldmann wrote: >> #format html >> >> >> But I get empty page. > > Note that the html parser is a "safe" html parser (to avoid abuse of the > wiki / security risks), so it does not allow all html tags. > > Maybe iframe is not in the allowed set of tags. -- Calligraphy of geese / Against the sky / The moon seals it / (Buson/Hass) From rb.proj at gmail.com Thu Sep 18 12:10:31 2008 From: rb.proj at gmail.com (R.Bauer) Date: Thu, 18 Sep 2008 18:10:31 +0200 Subject: [Moin-user] Using IFRAME In-Reply-To: References: <1221748583.24211.34.camel@server.firma.waldmann-edv.de> Message-ID: victorlei at gmail.com schrieb: > A propos IFRAME in moin 1.7.1 > > Inside a macro, the following works: > > The following results in an empty page: > > The only difference is in the height value: "400" works, but "100%" doesn't. > > Is this a bug or a feature? > > Victor > a bug of which browser ? cheers Reimar From rick.vanderveer at gmail.com Thu Sep 18 12:15:36 2008 From: rick.vanderveer at gmail.com (Rick Vanderveer) Date: Thu, 18 Sep 2008 11:15:36 -0500 Subject: [Moin-user] Using IFRAME In-Reply-To: References: <1221748583.24211.34.camel@server.firma.waldmann-edv.de> Message-ID: <5c39e1ca0809180915tb959988j94cdac0d9b3186c1@mail.gmail.com> One workaround, instead of "#format html" install and use "#format raw". However, due to severe security concerns, use this only on internal wiki's. Look on the macro page for 'raw'. Also, height="100%" doesn't work for me either, you must specify a height in pixels. -Rick On Thu, Sep 18, 2008 at 10:58 AM, wrote: > A propos IFRAME in moin 1.7.1 > > Inside a macro, the following works: > > The following results in an empty page: > > The only difference is in the height value: "400" works, but "100%" doesn't. > > Is this a bug or a feature? > > Victor > > On 9/18/08, Thomas Waldmann wrote: >>> #format html >>> >>> >>> But I get empty page. >> >> Note that the html parser is a "safe" html parser (to avoid abuse of the >> wiki / security risks), so it does not allow all html tags. >> >> Maybe iframe is not in the allowed set of tags. > > > -- > Calligraphy of geese / Against the sky / The moon seals it / (Buson/Hass) > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Moin-user mailing list > Moin-user at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/moin-user > From daniel.d.mclaughlin at intel.com Thu Sep 18 19:07:02 2008 From: daniel.d.mclaughlin at intel.com (McLaughlin, Daniel D) Date: Thu, 18 Sep 2008 16:07:02 -0700 Subject: [Moin-user] Add single login account to standalone wiki Message-ID: <8B23168BCBB43B49A4C8EAB32D4B62F135B7EA72@orsmsx505.amr.corp.intel.com> Hello, I have a basic standalone wiki (moin-1.6.2) with default config and no authentication method. It is installed on a server for use inside a corporate firewall. The users want to password-protect the wiki by using single username and password that everyone on the team would use. The help file indicates the basic authentication method by moin via username/password would import MoinMoin/auth/MoinAuth. from MoinMoin.auth import MoinAuth auth = [MoinAuth()] This class does not exist in /usr/local/lib/python2.4/site-packages/MoinMoin. Do I need to download it? I find no reference to this class online. The wiki front page has the standard login form at the top, which allows profile creation. It is not clear if this is to be used in my case or if MoinAuth uses local accounts on the server. The login form is on the same page as the top level data page, so I am not sure how that protects the data. Can someone point me to or provide some instruction on adding username/password login authentication on an existing statndalone wiki? Mig -------------- next part -------------- An HTML attachment was scrubbed... URL: From tw-public at gmx.de Fri Sep 19 03:41:18 2008 From: tw-public at gmx.de (Thomas Waldmann) Date: Fri, 19 Sep 2008 09:41:18 +0200 Subject: [Moin-user] Add single login account to standalone wiki In-Reply-To: <8B23168BCBB43B49A4C8EAB32D4B62F135B7EA72@orsmsx505.amr.corp.intel.com> References: <8B23168BCBB43B49A4C8EAB32D4B62F135B7EA72@orsmsx505.amr.corp.intel.com> Message-ID: <1221810079.18869.25.camel@black.firma.waldmann-edv.de> > I have a basic standalone wiki (moin-1.6.2) Updating that to 1.7.2 should be relatively easy. > with default config and no authentication method. It is installed on a > server for use inside a corporate firewall. OK. > The users want to password-protect the wiki by using single username > and password that everyone on the team would use. Could be done, but IMHO that is a bad idea. If everybody uses the same username, you don't see who did what change. If someone leaves the team, he/she will still know the password - no easy way to revoke access. Also, the probability that such a "common user/password" leaks out and is soon known by everybody is rather high. So I suggest you have username/password for each user (as usual). Then have a page UserGroup and put all legitimate usernames into a 1st level list on that group definition page. Then use UserGroup:read,write,delete,revert in your default acl. If you do it that way, every UserGroup member can add new members to / remove other members from the group definition. If that is not wanted, just use a non-default acl on the UserGroup page. > The help file indicates the basic authentication method by moin via > username/password would import MoinMoin/auth/MoinAuth. > from MoinMoin.auth import MoinAuth > auth = [MoinAuth()] Looks like you are reading the 1.7 docs (and auth is slighlty different there). You have a full set of matching help pages in YOUR wiki. If you read on masterXX.moinmo.in, be careful you choose master16 for 1.6, master17 for 1.7, ... > The wiki front page has the standard login form at the top, Usually every page has that Login link that shows the form. > which allows profile creation. It is not clear if this is to be used > in my case or if MoinAuth uses local accounts on the server. Moin does not use UNIX or Windows user accounts by default. > The login form is on the same page as the top level data page, so I am > not sure how that protects the data. Well, you could have a restrictive acl_rights_default and just open the front page for everybody (the front page would not contain any sensitive information in that case). From jdd at dodin.org Sat Sep 20 03:50:18 2008 From: jdd at dodin.org (jdd) Date: Sat, 20 Sep 2008 09:50:18 +0200 Subject: [Moin-user] templates?? Message-ID: <48D4AB3A.2030809@dodin.org> Is it possible to have in Moin the same system than mediawiki: http://fr.opensuse.org/Mod?les this allows to "tag" a page with annouces or warnings thanks jdd -- http://www.dodin.net http://valerie.dodin.org http://www.youtube.com/watch?v=t-eic8MSSfM From rupert.thurner at gmail.com Sat Sep 20 05:02:41 2008 From: rupert.thurner at gmail.com (rupert THURNER) Date: Sat, 20 Sep 2008 11:02:41 +0200 Subject: [Moin-user] templates?? In-Reply-To: <48D4AB3A.2030809@dodin.org> References: <48D4AB3A.2030809@dodin.org> Message-ID: <6af4270809200202w19847397k2e40cda1d13c8c36@mail.gmail.com> http://moinmo.in/MacroMarket/IncludePage-1.7 maybe? On Sat, Sep 20, 2008 at 9:50 AM, jdd wrote: > Is it possible to have in Moin the same system than mediawiki: > > http://fr.opensuse.org/Mod?les > > this allows to "tag" a page with annouces or warnings > > thanks > jdd > > -- > http://www.dodin.net > http://valerie.dodin.org > http://www.youtube.com/watch?v=t-eic8MSSfM > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Moin-user mailing list > Moin-user at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/moin-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdd at dodin.org Sat Sep 20 05:03:36 2008 From: jdd at dodin.org (jdd) Date: Sat, 20 Sep 2008 11:03:36 +0200 Subject: [Moin-user] templates?? In-Reply-To: <6af4270809200202w19847397k2e40cda1d13c8c36@mail.gmail.com> References: <48D4AB3A.2030809@dodin.org> <6af4270809200202w19847397k2e40cda1d13c8c36@mail.gmail.com> Message-ID: <48D4BC68.9050609@dodin.org> rupert THURNER a ?crit : > http://moinmo.in/MacroMarket/IncludePage-1.7 maybe? may be :-) thanks jdd -- http://www.dodin.net http://valerie.dodin.org http://www.youtube.com/watch?v=t-eic8MSSfM From jarod.beekman at gmail.com Sat Sep 20 13:43:53 2008 From: jarod.beekman at gmail.com (Jarod Beekman) Date: Sat, 20 Sep 2008 10:43:53 -0700 Subject: [Moin-user] Docutils non-root installation Message-ID: <4bafe4040809201043y2a49b3b5jc020b13bcc9f0142@mail.gmail.com> I'm trying to get docutils 0.5 (2008-06-25) working with moinmoin 1.7.2. I am on a hosted server and I had to install docutils as a non-root user. MoinMoin returns the message: "Rendering of reStructured text is not possible, please install Docutils." This wasn't surprising and I figured that it was the result of not having either the modules or the binaries in the correct path so I added the following to moin.cgi: sys.path.insert(0, '/home/mydir/local/lib/python') # Path to the docutils directory with modules. os.environ['PATH'] = '$PATH:/home/mydir/local/bin' # Path to docutils binaries os.environ['PYTHONPATH'] = '/home/mydir/local/lib/python' # Same as above and I added to .bashrc export PATH=$PATH:/home/mydir/local/bin # Path to docutils binaries export PYTHONPATH=/home/mydir/local/lib/python # Path to docutils modules I am still getting the same error. I've tried to enable better logging but I don't completely understand the logging mechanism so I'm not getting any messages about docutils or the rest parser. I apologize if I missed something in the docs, but I've spent quite a bit of time looking. Any help is appreciated. Thank you. -- Jarod Beekman From rick.vanderveer at gmail.com Sat Sep 20 14:05:27 2008 From: rick.vanderveer at gmail.com (Rick Vanderveer) Date: Sat, 20 Sep 2008 13:05:27 -0500 Subject: [Moin-user] templates?? In-Reply-To: <48D4BC68.9050609@dodin.org> References: <48D4AB3A.2030809@dodin.org> <6af4270809200202w19847397k2e40cda1d13c8c36@mail.gmail.com> <48D4BC68.9050609@dodin.org> Message-ID: <5c39e1ca0809201105m5828ece1k2d35c0ac7b0f5074@mail.gmail.com> JDD, It sounds to me like you are looking for Admonitions, a new feature added in 1.7. See here: http://moinmo.in/HelpOnAdmonitions Hope this helps... :-) Wiki-maintainers, Just a comment-- it took me forever to actually find the above link because I couldn't for the life of me remember what they were called, AND it isn't listed anywhere in the 'features' pages or the HelpOnMacros (or similar pages), AND it isn't in the 'macros' or 'parsers' directory. I finally tracked it down by looking in the theme 'img' directory and found 'admon-caution.png'. My point is, this is actually probably a useful feature many people could make more use of, but probably suffers from lack of awareness. Maybe it should be added to the features page as well? I'll add it sometime this weekend, and if people don't like it, the page can be reverted. (Once I did finally find it, a linkto title search did turn up that it was linked from the HelpOnMoinWikiSyntax page, so my bad for not checking there. But,I still think more crosslinking might be nice. :-) -Rick On Sat, Sep 20, 2008 at 4:03 AM, jdd wrote: > rupert THURNER a ?crit : >> http://moinmo.in/MacroMarket/IncludePage-1.7 maybe? > > may be :-) > thanks > jdd > > -- > http://www.dodin.net > http://valerie.dodin.org > http://www.youtube.com/watch?v=t-eic8MSSfM > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Moin-user mailing list > Moin-user at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/moin-user > From rb.proj at gmail.com Sat Sep 20 16:02:30 2008 From: rb.proj at gmail.com (R.Bauer) Date: Sat, 20 Sep 2008 22:02:30 +0200 Subject: [Moin-user] templates?? In-Reply-To: <5c39e1ca0809201105m5828ece1k2d35c0ac7b0f5074@mail.gmail.com> References: <48D4AB3A.2030809@dodin.org> <6af4270809200202w19847397k2e40cda1d13c8c36@mail.gmail.com> <48D4BC68.9050609@dodin.org> <5c39e1ca0809201105m5828ece1k2d35c0ac7b0f5074@mail.gmail.com> Message-ID: Rick Vanderveer schrieb: > JDD, > It sounds to me like you are looking for Admonitions, a new feature > added in 1.7. See here: > http://moinmo.in/HelpOnAdmonitions > > Hope this helps... :-) > > > Wiki-maintainers, > Just a comment-- it took me forever to actually find the above link > because I couldn't for the life of me remember what they were called, > AND it isn't listed anywhere in the 'features' pages or the > HelpOnMacros (or similar pages), AND it isn't in the 'macros' or > 'parsers' directory. I finally tracked it down by looking in the > theme 'img' directory and found 'admon-caution.png'. My point is, > this is actually probably a useful feature many people could make more > use of, but probably suffers from lack of awareness. Maybe it should > be added to the features page as well? I'll add it sometime this > weekend, and if people don't like it, the page can be reverted. (Once > I did finally find it, a linkto title search did turn up that it was > linked from the HelpOnMoinWikiSyntax page, so my bad for not checking > there. But,I still think more crosslinking might be nice. :-) > > -Rick > > Hi Rick it is also listed on HelpOnMoinWikiSyntax. And everyone is welcome to help with documenting, (cross)linking and other help pages. cheers Reimar From net.sourceforge.lists.moin-user at pooryorick.com Sun Sep 21 16:59:50 2008 From: net.sourceforge.lists.moin-user at pooryorick.com (Poor Yorick) Date: Sun, 21 Sep 2008 16:59:50 -0400 Subject: [Moin-user] rst and "what links here" functionality in moin-1.6.3 Message-ID: <48D6B5C6.1040000@pooryorick.com> I recently sent a concise email to this list describing how links in the rst format `this is a link <../SomePage>`_ don't get picked up by the "what links here" functionality. This is such a fundamental feature for a wiki that I was expecting to be quickly corrected on how restructured text could be used while keeping "what links here" functionality intact. but didn't get any response. Is it true that restructured text breaks "what links here", or is it because the link is a relative sub-page? Could someone describe how they use restructured text links without breaking "what links here?" -- Yorick From mailinglist.honeypot at gmail.com Mon Sep 22 13:21:11 2008 From: mailinglist.honeypot at gmail.com (Steve Lianoglou) Date: Mon, 22 Sep 2008 17:21:11 +0000 (UTC) Subject: [Moin-user] Creating a dynamic header like http://moinmoin.wikiwikiweb.de/ Message-ID: Hi all, We're in the process of moving our MoinMoin between servers. When making the switch, I'm anticipating some time when the domain for our wiki will still point to the old server while the DNS propogates. I've setup a temporary domain that people can access the new moin right now. To ensure no data loss in the conversion and minimize confusion I will be changing the moin on the old server to be read only, and also added a `page_header1` in our wikiconfig.py to indicate that the user should be going to the tmp url while the DNS switches over completely. This is all fine so far, but I'm curious if/how I can make the URL that I report in my `page_header1` to be dynamic, like it is on the moinmoin.wikiweb.de site so that it can return the appropriate URL for the same page on the new server that the user is trying to access on the old server. So, in the header, when the user tries to access this page: http://example.com/cgi-bin/moin.cgi/SomePage I'd like to convert it to: http://new.example.com/SomePage (we moved from cgi to mod_wsgi, to boot) Thanks for any help, -steve From mailinglist.honeypot at gmail.com Mon Sep 22 19:09:27 2008 From: mailinglist.honeypot at gmail.com (Steve Lianoglou) Date: Mon, 22 Sep 2008 23:09:27 +0000 (UTC) Subject: [Moin-user] =?utf-8?q?Creating_a_dynamic_header_like=09http=3A//m?= =?utf-8?q?oinmoin=2Ewikiwikiweb=2Ede/?= References: Message-ID: Steve Lianoglou gmail.com> writes: > This is all fine so far, but I'm curious if/how I can make the URL that I > report > in my `page_header1` to be dynamic, like it is on the moinmoin.wikiweb.de > site > so that it can return the appropriate URL for the same page on the new > server > that the user is trying to access on the old server. > > So, in the header, when the user tries to access this page: > http://example.com/cgi-bin/moin.cgi/SomePage > > I'd like to convert it to: > http://new.example.com/SomePage > > (we moved from cgi to mod_wsgi, to boot) Replying to myself, and for posterity ... When run as a CGI, the os.environ['REQUEST_URI'] has the "/cgi-bin/moin.cgi/SomePage" part of the request. You can grab that string, mangle it however you like, and use it in the page_header/footer. So in the specific case I outlined above, I can do something like this: import os _new_url = 'http://new.example.com/%s' % os.environ['REQUEST_URI'][18:] page_header1 = '

The new URL for this page is: ' \ '%s

' % (_new_url, _new_url) And the new address will be listed at the top of every page ... style w/ custom message and css to taste. -steve From tw-public at gmx.de Tue Sep 23 09:19:47 2008 From: tw-public at gmx.de (Thomas Waldmann) Date: Tue, 23 Sep 2008 15:19:47 +0200 Subject: [Moin-user] rst and "what links here" functionality in moin-1.6.3 In-Reply-To: <48D6B5C6.1040000@pooryorick.com> References: <48D6B5C6.1040000@pooryorick.com> Message-ID: <1222175987.9801.19.camel@server.firma.waldmann-edv.de> On Sun, 2008-09-21 at 16:59 -0400, Poor Yorick wrote: > I recently sent a concise email to this list describing how links in the rst format > > `this is a link <../SomePage>`_ > > don't get picked up by the "what links here" functionality. This is such a > fundamental feature for a wiki that I was expecting to be quickly corrected on > how restructured text could be used while keeping "what links here" > functionality intact. but didn't get any response. I sent (a rather general) response to the list with subject "rst and docbook parsers" at Thu, 18 Sep 2008 11:00:59 +0200, didn't that get through to you? Maybe the moin wiki rst / docbook users should try to organize and participate a bit more in moin development - I am sure there are some python coders within the rst using moin wiki users (and maybe the same is true for docbook). I am sure an active developer / maintainer who uses this code himself could test and fix some of the problems quite easily. (The other long term option would be to move the rst/docbook support from moin distribution to the market pages on the wiki and consider it as 3rd party supported extension.) From net.sourceforge.lists.moin-user at pooryorick.com Tue Sep 23 09:43:20 2008 From: net.sourceforge.lists.moin-user at pooryorick.com (Poor Yorick) Date: Tue, 23 Sep 2008 09:43:20 -0400 Subject: [Moin-user] rst and "what links here" functionality in moin-1.6.3 In-Reply-To: <1222175987.9801.19.camel@server.firma.waldmann-edv.de> References: <48D6B5C6.1040000@pooryorick.com> <1222175987.9801.19.camel@server.firma.waldmann-edv.de> Message-ID: <48D8F278.3080802@pooryorick.com> Thomas Waldmann wrote: > On Sun, 2008-09-21 at 16:59 -0400, Poor Yorick wrote: >> I recently sent a concise email to this list describing how links in the rst format >> >> `this is a link <../SomePage>`_ >> >> don't get picked up by the "what links here" functionality. This is such a >> fundamental feature for a wiki that I was expecting to be quickly corrected on >> how restructured text could be used while keeping "what links here" >> functionality intact. but didn't get any response. > > I sent (a rather general) response to the list with subject "rst and > docbook parsers" at Thu, 18 Sep 2008 11:00:59 +0200, didn't that get > through to you? My trash can did, and I've now fished it back out. Thanks for the heads-up, and the information regarding rst in moin. With any luck, I'll find some time to help fix rst-related bugs. -- Yorick From wtp at wtp3.org Wed Sep 24 23:11:33 2008 From: wtp at wtp3.org (Krzysztof Stryjek) Date: Thu, 25 Sep 2008 05:11:33 +0200 Subject: [Moin-user] Small problem with Dictionary Message-ID: <20080925031133.GB68907@fw.wtp3.org> Hello, I've made my wiki "global" Dctionary which includes: url-python:: [[http://www.python.org|Python]] On some page I put such code: <> And as result there only text [[http://www.python.org|Python]] (not parsed). Is there any possibility to change this behavior? Of course at dictionary page it's shown correctly... Thanks a lot for your help. Reagrds, -- /~\ The ASCII Krzysztof Stryjek \ / Ribbon Campaign wtp (at) wtp3.org X Against HTML http://fw.wtp3.org/~wtp/ / \ Email! GG: 3608113 JID:wtp at chrome.pl Never be led astray onto the path of virtue. From skip at pobox.com Fri Sep 26 10:37:34 2008 From: skip at pobox.com (skip at pobox.com) Date: Fri, 26 Sep 2008 09:37:34 -0500 Subject: [Moin-user] Share LocalBadContent between two wikis? Message-ID: <18652.62382.946655.150253@montanaro-dyndns-org.local> Is it possible to robustly share the LocalBadContent page between two or more otherwise independent sibling wikis? Are symlinks the way to go or is there some better way to avoid duplication of effort? Thx, -- Skip Montanaro - skip at pobox.com - http://www.webfast.com/~skip/ From vincefn at users.sourceforge.net Sat Sep 27 04:38:37 2008 From: vincefn at users.sourceforge.net (Vincent Favre-Nicolin) Date: Sat, 27 Sep 2008 10:38:37 +0200 Subject: [Moin-user] moin wiki on sourceforge web servers, anyone ? Message-ID: <200809271038.37876.vincefn@users.sourceforge.net> [my previous message on this site did not go through apparently - if it did you can discard it, more info here] Hi, Last week sourceforge finished migrating the web servers to a new data center. After that my moin wiki stopped working, as all others I found. I thought at first that this was only due the change in the location of 'persistent' (with read-write access from the apache server) directories, but I've been unable to make it working again. Their new way (without shell access) to upload web files works well, so it is not the problem - there is cgi-python support. Last night I experimented a little and tried to catch exceptions inside the moin.cgi script. It turns out that if I modify the import line in moin.cgi to : ############## try: from MoinMoin.server.server_cgi import CgiConfig, run except ImportError,err: print err ############## Then I get the following error: ###### /usr/lib64/python2.4/lib-dynload/_socketmodule.so: failed to map segment from shared object: Cannot allocate memory ###### I tried googling around with this error but I did not find anything definitive. Maybe some security setting on their web server. Anybody managed to get a moin wiki re-running on the sourceforge servers since the migration ??? Note that the above tests were done from a clean 1.7.2 moin install, although it won't make much difference as the python error appear very early in the script. Vincent -- Vincent Favre-Nicolin CEA Grenoble/INAC/SP2M http://inac.cea.fr Univ. Joseph Fourier (Grenoble) http://www.ujf-grenoble.fr ObjCryst & Fox http://objcryst.sf.net/Fox From tw-public at gmx.de Sun Sep 28 16:28:54 2008 From: tw-public at gmx.de (Thomas Waldmann) Date: Sun, 28 Sep 2008 22:28:54 +0200 Subject: [Moin-user] moin 1.8.0beta3 released Message-ID: <1222633734.10956.5.camel@black.firma.waldmann-edv.de> See http://moinmo.in/MoinMoinDownload for the release archive and the change log. See the MoinBeta page for the list of changes. Some system text translations and help pages still need improvement - if you know a non-english language, you can also help translating and/or fixing stuff. Please translate on master18 wiki, see: http://moinmo.in/MoinDev/Translation - your work will get into 1.8.0 release then. From linuxmail at 4lin.net Sun Sep 28 17:33:09 2008 From: linuxmail at 4lin.net (Denny Schierz) Date: Sun, 28 Sep 2008 23:33:09 +0200 Subject: [Moin-user] Apache2 HTTPS Client Cert: User idenification Message-ID: <1222637589.862.15.camel@kusanagi> hi, we have apache2 installed and using https clients certs for accessing the wiki. Is there a way, to get the username automatically for the edit history? So, that we can see, who did the changes? cu denny -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From linuxmail at 4lin.net Mon Sep 29 13:07:51 2008 From: linuxmail at 4lin.net (Denny Schierz) Date: Mon, 29 Sep 2008 19:07:51 +0200 Subject: [Moin-user] CSS Manadarin theme: table-of-contents position Message-ID: <1222708071.23385.20.camel@kusanagi> hi, we use the Mandarin theme and the table-of-contents div shows up in the middle, instead of left side. Does anybody knows the correct divs, which i have to use? cu denny -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Dies ist ein digital signierter Nachrichtenteil URL: From rick.vanderveer at gmail.com Mon Sep 29 15:53:16 2008 From: rick.vanderveer at gmail.com (Rick Vanderveer) Date: Mon, 29 Sep 2008 14:53:16 -0500 Subject: [Moin-user] Apache2 HTTPS Client Cert: User idenification In-Reply-To: <1222637589.862.15.camel@kusanagi> References: <1222637589.862.15.camel@kusanagi> Message-ID: <5c39e1ca0809291253s43ea674cie4254efd194f75ae@mail.gmail.com> Correct me if I'm wrong here, but I think accessing the wiki via either https or plain old http is a separate issue from actually logging in. Switching to https is merely switching the protocol, but not providing a login method. You still need to "log in" somehow. Assuming since this is a secure site that it's an internal wiki, you might want to look into some of the auth methods, such as LDAP or Active Directory. -Rick On Sun, Sep 28, 2008 at 4:33 PM, Denny Schierz wrote: > hi, > > we have apache2 installed and using https clients certs for accessing > the wiki. Is there a way, to get the username automatically for the edit > history? So, that we can see, who did the changes? > > cu denny > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Moin-user mailing list > Moin-user at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/moin-user > > From rick.vanderveer at gmail.com Mon Sep 29 16:05:02 2008 From: rick.vanderveer at gmail.com (Rick Vanderveer) Date: Mon, 29 Sep 2008 15:05:02 -0500 Subject: [Moin-user] Changing default behavior on downloads. Message-ID: <5c39e1ca0809291305m5962fbf7oed0de750ab1d0ba2@mail.gmail.com> Yes, it's the old "downloading attachments" topic again. :-( I know that the developers are reluctant to reverti to the old behavior of linking to a document and have it download by default. The new method requires a "|&do=get" statement. But that *still* baffles a vast majority of my users, and I continue to get questions about this ("How do I make it download directly again?"). So, it occurred to me that right now the default behavior is to use "&do=view". I would like to switch this to &do=get, and make the &do=view the optional statement. Switching this behavior would bring linking back in line with what I think many wiki users would expect (not just my little wiki, but many on this reading list). Is it possible to switch this simple statement? Where would this change be made? -Rick From tw-public at gmx.de Tue Sep 30 04:30:32 2008 From: tw-public at gmx.de (Thomas Waldmann) Date: Tue, 30 Sep 2008 10:30:32 +0200 Subject: [Moin-user] Changing default behavior on downloads. In-Reply-To: <5c39e1ca0809291305m5962fbf7oed0de750ab1d0ba2@mail.gmail.com> References: <5c39e1ca0809291305m5962fbf7oed0de750ab1d0ba2@mail.gmail.com> Message-ID: <1222763432.7830.41.camel@black.firma.waldmann-edv.de> Rick, I completely understand the point that you are making. But we should try to solve that in another way (suggestions welcome). Problem is: Even if we introduce some way to configure the default "do=" value (that would be possible, of course) for now, that would just delay the problem to a later moin release (2.0 or so). That is because attachments will be items on their own then (like pages will be also items of just some specific mimetype). AttachFile action will go away and will just be replaced by normal item rendering. Links to files will be just links to items (same as links to pages) and we will either provide a markup converter converting attachment:foo to /foo or emulation code for "attachment:". At the place where the link is rendered there will be no cheap way to know the target item mimetype (one would have to open target item metadata for all links to know the mimetype, that would be slow), thus link generation must be the same for page and file items. If you link to a page item, it is using "show" action [default], therefore it has to be the same for files (note that the concrete url param "action=show" or "do=view" (or just nothing because it is default) does not matter, the behaviour is the point). Also, even if we would find out the mimetype of the link target, what shall we do with it? What should be done depends on the capability of the user agent and on the intent of the user, e.g.: If it is a jpeg image - does the use want to download that foto or just look at it? If it is a pdf, does the user want to download it or render it within the browser - does he have a browser plugin? If it is some unified diff, just look at it or download it? Because of these undecidable issues (as far as moin is concerned, the user usually knows what he/she wants), I am rather thinking that we should not try to do magic depending on the target item mimetype, but just link to the "show" rendering (that rendering will also offer some option to download it). Well, and this is exactly what recent moin releases do. What I would like to have is a much more pretty "show rendering" than the rather ugly thing we have now. So help with layout and CSS is also welcome (CSS hates me :). Not sure though if the best time to improve this is now - maybe rather AFTER we merge the storage refactoring into main repo in a few months. The "show" rendering could also show some metadata of the item and maybe its recent history. For images, it could be some scaled rendering. Cheers, Thomas From tw-public at gmx.de Tue Sep 30 06:35:24 2008 From: tw-public at gmx.de (Thomas Waldmann) Date: Tue, 30 Sep 2008 12:35:24 +0200 Subject: [Moin-user] Small problem with Dictionary In-Reply-To: <20080925031133.GB68907@fw.wtp3.org> References: <20080925031133.GB68907@fw.wtp3.org> Message-ID: <1222770924.28587.2.camel@server.firma.waldmann-edv.de> > I've made my wiki "global" Dctionary which includes: > > url-python:: [[http://www.python.org|Python]] > > On some page I put such code: > <> > > And as result there only text [[http://www.python.org|Python]] (not > parsed). Yes, GetVal does not parse/render. > Is there any possibility to change this behavior? You could write a GetValAndRender macro. Hint: there is some renderText function in wikiutil. From wtp at wtp3.org Tue Sep 30 06:45:15 2008 From: wtp at wtp3.org (Krzysztof Stryjek) Date: Tue, 30 Sep 2008 12:45:15 +0200 Subject: [Moin-user] Small problem with Dictionary In-Reply-To: <1222770924.28587.2.camel@server.firma.waldmann-edv.de> References: <20080925031133.GB68907@fw.wtp3.org> <1222770924.28587.2.camel@server.firma.waldmann-edv.de> Message-ID: <20080930104514.GI68907@fw.wtp3.org> Hello, Dnia Tue, Sep 30, 2008 at 12:35:24PM +0200, Thomas Waldmann napisa?(a): > > Yes, GetVal does not parse/render. > That's OK. It's not only described (HelpOnVariables), that's the same as FootNote. So I aksed. > > Is there any possibility to change this behavior? > > You could write a GetValAndRender macro. > > Hint: there is some renderText function in wikiutil. > Thanks a lot for hint. I will try to write such macro. I'll infomr you if it works. Thanks a lot for your answer. Regards, -- /~\ The ASCII Krzysztof Stryjek \ / Ribbon Campaign wtp (at) wtp3.org X Against HTML http://fw.wtp3.org/~wtp/ / \ Email! GG: 3608113 JID:wtp at chrome.pl Sex is like pizza -- when it's good, it's great; and when it's bad, it's still darn tasty! From tw-public at gmx.de Tue Sep 30 07:26:02 2008 From: tw-public at gmx.de (Thomas Waldmann) Date: Tue, 30 Sep 2008 13:26:02 +0200 Subject: [Moin-user] Changing default behavior on downloads. In-Reply-To: <79990c6b0809300331r3d325ef9u4966fdcb9aa06581@mail.gmail.com> References: <5c39e1ca0809291305m5962fbf7oed0de750ab1d0ba2@mail.gmail.com> <1222763432.7830.41.camel@black.firma.waldmann-edv.de> <79990c6b0809300331r3d325ef9u4966fdcb9aa06581@mail.gmail.com> Message-ID: <1222773962.28587.27.camel@server.firma.waldmann-edv.de> > Apologies for coming in part way through this, but I have the same > issue as Rick, I guess many people have. So I hope someone finds a good way to handle it - one that we can also use for future moin. > I am not 100% sure I follow your proposal here, but it seems obvious > to me that the choice between rendering inline, or linking to an > object, have to be different things. Oh, we have that: [[foo]] or [[attachment:foo]] links to a rendering of foo. {{foo}} or {{attachment:foo}} tries to render it in-place ("transclude"). But the problem you all have is that you want to link (thus, it is the upper syntax), but not to the rendering URL of the item, but to the raw download URL of it (so a modifier is needed, that is this "&do=get" thing). > So I assume we are limiting ourselves to links (which render as href>). Yes. > OK, so I click on that link. At that point, the target is > being fetched (that's the point!) and so checking its mimetype and > transmitting the file and its mimetype to the browser are > straightforward. You can't do that in general or a clicking a link to a wiki page (mimetype will be something like text/x-moin-wiki) will trigger its download as a text file (definitely not what you usually want, you want a rendering of it :). > This seems so simple to me that I'm sure I have missed something. Can > you direct me to a document explaining how attachment links are > expected to work in 2.0? I described the essential part in my last post here. It is just that we will have only one basic type of thing in future moin: a item. That item will have revisions. Revisions have data and metadata. Metadata includes stuff like editor, acls, mimetype, etc. Data is just the raw data (e.g. a pdf, png or text of a wiki page). Rendering of links to items should not depend on target mimetype (see last post), the link by default links to a rendering of the item (how exactly a item is rendered after you followed that link is of course dependant on the mimetype of it, text/x-moin-wiki will be rendered as usual, image/* might show some scaled view, application/zip might display a listing of zip file directory, application/foo-bar might just show some download button and some stuff from the metadata/history). Note: that's just a braindump. We already have the storage code, but the user interface has yet to get coded (currently there is just some compatibility code and AttachFile is not removed yet). You can find some more details on the wiki, search for ChristopherDenter or Storage Refactoring. The new storage code is there: http://hg.moinmo.in/moin/1.8-storage/ (do ignore the "1.8" in it, that just means that the code is based on 1.8, not that it will be released as 1.8). From p.f.moore at gmail.com Tue Sep 30 08:01:35 2008 From: p.f.moore at gmail.com (Paul Moore) Date: Tue, 30 Sep 2008 13:01:35 +0100 Subject: [Moin-user] Changing default behavior on downloads. In-Reply-To: <1222773962.28587.27.camel@server.firma.waldmann-edv.de> References: <5c39e1ca0809291305m5962fbf7oed0de750ab1d0ba2@mail.gmail.com> <1222763432.7830.41.camel@black.firma.waldmann-edv.de> <79990c6b0809300331r3d325ef9u4966fdcb9aa06581@mail.gmail.com> <1222773962.28587.27.camel@server.firma.waldmann-edv.de> Message-ID: <79990c6b0809300501y65c938bdp7979629125b7b299@mail.gmail.com> 2008/9/30 Thomas Waldmann : > Rendering of links to items should not depend on target mimetype (see > last post), the link by default links to a rendering of the item (how > exactly a item is rendered after you followed that link is of course > dependant on the mimetype of it, text/x-moin-wiki will be rendered as > usual, image/* might show some scaled view, application/zip might > display a listing of zip file directory, application/foo-bar might just > show some download button and some stuff from the metadata/history). Ah, I see now. In which case, to me, it's still simple. For "data" (images, zip files, binary files, probably even program code - basically, anything other than text/x-moin-wiki, and equivalents for other markup), I want the "rendering" to simply be the item data, with its associated mimetype. Then clicking on the link causes the browser's configured action (usually download, but maybe display for images and text) to occur. And the standard browser right click "Save target as" action works as I want. (That's actually a major point - with custom rendering, right click "Save as" never works for images, zipfiles, etc etc. You are compelled to use the user interface of the rendered page, whether it suits you or not). The sort of rendering you suggest, I simply don't want. If, for a special case, I did, I would give the item a *different*, non-standard mimetype, and write an appropriate renderer. If Moin came with some such renderers bundled, that might help (but as I'd rarely, if ever, use them, I could equally see it as bloat). Summary - I don't want Moin to render anything other than Wiki markup. If you have compelling examples of why a specific renderer might be more useful than straight download (note - the ones you mention above are not compelling to me) then I'd be interested, because frankly I cannot think of any. Paul. From p.f.moore at gmail.com Tue Sep 30 08:34:08 2008 From: p.f.moore at gmail.com (Paul Moore) Date: Tue, 30 Sep 2008 13:34:08 +0100 Subject: [Moin-user] Changing default behavior on downloads. In-Reply-To: <79990c6b0809300501y65c938bdp7979629125b7b299@mail.gmail.com> References: <5c39e1ca0809291305m5962fbf7oed0de750ab1d0ba2@mail.gmail.com> <1222763432.7830.41.camel@black.firma.waldmann-edv.de> <79990c6b0809300331r3d325ef9u4966fdcb9aa06581@mail.gmail.com> <1222773962.28587.27.camel@server.firma.waldmann-edv.de> <79990c6b0809300501y65c938bdp7979629125b7b299@mail.gmail.com> Message-ID: <79990c6b0809300534y55a3392dx293a4e2bf886d8e@mail.gmail.com> 2008/9/30 Paul Moore : > Summary - I don't want Moin to render anything other than Wiki markup. Thinking a little more on this, if we have normal and inline link types, and the general intention is for normal links to link to a "rendered" page, then I would argue strongly that a "raw" link type is needed, which does deliver the item data without rendering. Some points: 1. To me, "raw" links would be more useful than "rendered" links for anything other than markup. 2. A raw link could be implemented as a macro. But so could the "rendered" case. 3. Having to use a macro for what is to me, the normal case, seems backward. But that's a preference issue. 4. The choice of behaviour which is supported by syntax rather than macros is important - naive users see macros as "complex". So we could have: [[Rendered Page]] {{Inline Object}} <> People could probably get used to this, if you insist that non-markup types should have a specific rendering action. (Question: for how many mime types do you see core Moin having custom rendering actions? I assume the default rendering action would be some sort of attachment manager page?) Looking at URLs for a moment, I would say there should be a request parameter to force raw or "rendered" (I dislike this term, I'd rather say "custom page", but I'll stick with "rendered" as it's your term) behaviour. So http://server/...../MyPage?format=raw - would always generate raw data served with the item's mime type) http://server/...../MyPage?format=rendered - would generate a custom display page [1] The unadorned URL http://server/...../MyPage would generate the rendered form for text/x-moin-wiki (and maybe other markup types), and the raw form for other mime types. [1] The custom display is the rendered markup for markup types, a custom page for certain types which have special code (your zip and image examples) and a download manager page as default. I find it relevant that there are only two possible options that can apply to *all* mime types. These are "raw" and a download manager page. The "rendered" action can only ever apply to some mime types (abeit one of these is markup, which is by far the most common type). Maybe there should be *three* options - ?render=raw, ?render=manager and ?render=formatted, with the default varying by mime type, so that without ?render=, the user gets an "appropriate" result. On that basis, the discussion centres round what counts as "appropriate" - maybe just exposing that decision in the wiki config is sufficient, then I would use raw and formatted only with raw as default, and you would use formatted far more often, and manager as the default. This comes full circle to Rick's suggestion that we allow ?do=get vs ?do=view to be configurable, and indicates that maybe making that possible now isn't so far from the likely final form for 2.0. (Or to put it another way, the ?do problem won't go away in 2.0, people will still differ in their preferences, so let's implement a configurable default now, and get some experience of how effective it is before designing the final UI for 2.0). Paul. From tw-public at gmx.de Tue Sep 30 10:01:22 2008 From: tw-public at gmx.de (Thomas Waldmann) Date: Tue, 30 Sep 2008 16:01:22 +0200 Subject: [Moin-user] Changing default behavior on downloads. In-Reply-To: <79990c6b0809300501y65c938bdp7979629125b7b299@mail.gmail.com> References: <5c39e1ca0809291305m5962fbf7oed0de750ab1d0ba2@mail.gmail.com> <1222763432.7830.41.camel@black.firma.waldmann-edv.de> <79990c6b0809300331r3d325ef9u4966fdcb9aa06581@mail.gmail.com> <1222773962.28587.27.camel@server.firma.waldmann-edv.de> <79990c6b0809300501y65c938bdp7979629125b7b299@mail.gmail.com> Message-ID: <1222783282.28587.122.camel@server.firma.waldmann-edv.de> > > Rendering of links to items should not depend on target mimetype (see > > last post), the link by default links to a rendering of the item (how > > exactly a item is rendered after you followed that link is of course > > dependant on the mimetype of it, text/x-moin-wiki will be rendered as > > usual, image/* might show some scaled view, application/zip might > > display a listing of zip file directory, application/foo-bar might just > > show some download button and some stuff from the metadata/history). > > Ah, I see now. In which case, to me, it's still simple. For "data" > (images, zip files, binary files, probably even program code - > basically, anything other than text/x-moin-wiki, and equivalents for > other markup), I want the "rendering" to simply be the item data, with > its associated mimetype. OK, now there are some new problems: a) define "data" (then introduce magic dealing with it, then try to manage the magic - see sorcerer's apprentice and how image links behaved before 1.6 :) b) There are some cases where different handling is possible, e.g. do image/jpeg - you really want to see that 12Megapixel jpeg image (or rather a scaled version)? text/python - show it highlighted (rendered), show it raw, download it? Your browser might be able to help you with the scaling (while other users' browsers might not be able to do that), but it won't highlight python code for you. UI: Where do we put the user interface for item operations (like delete, revert, info, upload(!), download, different views of item, ...) if we just feed the raw data after following a link to the item? What do we show while the item is not yet uploaded? OK, we could show the upload dialogue html. BUT: imagine that item is used with transclusion, like {{/foo.png}} then it would transclude the upload html - maybe not what you wanted). Note to self: transclusion needs more thinking in general. In short: if linking to raw, you can't do it the "object oriented way" (having some UI like we have for wiki pages). > The sort of rendering you suggest, I simply don't want. If, for a > special case, I did, I would give the item a *different*, non-standard > mimetype, and write an appropriate renderer. Ehrm. You want to modify image/jpeg to image/x-jpeg-scaleto800x600 ??? Sorry, but that sounds like abuse of the mimetypes and you would have to manually edit that (how? see UI problem...). And even if one did that, you still have to UI problem. And if there is no UI, there is no user decision / user interaction possible (one user might want to see a scaled version, another might want to get the big version). Right click in the browser is not enough to deal with that problem for the general case. > If Moin came with some > such renderers bundled, that might help (but as I'd rarely, if ever, > use them, I could equally see it as bloat). Well, moin ever had that (called parsers) and they are quite useful imho. What we plan to do is just to generalize the concept and make the code easier and more powerful (if you look into AttachFile, that is just one big specialcase hack and a pain to maintain). With the new storage and new UI you will be able to have a history of a file, you will be able to revert user mistakes ("oops, i overwrote the important.doc with a wrong version"), you can control access to files by own ACLs, etc. > If you have compelling examples of why a specific renderer might be > more useful than straight download (note - the ones you mention above > are not compelling to me) then I'd be interested, because frankly I > cannot think of any. There are MANY examples. Some you can see in moin wikis running since years (by the use of either builtin or plugin parsers - they do nothing else than special rendering of some piece of data): * highlighting of programming language files, of patches, ... * rendering CSV to tables * rendering Creole Wiki, ReST or docbook markup * rendering (safe) html * (see more on ParserMarket) * showing ZIP directories Most of the above addresses the special case of text/* formats, but this is simply because old moin storage code can not deal with generic items, but just with (text) pages and attachments. You see, it is not that easy to keep the old attachment link/download behaviour. In case we won't find a solution that makes everybody happy (AKA "the wholy grail"), see it like this: * minus: the current plan will make item download 1 click harder to do as it was in moin 1.5 and before * plus: you will be able to deal much better and safer with files because of the new features Ideas (thanks for getting me to think about this again :): A) LINK BOX Maybe the theme code can solve this dilemma by having a "Link box" that has links for every link target used on that page: vvvvvvvvvvv link text, linked to rendering of target item [DL] [OtherPage] [DL] [/SubPage] [DL] [/foo.doc] ^^^^ download/raw icon, linked to raw download of target item Pro theme solution: if you don't like it, just use another theme. B) Slightly modified inline link rendering We currently decorate all non-intrawiki links with a link item (globe icon for http links, disk icon for ftp links, terminal icon for ssh, interwiki icon for interwiki links, etc.). We do no use decoration for intra-wiki links, but we could: vvvvvvvvvv linked to rendering of target item This is a [DL] [LinkText] example. ^^^^ download/raw icon, linked to raw download of target item Problem: the decoration icons are currently rendered using css :before, there is no html for them. If we re-introduce doing it by extra html (we had that in old moins), it will cause some trouble to the gui editor converter (could be solved by not doing it when feeding gui editor)., maybe line wrapping problems (icon at end of line n, link at beginning of line n+1), etc. Problem: Not sure if that makes everybody happy, because of the icons interrupting flow of reading and some people like to remove the icons because of this. Notes for A) and B): * it does not make too much sense if target is an item people usually want to see rendered (wiki text, programming language text, maybe images, ...). But we don't want to look at target mimetype, thus we would have quite some icons with rather useless links. * minor problem: this won't easily work with interwiki links because we don't know the target wiki software so we can't know the raw/dl URL. That problem is a rather generic one and also true for non-ascii interwiki pages and other stuff. From p.f.moore at gmail.com Tue Sep 30 10:20:45 2008 From: p.f.moore at gmail.com (Paul Moore) Date: Tue, 30 Sep 2008 15:20:45 +0100 Subject: [Moin-user] Changing default behavior on downloads. In-Reply-To: <1222783282.28587.122.camel@server.firma.waldmann-edv.de> References: <5c39e1ca0809291305m5962fbf7oed0de750ab1d0ba2@mail.gmail.com> <1222763432.7830.41.camel@black.firma.waldmann-edv.de> <79990c6b0809300331r3d325ef9u4966fdcb9aa06581@mail.gmail.com> <1222773962.28587.27.camel@server.firma.waldmann-edv.de> <79990c6b0809300501y65c938bdp7979629125b7b299@mail.gmail.com> <1222783282.28587.122.camel@server.firma.waldmann-edv.de> Message-ID: <79990c6b0809300720o99cdd4qf69e5ae7553b9a08@mail.gmail.com> 2008/9/30 Thomas Waldmann : > OK, now there are some new problems: [...] I'll have to think about this before responding, but it seems to me that there is a fundamental point here. You are assuming (likely based on user feedback, I concede) that the old attachment behaviour (get by default, manager page for non-existent attachments, can't recall the rest offhand, I'll need to find an "old" wiki to check) is not acceptable. In our group, I don't believe we ever had an issue with it. Conceded, new features such as versioned attachments might be useful, but I've yet to be convinced that the UI changes that seem to be needed to support this (specifically, non-intuitive ways of specifiying inline "download" links) are worth it. My experiences are certainly limited, but from other comments on the list, they don't appear to be unique. More when I've digested your previous post. Paul. From tw-public at gmx.de Tue Sep 30 13:59:49 2008 From: tw-public at gmx.de (Thomas Waldmann) Date: Tue, 30 Sep 2008 19:59:49 +0200 Subject: [Moin-user] Changing default behavior on downloads. In-Reply-To: <79990c6b0809300534y55a3392dx293a4e2bf886d8e@mail.gmail.com> References: <5c39e1ca0809291305m5962fbf7oed0de750ab1d0ba2@mail.gmail.com> <1222763432.7830.41.camel@black.firma.waldmann-edv.de> <79990c6b0809300331r3d325ef9u4966fdcb9aa06581@mail.gmail.com> <1222773962.28587.27.camel@server.firma.waldmann-edv.de> <79990c6b0809300501y65c938bdp7979629125b7b299@mail.gmail.com> <79990c6b0809300534y55a3392dx293a4e2bf886d8e@mail.gmail.com> Message-ID: <1222797589.28587.168.camel@server.firma.waldmann-edv.de> > Thinking a little more on this, if we have normal and inline link > types, and the general intention is for normal links to link to a > "rendered" page, then I would argue strongly that a "raw" link type is > needed, which does deliver the item data without rendering. Assuming we do that and you use that markup to put 1 link to raw download of some item on some page and the item is not linked from anywhere else (could easily happen), how do you get to the UI of that item? I guess the only way would be rather uncomfortable via TitleIndex (assuming we list items of all mimetypes there). > 2. A raw link could be implemented as a macro. But so could the "rendered" case. > 3. Having to use a macro for what is to me, the normal case, seems > backward. But that's a preference issue. Sure :) As I told some times already, it is not quite just preference. There is a real problem for creating an UI with raw links. > types should have a specific rendering action. (Question: for how many > mime types do you see core Moin having custom rendering actions? Well, that depends a bit on time and on how much people will help sooner or later. That stuff will be pluggable, so I expect quite some people will write the renderers they need personally (sure, you might write none as you don't need any :). For moin core development, I see those renderers will be developped first: * all stuff that deals with some sort of text that we already have in MoinMoin/parsers/* see http://hg.moinmo.in/moin/1.8/file/tip/MoinMoin/parser/ * note: rst and docbook long term future might depends on somebody maintaining them (this is a general issue, not strictly related to this discussion) * next thing will be a default fallback handler for */* or application/octet-stream mimetype, just showing the UI with upload, download, history and maybe some other metadata This will get us going and will be a usable thing. The next easy step is: * some image/* handler with scaling including some JPEG/ITCP metadata (code already exists at another place) * application/zip (show zip directory, install moin packages - code exists in AttachFile) * maybe a handler for twikidraw stuff Sooner or later: * PDF (there are browser plugins that render PDF within the browser - if they stop to be total crap at some time in the future, that would be nice) * stuff that is currently handled by EmbedObject (?) * audio/video multimedia metadata * OpenOffice.org metadata (?) * plugins done by moin community for whatever they need > assume the default rendering action would be some sort of attachment > manager page?) Rather a "item" UI that does everything that is generic for a single item: history, delete, download, upload, show basic metadata. If we can make the UI code exploit inheritance, that maybe would be the base class with the more specific renderers just adding what they offer additionally. > Looking at URLs for a moment, I would say there should be a request > parameter to force raw or "rendered" (I dislike this term, I'd rather > say "custom page", but I'll stick with "rendered" as it's your term) > behaviour. So > > http://server/...../MyPage?format=raw - would always > generate raw data served with the item's mime type) > http://server/...../MyPage?format=rendered - would generate a > custom display page [1] > > The unadorned URL http://server/...../MyPage would generate the > rendered form for text/x-moin-wiki (and maybe other markup types), and > the raw form for other mime types. Sure, that's the idea. We already have that, it just needs to be unified in a sane way (action=show [default] / action=raw vs. do=view / do = get for AttachFile). > I find it relevant that there are only two possible options that can > apply to *all* mime types. These are "raw" and a download manager > page. For links yes, that is the kind of links we need. The UI on the "rendered" display has more stuff, though: history, delete, download, upload, show basic metadata. > The "rendered" action can only ever apply to some mime types > (abeit one of these is markup, which is by far the most common type). No, above UI/rendering applies to all mimetypes. Some mimetypes will offer more, but no mimetype will offer less. Note that "rendering" an item does not necessarily mean that you see the item data's content somehow. It could be also just rendering some of its metadata and some UI functions. > Maybe there should be *three* options - ?render=raw, ?render=manager > and ?render=formatted, Ugh, that would make linking even more complicated than it already is. |-) > with the default varying by mime type, As I said, if link generation depends on target mimetype, it might get very slow as there can be many links on a page... > without ?render=, the user gets an "appropriate" result. On that > basis, the discussion centres round what counts as "appropriate" That's only the 2nd half of the problem. > maybe just exposing that decision in the wiki config is sufficient, > then I would use raw and formatted only with raw as default, and you > would use formatted far more often, and manager as the default. This > comes full circle to Rick's suggestion that we allow ?do=get vs > ?do=view to be configurable, As I already explained, that does not work that way. From tim.bird at am.sony.com Tue Sep 30 15:01:05 2008 From: tim.bird at am.sony.com (Tim Bird) Date: Tue, 30 Sep 2008 12:01:05 -0700 Subject: [Moin-user] Changing default behavior on downloads. In-Reply-To: <1222797589.28587.168.camel@server.firma.waldmann-edv.de> References: <5c39e1ca0809291305m5962fbf7oed0de750ab1d0ba2@mail.gmail.com> <1222763432.7830.41.camel@black.firma.waldmann-edv.de> <79990c6b0809300331r3d325ef9u4966fdcb9aa06581@mail.gmail.com> <1222773962.28587.27.camel@server.firma.waldmann-edv.de> <79990c6b0809300501y65c938bdp7979629125b7b299@mail.gmail.com> <79990c6b0809300534y55a3392dx293a4e2bf886d8e@mail.gmail.com> <1222797589.28587.168.camel@server.firma.waldmann-edv.de> Message-ID: <48E27771.1060405@am.sony.com> Thomas Waldmann wrote: >> Maybe there should be *three* options - ?render=raw, ?render=manager >> and ?render=formatted, > > Ugh, that would make linking even more complicated than it already is. > |-) > >> with the default varying by mime type, > > As I said, if link generation depends on target mimetype, it might get > very slow as there can be many links on a page... At the risk of pouring more fuel on the fire, I think the basic problem is in having MoinMoin manage the presentation to the browser of the "raw" attachments at all. The reason for all the weird behavior is simply that MoinMoin is trying to do some portion of the work (e.g. mime-typing) that the web server and/or browser normally do, and messing it up. A case in point is that when I try to do "save-as" by right clicking from my browser, my browser uses the page name, instead of the name of the attached file (because that's buried in the params in the URL, instead of in the path where most browsers expect the downloaded file name to be). This is annoying as all get-out. Instead of trying to manage the mime-typing, MoinMoin could just use standard URLs, and let the server and browser "do their thing". IMHO, it would be nice if non-page items (e.g. files) were accessible from the the web server via direct links (NOT via the MoinMoin CGI script). At least for the current version of some item. This allows the web server and browser to handle regular download of the items in the standard fashion. If MoinMoin wants to build a fancy page for handling meta-info (history, revisions, comments, etc.), it can do that through a link through itself. That is, the "raw" url for some item should not be: http://server.com/moin.cgi/PageName??item=foo.pdf but just: http://server.com/really/just/a/file/path/foo.pdf The big problem, of course, is that the file space is segmented by page name. If the attached files were in one directory, this becomes trivial to implement (at the cost of possible name space collisions - although I'll note here that even wikipedia, with it's enormous size, uses a flat uploaded file namespace). Even if you present the documents under page names, then you could still put them out somewhere where the web server can serve them directly, instead of having MoinMoin get in the way. -- Tim ============================= Tim Bird Architecture Group Chair, CE Linux Forum Senior Staff Engineer, Sony Corporation of America ============================= From rick.vanderveer at gmail.com Tue Sep 30 16:01:54 2008 From: rick.vanderveer at gmail.com (Rick Vanderveer) Date: Tue, 30 Sep 2008 15:01:54 -0500 Subject: [Moin-user] Changing default behavior on downloads. In-Reply-To: <48E27771.1060405@am.sony.com> References: <5c39e1ca0809291305m5962fbf7oed0de750ab1d0ba2@mail.gmail.com> <1222763432.7830.41.camel@black.firma.waldmann-edv.de> <79990c6b0809300331r3d325ef9u4966fdcb9aa06581@mail.gmail.com> <1222773962.28587.27.camel@server.firma.waldmann-edv.de> <79990c6b0809300501y65c938bdp7979629125b7b299@mail.gmail.com> <79990c6b0809300534y55a3392dx293a4e2bf886d8e@mail.gmail.com> <1222797589.28587.168.camel@server.firma.waldmann-edv.de> <48E27771.1060405@am.sony.com> Message-ID: <5c39e1ca0809301301l31ffd2beqe019d043db83537@mail.gmail.com> Really, all I want is a sane method of making files easily downloadable. :-) (actually, I just want my users to leave me alone about it, but we need to fix the first part before the second part will happen. :-) That's why I suggested in my earlier email if I could just change the "&do=view" parameter, it would quiet my users for a little while at least (future be damned, LOL!). I know that a wiki presents it's own unique challenges, by the nature of what it does. But, there has to be *some* happy medium. Imagine if the rest of the web operated this way? Remember back before admins figured out how to configure mime types, and you would occasionally click a download, and instead of downloading it dumped a bunch of binary onto your screen (and usually crashing the browser in the process)? I feel sorta like we've taken a step back to those days with the convoluted way attachments are handled here. It seems to me that if a web server can have a mime-types table, that the wiki can have a similar approach. I agree with Tim that it seems this mimetype handling is best left up to the browser/server, not the wiki (but, yes, I've read your other posts and know that it's not as simple as that. :-( ). Like what Paul said, with the exception of graphic files, and maybe some embedded media files, I want *everything else* downloaded. That includes zip files. For most users, it's not useful to display the contents of a zip file, they want it downloaded to their computer. Don't get us wrong, we know that you're laying the groundwork for some important bold new features (revisioned attachments, nice! ), but we have to also respect the behavior users expect (otherwise they come yelling at us!). You mentioned you're against any "magic" on Moin's behalf, but simply defaulting to "view" is a little *too* simplistic. Even if it was based on crude file extensions (.doc, for example), that seems better than nothing. At Tim Bird? Honestly, I'm not sure the Wikipedia-style approach is the best method (a flat file structure). It seems to me that that style would make revisioning in future versions more difficult. Also, I think that if you had it in a flat structure, it would be harder to manage individual file protection via most authentication methods or ACL's. Just my two-cents. :-) I appreciate the dialog this thread has generated... -Rick On Tue, Sep 30, 2008 at 2:01 PM, Tim Bird wrote: > Thomas Waldmann wrote: >>> Maybe there should be *three* options - ?render=raw, ?render=manager >>> and ?render=formatted, >> >> Ugh, that would make linking even more complicated than it already is. >> |-) >> >>> with the default varying by mime type, >> >> As I said, if link generation depends on target mimetype, it might get >> very slow as there can be many links on a page... > > At the risk of pouring more fuel on the fire, I think the > basic problem is in having MoinMoin manage the presentation to > the browser of the "raw" attachments at all. > > The reason for all the weird behavior is simply that MoinMoin > is trying to do some portion of the work (e.g. mime-typing) > that the web server and/or browser normally do, and messing > it up. A case in point is that when I try to do "save-as" > by right clicking from my browser, my browser uses the page > name, instead of the name of the attached file (because that's > buried in the params in the URL, instead of in the path where > most browsers expect the downloaded file name to be). This > is annoying as all get-out. Instead of trying to manage > the mime-typing, MoinMoin could just use standard URLs, > and let the server and browser "do their thing". > > IMHO, it would be nice if non-page items (e.g. files) were > accessible from the the web server via direct links > (NOT via the MoinMoin CGI script). At least for the current > version of some item. This allows the web server and browser > to handle regular download of the items in the standard > fashion. If MoinMoin wants to build a fancy page for handling > meta-info (history, revisions, comments, etc.), it can do that > through a link through itself. > > That is, the "raw" url for some item should not be: > http://server.com/moin.cgi/PageName??item=foo.pdf > but just: > http://server.com/really/just/a/file/path/foo.pdf > > The big problem, of course, is that the file space is segmented > by page name. If the attached files were in one directory, this > becomes trivial to implement (at the cost of possible name > space collisions - although I'll note here that even wikipedia, > with it's enormous size, uses a flat uploaded file namespace). > Even if you present the documents under page names, > then you could still put them out somewhere where the web server > can serve them directly, instead of having MoinMoin get in the way. > -- Tim > > ============================= > Tim Bird > Architecture Group Chair, CE Linux Forum > Senior Staff Engineer, Sony Corporation of America > ============================= > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Moin-user mailing list > Moin-user at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/moin-user > From vincefn at users.sourceforge.net Thu Sep 25 16:02:12 2008 From: vincefn at users.sourceforge.net (Vincent Favre-Nicolin) Date: Thu, 25 Sep 2008 22:02:12 +0200 Subject: [Moin-user] MoinMoin & Sourceforge Message-ID: <200809252202.12149.vincefn@users.sourceforge.net> Hi, This message is mostly for people hosting a moinmoin wiki on sourceforge. Last week sourceforge finished its migration of web servers to a new data center. They also changed the permissions on their data servers, so that my moinmoin wiki stopped working. At first I thought this was just because they moved the old 'persistent' data, but after moving the data files and updating paths it still does not work... A clean install did not help either. I also made tests with the pythontest.cgi, which worked at first (reporting python2.4) but does not report anything now... I almost think I triggered some extra protection on the server by modifying the script (adding an 'ls /home/persistent/o/ob/objcryst' to see what was going on...) I also looked at other moinmoin sites on sourceforge, and all those I looked at seem to be down. SO I'm wondering if there are other people reading this list who had a monmoin wiki on sourceforge, and had a better luck than I did ?? Vincent -- Vincent Favre-Nicolin CEA Grenoble/INAC/SP2M http://inac.cea.fr Univ. Joseph Fourier (Grenoble) http://www.ujf-grenoble.fr ObjCryst & Fox http://objcryst.sf.net/Fox From vincefn at users.sourceforge.net Thu Sep 25 17:57:34 2008 From: vincefn at users.sourceforge.net (Vincent Favre-Nicolin) Date: Thu, 25 Sep 2008 23:57:34 +0200 Subject: [Moin-user] MoinMoin & Sourceforge In-Reply-To: <200809252202.12149.vincefn@users.sourceforge.net> References: <200809252202.12149.vincefn@users.sourceforge.net> Message-ID: <200809252357.34522.vincefn@users.sourceforge.net> On jeudi 25 septembre 2008, Vincent Favre-Nicolin wrote: > I also made tests with the pythontest.cgi, which worked at first > (reporting python2.4) but does not report anything now... I almost think I > triggered some extra protection on the server by modifying the script > (adding an 'ls /home/persistent/o/ob/objcryst' to see what was going on...) OK, forget that part - the pythontest.cgi does work, as well as the explore.py (from http://moinmo.in/HelpOnInstalling/ApacheOnLinuxFtp) - I just had forgotten the +x permissions on the cgi scripts... But the moin.cgi still does not work properly (I see the python script is executed, but no wiki page)... Anyone using sf.net had more luck ? -- Vincent Favre-Nicolin CEA Grenoble/INAC/SP2M http://inac.cea.fr Univ. Joseph Fourier (Grenoble) http://www.ujf-grenoble.fr ObjCryst & Fox http://objcryst.sf.net/Fox From tw-public at gmx.de Sun Sep 28 16:19:21 2008 From: tw-public at gmx.de (Thomas Waldmann) Date: Sun, 28 Sep 2008 22:19:21 +0200 Subject: [Moin-user] Share LocalBadContent between two wikis? In-Reply-To: <18652.62382.946655.150253@montanaro-dyndns-org.local> References: <18652.62382.946655.150253@montanaro-dyndns-org.local> Message-ID: <1222633161.10956.3.camel@black.firma.waldmann-edv.de> > Is it possible to robustly share the LocalBadContent page between two or > more otherwise independent sibling wikis? Are symlinks the way to go or is > there some better way to avoid duplication of effort? If you are a bit careful and the regexes are useful for everybody, you can add them to MoinMaster:BadContent and duplication of effort will be avoided globally. From p.f.moore at gmail.com Tue Sep 30 06:31:12 2008 From: p.f.moore at gmail.com (Paul Moore) Date: Tue, 30 Sep 2008 11:31:12 +0100 Subject: [Moin-user] Changing default behavior on downloads. In-Reply-To: <1222763432.7830.41.camel@black.firma.waldmann-edv.de> References: <5c39e1ca0809291305m5962fbf7oed0de750ab1d0ba2@mail.gmail.com> <1222763432.7830.41.camel@black.firma.waldmann-edv.de> Message-ID: <79990c6b0809300331r3d325ef9u4966fdcb9aa06581@mail.gmail.com> 2008/9/30 Thomas Waldmann : > I completely understand the point that you are making. > > But we should try to solve that in another way (suggestions welcome). > > Problem is: > > Even if we introduce some way to configure the default "do=" value (that > would be possible, of course) for now, that would just delay the problem > to a later moin release (2.0 or so). > > That is because attachments will be items on their own then (like pages > will be also items of just some specific mimetype). > AttachFile action will go away and will just be replaced by normal item > rendering. > Links to files will be just links to items (same as links to pages) and > we will either provide a markup converter converting attachment:foo > to /foo or emulation code for "attachment:". > > At the place where the link is rendered there will be no cheap way to > know the target item mimetype (one would have to open target item > metadata for all links to know the mimetype, that would be slow), thus > link generation must be the same for page and file items. > > If you link to a page item, it is using "show" action [default], > therefore it has to be the same for files (note that the concrete url > param "action=show" or "do=view" (or just nothing because it is default) > does not matter, the behaviour is the point). > > Also, even if we would find out the mimetype of the link target, what > shall we do with it? What should be done depends on the capability of > the user agent and on the intent of the user, e.g.: > > If it is a jpeg image - does the use want to download that foto or just > look at it? > > If it is a pdf, does the user want to download it or render it within > the browser - does he have a browser plugin? > > If it is some unified diff, just look at it or download it? > > Because of these undecidable issues (as far as moin is concerned, the > user usually knows what he/she wants), I am rather thinking that we > should not try to do magic depending on the target item mimetype, but > just link to the "show" rendering (that rendering will also offer some > option to download it). > > Well, and this is exactly what recent moin releases do. > > What I would like to have is a much more pretty "show rendering" than > the rather ugly thing we have now. So help with layout and CSS is also > welcome (CSS hates me :). > > Not sure though if the best time to improve this is now - maybe rather > AFTER we merge the storage refactoring into main repo in a few months. > > The "show" rendering could also show some metadata of the item and maybe > its recent history. For images, it could be some scaled rendering. Apologies for coming in part way through this, but I have the same issue as Rick, in that I have an internal Wiki where click-to-download attachments are relatively common, and people want to keep that. I am not 100% sure I follow your proposal here, but it seems obvious to me that the choice between rendering inline, or linking to an object, have to be different things. Whether a JPG is shown in the page flow, or as a link to a JPG file, are different intents, and need to be recognised in the markup (like and in HTML). So I assume we are limiting ourselves to links (which render as ). OK, so I click on that link. At that point, the target is being fetched (that's the point!) and so checking its mimetype and transmitting the file and its mimetype to the browser are straightforward. This seems so simple to me that I'm sure I have missed something. Can you direct me to a document explaining how attachment links are expected to work in 2.0? Paul.