---- Dylan Jay email@example.com Avaya Communication Tel: +61-2-9352-8642 Level 3, 123 Epping Road FAX: +61-2-9352 9224 Nth Ryde NSW 2113 Mobile: 0409 606 171 AUSTRALIA
> I have a local Zwiki which I am unable to edit. It seems to be caused by
> the fact that my SMTP server is currently down, so subscribers to the
> site can't be notified.
> Is it intended that edits fail if mail can't be sent?
No. That may need some new attention.
> Is there a way to determine version of Zwiki I'm running?
In recent versions, call the zwiki_version method on any page. Eg .../FrontPage/zwiki_version
If your site is on the internet you can also give a page url to the ZwikiAnalyzer. This will be able to identify older versions by checking for known method names etc (eventually).
I like it.
> 1) is there a way of eliminating any spaces/special
> characters in the title of the page to be created?
When using square-bracket links ? The latest code takes care of that for the url, but doesn't change the title that people see.
> 2) Is there a better way to create a unique title for
> each wiki page. For instance, (and this might be more
> of a Metapublisher question) is there a way to create
> a zwiki page based on a unique (numerical) identifier,
> and have the title of the page be the title of the
> poem or story.
Someone pointed out the way ZwikiIssueTracker does it. I think the best for your situation would be to use the latest code with it's enhanced freeform links; then you should be able to use the actual title within square brackets for your pages, and the ids/urls will be generated as needed.
Yes, lastEditTime/last_edit_time have been changed recently (see http://zwiki.org/ChangeLog ). The ZwikiIssueTracker instructions are accurate for the latest zwiki code in cvs.
The details are on http://zwiki.org/KnownIssues (#178 editform contains wrong permission check for file upload).
-- Mark Bucciarelli
Got it. Needed to put a call to browser_id_manager.encodeUrl() in the index_html. Works great now.
Did some cleanup
Does it work for you ? I've been having problems.
> I downloaded the latest tgz, but standard_wiki_footer does not contain
> the necessary code. Could you send me the DTML snippet to make this work?
> Also, a
print this page link that uses a user-defined style-sheet and
> displays only the document content would be a great standard feature. A
> simple dtml
Thanks for this.. I tried it (printable). Things like this are also an option and I think give a more accurate rendering -
mojixof Japan Zope User Group(http://zope.jp/).
XSSin Japan) from
Thanks mojix. I am cc'ing zwiki.org for people interested in this. Those who want to learn more about this issue should also check out SecurityAlertForZeroPointSix and the zope.org doc linked there.
All: I don't take responsibility for locking down people's public zwiki installations, but I try to warn about the issues and provide sensible default settings in wiki templates etc. We probably need to review the latter.
Best regards --Simon
This is great. I wonder if the latest code allows japanese characters in square bracket links.
Thanks - unfortunately I don't know how to do that, at least within the bounds of unpaid development time. The CMF environment is too different. Perhaps this will be less of a problem as zope 3 emerges.
Regards - Simon
I think it also needs site customization of the wikilink regular expression. The caplilization thing isn't i18n
This is a good first step. How do people get a copy of the defaults to modify them however? Perhaps just a customize page that has links that makes a copy of each default into ZODB?
Getting a copy of defaults - I don't want to do anything complicated. Currently one reads the upgrade docs and finds out that defaults can be got from a certain link at zwiki.org, or from Products/ZWiki/templates/defaults. I could probably make /view_source work as it used to. If we made a pushbutton for it, where could it go that's simple, natural and maintenance-free ?
Other ease-of-admin issues - simpler catalog and tracker setup. We can automate these with a python or dtml wizard, but what's the best ui ? Add zwiki catalog, Add zwiki tracker options in the ZMI add menu; list catalog and tracker among the wiki templates on the add zwiki web form; pushbuttons on the special admin form discussed above..
... Your resource referal friend, - DeanGoodmanson (For those who haven't given a month to the Python-URL!, give it a zing, it will wonderfually warp your outlook. Then again, looking at half the items at every garage sale and pondering which of your friends could use /that/ doesn't help either. ;-) )
But we'll be back. Chrism was robbed. :) Good job Andy.
Also, I'm thinking of declaring 0900-1000 PST on wednesdays as the zwiki chat hour on #zope. I'm often on as sm, but if this fixed time would be helpful let me know.
The problem I have is: should I choose Python 2.1 or Python 2.2 as a requirement. Python 2.1 is much more used for Zope 2.4 and Zope 2.5, but Python 2.2 has the e-mail package.
I think of starting in Python 2.2 and hope for Zope3 and/or Zope 2.7 to be ready by the time I complete this project ;)
Thanks.. it depended on the bobobase_modification_time index which I removed. Fixed.
> I started working on a new mail-in frontend (instead of using
Great. For the MIME parts, how about ExtFiles? (and extfile-based Photos for images) ? As for python, it's a bit of a drag but shouldn't be hard to stay 2.1 compliant.. wouldn't you prefer all those zope 2.3/2.4/2.5 users to be able to use your frontend.
IssueTrackerand including it default sites already preconfigured?
I like your front page that has a sort of
blog already set up. Can you make that the new default FrontPage in Zwiki? It would be great to have the last
issues on the right side, and the last few GeneralDiscussion entries at the bottom as a default to make zwiki really scream out of the box. :)
waiting patiently for 0.10
Ok, since you ask for it, here is another of my feature suggestions. This is something that I tried to hack togeather in my very first ZWiki but gave up. I want a printable report. This is essentially a set of wiki pages printed nicely starting from one page and by crawling or something, all the related pages after. How to get the "right" set of pages is open for discussion, perhaps it could be restricted to just children and siblings, perhaps a stright breadth-first crawl.
the primary motivation is meeting type readouts. I dump ideas in wikis and then have meetings. I want to take the 10 most relevent pages centered around 1 or 2 pages with me to a meeting without having to think about it.
I'd be happy to hack on these with some pointers for help, or maybe they'll just magically appear in 0.10.0. :)
I probably use ExtFile? or ExternalFile? for storing the attachements on the filesystem. I might also use some of the code of Mailman's Srubber.py to store attachements to the filesystem directly.
> As for python, it's a bit of a drag but shouldn't be hard to
> stay 2.1 compliant.. wouldn't you prefer all those zope 2.3/2.4/2.5 users
> to be able to use your frontend.
I thought the email package required Python 2.2, but it doesn't! So I'm now developping the frontend with Python 2.1 and requiring the email package.
To be continued...
IssueTrackerand including it default sites
blogalready set up. Can you
issueson the right side, and the last few GeneralDiscussion
Yes, but how exactly should we do these things without adding complication for people who don't want them.
I'm thinking the simplest ui would be
Add Zwiki Catalog and
Tracker actions in the ZMI add menu.
I'll see your idea, and raise you one. Where's the UI for this ? We'll probably want options eg for different output formats. The page footer, the hierarchy map, or a single footer link leading to a separate printform suggest themselves. Say it's the latter, and printform is a dtml method, page template or python script.
You can prototype this on a wiki page of course. I think a useful default will be to print the current page and it's children. I think there's a method in Parents.py that will return that list of pages in the right order. That would be a start. Next, it could render each of these using one of the "printable" tricks discussed here recently.
...ok, the Parent.py's offspring method returns the children but html-formatted. I have checked in two utility methods which will help: offspringAsList and offspringIdsAsList.
Now, how about something like the demo code on TestPage:
<dtml-in offspringIdsAsList prefix=x> <h2><hr>&dtml-x_sequence_item;</h2> <dtml-try> <dtml-var "folder()[x_sequence_item](bare=1)"> <dtml-except> <p> Could not render </p> </dtml-try> </dtml-in>
Hope this gives you some ideas.. -Simon
Thanks, certainly :)
I moved this into a print dtml method. Check it out: http://zwiki.org/ZwikiDocs/print .
With some more options this could be pretty useful. Potentially quite hard on the server too.
ZPT like edit and normal wiki view should be too :)
> Now, how about something like the demo code on TestPage::
Hey, nice work. Looks pretty good. One nice extra feature would be replace wikilinks with links to anchors on the same page.
> ZPT like edit and normal wiki view should be too :)
Well, I have good news for you. :)
Incorporating the remaining WikiForNow features was a focus of this release before I got sidetracked. The big items were pre-rendering of structured text, which we have with bells on, and regulations, which is there but needs beta-testers. See RegulatingYourPages.
You can see from my todo list that I hoped to add any remaining desirable WFN features - I think edit comments are worthwhile - but that might have to wait for next month. That will mean that WikiForNow has been assimilated and main zwiki should be suitable for use on zope.org.
ZPT support has just been checked in, see ChangeLog? for the details. Also I have re-implemented the default standard_wiki_header & standard_wiki_footer methods as a wikipage template  and that is now installed here. Let me know if you notice any differences or problems. Still to do: convert the forms (& dialogs, mailout etc) to page templates, and use page templates for all the builtin defaults (?). I'll leave that for later or for someone else.
 That was.. interesting. Like a three-way chess game.
> Hey, nice work. Looks pretty good. One nice extra feature would be
> replace wikilinks with links to anchors on the same page.
Thanks. You mean for online browsing ? I agree it's pretty handy for that too. I quickly saw a bunch of stuff I never would have seen otherwise. But the performance is a problem - I tried ZWiki/print and it never finished.. and meanwhile zope's multi-threading appeared more theoretical than actual. It would be great if we could find a way to do this at low cost, even whole-wiki printouts.
Wow, your a dynamo! Does this include the advanceoptions page with security permissions, rename etc on it? That seemed like a nice UI enhancement to me.
> ZPT support has just been checked in, see ChangeLog? for the details. Also
> I have re-implemented the default standard_wiki_header &
> standard_wiki_footer methods as a wikipage template
>  and that is now installed here. Let me know if you notice any
> differences or problems. Still to do: convert the forms (& dialogs,
> mailout etc) to page templates, and use page templates for all the builtin
> defaults (?). I'll leave that for later or for someone else.
I'd love to download and have a play soon when I get a chance. I had an idea for skinning. How about putting the templates in a subdir like you used awhile back. But instead of copying them to the main wiki folder, ZWiki looks in that folder for them. Then a folder property can be set to redirect which folder to look in for the templates. Then each skin is a just a subfolder. This is essentially what CMF does. The other thing it does is make the default template folder readonly. That way the content can actually come from the filesystem product and is really easy to upgrade with each ZWiki release. There is probably a CMF related product to do this with CMF from memory.
> ..  That was.. interesting. Like a three-way chess game.
> > Hey, nice work. Looks pretty good. One nice extra feature would
> > replace wikilinks with links to anchors on the same page.
> Thanks. You mean for online browsing ? I agree it's pretty handy for that
> too. I quickly saw a bunch of stuff I never would have seen otherwise.
> But the performance is a problem - I tried ZWiki/print and it never
> finished.. and meanwhile zope's multi-threading appeared more theoretical
yeah, 100% cpu with python doesn't seem to leave much room for leftovers.
> than actual. It would be great if we could find a way to do this at low
> cost, even whole-wiki printouts.
I guess that would depend on the where the cost is being incurred. How hard is extracting out the links in a page? could that be cached in a ZCatalog? How much cost is rendering each page? ZPT I have a feeling may improve rendering but that is only a theory I have, maybe others have more experience with that.
Is that a twiki? The default twiki is much more slick than that.
> myself seriously considering changing the out-of-box default from simple to
> Here's my thinking:
> - I hear people avoiding zwiki because they perceive it as being too
> complex/bloated, on top of the already scary zope requirement.
I think the complexity perception might come from things like having to go outside of the wiki set set permissions and stuff like that, but I'm not sure.
> - Those who want more features will happily try learn about full/simple,
> useroptions etc, Those who want something they can understand immediately
> they'll look for another wiki.
> Thoughts ?
Slickness leads to a impression of high quality (rightly or wrongly), so it's a bit swings and roundabouts.
I suggest probably a set of default skins that can easily be swapped between, e.g. Slick and simple, simple and simple, power user etc.
I was so pleased when I deleted most of the sub-pages from the SandBox (and moved relevant experiements to the SandBox) that I decided to clean thetest pagest out of the the TestPage also.
Near the end I ACCIDENTALLY DELETED THE TEST PAGE...Thus the Sand Box seems to be taken along with it! (Although annoying, perhaps a confirmation on DeletePage? might be helpful..)
Thanks for the cleanups. Are you using the "manage this page" panel ?
Yes. I started with DeleteMe's on the first line, then quickly switched to the "manage this page" panel from a full setting. It was handier for re-parenting mostly VisitorLog sites.
I thought the slowness was due to my many changes...looking forward to hearing database pack results.
A tidbit for the usability lab: I encountered a paranoia level of a 8 back-o-the-neck-hairs when I changed the
manage this page (newid) text box, first thinking I would reparent the page, but then just decided to Delete the page....stopped and made sure the text entry matched the page I wanted to delete. Slight confusion in the term "manage this page:" .. this = current page, or pagename in text box?
No, not at all. I think what's happening is that due to the current robot activity zope's memory usage keeps creeping up past 100Mb, causing slowdowns. I've just changed the diff browser to use form buttons to try and keep them out of the zmi. Seems to be working.
14-day pack: 373 -> 309Mb.
7-day pack: 309 -> 166Mb.
Clearly we can't maintain real page history in this kind of environment. I would temporarily disable the history link except having 7 days or 1 day of diffs is still useful.
> I wanted to delete. Slight confusion in the term "manage this page:"
> .. this = current page, or pagename in text box?
Since I just did a pack, a lot of them don't exist and now bring up the standard_error_message, whose links bring up a create form and initiate a full-wiki search. Those I will convert to form buttons also.
The revisions that do still exist come up fine, which allows scooter to get into (part of) the zmi again, find all the other revisions, cruise through the zope help etc. I have mostly granted
View management screens permission to Anonymous, so that people can examine the setup and to permit external editing (and maybe other reasons I have forgotten). I think this will have to come to an end now. Probably all ZMI pages should have the NOINDEX, NOFOLLOW meta tags. In any case the lesson seems to be: if you want to leave your zmi open to people, don't let search engines get wind of it.
Here's my 2 cents worth.
We're a software house and we use ZWiki for internal documentation. I looked at a few wikis, realised that there was a lot of choice so narrowed the search down to python based ones. We then installed MoinMoin and were happy with everthing except that it appeared to only keep one level of changes. ZWiki has a full edit history so we installed that and have been using it ever since.
I've read some books and now have a better understanding of what Zope is (and, yes it's "scary") but this didn't enter into the equation when we picked ZWiki. I saw it more like needing a JVM before I could run a Java program - it's just a prerequisite with a separate install, no big deal.
Once ZWiki was in, I cusomised a few things - specifically, forcing page
caching off and prefering ZWiki user names over Zope user names. I also
modified the user options page to have a set of
company defaults and turned
on various things like headings on comments (with the default being on). I'm
worried about how to upgrade to any new versions.
My preference would be to have most features turned on with some simple step-by-step instructions for turning them off again.
Hope this helps.
Regards, Mark Chambers
> After browsing the twiki over at http://emacswiki.org, once again I found
> myself seriously considering changing the out-of-box default from simple to
> Here's my thinking:
> - I hear people avoiding zwiki because they perceive it as being too
> complex/bloated, on top of the already scary zope requirement.
> - Those who want more features will happily try learn about full/simple,
> useroptions etc, Those who want something they can understand immediately
> they'll look for another wiki.
> Thoughts ?
> forwarded from http://www.zwiki.org/GeneralDiscussion
>> MoinMoin ... appeared to only keep one level of changes. ....
>> ZWiki has a full edit history so we installed that and have been using it ever since.
Forgive me, going to pull yet another newb question.. I haven't seen the light on the FULL edit history.
ZWiki's multiple page history is enable via Zope's object history, right?
This is grand, but don't you lose those revisions on a DB Pack?
Is there another way to keep revision history and keep the server optimization benefits of a pack?
I didn't think you should count on the History ZMI page beyond a short-term (so to speak) Undo capability.
That would be a fantastic feature. The only way I heard of this happening is by using a mounted ZODB for ZWikis? so that global packs don't interfer.
Remote. Creating a zwiki requires an extra step to choose type(and rendering) . Admins can create and add types.
I'm quite interested in the type/template idea. I noticed in passing that TWiki has a type/template idea. I quite like the idea of forms, or something more like ZPT for wikis, or say Cards in HyperCard? Anyone have any feedback on what other wikis have?
System , for pages like RecentChanges?, UserOptions?, FrontPage and so on.
Help for helppages. you could have help for admin and for users. You could also have generic help specific help(types of zwikis are specific, and each type has an accompanying help page)
Remote, for remote links.
log and logt(logtop)for logpages(rather specific)logt pages append to the top instead of bottom(logt footer has an additional parameter for this)
A number of pagetypes that are specific to the use of the web. I first used it in development, though that was not the original aim. You could use a queue of pages handling from early proposals to late debugging. To keep it simple i just use Design and Testing pages(next to bugzilla), but there will/could be more design and test phases, as well as pages for managing and planning. A Design page has an extra form with subscription at the bottom(custom footer) so anyone can add/subtract participants to a discussion, and see who is copied. It already replaced a number of email discussions
my RecentChanges? pages show the icons of the pages, which improves overview.
> I've read some books and now have a better understanding of what Zope is
> (and, yes it's "scary") but this didn't enter into the equation when we
> picked ZWiki. I saw it more like needing a JVM before I could run a Java
> program - it's just a prerequisite with a separate install, no big deal.
Well good, that's how I'd like it to work.
> Once ZWiki was in, I cusomised a few things - specifically, forcing page
> caching off
Oh ? Do you mean you changed standard_page_type to one of the non-pre-rendering/pre-linking types ? How come ?
> turned on various things like headings on comments (with the default being
> on). I'm worried about how to upgrade to any new versions.
Does "Upgrading DTML methods" on UpgradeGuide? help ? Ie you have made customizations that you want to keep, so the simplest thing for you to do is leave your methods in place and upgrade zwiki and hopefully they won't require any changes. Also from now on you have the option of using one wikipage page template instead of the two standard_wiki_header/footer dtml methods which may make life simpler.
> My preference would be to have most features turned on with some simple
> step-by-step instructions for turning them off again.
The current situation is that wikis by default have all features installed and operational, but some of them require a single click on "full" to be made visible, namely: page hierarchy, subscriber count, annoying quote, page management panel. Does this seem a reasonable compromise ?
 This last additionally requires the Manager role. Perhaps instead
it should depend on
Zwiki: Reparent pages,
Zwiki: Delete pages, and
Zwiki: Rename pages permission ?
That's correct. Zope.org handles this by keeping wiki pages in a separate mounted zodb which is never packed. I think there are alternate storage mechanisms that should help here too, perhaps DirectoryStorage?. Zope 3 has a new versioning system which would help. But it would be nice if we could keep more robust page history in a vanilla zodb installation, even one that's being packed frequently.
> the code, or just the idea. One is subscription for users, combined with
> a table mapping users to emails. User management is simpler that way. You
> can change an email or eliminate a user in a centralised place. Also,
Sounds like a good idea.
> it possible to enforce usernames. Another is generalisation of
> remotewikiurls to include a parameter \%s (4 lines of code).
This too, probably.
> a bigger one is that each zwiki gets a type. Not a subclass, because
> types indicate content. They can change over time. Just a type, with its
> own header, footer, template and so on .
You mean each page I think. It sounds like your "type" chooses a particular page layout and also functions like a WikiWikiWeb:WikiCategories tag. Does it also choose the rendering rules for the page body, like the page_type property ? Is the wiki where you've implemented this public ?
If you'd like, post some of these patches under ZwikiModifications or as wishlist issues in the tracker (use :: for quoting). Thanks..
> Mark Chambers wrote:
> >> MoinMoin ... appeared to only keep one level of changes. ....
> >> ZWiki has a full edit history so we installed that and have been
> using it ever since.
> Forgive me, going to pull yet another newb question.. I haven't seen the light
> on the FULL edit history.
> ZWiki's multiple page history is enable via Zope's object history, right?
> This is grand, but don't you lose those revisions on a DB Pack?
Yes, I believe so - but
> Is there another way to keep revision history and keep the server optimization
> benefits of a pack?
> I didn't think you should count on the History ZMI page beyond a short-term
> (so to speak) Undo capability.
> forwarded from http://zwiki.org/GeneralDiscussion
Not sure why the need for type outside of special tags in the content itself eg RemoteWikiLink?. Do you have so use cases where this is useful?
1. if a wikipage page template is found in the zodb (in this folder or acquired, use that 2. if a standard_wiki_header or standard_wiki_footer dtml method is found in the zodb, use that. If one is missing, use the default value for the other. Note the defaults for these methods were last updated just before 0.10.0. 3. otherwise, use the default page template. (ie from the filesystem)
Zwiki: Delete pagesand added
Zwiki: Rename pages. The latter permission mainly exists to control the use of the "change all links" function.
The page management panel currently appears if: the user's display mode is full and they have
Zwiki: Rename pages or
Zwiki Delete pages permission and they have authenticated or configured a zwiki username. (I don't bother displaying the page management panel if they only have Reparent permission). In addition, each of the three buttons appears depending on the corresponding permission.
There was a howto somewhere about how to make standard_html_header and footer use the content out of a ZPT instead. That might be useful? or I guess a new install doesn't come with a standard_wiki_header anymore right? so it's not a problem.
Is there a way I could set a property to change the ZWiki page to use templates/skinX/wikipage.zpt instead?
Then if you make templates/defaults to be completely readonly so that no one makes the mistake of customizing defaults, and those defaults come out of the filesystem on each upgrade. Then you've solved the whole upgrade problem. Plus you allow for people to swap their skins easily.
How do you mean "make defaults readonly.. solves the whole upgrade problem" ? Once they customize, they'll always have the upgrade problem will they not ?
However, Localizer depends on Python 2.1, because it has important features for i18n (unicode support and the gettext module).
So the multilingual version of Zwiki will require Python 2.1, only the monolingual one will work with Python 1.5.2
>>I've seen the release plan for ZWiki 0.10, how do you want to coordinate
>>the i18n effort? If you like I can create a branch named "i18n" for this
>>project, I (or we :-)) could work on it and when it's ready you could do
>>the merge with the trunk.
>You mean a branch in zwiki cvs right ? I have avoided the complication of
>branches so far, but if you think it's easiest that would be fine.
>Otherwise you could just check in your i18n changes to the trunk starting
>after 0.10. I think your changes won't require major rework of the
>product, is that right ?
Ok, I'll wait the release of 0.10 to commit, and will use the trunk.
That's right, my changes don't require major rework of the product.
>Ideally we could cc these discussions on GeneralDiscussion, or a new
>DevDiscussion? list if that's too busy, or one of the mail lists.
>Best regards, and congratulations on your new freelance status -
-- J. David Ibáñez, http://www.j-david.net Software Engineer / Ingénieur Logiciel / Ingeniero de Software
If you want simple skinning then just swapping CSS seems to go quite a long way. That's what we settled on anyway. Wiki pages have a pretty easy structure - title, search, quote, content, footer - makes them ideal for just marking out the sections as <div>s. Then you can simply use the stylesheet to change the positions & the look. We just put an drop down list on UserOptions? that sets a cookie for which theme you want, and that then gets used in the include css line of the page header. Obviously it's a bit more limiting than having multiple zpts, but it avoid any problems with the skins having code in them & maintaining them. Actually quite surprising just how much you can do with CSS when you get into it. You're welcome to our stylesheets if you want them...
The number of types depends on how structured the individual wikis are.
I think the main issue for types is: is it after the fact categorising or is it setting up structures upfront.
I don't see much value in after the fact categorising. If all wikis are
just talk then i would use very few types. Discussion subjects are often too fluid to split up in many categories.
Remotewikilinks are easily categorized because they follow a tight scheme(it could be strained though, if people start adding a lot of comments in remotewikilinks). On this site i also see a lot of pages for individual users(with their name). That could get a separate type too.
It helps to keep the number of types down, and general. Too much detail messes up the value(confusion, bad fit).
An imporant help is type
Default to mop up all zwikis that don't fit neatly into a scheme.
But when types guide process, you first design the types and then have people stick to them(or people can choose to stick to them), and that can be valuable. Guiding process indicates that you can't just do anything in a zwiki of a certain type. Well, it's only text, so in principle you can, but the header, footer, the template and helpfile remind you and guide you what should happen on the page, and what should not happen. Take the zope fishbowl process, see http://dev.zope.org/Fishbowl/Introduction.html, which describes four phases Inception, Elaboration, Construction, and Transition. Well, there could be four types to go with that. Suppose you have a more journalistic site. There could be a pagetype that reports things (meaning, you aim for objectivity)and another pagetype that is op-ed(where opinions can dominate the piece).
So the set of types come at administrator level and the types depend on the purpose of the site.
It is remarkable how a site like slashdot has only subject types, no process types. At least I'd like a type
funny intent seems reasonable too. Of course, types constrain process: you can't just mix in all kinds of comments in a summary. Which i think is for the better
render asdialog when I add/edit a page. I am logged in, my user preferences and permissions seem to be set correctly. What should I check? Thanks, Kent
render asdialog when I add/edit a page. I am logged in,
If you're using the latest editform, just having
Zwiki: Change page
types permission should do it. Previous versions required that you enable
Advanced edit options in UserOptions?, and/or that you click on "full".
Hope this helps..
This will make ZWiki able to save attachements to your wiki. This can be used for things like photoalbums, or to add documents (pdf, word, py, etc.) to specific pages.
Please give it a try, and let me know what you think of it.
This requires Python 2.1 and the email package installed.
Please note that this is the first (alpha) release of the ZwikiFrontend?
I think using a portal_skin folder would be the way to go. Having to rely on third party products being installed is painful so I would go there however.
> How do you mean "make defaults readonly.. solves the whole
> upgrade problem" ?
That's what the portal skins stuff does I think. Essentially what your filesystem templates showup as if they are inside the ZODB. They can be viewed, copied etc from ZMI, but they are read only, ie they can't be deleted. When they change on the filesystem, eg after an upgrade, then the folder contents change also. This allows you people to copy and extend from your defaults in the filesystem easily and makes sure that there is no clashes after an upgrade.
> Once they customize, they'll always have the upgrade problem
> will they not ?
If they want to incorporate new features then yes. If they don't then it's no problem. However if you use templates well with slots etc, this might be minimized also. Currently I have to will have a problem if I customize some pages and not others.
I have updated the ZwikiIssueTracker page.
Agreed, that's what I'd like us to do with the zwiki UI content. NB Kapil has separated out this DirectoryView? functionality as a separate product.
> be minimized also. Currently I have to will have a problem if I
> customize some pages and not others.
Will you ? Aren't customizing wikipage/editform/backlinks/subscribeform pretty independent of one another right now ?
Ah, that's why we didn't find it. We thought you might be awake early :)
We found a new roadblock for the mailin-with-curl setup - a sendmail setup may be running piped executables with the security-conscious smrsh, which can be configured to allow curl but still won't allow the "<" in the command line. Your zwiki_frontend.py could be a solution here.
What are the chances of making it compatible with python 2.1 and 1.5.2 ?
Nice to know I can be of any help ;)
> What are the chances of making it compatible with python 2.1 and 1.5.2 ?
Well, ZwikiFrontend is compatible with Python 2.1 already if you install the email package ;). I only use the email package to use the modern API of email to iterate through the MIME-attachements. This could be rewriting using things like older python libs, but I would like to work on further integration with Mailman 2.1, which requires Python 2.1 as well.
I should really use something like the FileUploadRequest class instead of urlencoding the mailmessage, but I didn't have a look to rewrite it.
Please give me comments about my Python coding. I'm quite new to the language, and I'm sure the code can be improved ;)
Ok, but FYI you have lots of potential users out there who don't want to upgrade their stock python yet.. :) Thanks for your work.
> Ok, but FYI you have lots of potential users out there who don't want to
> upgrade their stock python yet.. :) Thanks for your work.
Ok, I'm now trying to add some dutch politics ("PolderModel") to the ZwikiFrontend . I'll try to make uploading text files to a wiki Python 1.5.2 compliant (and thus not using the email package). If users want to use more MIME-things (like adding Wordfiles, Images, etc. to their wiki) they should grow up and use Python 2.1 and the email package.
If I can get this to work in time, does that mean we can start moving text to the DeprecatedCurlSetup page?
Can't it be somebody is mailbombing Zwiki or something like that? I still see markus.roell is subscribed to the whole wiki.
Mmmh, might have a look if i can implement size limits to the ZwikiFrontend, just in case.
No, it's not time for that.
I would like to see us flesh out a collection of example mailin setups that work, for people to choose from.
> Can't it be somebody is mailbombing Zwiki or something like that? I still
No, that's not happening. It could be something like I'm running freebsd's stock python that has limited stack space or some such issue.
> Mmmh, might have a look if i can implement size limits to the
> ZwikiFrontend, just in case.
Yes, you'll need them - too easy to bring down a site by mailing in huge mime attachments otherwise.
Sortof. I would have to create a new ZWikiFolder, work out which ones in the old one I've modified, delete them, and copy from the new Zwiki folder back to the old one, then delete the new temporary one. A pain in the arse, especially if it;s a long time between upgrades I can't remember which ones I've changed
Double Headersproblem... : http://www.freezope.org/forum/misc/00000039
I liked the more general term IssueTracker (proposed a couple of weeks ago on GeneralDiscussion) even more. Then again, other sites tend to call it something like a BugTracker.
The ReleaseNotes have been updated and Zwiki 0.10.0rc1 is out. Please download from http://zwiki.org/releases/ZWiki-0.10.0rc1.tgz and hammer on it! I hope to do the final release a week from now as described on ReleaseProcess.
Thanks all, -Simon (goes to bed)
ZwikiTrailis not defined when trying to access the page TeXmacsIssueTracker?, which is where I have pasted the ZWikiTracker?/editform code. What am I doing wrong? can anybody help?, thanks folks, AlV.
zwiki> Hello all. I'm trying to ensure that adoption of 0.10.0 at the
zwiki> TeXmacsWiki? is painless, and I'm fighting with
zwiki> the tracker, because that would make the issue list much more manageable. I've
zwiki> followed instructions (save for caching, I'll enable that later) and found the
zwiki> following error: NameError?: global name
ZwikiTrail is not defined when
zwiki> trying to access the page TeXmacsIssueTracker?, which is where I have pasted
zwiki> the ZWikiTracker?/editform code. What am I doing wrong? can anybody help?,
zwiki> thanks folks, AlV.
remove the code. It isn't necessary.
What Tony said - remove the dtml at the top that includes the ZwikiTrail?, that's a local zwiki.org thing.
> manageable. I've followed instructions (save for caching, I'll enable
> that later)
I'm glad you're upgrading, and interested in the above - do you mean you're trying to stay with non-pre-rendering page types for now ? Did you disable AUTO_UPGRADE, or what ? Let us know how it goes. NB actually all page types do "pre-rendering" at the moment, though in some cases it's a very minimal step.
Hi Pieter - nothing against your code, but it arrived late in the feature freeze/bugfix phase for 0.10, it's alpha, and I don't feel it needs to go into the 0.10 tarball. The zwikidotorg front page sends people to WikiMail to set up mailin, so making sure it's visible there should be equally as good.
So, in my case, I would like all of the following to be a link to just one page: SupportProcess?, SupportPolicy?, GettingSupport?, SupportFAQ?, HowToGetSupport?, etc. This may sound trivial, but having the ability to symlink wiki pages would resolve a lot of the issues with pluralization and multiple interpretations with how to taxonomize (Is that a word?) a wiki's contents.
Is there a zope product that could be used as a symlink creator that would serve this need?
> The zwikidotorg front page sends people to WikiMail
> to set up mailin, so making sure it's visible there should be equally as
> good. I'll do that later. I'll first try to make it more usefull and support stock ancient Pythons.
I didn't have a chance to have a look at the rc (deadline for some other project on friday). I'll really would like it if setting up a Bug/IssueTracker would be very simple.
Keep up the good work.
Another way to achieve this might be with the Fuzzy matching code. Instead of having one alternative which is the title, there could be a property which lists synonym names for a page and any links to those synonyms go to the "one true page". This idea is off the top of my head so I'm not sure if its a bastardization of wiki or a clean solution. It does come to mind that it would be easier to manage since you only dealing with one page rather than one + multiple symlinks... and what happens when the "one true page" is removed? And better still, instead of a property (which I feel uneasy about with regard to wikis... including that "type" proposal), how about a special line in the page saying something like
WikiAKA? SupportProcess? SupportPolicy? GettingSupport? SupportFAQ?
which instructs the fuzzy matching to match any of those names to that page. Nice and easy for anyone to edit :)
Me too. Hopefully we'll have automated catalog & tracker setup in next month's release.
Yup. You could also just write HTML links, or add support for twiki's (?) [link target|link label]? syntax. Or create those extra pages and on each one put a DTML redirect to the primary page.
But doesn't having synonyms for a page defeat the simplicity of wiki ?
ZWiki already does this
> and on each
> one put a DTML redirect to the primary page.
> But doesn't having synonyms for a page defeat the simplicity of wiki ?
It's a very good question and it'd be interesting to know what different user think.
Personally in my wikis I end up with lots of pages that say "see ProperNewName?", which is easy enough to do but not that nice really. I could see the benifit of having synonyms. What happens a lot is that an initial name for a page is created and then it's moved to a new page that where the name better suits it. Rather than find and replace all the links (possibly external too) I put a placeholder that asks the user to go to the new page. External links is a good example agaist the synonym proposal. It wouldn't support that. Perhaps something like
would be better for the place holder pages?
Applications like word supposidly support webdav and definitatly support RTF. I was thinking of roundtrip RTF editing, e.g. http://site/wiki/APage/asdocument.rtf view would enable a wiki page that has been converted to rtf to be opened using the default RTF editor (e.g. msword). Then assuming the app understood webdav, hitting save would save it right back into zope (and the wikipage code would reverse engineer rtf back into stx by chucking out any weird formating). This would be really nice since I would love to use a spell checker plus I quite often go from Wiki pages to word documents and then back again. Converting to word doc is easy enough via cut and paste, however going back the other way doesn't work. The other advantage in this that people who like wysiwyg can edit a wikipage as easily as everybody else. Like I said, I like stx and am not a wysiwyg person but there are plenty of them out there so supporting them can't hurt and can only increase wiki popularity.
The bad news is that word doesn't even work as I describe as above. If I open a rtf document from a zope url it opens word but doesn't let me save back to the website. It does work with webdav but the only way it does if its opened from the explorer via a "Web folder". Stupid MS once more. External editor would probably solve this problem however. I have problems with external editor however since it requires client side installation (someone should make it an unsigned applet or something).
Also, this who argument for roundtrip formatted document could apply equally to html as it does to rtf, just as it works with ZPT and their source.html virtual view.
If you're sure the page source no longer has that reference, but you still get the error, then try visiting .../TeXmacsIssueTracker?/clearCache ?
I have been following the instructions in HowToInstallAZwikiCatalog with a view to using the tracker, but after building the catalog as described, RecentChanges? no longer works (I get a "Document contains no data" warning and a python core file appears in the Zope directory). The tracker page also does not work: there is nothing between the header and the footer. After deleting the Zcatalog, RecentChanges? works again, but obviously using the tracker needs the catalog.
I am using ZWiki version 0.10.0rc1 with Zope 2.5.1 and python 2.1.3 on Tru64 Unix version 5.0 . Does anyone have any ideas about what might be going wrong, or what I need to look at to investigate this? Nothing appears in var/Z2.log.
... --2003/04/27 09:32 GMT
Hello,, i,am user zope with metapublisher, how can i sort my entries (abc)..?!
please mail me..(firstname.lastname@example.org)