Old GeneralProblems are moved here, most recent at the bottom.


- redirect after edit sometimes hangs in IE ? have to click Change again

Does anyone else see this problem, or have any insight on it?

with the separate edit page, I guess it's no longer a problem


- I noticed that I can't access the zwiki pages anonymously unless the anonymous user has view management screens abilility. Is there a way around this? --Graham Chiu

Fixed in 0.2 - thanks.


- Zope Error encountered by my Netscape 4.71 (Linux) when selecting some links; usually this is overcome when I go BACK and reselect, but not always. The error message is not helppful. And while I am at it, this box does not wrap when I input to Edit.,and the last editable character doesn 't show on the form, making it difficult to know what Ia ma typing,when theree is a long line.

Thanks. I was hacking (breaking things) just then - you should not see any errors now unless you enter bad DTML code, let me know if they continue.

yes textareas are no fun. I'll try the wrap attribute, I was afraid it'll screw something up. Or try the large form I just added.

Alright! That's a good sign of life I recognize from you-know-where :) Thanks - I'll investigate these other attributes. Let me know how the latest works for you.


I get an error when I try to access your help page ! --TheCellist? 10/11/99

I was hacking. Try it now

Very good ;)


- ^M's are added by browser edits fixed --SM


- I note that here the edit form is off page, but the version .2 that I downloaded does not have this?

*No it doesn't - see standard_wiki_footer/document_src & editform/document_src for the versions in use here. --SM*

I tried it, and get the following traceback when attempting to edit

Traceback (innermost last):
  File f:\Zope2\lib\python\ZPublisher\Publish.py, line 214, in publishmodule
  File f:\Zope2\lib\python\ZPublisher\Publish.py, line 179, in publish
  File f:\Zope2\lib\python\Zope\__init__.py, line 201, in zpublisher_exception_hook
    (Object: ElementWithAttributes)
  File f:\Zope2\lib\python\ZPublisher\Publish.py, line 165, in publish
  File f:\Zope2\lib\python\ZPublisher\mapply.py, line 160, in mapply
    (Object: editform)
  File f:\Zope2\lib\python\ZPublisher\Publish.py, line 102, in call_object
    (Object: editform)
  File F:\Zope2\lib\python\OFS\DTMLMethod.py, line 145, in __call__
    (Object: editform)
  File f:\Zope2\lib\python\DocumentTemplate\DT_String.py, line 502, in __call_
    (Object: editform)
  File f:\Zope2\lib\python\DocumentTemplate\DT_With.py, line 148, in render
    (Object: this)
  File F:\Zope2\lib\python\DocumentTemplate\DT_Var.py, line 272, in render
    (Object: src)
KeyError: (see above)

*Not sure why.. do you see a src() method in your lib/python/Products/ZWiki/ZWikiPage.py ? --SM*

PS: is there a way to turn off the hypertext for code enclosed within pre elements?

*you could prepend each line with ! --SM*


- international characters not preserved fixed, hopefully --SM


- I looked at "see standard_wiki_footer/document_src & editform/document_src for the versions in use here. " but it looks like they are just placeholders.
*The above links work for me. Try manage_main --SM*


When I click on new Zwiki page, it doesn't give me a chance to name the page. It also doesn't link to this new page automatically. As a manager I can rename it, but that seems as if it shouldn't be necessary. --RossBoylan@stanfordalumni.org current beta as of 11/17/99

I don't understand.. can you say more ? How would you want it to work ? --SimonMichael

Methinks the question stems from unfamiliarity with WikiWikiWeb:WikiNature, in which pages are created because they are linked from somewhere; renaming a page severs links to it, which is a BadThing? (in general), and is probably only appropriate in ManagerMode?. --Anonymous

Here's some more info. When I created a new Zwiki site, it has an almost blank page which says "This is a new Zwiki page". A "?" hyperlink appears after the Zwiki. If you click on it, you get a very similar page, only now Zwiki is underlined. Inspecting the folder, I see a new object has been added with an id of "ZWiki". This page has the whole "Zwiki" word as a hyperlink.

When I first saw the page I thought simply had a message to let you know it was a new page. When I noticed the new page had been added, and read some docs saying "Zwiki" was a special keyword, (it isn't, which docs do you mean ? I think this was from a quick look at the TextFormattingRules. Obviously it wasn't from a close reading!) I decided the intent was to let people add pages.

At any rate, it would be nice if people could add pages. The current behavior is confusing, and seems either broken or not useful. -- RossBoylan 11/25/99

Ross, thanks for your feedback. Here's what's supposed to happen:

  1. click Edit this page
  2. write a capitalized WikiName at the bottom, eg "NewPage?"
  3. click Change; you should see the updated page. At the bottom you should see "NewPage?" followed by a ?. The question mark indicates that NewPage? does not yet exist.
  4. click on the ?; you should see a brand-new, empty, page called NewPage?.
  5. (repeat, to build your wiki....)

diagnostic questions trimmed --SimonMichael

The behavior is as you describe. The new Zwiki page has almost the same contents as the old one, so it wasn't clear I was going anywhere. As I said, I did actually get a new page.

Now, I read a few things before diving in--more than most of the users I'm thinking of would want to--and I didn't catch this part. So whether this is a good approach to adding pages, or whether (Z)wiki is good for the uses I'm planning, are still open issues. But I'd say there's no bug, just misunderstanding. A modest change would be to make clear what the minimal stuff you need to read to get going is. For example, I thought just reading the structured text rules would do if that was the format I was using. But TextFormattingRules were also important. --Ross

You're right about the TextFormattingRules documentation being fragmented and probably confusing for wiki newcomers. All improvements are welcome. Are things clearer for a person starting at WikiWikiWeb:FrontPage ? --SimonMichael

Updated & refactored the TextFormattingRules & documentation --SimonMichael


*moved here
What the heck? I just added a comment, and ZWiki collapsed all the previous lines together?? I hope this fixes it. --HCSIII
a StructuredText rule took effect ? you changed the page type ?*

(May not be a problem with ZWiki) Using Mozilla and Structured Text, editing pages seems to not include sufficient hard returns in the final result, collapsing previously entered text together. --HCSIII

Incidentally (this is Mozilla specific, I'm sure, not a ZWiki problem, just a warning) in the edit field in Mozilla, pressing Delete (on Win95) deletes the first line of the control. Yikes! --HCSIII

assuming there's no zwiki problem here unless I hear otherwise.. --SimonMichael


I edited AtisWiki, but RecentChanges? did not notice the edit (The page remained near the bottom.) The RecentChangesBF? page properly recorded the change. It seems that RecentChanges? may be noticing only new pages. --CliffordAdams

Backlinks also appear to have problems. The RecentChanges? page reports:

Zope Error Zope has encountered an error while publishing this resource.

Error Type: KeyError? Error Value: 85

...when I click on the RecentChanges? backlink. ZwikiProblems reports the same error with a value 213.--CliffordAdams

I see the same thing.. my catalog keeps getting out of sync for some reason.. investigating --SimonMichael


searching/JumpTo? can be busted - somehow, at times, I get a JumpTo? page with an URL that's below another zwiki URL, from which nothing will work. Prob. an acquisition problem. - try jumping to RecentChanges? from:

http://joyful.com/zwiki/ZwikiProblems/SearchPage

-karl@digicool.com

I fixed a link which led into that nested limbo - you should not end up there now, in normal browsing--SM


ZWiki and cvs version of Zope as of 26 Feb 2000 do not play well together. Changes in ZCatalog and SearchIndex seem to be where the problem lies. Workaround I use:

Use lib/python/Products/ZCatalog and lib/python/SearchIndex from Zope-2.1.4-src.

-jwashin@vt.edu

thanks, I removed zcatalog code for the moment --SM


I've seen situations where back-links is empty when it should not be, but the zcatalog version show the correct set of back-links. RonDagostino

I got some kind of attribute error when I tried to create a page by clicking on the question mark. Unfortunately I didn't write anything down to document the exact error message, and now it seems to work fine. Sorry. RonDagostino

I've seen situations where the recent changes page is more accurate then the zcatalog version; in particular, I've seen the zcatalog version missing a change to front page. RonDagostino

I disabled the zcatalog support for the moment --SM


It seems that the 'Last edited ' info is consistently incorrect, at least on our Zwiki installation it seems to be out by a day! It doesn't seem to update on these Zwiki pages when I edit them either. any clues? cheers, Phil A.

No.. wait I see what you mean on this server. I think its clock is off by ~24 hours, or I have a bug. Comments welcome. --SM

Well, on this machine, the time returned by date is correct, but the modification time of the objects in the ZWiki is out by a day or so. It seems that the mtime of the Zope object is wrong --- have a look at the relevant management pages. Weird. Could it be faulty BST code subtracting one from the day instead of the hour?

Oh, and Formal Systems likes ZWiki :) --- its replaced all the junk on the whiteboards overnight. Phil A.

right on.. I just bought a couple of whiteboards myself :) --SM

upgrading zope past 2.0 has fixed the timestamps on this site, presumably that was your problem too --SM


I got hit with an editing bug that I can't reproduce. I hit "change" at least twice rapidly, got the "already edited" failure message, and when I revisited the page, the content was slightly mangled. Missing text in the middle where my edit was, and at the bottom:

-----------------------------14887053482020459773826162968 Content-Disposition: form-data; name="Change"

Change (pagename was here) -----------------------------14887053482020459773826162968--

(end of text)

-karl@digicool.com

not reproduced, presumed resolved --SM

This is a symptom of the MultiplePOSTBug?; an upgrade to 2.2.5/2.3a1 or EvanSimpson's PatchedHTTPServer? will correct. -- TresSeaver


The page editing advisory stuff which went in 0.6 doesn't seem to work in the version I'm playing with (0.6.1). Can you explain what's supposed to happen when two people edit the same zwiki page at once? (Do I have to edit from seperate logins to get the effect?)

cheers, Phil A

I just tried this. The last change overwrites the previous ones, so you can lose stuff. neil (I'm a wiki-nobody, by the way)

*I think I neglected to include the hidden timestamp field in the editform. See this site's editform. Does that solve it ? --SM*

It might if I could get at that resource! As it is I get a zope error. Have you turned off anonymous manage access to your zwiki btw? [pja]?

*actually I did, around the time we got SlashDotted. There's a view_source method now, and there is an editform in place again - I was using the built-in default for a while - so try http://zwiki.org/editform/view_source, or the sample wikis. --SM*


I've made some modifications to ZWikiPage.py which alter handling of recently created but not-yet-edited pages. See NeverSaved for details. --GTK

cool. I want to create pages as late as possible, too --SM

in 0.7.0 --SM


Dec 5, 2000: (Hi Duncan, long time no see :) - I am using a (localized to French) Zwiki on our intranet here, with people not familiar with the concept. For users who have not yet set their UserName? cookie, I would like the RecentChanges? page to display their internal IP address instead. Is this difficult ? Easy ? Any hint welcome, thanks - fredp

PS: damn, I just discovered that my 0.7.0 Zwiki doesn't do that, but this one already does ! :-)... Where do I look to see how it's done ?

PPS: of course, asking the question guarantees you'll find the answer yourself within minutes - in this case, here ... sorry ! :)

no problem! glad you found it --SM


WhatsTheCurrentFunctionalityProblems - I think I must be a bit slow here, but... Where did the wonderful "Page History" come from? Aha, I have it! For those as slow as me, add this line to standard_wiki_footer: '<a href="GeneralProblemsArchive/manage_change_history_page">Page&nbsp;history</a>'. Happily this and your other recent updates mean I can retire ManagedMode. Thanks. --GeoffGardiner


2001/3/16. Zope 2.3.0, Zwiki 0.8.1 I can no longer edit pages :-( Here is the error text KError? Sorry if it is something obvious. KeithMantell

It looks like you have a version of editform from an old version of zwiki ? There was an incompatible change I think around 0.6. This may apply to your other dtml methods too. Does this help ? --SM

presumed resolved --SM


Request: does anyone know of a way to stop Zope from issuing 404 messages and display a particular object instead? I've shifted discussion to Zope404andFriends, as it got a bit silly with all my updates. --GTK


Leftover formfiles in tmp directories: Everytime i hit "Change Some Page" Button a nsform3A93ADA0... is created in my Browsers tmp directory containing all the form data! Why is that so? (It also happens as I enter this text)--BeWo (02|21|2001)

That's a netscape configuration issue I believe.


WikiAcquisition doesn't work anymore in 0.6.1 created Wiki. When I try to reference a WikiPage? of the containing folder, the text is displayed as a link. But following that link gives a KeyError?.

An older Wiki created with 0.5 still works the old way, so I guess that it is a problem with the ZWikiWeb? product which sets some variable into the newly created folder. The generated HREFs look the same in both cases.

-Daniel Dittmar

Do you see this with 0.7.0 ? --SM

probably standard_wiki_header issue/presumed resolved


<dtml-var action> is valid on edit but not for viewing thereafter --SM

something to do with create/edit form.. presumed resolved --SM


some page names break page deletion

deleteme on [Sandbox::Link]? & [it's]? gives an error --SM

seems impossible to create pages like these now.. presumed non-issue --SM


search hangups

searching on this site is sometimes extremely slow ? eg when doing a search rather than a jump --SM

can't reproduce, presumed non-issue --SM


creating a page does not record last editor

When you create a new page your username does not get into its username property. You have to go back to edit the page for this. --GeoffGardiner

fixed --SM


need to include GPL text --SM

done


need to be able to control the type of new pages

I forget the exact security/maintenance issue, but basically we should allow the wiki admin to determine the type of all new pages via a folder attribute, to prevent people from accidentally creating differently-behaving or dtml-aware pages. --SM

done, use standard_page_type --SM


page deletion needs to cope with bogus parents --SM

fixed


missing parents / missing page title / hierarchy links disappear

sometimes no page title appears and the page does not appear in contents. context() is returning nothing in this case. This happens when the page's parents do not exist, eg when they are renamed or deleted, or when a page ends up being it's own parent.

Workaround: clear the parents by visiting PageName?/reparent --SM

disappearing parents

20000213: parents are disappearing quite frequently - problem with new reparenting form I think --SM

robots were following the "set" links. I password-protected page reparenting as an interim fix

saving properties in mgmt interface erases parents

July 17, 2000: When using the structured template, if you change the properties on FrontPage through the management screens you lose the context list in the header. Editing the properties in the management screen seems to change the parents property from an empty list into a list with an empty string. Using reparent twice to set and then clear the parent fixes this, but the python code underneath should possibly be a bit more robust. --DuncanBooth

Suppose an isolated wiki document. It's name shows in the document head, the parents property is empty! Now press "save changes" button on properties management tab. The parents property is empty as before, but name doesn't show any longer if you click the view button!

I tried this with BeWoDummyPage? in this wiki. But it is created (from here) without a parent document and remains broken even after i tried the following.

Workaround (which does it's job for me):

 visit http://somewhere/isolateddocument/backlinks
 press "Reparent" Button

Ah, i just recognized, that this bug was reported by DuncanBooth, too! see GeneralProblems

--BeWo

Check if these problems remain after integrating the newer WikiForNow parenting code.

For 1.0, we now do a quick check for bogus parents and reset if necessary. Blank titles should no longer last beyond one page view. --SM


editform generates a transaction

This is not really a ZWiki problem, but I figured perhaps someone here can help :-)

Something in my editform is generating a transaction and I don't know what it is. This makes editing always fail, because there will always be a change after the timestamp was emitted.

Of course it's also possible that the blame lies on standard_wiki_header or footer

Anyway... perhaps there is a way for ZWiki to avoid this situation? It is remotely possible that someone wants their editpage to generate a transaction on purpose.

*Are you running a very recent version ? Today I experienced a problem just like this. You might need the latest zwikipage.py from cvs. Check out the username attribute handling in __call__. Let me know if this doesn't help. --SM*

No. I'm running my own version (see LaloMartins) which is based on WFN. That's why I said it's not really a ZWiki problem :-) what generates the transaction is probably something in my changes to the editform to allow creation of folders.

ah. good.


acquisition of zwiki pages has issues

WikiAcquisition says:

" Zope-style acquisition: ZWiki picks up this behaviour for free. To see it, define a subfolder within your wiki folder and start a sub-wiki there. In the sub-wiki, you can reference pages from the parent wiki; I think all links will work ... "

I have a ZWikiWeb? with subzwikiwebs (0.7.1 on Zope 2.2.4b1). I delete HelpPage from the lower level wikiweb and get the following traceback (see below):

Traceback (innermost last):
  File D:\WEBSIT~1\lib\python\ZPublisher\Publish.py, line 222, in publishmodule
  File D:\WEBSIT~1\lib\python\ZPublisher\Publish.py, line 187, in publish
  File D:\WEBSIT~1\lib\python\Zope\__init__.py, line 221, in zpublisher_exception_hook
    (Object: Traversable)
  File D:\WEBSIT~1\lib\python\ZPublisher\Publish.py, line 171, in publish
  File D:\WEBSIT~1\lib\python\ZPublisher\mapply.py, line 160, in mapply
    (Object: HelpPage)
  File D:\WEBSIT~1\lib\python\ZPublisher\Publish.py, line 112, in call_object
    (Object: HelpPage)
  File D:\WebSite224b1\lib\python\Products\ZWiki\ZWikiPage.py, line 153, in __call__
    (Object: HelpPage)
  File D:\WEBSIT~1\lib\python\OFS\DTMLMethod.py, line 172, in __call__
    (Object: standard_wiki_header)
  File D:\WEBSIT~1\lib\python\DocumentTemplate\DT_String.py, line 528, in __call_
    (Object: standard_wiki_header)
  File D:\WEBSIT~1\lib\python\DocumentTemplate\DT_Util.py, line 337, in eval
    (Object: context(REQUEST, with_siblings=0))
    (Info: REQUEST)
  File , line 0, in ?
  File D:\WebSite224b1\lib\python\Products\ZWiki\ZWikiPage.py, line 685, in context
    (Object: HelpPage)
  File D:\WebSite224b1\lib\python\Products\ZWiki\ZWikiPage.py, line 656, in getancestors
    (Object: HelpPage)
  File D:\WEBSIT~1\lib\python\OFS\ObjectManager.py, line 624, in __getitem_
    (Object: Traversable)
KeyError: (see above)

I wonder whether this is relevant: in my standard_wiki_header I display the subwiki name thus: '<dtml-var "PARENTS[0]?.title">'. This works for the page display, but in the editform it points one level higher. --GG

I think that will cause a broken link, but should not cause the traceback. In that situation I use the wiki_base_url or wiki_page_url methods to get a more dependable url. Re the traceback - if you comment out the call to context() in standard_wiki_header does it work ? --SM

  1. wiki_base_url is on the right lines, but how would I get the title property from this?
  2. Yes, the context() is the problem. This seems to work. What do we lose by doing this (silly me - a useful bit, I see :-)? --GG

More details on acquisition for 0.7.1. With the context() bit commented out, acquisition seems to work. However it jumps you between levels at present, so is dangerous to use.

I created a SandBox ZWikiWeb within a ZWikiWeb folder. I deleted all elements from SandBox except the FrontPage.

New pages are created at the right (/Wikis/SandBox) level, so that works. You can jump to a higher level page such as HelpPage and, if there's a link back to FrontPage you get back to the lower level, so that works.

However several things don't work. The links on the header and footer that use &lt;a href="&amp;dtml-wiki_base_url;/... dump you up to the wrong (/Wikis) level and leave you there. So, for example, the Entire wiki and Page contents show you the level higher, if the page you're on has been acquired. RecentChanges is fine, however.

If you edit HelpPage, you exit at the higher level not at the lower, even though the entry URL is correctly /Wikis/SandBox/HelpPage/editform... .

If it were not for the editform issue I think I would try to just delete anything to do with the dtml-wiki_base_url in standard_wiki_header and _footer. --GG 2000-11-29.

I'm a quite confused as to the current status of this issue. Has it been resolved? Do any patches exist? I'm seeing the exact above traceback with ZWiki 0.8.1 with Zope 2.2.5. I am using Apache with SiteRoot? and ProxyPass? setup. --BarryKaplan? 2001-01-21

Myself, I have not looked into this issue, nor do I plan to until I've integrated the new parenting code I've received from Ken. Anyone wanting to play with the above scenario in a hurry would need to either fix context() or remove it from their standard_wiki_header --SM

You're right Barry, Zwiki 0.8.1 suffers from the context problem. But my impression is that i really don't want standard wiki pages to be acquired at all. I tried to explain why i'd like to have wikimethods at hand on AcquisitionAndNamespaces?. --BeWo 22.02.2001


scrolling to bottom after comment doesn't work in IE ?

IE bug.


How can I add images/diagrams etc.. to zwiki pages? I couldn't find the info on these pages...!

see AdvancedEditOptions?.


difficulties enabling file upload

Sorry to be dense on enabling file/image uploads, but I can't seem to activate this feature. As far as I can tell, permissions to change ZWiki pages, upload files, FTP access are enabled, yet no options for uploading files or changing the rendering are offered. This is true whether I'm logged in as a user or as a manager/owner, so I don't think it's a permissions problem. I have gone to the userOptions page and said yes to advanced options. I'm running ZWiki-0.9.3.tgz, downloaded from Simon Michael's distribution directory. Looking ZWikiPage.py, I see some commented remarks mentioning a sensible permission:Add Documents, Files, and Images but don't see this permission actually defined under the security tab of the management screen. I also see mention of an "upload" object, so I added a folder with the id "upload" to the ZWikiWeb? folder, to no avail. Could someone provide step-by-step instructions for a dunderhead? Or a specific list of permissions needed? My stupidity aside, thanks for a keen tool!

Hmm.. some thoughts off the top of my head. The upload folder will be used if present but isn't needed. You need "Add Documents, Files, and Images" permission on the folder. Not to be confused with "Add Documents, Images and Files" permission which zwiki ignores at present. You also need "Change ZWiki Pages" or "Append to ZWiki Pages" permission on the folder (or at least the current page), since uploading adds a link to the page. You need a standard_wiki_footer which includes the upload form - the zwikidotorg sample wiki should have this. If in fact it doesn't, this site's copy can be found here. Finally you need to go to your useroptions page and select "show advanced edit options". You'll probably need cookies enabled for this to work. If that's a problem just change standard_wiki_footer's dtml so it reveals the upload form unconditionally. That's all I can think of - does this help ? --SM

It seems I've met the above criteria, but, alas, still can't convince my Zwiki to let me upload. I downloaded the standard_wiki_folder mentioned above and looking through the source, don't see where the upload form is rendered. Is the upload form another dtml method not explicitly included in the sample wiki? Here's the last bit of the downloaded standard_wiki_footer:

<dtml snipped>

I'm missing where the upload form gets tacked on here. Sorry if I'm being dense! I can set my UserOptions? such that your site asks for an upload, so cookes should be set properly. I tried to clean house by deleting all the ZWiki bits in the product management screen, deleting my ZwikiWeb? folder, shut down Zope (version 2.3.2), rm'd the old Products/ZWiki directory, unpacked ZWiki-0.9.3.tgz, restarted zope and reimported ZWikiWebs?.zexp. By George, that should chase out old versions, but I'm still stymied. Thanks for any suggestions. --Steve

Oh I'm sorry - forget what I said about standard_wiki_footer, the upload form is in editform of course. --SM

YeeHah?! It works! Thanks Simon. I'm a pinhead for not checking the editform method. By the way, it appears the 0.9.3 tarball must have a slightly different version editform. Are your AdvancedEditOptions? going to be a part of the standard ZWiki now? Hope so...Thanks for your help! --Steve


last editor username seems to be broken ? I always see "last edited by IP address"

fixed in 0.9.5


Can't set Cookies in UserOptions? page

Zwiki Version: ZWiki-0-9-5 from ZWiki-0.9.5pre1.tgz I can't set cookies on the UserOptions page. I noticed that ZWiki was interpreting the underscore characters in the following (from UserOptions):

width: <input type="text" name="zwiki_width" size=3 maxlength=3 tabindex=1 value="<dtml-var zwiki_width missing=80>"> height: <input type="text" name="zwiki_height" size=3 maxlength=3 tabindex=2 value="<dtml-var zwiki_height missing=25>">

as text that should be underlined via <u> and </u>. In other words the INPUT control for zwiki_height was named zwiki</u>height. Putting a new line between the two input tags fixed the problem (new paragraph).

Thanks for a great product!!!