This page contains notes from users noting functionality & features in Zwiki that have made into into the current codebase. (Note, this is not precise organization.)

(Attempts at archiving SuggestionsAndComments)

See also: OriginalZopeWikiProposal (an introductory note from pre-ZWiki days)

Keeping New Page link from creating a page object without Change I wonder if you could have a "never edited" flag on each page, which would then allow you to reap the spurious junk created from SandBox experimentation.

URL recognition

How about allowing outside links in square brackets? . It feels inefficient to have to repeat it twice in an anchor element.

classic wiki mode doesn't need em.. I might add this to the others.. got to strike a balance between convenient markup rules and simplicity/robustness though --SM


Annoying quote as Fortune

Now what about randomizing the AnnoyingQuote? Might not be necessary on a busy Wiki, but it could keep the first quote from fading into obscurity.

More details at AnnoyingQuoteDiscussion

Undo and Diff functionality requests

TimeTravel! Since ZWiki is Zope-based, why not play with the undo and verioning features to add a TimeTravel ability to WiKi? pages? This could server both as a way to undo in case of sporadic vandalism or, more interesting, to add the time dimension to a page! TimeTravel goes beyond a history mechanism because it is fun, you can set a initial date and a refresh rate in seconds than the whole dynamism of that page would be displayed in motion before your eyes. You could select past-present , present-past or random for the slide show direction. I think this is very WikiNature?!

Some argue that history detracts from WikiNature?,but I agree this would be useful and fun, patches welcome

Image Upload and embedding.

It would be nice to be able to include images in a wiki page. I envision uploading an image and then being able to hyperlink to it simply by typing the name. For example, upload ProductUMLDiagram.gif and somehow associate the name UMLDiagram to it (and maybe make it live in the [Product] page), and then you can see it on the page simply by including something like [UMLDiagram] or maybe [Product:UMLDiagram]. The remote links thing uses this syntax, and images need a place to live, so maybe leverage the existing syntax and make the image live in a page? All I know is that I would like the ability to submit pictures, see other pictures people have submitted, etc. Maybe Zope gives you this for free or very cheap? I am new at Zope, so I don't know if this is true. I hope so.

you can embed a remote image in a page with HTML; or if you have access, you can upload an image via the zope management UI and refer to it, again with a HTML link --SM

Leveraging Zopes security, for those who want it...

I am not a Wiki expert but to a certain extent I think that Wiki gives to much power to anonymous users. For example while adding this comment I could have accidentally (thru ignorance)or maliciously (by intent) erased all of the previous comments. Or I could have put words into someone elses mouth.

A couple of features I think would be nice to add to ZWiki.

  1. In addition to the "Change ..." button add a "Add ... comments" button. With this button a users comments are appended to the current page instead of the user having full editorial control over the whole page.
  2. If a user needs or should be allowed full control to the entire page how about limiting it to authenticated users.
  3. How about an "undo" button to be able to go back to previous page. This could help with the "oops, I didnt' mean to..." factor.

Just some thoughts.

Jimmie Houchin

The "existence proof" of the contrary is the original WikiWikiWeb, which is totally open to anonymous abuse, and yet has managed to grow to in page count into the tens of thousands, without suffering from said abuse. See WikiWikiWeb:WhyWikiWorks for discussion of why. -Tres

Very true. I will be adding permissions though, so that a site admin can enforce their policy of choice. --SM

id or title in header?

Currently (v. 0.5) , the "Id" attribute of a ZWiki page is displayed in the top left corner. It would be nice if the "Title" attribute was used instead, if set.

This would make it possible, for example, to have a Zope folder "foo" containing a ZWiki page "index_html", with the title "The Foo Page". Surfing to ".../foo" would display a ZWiki page with the headline "The Foo Page", and not "index_html" as now.

could be useful in some cases.. I like having a single unmistakable name for a page. But it should not be hard to change your standard_wiki_header to display the title instead. --SM

ToDo?: Add this to [ZWikiCustomization]?

Edit conflict checking

Is there any risk of multiple users editing the same page and resulting in a loss of data? How is this case handled? Does Zope prevent it from happening and how?

Yes, this risk exists in the current code. I have patches from JimFulton which should prevent this, which will be in 0.6

Wiki pages are volatile by nature. A wiki page may be edited by multiple authors at any time. Here are some tips to minimize the (small) risk of overwriting someone else's brand-new edits, or losing your own:

Update: edit conflict checking in zwiki 0.6.1:

--SM 2000/08/01

Some thoughts that used to be on ZwikiProblems but were subject to MovingToCombatHumongousPageSyndrome?:

I am losing edits when >1 people are editing a wiki page. Can this be solved? --[neil]

Hmm, does any WikiClones solve that particular problem? The reason that would happen is when you edit a ZWikiPage and submit your changes, you're overwriting the whole thing. Seems to me the way around that would be to have some sort of intelligent merge logic, kind of like CVS does when more than one person makes changes to a file. Maybe it's even something that all of ZoPe could benefit from...? --MattBehrens

There's some discussion in HowToAvoidEditingConflicts?. It doesn't help much. (I see what you mean --neil)

It seems to me that Zope has it all there now. If the edit this page method included setting up a version for the current session, then the Change method included the Save edits method then deleted the version, the problem would be solved. Housekeeping would necessitate a clearout of orphaned versions - I have no idea how to do that, but it must be easy :-) Also, a nicer error message or when someone else tried to edit the page under version control would be useful. All this might be total BS of course. I'll give it a go. --neil

Any housekeeping makes me cringe, unless it's automated :-) I keep thinking with my UNIX/CGI hat on, so this may be very un-[ZopeZen]?-like. Seems like you could, when you submit an edit, submit both the original copy and the new copy in the POST transaction. If the original copy and the current copy differ, then make a unidiff of the original copy and the new copy and try to apply it to the current copy with patch. For most edits, it seems like that would work. If patch couldn't solve it, then present the edit dialog again, except it'd show differences between current and new that must be resolved manually. Maybe.

I think the concepts are sound, in any event, even if it is all described in UNIX terms... --MattBehrens

Oh, hey, JimFulton has some commentary on this as well...

JimFulton said:

*If the timestamps differ, then the new edit could be rejected. Alternatively, some attempt could be made to resolve the conflicts.*

I think a lot of fuss could be saved (checking diffs etc)if the page is automatically put into a version on being requested for editing. That way, in the case of multiple people wishing to edit the same page, they could be told to wait a few moments until the page had been released by the first editor. Isn't this exactly what versions are for? --neil

Sure, I'm just thinking that I'd hate to write several paragraphs and have the system rudely tell me that I couldn't put my changes in, could I please retype them later? Just seems like it'd scale better, especially on potentially busy ZWikis? where lots of editing conflicts might happen. --MattBehrens

The C2 wiki and UseModWiki use similar methods to detect edit conflicts. Both of them use a number (C2 uses a timestamp, UseModWiki uses the page version number) to detect possible conflicts. If the page author (IP address or UserName? cookie) is the same as the last edit, however, the new edit is not considered a conflict. (This happens if the user uses the "back" button to re-edit a page. The wiki does not stop users from conflicting with themselves. :-)

In Ward's C2 wiki, an edit conflict generates a warning, and the changes are not saved. In UseModWiki, a new page is displayed with both the current and the submitted text in separate textareas. The user can cut/paste between the two areas, and save again. I'm not sure all the extra work was worthwhile--the resulting screen is fairly confusing, and it is hard to manually compare the two versions. (I may add a colored-diff output to the conflict page.) --CliffordAdams

The birth of DeleteMe

There needs to be some way to delete ZWiki pages from within the ZWiki product without going through the Zope management interface. I've found it necessary to delete pages as I refactor stuff, change my mind about where things should go, what page names should be, etc. It really helps to be able to delete pages. DolphinWikiWeb? (a Perl-based wiki clone) allows you to delete a page as long as there are no references to it in the local wiki web. I've found this to be a good rule. -RonDagostino

OK, I created the DTML part of a DeletePageFeature. -RonDagostino

auto-DeleteMe has been implemented --SM 2000/01/05

It's always nice when someone strolls through the code

GeoffGardiner: trivial, perhaps, but would you realign comments with the code? I found the elegant Python indent mechanism to be visually disrupted by comments all over the place particularly (sorry ken)

# ken's parenting code:
        if ob.parents is None:
            ob.parents = []
# ^^^ ken's parenting code

Not Ken's fault! :) I put in these temporary delimiters with notions of gathering structured linking code into its own module. Will fix --SM

Thanks. G

The STX list linebreak problem rears it's head.

I wish that StructuredText would let me create bullet lists that didn't have empty lines between entries (drop the p tags within each li). --BillSeitz

NB you can do it with <li> like on FrontPageSimple?

Now fixed in 0.12.0

More image linking collaboration

I now have patches to to enable the use of inline images (both local and remote). I'll post them somewhere when I get a moment. --GeoffGardiner

Yes please --SM

(Ok, they're in ManagedModeCode? and the release is on my Zope/Members pages).


I'd like to get some form of searching going, and don't know whether Catalog problems you seem to have encountered are still going to be around. --[GG]?

probably - I plan to integrate the relevant code from WikiForNow. --SM

WikiBadges - More org, less fray

Had some thought on Badges and how to decide on carrying out requested actions like Rename Me. See the BadgeVoting page if you are interessted. --BeWo 2001/Jan/22

URL linking gets more protocol's

How about activating like linking? Easily done in line 91 of

 url = r'["=]?((http|https|ftp|mailto|file):%s)' % (urlchars)                

--BeWo 2001/Feb/19

Good idea, added to the working version. --SM (https:testing)

Sweet, but how about gopher:// et al.? --kas 2001/Mar/01

Ack! must support gopher (I like these easy ones :) --SM

JasonByron? helps with image embedding

I finished a patch for zwiki that eliminates a little html in the source when using images.

Basically when you type just the name of the image you downloaded it renders with an enclosing img tag pointing to the uploads dir. The image does not need to be a wiki word, just have a gif,jpeg,bmp,tif... extension. The patch also changes the image upload button so that it just adds the image name alone.

That's it. Any comments/suggestions would be appreciated.

I put the patch on ImageUploadRecognizePatch

thanks, Jason

/print method implementation kick-off

I'd love to see a printable *version link, like they have on the CMF . I can look into it, but i'm very lacking in zope zwiki zen. Any pointers would help! - JosYule*

What would you do to this page to make it printable ?

Basically, what they do over on the CMF/Zope site is strip away all navigation tools and leave just the content. So for Wiki, i'd see a link that would take you to a page that renders just the content. Leave off the standard-header and -footer, that might actually take care of it. Oh, and just make sure the background is white with black text (or whatever, but that's what works for me on a printer) ( i was actually looking to make the background/text/bar colour setable via properties, is this interesting at all?). -JY

Loose, but not too loose, RemoteWikiLinks targets

Please consider relaxing the requirement that the remote page name is limited to your interpretation of a WikiName. I can't use this feature to link to most of the pages on my own wiki (FrikiServlet?), as it's page names are very freeform. That's not much of a worry (there's little useful content there), but the inability to link to some of the pages on the many Wikis which have expanded the WikiName syntax to include acronyms, middle initials and so on is a big limitation.

I suggest a remote Wiki link be specified by the following pattern:

Any WikiName which represents a local page with a RemoteWikiURL, followed by a colon(:), followed by any group of non-punctuation, non-space characters.

Done.. let's see.. fingers crossed --SM

RFC: four simplifications --SimonMichael, 2003/03/06 07:30 GMT
Here are four related ideas which I think have promise:

  1. invariant ids - currently there is no invariant relationship between a page's name and it's id. The id is usually assigned based on the name (canonicalIdFrom) but title and id can also be completely unrelated and links still work (eg issue pages). This is the reason linking large numbers of freeform links is expensive, because you have to check the titles of all pages (directly or via catalog). Is this a useful or a superfluous feature ? Doesn't it give rise to confusion ? We could simplify and say a page's id is always the canonicalIdFrom the title (page name). Then checking a freeform link is easy.
  2. new issue naming scheme - this means issues will no longer be able to have a long name and a numeric id. What if we embed the number at the beginning of the name instead. Eg "0444 having trouble with...", which will have id "0444HavingTroubleWith...". Relying on standard_error_message we can still reference issues with a standard short url (, they will sort correctly etc.
  3. drop punctuation from ids - although we can abbreviate them, issue urls will be longer and more ugly than they were. To alleviate this somewhat, let's drop punctuation characters from ids instead of quoting them. This means punctuation in freeform links will be insignificant, like spaces. This sounds fine, it was really accented characters I wanted to preserve, not general punctuation.
  4. merge issue page type - instead of having a separate page type for issues, we could select "issue" behaviour based on the page name. If a page's name begins with a number, it's an "issue" and should have the issue form displayed and be listed in the IssueTracker. I figure issues are a common and useful enough concept it wouldn't hurt to merge this into the default page type, and using one kind of page everywhere reduces confusion. Easier to change a page to an issue and vice-versa, whether that would be useful I'm not sure.