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

old RemoteWikiLinkFix(es)

- Editing [square brackets]? doesn't work for me. Perhaps you should escape the space with a %20 or something.

ahaar, ye found a bug with me new edit links.. thanks.

URL's with two capitals in them get interpreted by ZWiki! How do i fix this? -- NoneToBe

Prepend the offending token or the whole line with a "!" (bang).

Let's see if this url shows correctly

Classic Wiki


Try this instead

Classic Wiki


Perhaps I have to do this:


*Yes, this happens because the url contains a WikiName. You need to prepend TextFormattingRules with ! as I have just done. Or, it's often easier to put a ! at the beginning of the line to protect the whole thing. Things may be different with the other page types. --SimonMichael*

The URL does not work for me. It turns into a reference to FrontPage relative to the current folder. Interestingly, it seems to work fine on this machine...

Here are some variants:

  1  An effort to use the standard hyperlink method with "link": 

  2 Try to hide the thing with quotes ""

--Ross Boylan 11/25/99

Check out the TextFormattingRules. I think you are looking for (wikiname protected with !) or (whole line protected with !) (Edit this page to see the syntax) --SimonMichael

Yes, those both seem to work well. I didn't see these mentioned in the write-up on structured text. I thought the idea was for people to be able to code URL's without needing to know html. Both of the preceding examples require such knowledge.

I'll try typing the raw URL here, with just the escape: --Ross

HTML is available for people who want to do unusual stuff, but if you're linking to a page within this wiki, just type its name. eg FrontPage. --SimonMichael

Having ~ in urls in structured text keeps the urls from being parsed properly.

This just bit me too. In particular: Name doesn't work.

*maybe fixed in StructuredTextNG ? personally I prefer the other link syntaxes available here. eg http://host.name/~user or Name --SM*

*Tildes in URLs? should be avoided, for the reasons Jukka Korpela gives in Why tilde (~) should not be used in Web addresses (URLs) . Of course, not everyone has taken heed of this yet. --[deltab]?*

Using JumpTo? (in the 0.4.0 sample site ) from a page that displays BackLinks (such as FrontPage/backlinks) doesn't work because aq_parent is now the FrontPage, not the enclosing folder.

thanks, fixed --SM

Having various autowikilink problems:

[MP3StreamingOverHTTP]? [link/with/slash]? (can create, but will give problems) -karl@digicool.com

*will investigate (ZWikiTest?)
will enable # targets on bare urls
numeric digits can be easily enabled - I do have some doubts about enabling too-complex link patterns by default, because simplicity & readability become compromised --SM*

Using the square bracket notation to generate hyperlinks does not work well with spaces; I get an error if I try to create a page with a space in it.


*hmm, it [used to work]? - looks ok to me.. --SM*

Hmm, doesn't look like links to targets within URLs? get recognized .. http://www.hicom.net/~oedipus/weave.html#sim


My RecentChanges? page doesn't make hyperlinks out of page names that do not conform to WikiName format. This site's RecentChanges? seems to handle it. Can I get the patch? -RonDagostino

*oh, I get it - I need to enclose the page names in [] square brackets; I wonder where I got the text from? Maybe the sample wiki?*

The link bar at the top (FrontPages? RecentChanges? ...) maps to the wrong path when you are editing a page. So, right now when I am editing ZwikiProblems (at URL http://zwiki.org/zwiki/ZwikiProblems/editform), the links are all mapping to http://zwiki.org/zwiki/ZwikiProblems/FrontPage, http://zwiki.org/zwiki/ZwikiProblems/RecentChanges, etc.

fixed in 0.9.0 --SM

Space in Links

space-named folders cause broken links -
Michael Bernstein <webmaven@lvcm.com> writes:
> I've found that if you name a structured Zwiki folder with
> an id that has a space in it, that the link on child pages
> that is supposed to go to the root page of the folder (ie.
> FrontPage) replaces the space with %2520 instead of %20,
> which breaks the link.

believed resolved --SM

stx footnotes conflict with wikilinking

The StructuredText rule "Text enclosed in brackets which consists only of letters, digits, underscores and dashes is treated as hyper links within the document." doesn't work properly. Hah! Gotcha! It should be restated: "Text enclosed in brackets surrounded by spaces (and commas and what else?) (i.e. [like_this], [not_like_this]) which consists only of letters, digits, underscores and dashes is treated as hyper links within the document." Also note the unwanted "create-page" questionmarklinks.



zwiki and stx's use of square brackets probably still conflict.. I'll look into it.. maybe.. patches welcome --SM

The reason the construction [ABC] has this strange rendition as &lt;a href="#ABC">&lt;a href="ABC">ABC&lt;/a>&lt;/a> is that it is first parsed as StructuredText (where it is treated as a link internal to the page) then afterwards as a bracketed expression that is dealt with as a WikiName (where it is treated as a link external to the page).

So you can't use the construction '[ABC]:XyZ' as the first part of a RemoteWikiName because it has already has the form &lt;a href="#ABC">ABC&lt;/a>:XyZ by the time it is passed to the RemoteWiki routine. --GeoffGardiner

20010424: disabled stx's use of square brackets as an interim fix --SM

square brackets in remote urls

JohnDeBruyn reports that []-linked pages can't be used for RemoteWikiLinks

eg testpage, [testpage]:remotepath

fixed --SM

Broken Bookmarks from backlinks pages (v0.8.1.):

Suppose you look at some_page and click at some_bockmark - Everything is fine!

Now suppose looking at some_page/backlinks and click some_bookmark - Makes you jump to some_page/some_bookmark, which doesn't exist :( --BeWo

there was a fix in 0.9.0, also I have just fixed the same problem with the default bookmark links --SM

Remote Wiki Links components added to backlinks (v0.8.1.):

Suppose a page contains remote_wiki:wiki_page then wiki_page will show up as a backlink of local wiki_page.

I consider this a problem, if wiki_page is a wiki badge especially.

(Sorry for lacking time and knowledge to deliver some bugfixes - i'm working on it)


eg if I write WikiWikiWeb:WikiBadge here, then this page appears as a backlink of WikiBadge ? true, but I'm not sure it's worth bothering about this.. wikibadges have always been rough and ready --SM

remote wikilinks slurp trailing punctuation

When you end a sentence with a remote wiki link, the parser slurps up trailing punctuation. E.g., WikiWiki:MeToo.

I tightened up the regexp to fix this. Remote paths are now assumed to end with a letter, digit or /. This will probably turn out to be too narrow. Code which knows w3c URI standards should probably be used --SM

On UseModWiki and WikiWiki the rightmost and only the rightmost punctuation character is dropped.

I don't understand this last part - can you explain further ? --SM presumed resolved

virtual hosting leads to broken urls

ZWiki may not play well on a site that is virtually-hosted with the SiteServer? product. For example, go check out the address http://www.vineyarddiscussion.org and notice that the table of contents links and the image link on the front page incorrectly include the Site/VineyardDiscussion? path, while the large front page heading (correctly) does not. I believe the problem lies in the wiki_page_url() method in ZWikiPage.py, but I don't know enough to be able to be sure about this let alone fix it:

    def wiki_page_url(self):
        """return the url path for the current wiki page"""
        o = self
        url = []
        while hasattr(o,'id'):
            o = getattr(o,'aq_parent', None)
        return quote('/' + join(url[1:],'/'))


I added a custom fix for my problem by changing the above return line to read as follows (and this means the above links are now correct):

        return replace(quote('/' + join(url[1:],'/')), 'Site/VineyardDiscussion/Wiki', 'Wiki')

I had to import replace from the string module, too:

  from string           import split,join,replace

The general problem still exists, but at least my site is working OK for now. -RonDagostino

I'm sending Simon a patch for this, which replaces wiki_page_url and wiki_base_url with the following:

    def wiki_page_url(self):
        """return the url path for the current wiki page"""
        return '/' + self.absolute_url(relative=1)

    def wiki_base_url(self):
        """return the base url path for the current wiki"""
        return '/' + self.aq_inner.aq_parent.absolute_url(relative=1)


I've had problems with your code on my server and changed it as follows:

    def wiki_page_url(self):
        """return the url path for the current wiki page"""
        return self.REQUEST['BASE1'] + '/' + self.absolute_url(relative=1)

    def wiki_base_url(self):
        """return the base url path for the current wiki"""
        return self.REQUEST['BASE1'] + '/' + self.aq_inner.aq_parent.absolute_url(relative=1)

However, I don't know if my patch breaks anything else.


this is the most irksome issue with 0.6.1 right now.. both the old way and the new way of doing this break something. task #1 when zwiki work resumes --SM

Evan's code almost worked for me, but not quite. This is how I changed it:

    def wiki_page_url(self):
        """return the url path for the current wiki page"""
        return self.absolute_url(relative=0)

    def wiki_base_url(self):
        """return the base url path for the current wiki"""
        return self.aq_inner.aq_parent.absolute_url(relative=0)


Evan's code went in around 0.7.0. I believe I tried Eric's to fix something but it broke something else. A comprehensive set of unit tests for this functionality would really help us out here (cf LaloMartins/DocTest?) --SM

wiki_base_url() & wiki_page_url() still have problems with a SiteRoot? (seems like mgmt ui & zwiki respond differently within 3 nested siteroots) --SM

We're using SiteRoot? to enable cohabitation of Zope with Apache. All the WikiLinks? work but all the links in the header and footer are broken (including editpage which is kinda crucial ;) This with only one level of SiteRoot? not 3 nested. Versions: Zope 2.2.4 Zwiki 0.8.1 SiteRoot? 2.0b3 --SimonWilliams

Is there currently a problem with ZWiki and SiteAccess?? I am using the most current version of ZWiki and Site Access on Zope 2.2.5. I have one area that is SiteRooted? and the varialble wiki_base_url isn't picking up the url correctly.

For Example: Here is the actual directory structure /Engineering/Doc/Wiki

I have a SiteRoot? in /Engineering that make every link http://myhost/Engineering

When I go into the Wiki, the header links where it uses wiki_base_url to get the url are all pointing at /Doc/Wiki --email

Christian Scholz wrote:

I was just working on my VirtualSiteRoot product for Zope (some replacement
for SiteRoot which is a little more flexible hopefully) I encountered some
problem with the recent ZWikiPage. 
So I have a simple question:

Is there a special reason why you use

return / + self.absolute_url(relative=1)

in wiki_page_url() with the relative-flag? Actually in my environment this creates links like http:///FrontPage/editform (same for wiki_base_url). After changing both lines to

def wiki_page_url(self): """return the url path for the current wiki page""" return self.absolute_url()

def wiki_base_url(self): """return the base url path for the current wiki""" return self.aq_inner.aq_parent.absolute_url()

it seems to work ok..

(I hope there's no special reason because otherwise I don't know how to use ZWikis with virtual sites without always using a personally patched version. ;-)

My environment is Zope2.3 btw. but I had the same problems with 2.2 also. (ZWiki 0.8.1)

The above is what's in the code as of 0.9.0. My impression is that this one causes the least breakage - not sure how much that is. Still need tests so I or someone else can track this and lay it to rest. --SM

Working on this in VirtualHostingSummary - feedback needed

No feedback here or on zope list - presumed fixed

structured text hyperlinks don't work with some legal urls
eg test --SM

added to known problems