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


- & lt; gets changed to < - fixed


Doing this broke Zope earlier. Does it now?Nope Obviously that bug was fixed!


- wikilink regexp problem: "en", "de" in browser version get converted oh yeah, because they're in brackets. This is expected behaviour which ! would prevent


For some reason the changes box appears only as tiny box on the bottom of the screen. It is very hard to use. This site is much nicer. What's the secret? -- RossBoylan 11/25/99

You can customize your footer with a standard_wiki_footer DTMLMethod. The current ZWiki-0.3 comes with a footer like the one on this site. --SimonMichael


I get seemingly random indentation levels for my bulleted lists. I'll paste a bit of it in here and give a link to the full page. All bulleted items below should be at the same level. If you go to the full page, you'll also see items which get less than the proper indentation (Webmaster under Internal Positions and most of the items under Membership near the bottom).

Externally Oriented Positions

Can you explain what's going on? By the way, thanks for your prompt responses to my earlier questions, and good humor even though they weren't bugs. --RossBoylan

You are welcome. The above is strange! Still trying to figure it out from StructuredTextRules?. Maybe a structured-text expert can comment --SimonMichael

I fixed it by making each bullet have a "hanging indent" (new lines move over to beyond the bullet). --TresSeaver


Let me try something with an s at the end by using the &#115; notation. Here we go: AnExampleWithFinal?s

Hung Jung Lu


If you append two carriage returns to a page, then the last paragraph appears in bold (just like this one!)

Yup, a quirk with current structured text --SM


Paragraphs that start with single words appear to be rendering as lists.

Hi. How are you?

Great. And You?

A known problem with current StructuredText. A workaround: prepend <!----> --SM


If "!" is the first character on the page, it does not serve as aZwiki hypertext escape. I thought I had some problems getting it to work anywhere on the first line, but I can't reproduce them. See my RossBoylan page for the text I was working on.

ack.. HasThisBroken ? must investigate --SM

it works, except when it doesn't because of an interaction with structured text. workaround: don't have a blank line before the one beginning with ! --SM

fixed in 0.7.0 --SM

Hooray! I put the test back in my RossBoylan page, and things look good.


The page "CliffordAdams" is not rendered correctly. There is a broken tag, etc.

fixed in 0.7.0 --SM


I've got a very interesting problem on my 0.6.1 Wiki. I am assuming that it is something incredibly stupid. I have two examples of graphics listed below. The first icon below works fine on this Wiki implementation as well as mine. The second one however does not, even though this syntax works fine within my other Zope pages. Can anyone give me any clues? It would be greatly appreciated. Complaints and comments can be directed to

Ron Gines

I realize that the above file does not exist on this server, however what you are seeing is exactly what I see off of my server (it is behind a fire wall so I can not directly link to it).

Does "http://yoursite/Images/PPELogo2" in your browser's address field work ?

The problem is that PPELogo2 is recognised as a WikiName and so an <a href="PPELogo2">?</a> element is added inside the HTML of the <img>; you can clearly see this in the generated HTML. The right way of fixing this would be to change ZWiki to not look for WikiNames in HTML, but a workaround is to insert ! before each WikiName - e.g. <img src="/Images/!PPELogo2" alt="[example]">. --deltab

*ah yes - zwiki is smart enough to recognize the first as a url (because it starts with http:) but not the second. We don't have a full html parser, but it may be possible to refine the regexps to catch this case. Patches welcome. --SM*


I installed ZWiki 0.7.1 on my homebox today and I can't seem to figure out what is happening. On some pages ZWiki will start a new paragraph after an empty line, and also make a nice bulleted list using asterisks or dashes, while other pages require a "<p>" to start a paragraph and "<li>"'s to make bulleted lists. How come? I'm using the "hierarchal2" type of pages, btw... --KlausSeistrup

Most of your pages are in structuredtext mode, but one or two like RecentChanges? are in htmldtml mode to avoid StructuredText's interfering with their dtml. Zwiki 0.7 creates new pages with the same page_type as their parent, so your RecentChangesElsewhere page is in htmldtml mode. To fix, go to ".../RecentChangesElsewhere/edit?type=structuredtext" Perhaps there should be a per-wiki default type for new pages. --SM

Wonderful, thanks! --KlausSeistrup


Hi, just a quick question: In the standard_wiki_header there's this dtml line

context(REQUEST, enlarge_current=1)

It returns three BIG tags around the current page WikiName. That's way too big, how can I change this to one BIG tag?? --RemcoDurinck?

if you have acces, replace the <big><big><big> in Products/ZWiki/ZWikiPage.py. If not, you might be able to alter the size of BIG with a style declaration in standard_wiki_header. --SM

That worked! Thanks --RemcoDurinck?


moved from ZwikiProblems

I put some dtml code into this page and now it won't come up. Sorry. --RossBoylan.

Here's what was going on with it, for reference: 1. A missing > caused subsequent emphasized text to appear bold. 2. I converted your <> to &lt;&gt; so they would be rendered. 3. The page happened to be in structuredtextdtml mode; normally the edit will not allow broken dtml to be saved, but this was a rare case where the dtml was valid when posting the edit ("action" is defined) and not thereafter. Will add to known issues. Changed the page type to non-dtml. --SM


w3c validation issue with zwiki page html

Perhaps it is an unrelated issue, but please note that the {ZOPEDIR}/lib/python/ZPublisher/HTTPResponse.py file has a bug around line 344, that currently (at least in the Debian/unstable v2.2.4 of Zope) reads:

self.body=(%s\n&lt;base href="%s" /&gt;\n%s %

which is clearly incorrect. I found this bugette one day when I was checking my wiki pages with W3C's validator. The should, of course, read:

self.body=(%s\n&lt;base href="%s"&gt;\n%s %

after having corrected the line W3C's validator no longer barfs. --KlausSeistrup


old page title shown when creating a page --SM

fixed. Some might say, thoroughly banjaxed. --SM


html leakage into footer

Unbalanced <BIG> tags leak to the bottom of the page.

Can you reproduce on this site ? Which browser version ? --SM

2001/04/24: well that was easy enough to reproduce. I don't know any practical way to prevent it though, short of avoiding html-enabled page types. --SM


trailing spaces break stx example formatting

You have to beware of trailing spaces, when using :: to start a subparagraph in plain text! Otherwise it won't work:

  As you can see here!

Would be nice if this could be fixed, cause one tends to not recognizing trailing spaces when there are problems with rendering of structured text. At least place a warning on StructuredTextRules?.

yes, structured text is sensitive to whitespace and one becomes hyper-aware of it due to these issues. Some have been noted on WellUnderstoodProblems and TextFormattingSurprises --SM


trailing spaces break RemoteWikiURL(s)

I discovered another trailing space problem after quite some headache. It breaks access to local files on some (not all that would have been to easy) browsers. Have a look at OnViewingExternalFiles

Thänx BeWo

tightened up regexps to ignore trailing whitespace in a RemoteWikiURL --SM


stx renders a final one-line paragraph followed by trailing blank lines as a heading

eg:

I ended a paragraph in an URL (http://whatnot.com), two linebreaks and a signature (--MyName?) which was also made into a link. But ZWiki insisted on the signature being a header (H3) - now why is that? There are no lines after the signature, and definately no indented lines. --Futt

Watchout for spaces in the following lines. Delete them. :) --BeWo

known issue with zope's current StructuredText implementation, documented on WellUnderstoodProblems/TextFormattingSurprises --SM


creating horizontal rules with hyphens not supported in stx mode

---- does not create <hr>

Any help would be appreciated --Rick

It does when in classic wiki mode, but it's not part of current StructuredText. It would be easy enough to hack in - add something like

t = re.sub("^----";, "<hr>", t)

to your render_structuredtext* methods. I'm not sure it's worth the deviation from standards to include it in the stx modes by default. --SM


redirected to strange front page url

ehm, simon, some slight problems with the site ;p, zwiki.org redirects to /%21FrontPage...

Hmm. Do you have something funny in your "preferred front page" user option ? --SM

aha! i do! /me slaps himself
tav


stx heading on the first line doesn't work - you have to prepend a blank line. --SM

STX problem or symptom of the anti-decapitation kludge ? That whole latter area was a nightmare and I'm almost definitely not going there for 1.0

fixed in 0.9.3


Change to standard_wiki_header did not have effect to the generated wikiweb. Even Change to the wikiweb product seems not get used also.

Please give more details.


I suggest to change the id to title_or_id for the display on the page, but keep the title in head section as id unchanged.

Easy to do in your header - I'm not persuaded it should be the default.


Why does this site's FrontPage have antidecap kludge leakage (compare FrontPageSimple?)

Extra antidecap tag left over from old code, removed via zope management interface.


Don't know if this is a problem, but i don't know where else to put it.

When using HTML in a wiki page, specifically the <table> tag, Zwiki just wants to put <p> tags around everything, including the HTML tags... Is there a way for it to not do this? If i have a table which reaches the bottom of the screen, there is some space between it and the standard_footer, which i'd like to remove. Thanks, Jos.

Can you post your example ?


Exclamation mark does not always stop a word turning into a WikiName. For example, take this snippet of Perl code: use MyLib::myModule; .

Peter Keller

Interesting. RemoteWikiLinks:can't be escaped with !. Thanks --SM

Fixed in cvs


The "search" box is just a text box in the upper right corner, there is nothing that says what it actually does, and it doesn't have a "submit" button, its just a mystery box (at least as I see it in NS 6.1 and NS 4.7) --jojo (LAZUG person)

Just a site preference. I used to have all kinds of help text there.


Single quotes within <pre></pre> tags get eaten in Zope 2.3.x and ZWiki 0.9.4. Example:
First this to make it a regular instead of sticky key:

xmodmap -e remove Lock = Caps_Lock

Then to change it to escape:

xmodmap -e keysym Caps_Lock = Escape

There should be single quotes before remove and keysym, and after Lock and Escape. Text within Pre tags shouldn't be altered at all (including adding ZWiki tags). -efm TummydotCom?

StructuredText modes don't treat pre specially; one workaround is to use ::