UseModWiki | UseModWiki | RecentChanges | Preferences

Now, this page is considered the old bugs page.

Please feel free to add any bugs or possible bugs here. Alternately, send mail to mailto:usemod@usemod.com. --CliffordAdams

See the WikiPatches page for contributed bug-fixes.

Be nice if somebody refactored this into a WikiBugs page, with one subpage for each bug (along the lines of WikiPatches). Maybe I will do it someday but I'd have no problem if SomebodyElse? gets there first -RiVer

WikiBugs/editlinks mangles pages in special cases

Strange characters on line-ends:

Additional spaces appear on the end of the lines on my Linux-based installation when editing with Linux Netscape (haven't tested with others).

Also, when someone edits pages with Windows IE, additional ``newlines`` crawl in... :-(

Any tips?


--- usemod092/wiki.pl   Sun Apr 22 02:44:10 2001
+++ /usr/lib/cgi-bin/wiki.pl    Fri May  4 10:25:32 2001
@@ -3219,6 +3229,9 @@
   $summary =~ s/[\r\n]//g;
   # Add a newline to the end of the string (if it doesn't have one)
   $string .= "\n"  if (!($string =~ /\n$/));
+  # Remove "\r"-s (0x0d) from the string
+  $string =~ s/\r//g;

   # Lock before getting old page to prevent races
   &RequestLock() or die(T('Could not get editing lock'));

Code similar to this has been added to the development version. --CliffordAdams

Page caching bug(s):

I think http://www.mnot.net/cache_docs/ is a good document on the issue.

I installed UseModWiki at our site, and run into this problem immediately. Since our users use maybe all the possible browsers ranging from lynx to Opera to IE to anything else,

I had to find a solution.

--- usemod092/wiki.pl   Sun Apr 22 00:44:10 2001

+++ wiki.cgi    Sun Apr 29 00:01:57 2001
@@ -973,6 +973,8 @@  sub GetHttpHeader {
   my $cookie;
+  my $now;
+  $now = gmtime;
   if (defined($SetCookie{'id'})) {
     $cookie = "$CookieName="
             . "rev&" . $SetCookie{'rev'}
@@ -981,12 +983,20 @@
     $cookie .= ";expires=Fri, 08-Sep-2010 19:48:23 GMT";
     if ($HttpCharset ne '') {
       return $q->header(-cookie=>$cookie,
+                        -pragma=>"no-cache",
+                        -cache_control=>"no-cache",
+                        -last_modified=>"$now",
+                        -expires=>"+10s",
                         -type=>"text/html; charset=$HttpCharset");
     return $q->header(-cookie=>$cookie);
   if ($HttpCharset ne '') {
-    return $q->header(-type=>"text/html; charset=$HttpCharset");
+    return $q->header(-type=>"text/html; charset=$HttpCharset",
+                      -pragma=>"no-cache",
+                      -cache_control=>"no-cache",
+                      -last_modified=>"$now",
+                      -expires=>"+10s");
   return $q->header();

This pretty much solved the issue for us. I hope it (or something like this) will be included in UseModWiki 0.93.

I'm looking at this issue. I'm considering writing my own code for the HTTP headers, possibly with the CGI.pm version available as an option. --CliffordAdams

Saving pages takes 15-30 seconds or more: [Option for 0.92]

If you experience this problem, please let me ([usemod@usemod.com]) know. One site solved the problem by disabling the hostname lookups when saving pages. (This means that authors IP addresses (like 123.211.122.xxx) will be shown instead of hosts like foo.bar.example.com.) I'm planning to make the lookup an optional feature for the next release. [It is optional in 0.92--see the $UseLookup setting.]--CliffordAdams

FreeLinks is too free: [Fixed in 0.92]

Due to an error in the 0.91 ValidId routine, almost anything is allowed as a free-link. This could allow users to create pages that don't match the FreeLinkPattern?. This is only a problem for wikis that allow free links.

I am considering making an early release of 0.92 mainly for this fix. If you want to fix it now, simply change the lines:

    if (!($id =~ m|$FreeLinkPattern|)) {
      return "Invalid Page $id";
    if (!($id =~ m|^$FreeLinkPattern$|)) {
      return "Invalid Page $id";

As usual, please feel free to email me at mailto:usemod@usemod.com if you have any problems or questions regarding this patch. --CliffordAdams

FreeLinks and action=links: [Fixed in 0.92]

In version 0.91 the action=links does not properly handle FreeLinks within within text. (They will be ignored, and subpage FreeLinks will be incorrectly matched as ordinary subpages.) The fix is simple, at line 2960, change the code:

    if ($FreeLinks) {

      s/\[\[$FreeLinkPattern\|[^\]]+\]\]/push(@links,&SpaceToLine($1)),' '/ge;
      s/\[\[$FreeLinkPattern\]\]/push(@links, &SpaceToLine($1)), ' '/ge;
    if ($FreeLinks) {
      my $fl = $FreeLinkPattern;
      $text =~ s/\[\[$fl\|[^\]]+\]\]/push(@links, &SpaceToLine($1)), ' '/ge;
      $text =~ s/\[\[$fl\]\]/push(@links, &SpaceToLine($1)), ' '/ge;

The above fix is in the 0.92 release. --CliffordAdams

UseIndex? bug:

[Note that the UseIndex? feature is now disabled in the default UseModWiki 0.91 configuration.]

Perhaps a bug, perhaps not. We have been fiddling with the basic usemod code at http://flow.ne.mediaone.net/statement in a preliminary fashion. At times some links will continue to have the ? even when they have been defined. The page is still created, and can be edited, but the pageidx is apparently not updated. If I turn the indexing off in the script it then works fine. So apparently the problem lies in the updating of the script itself, and it's not a caching problem as I first thought. Any ideas?

For what it's worth, I've encountered this issue over on FuseWiki? (http://www.meta-magic.com/cgi-bin/fusewiki) as well. It's running on Linux 2.2.16 and perl 5.005_03. (18-Apr-2001)

I'm beginning to suspect a subtle bug in the index file updating. Sigh. You can turn off the fast-index feature by setting "UseIndex?" to 0 in the configuration. I'm beginning to wonder if there is some kind of system-dependent bug here. I'll update this page if I find any more information. --CliffordAdams

I saw the above behaviour when I installed UseModWiki on my NT Workstation (using apache) but set the page dir to a network drive. (to be part of automated backups)

The script worked fine when the page dir was a local directory


I've looked closely at the code, but I have no idea why this would occur. For now, I suggest changing the $UseIndex? setting to 0. It is purely a performance optimization, and is probably not very useful until you have a few hundred pages. I will probably set the default value of $UseIndex? to 0 for the next release. --CliffordAdams

See also MeatBall:MeatballWikiBugs (which may have some duplication with the above list). Meatball uses UseModWiki, and some of that site's users report bugs on the Meatball wiki.

Unexpected Nested List Misbehavior

[The example below was mangled, and I'm not sure what it was originally.]

  1. Number 1

  1. Number 2

  1. Number 3

  1. number 4

Caused by closing </OL> before <UL>. I think closing tag should kick in only if there is a blank line or next list item goes back to higher level (terminate sublist which is living in a LI element).

Also --

  1. Number 1

  1. Number 2

    1. bullet subitem

    1. second bullet subitem

  1. Number 3

  1. number 4

Nesting works, but it would be better with a (selectable option) default letter enumeration when sublisted in a numbered list. -- jerry

Hmmm... I'll have to think about these. One possibility I'm seriously considering is allowing users to simply use UL, OL, and LI tags, possibly even with options. This would allow users to create arbitrary lists relatively easily. --CliffordAdams

The following patch to 0.91 appears to make the nested listing work better. I'm somewhat unsure about the purpose of the code that I excised, however. I personally don't think using UL, OL, and LI tags is a good idea; you end up getting closer and closer to just writing HTML. --BobShowalter

<     if ($depth > 0) {
>     if ($depth > 0 && @htmlStack == $depth && $htmlStack[$#htmlStack] ne $code) {
>         $pageHtml .= "</" . pop(@htmlStack) . ">\n";
>     }
<       if (@htmlStack) {  # Non-empty stack
<         $oldCode = pop(@htmlStack);
<         if ($oldCode ne $code) {
<           $pageHtml .= "</$oldCode><$code>\n";
<         }
<         push(@htmlStack, $code);
<       }
<     }

It looks like this patch is partially implemented in 0.92. I'm not sure if the following bug is related, but sometimes when using a DefinitionList? with a following ---- line the line get's indented. It leads to confusing visual structure. Check out the front page of http://robowiki.net/ for an example of this. -- PEZ

I'm having some weird problem, maybe somebody knows what it is...

I've installed v0.91 of usemod wiki. No problems. But when I try to use preferences, from withing my Opera 5.02 browser, I can't save my preferences (userid 111 is given, no cookie send ). Using IE 5, I'm having no problem. However, if I try to save the preferences at UseModWiki with my Opera browser, I also don't have a problem.....

Anybody? HansDonner

I don't know much about Opera. One question--are you using the same hostname for both browsers? Does the hostname have at least two dots (like www.usemod.com), not two dots (like usemod.com)? There are sometimes problems with short names and cookies. Does Opera receive the cookie? (You might be able to check a cookie folder. If Opera has a "warn/ask about cookies" option, you might try enabling it to see if Opera sees the cookie.

If you changed the $CookieName?, try changing it back to just "Wiki", and see if it works. --CliffordAdams

Answer to your Question: Same host is used (both browser are even on the same laptop). the hostname has 2 dots (http://www.finiks.com/spel/? - restricted access). I can see Opera receive a cookie on entering the preferences, but when saving I don't see it anymore... About the cookie cache.. The cookies are nicely stored in cookie.dat, so that won't help.. I see if I can find out more about cookie behaviour, regarding Opera and CGI.PM.. -- HansDonner, Mar 1 (AM)

I've been playing with CGI's cookie capabilities... It seems to work OK with Opera... I'll have a look how UseModWiki works with it cookies.. -- HansDonner, Mar 1 (PM)

Is this even a bug?

There appears to be no discernable purpose for the typical user to make a password. I had assumed that by setting a password for my user name (JimboWales), I would prevent other people from passing themselves off as me on the RecentChanges page. But it doesn't seem to work that way. I could pretend to be CliffordAdams, even if he set a password.

It strikes me that having passwords for user accounts, simply as a way of "signing" what we are doing, is a good thing. If you don't care if people impersonate you, you can leave your password blank, or announce it on your namesake page. But if you do care, you should be able to at least make sure that recent changes (and diffs) don't claim that you did something, when you didn't.

Is this a bug?

It's not a bug: it is not designed to work this way. The setting of the password is now used to check if you have edit-right (if the config is set to restrict editing) and for logging in later with the same preferences... -- HansDonner

I understand what you are saying, but why shouldn't I be able to at least protect my identity? It seems annoying for someone to login as me and make changes. Why even have a user name at all? Preferences could be handled with a random cookie. --JimboWales

I consider this to be a documentation bug. (1/2 :-) Really, the whole login system is a mess. At this time, the user name is simply some descriptive text. Your "identity" in UseModWiki is the user-id number (like 1407), which is protected by a "randkey" (random key) number in the cookie. The regular password is only useful to allow you to share the user-id cookie between browsers or systems. (The administrative password is only used to check if the user has editor or administrator-level access. This has also been confusing to several users.)

Unlike most online systems, I do not want to force users to use the login system. I want people to be able to contribute without needing a user name or password. I was concerned about the possibility of impersonation, however, so the RecentChanges and history list also include the user-id number and hostname/IP address. (I made the user-id number and hostname use the link title feature--just move the mouse over the user-name link and you should see the id and host name appear (at least in MSIE and Netscape).) If someone tried to impersonate another, they could be caught (and possibly banned from the wiki if they continue).

In the near future I will probably move the login/password information to a separate page away from the preferences (probably with a link from the Preferences page). Later I hope to enhance the login features greatly, and possibly allow restricted usernames (only usable by one user-id) as an option. --CliffordAdams (id 1116 :-)

This is a legal usenet group:

for which the reference doesn't work as expected.

As a quick hack I did

sub SplitUrlPunct {
  my ($url) = @_;
  my ($punct);

  if ($url =~ s/\"\"$//) {
    return ($url, "");
  $punct = "";
  if($url =~ /^news:/) {
     ($punct) = ($url =~ /([^\+a-zA-Z0-9\/\xc0-\xff]+)$/);
     $url =~ s/([^\+a-zA-Z0-9\/\xc0-\xff]+)$//;
  } else {
     ($punct) = ($url =~ /([^a-zA-Z0-9\/\xc0-\xff]+)$/);
     $url =~ s/([^a-zA-Z0-9\/\xc0-\xff]+)$//;
  return ($url, $punct);

just to verify and located the problem. Seems to work. Don't know which url protocols allow a '+' and which not. -- HelmutLeitner

The problem is that the + characters are at the end of the URL--the + character is legal in a URL. (It is often interpreted as a space character, however.) I'm not certain this case is worth a specific change in the code when there are several ways to enter the URL:

Are there any other common cases of punctuation (besides /) at the end of URLs? --CliffordAdams

Does one of these patches fix something like us/Democrat? (well, the ? link after it) pointing to the edit page for the /Democrat? SubPage of the page it's on instead of to the edit page for us/Democrat?

No, because it isn't a bug. :-)

If you want to point to the subpage of a different page, and that page is not an ordinary WikiName (starting with a capital letter, then at least one lowercase letter, then at least one uppercase letter), then you'll have to use the Free Links form to link to that page (like [[us/Democrat]]). --CliffordAdams

errors in log during searches: (fixed in 0.92)

The problem is that this line...

   2114       while (<$PageDir/$dir/*.db $PageDir/$dir/*/*.db>) {

causes warning messages to be written if the specific directory doesn't exist yet. It doesn't crash the Wiki code, but it does case a lot of screen poop.

My fix was to patch the GenerateAllPagesList subroutine to check for the existance of each directory first by adding my lines 2114 and 2121 below.

   2109 sub GenerateAllPagesList {
   2110   my (@pages, @dirs, $id, $dir);
   2112   @dirs = qw(A B C D E F G H I J K L M N O P Q R S T U V W X Y Z other);
   2113   foreach $dir (@dirs) {
   2114     if (-e "$PageDir/$dir") {
   2115       while (<$PageDir/$dir/*.db $PageDir/$dir/*/*.db>) {
   2116         s|^$PageDir/||;
   2117         m|^[^/]+/(\S*).db|;
   2118         $id = $1;
   2119         push(@pages, $id);
   2120       }
   2121     }
   2122   }
   2123   return sort(@pages);
   2124 }

TimHolt?, http://www.NACSE.org

The 0.92 release has a greatly improved version which avoids the built-in glob function. It should avoid the error messages and be significantly faster. --CliffordAdams

Minor glitches with v0.91 link list (action=links)

You can add FreeLinks with leading or trailing blanks like:

    [[ UseMod ]]

The link works properly (here it is: UseMod), but is n

Caching and locked pages

When I lock some pages, and use the admin password to edit them, the cache will cache the HTML version of the page that includes the 'edit this page' text - similarly, when I view the page as admin, if the read only page was cached I don't get the 'edit this page' link. This second scenario is not a problem though, as I can always do action=edit.

Not quite sure how to fix this mind ... would involve some sort of flushing of the cache between admin/non-admin users for locked pages ...? Alternatively, maybe it should not cache pages when an admin user is editing a locked page - ie only cache the 'read only' version, as admin users can always use action=edit.


Right now there are a few problems (like the above) with the cached HTML versions. I would generally advise users to not enable caching unless they need to. --CliffordAdams

I get this error message:

Could not get editing lock at /....//wiki.pl line 3225.

I'm the one and only user of this wiki because it's new and there is no link to the wiki. I can't edit the page because I get this message. I have tried maintain, but it don't help. --MDE

Try action=unlock and see if that helps. (The unlock action tries a normal unlock, then tries a forced unlock if the normal one doesn't work.)

For future releases I plan to make the ordinary editing code try to force-clear the lock. (This might be an option that sites could turn off, but its useful for most sites.) --CliffordAdams

My host service has made some (unspecified) security enhancements and I am now getting this error. Is there a file containing the locks that needs a special permission set? - BobWaller

I'm also getting this error and I'd also wonder where the locks are kept so I can clear them manually. - Dave

The locks are kept in the $TempDir?, which is (unless you changed it in the config) the "temp" directory of your wiki. You can remove all the files in the "temp" directory to clear all locks. --CliffordAdams

Internet Explorer 5.5 SP1 woes

IE5.5 has problems dealing with UseModWiki version 0.92 (April 21, 2001). When editing the page, clicking "Save" will wait for ever. The page is saved in the background: I can see the changes by opening a new browser window. Strangely enough, the clicking "Preview" works. Furthermore, often links have to clicked twice... (MeatBall:InternetExplorerMustDie?) When testing the same pages with Netscape 4.08, no such problems. Any ideas? --MeatBall:AlexSchroeder

Are you using the same system for both IE and Netscape? One thing to try is turning off the $UseLookup option. (DNS lookup problems are usually the cause of long save delays.) --CliffordAdams

We have Netscape and IE5.5 running on the same machine. The problem occurs on UseModWiki (!) as well as on the one we are trying to set up [2]. The one we are trying to setup has $UseLookup = 0 as well as $UseCache = 0, $UseDiff = 0, $RunCGI = 1, $EmailNotify = 0, $UseDiffLog = 0, $UseIndex = 0, $SiteBase = "", and $FullUrl = "http://www.schutzenhaus.com/cgi-bin/wiki.pl" (just to name a few interesting options). Anyway, lookup cannot be a problem as it works when we use Netscape and it doesn't work when we use IE5.5... -- as

One more thing to try is changing the $RedirType setting from 1 (the default) to 2 or 3. It is possible that there is some problem handling the HTTP redirection request. This is especially likely if your slow edits update the RecentChanges page (since almost nothing is done after that point). I have tried your site with MSIE 5.0 and it worked properly--maybe you could upgrade? :-) --CliffordAdams

Don't allways expand ----

When the four dashes are preceded by whitespace, they should not expand into an HR tag. Example:

    Column 1   Column 2
Stuff Stuff

Should look like this:

    Column 1   Column 2
    Stuff      Stuff

Here is an untested idea:

    if ($ThinLine) {
      s/----+/<hr noshade size=1>/g;
      s/====+/<hr noshade size=2>/g;
    } else {

Should turn into:

    if ($ThinLine) {
      s/^----+/<hr noshade size=1>/g;
      s/^====+/<hr noshade size=2>/g;
    } else {

-- MeatBall:AlexSchroeder

I'm considering this, although I don't want to add many more "start of line"-special rules. One can use the pre tag as a workaround for now. --CliffordAdams

show all links page takes subpages out of context

On the [Show all links page], subpage links that are not fully qualified are shown as unsatisfied links.

For example, look up UseModWiki/Bugs in the [Show all links page] and compare the /Bugs and /SubPage? entries, which look identical, even though one is a valid subpage and the other is yet to be defined.


I'll have to look at this further--the non-fully-qualified subpage stuff is a bit tricky sometimes. --CliffordAdams

That's not all, it also will take link discriptions out of context. For example in [DontIncludeMe]. The link page results will show "DontIncludeMe?".

Yep--that looks like a bug--I'll need to strip the descriptions out of described links before the main processing. --CliffordAdams

action=editlinks fails on oldrclog

I was experimenting with action=editlinks to rename a page, and while it did succeed at renaming the page, I got an error; it said it couldn't find "oldrclog". I looked at the data directory, and while there was no "oldrclog", there was an "rclog.old". It develops that wiki.pl sometimes uses the config file variable $RcOldFile? to determine the name of the old rclog (by default, it's set to "oldrclog"), but creates the old log file by appending ".old" to the name of the $RcFile?.

The workaround is to set $RcOldFile? to "$DataDir/rclog.old" in your config file. (nope--see below)

-- WillDuquette

That workaround is wrong. Looking at the code the purpose of the oldrclog is to keep deep history, while the normal rclog would just have the recent past (say a few months) which will cover most people's queries. The recent changes action actually looks up the oldrclog if the requested from date is older than what's in rclog. Moving data from rclog to oldrclog needs to be done manually by the admin. Separate from this are the *.old files that are created by the editlinks command, I'm not sure what the purpose is. Anyway, the bug is that editlinks is expecting oldrclog to exist even though the admin may not have created it.

That's correct. I didn't see that bug since I did most of my testing on larger wiki databases which have the "oldrclog" file already. This is already fixed for the next release. The .old files are simply copies of the rc files before the edit occurred. They are there in case the script crashes or dies before it writes out the new files (which could happen if the system crashes or you run into a disk-quota-limit). --CliffordAdams

I recently upgraded from 0.90 (I think) with some SpeedyCGI patches to 0.92. Now I've got a problem with some free-link pages. For instance, [[Intro and Tour]] is stored on my system with the filename Intro_and_Tour.db. The links to this page no longer work. I experimentally created a new free link, and found that words starting with lowercase letters get capitalized, e.g. [[This is a Page]] generated a data file named This_Is_A_Page.db.

Eventually, I noticed the FreeUpper configuration variable, which must be new for 0.92 and defaults to 1. I set it to zero, then figured out how to use the new AdminFeatures to rename all the offending files, then set FreeUpper back to 1. The only bad thing about this (other than having to deal with it in the first place) is that I really just wanted to rename the pages, but the admin function also edits all the links. Oh well. Luckily, I only had a few pages that were affected, and I was able to pick them out by searching page index output.

My apologies for the difficult upgrade--I didn't do enough thinking about sites that were already using free-link pages. (This has also been an issue for the WikiPedia site.) If anyone else still has these problems, I have written some scripts (for the Wikipedia) that might be helpful. --CliffordAdams

The upshot of this, I guess, is that a method is needed to rename pages without editing links, in order to deal with this sort of upgrade issue.

-- DanMuller

Actually, there is a way to rename without editing, presuming that you're using the "editlinks" page. On the bottom of that page there is a checkbox "Substitute text for rename" (which is checked by default). If you uncheck that box, the page will be renamed without editing the links. (You will probably want to leave the "edit RecentChanges" checkbox checked.) --CliffordAdams

StoreHref? not cooking with enough gas

You are only storing the inner part of the open tag as a cookie. Instead, you should store the entire string, ala

sub StoreHref {
  my ($anchor, $text) = @_;

  return &StoreRaw("<a $anchor>$text</a>");

Otherwise, you will eat it with <a href="http://www.example.com">LinkPattern</a>.

Thanks for the fix--it will go in the next release. --CliffordAdams

file://Images do not display as images

file://someplace/.../foo.jpg does not display as an <image/> but instead appears as a linked URL (if you have $NetworkFile enabled). Replace sub UrlLink? with the code below.

sub ImageOrNormalUrl {
  my ($rawname,$useImage) = @_;
  my ($name, $punct, $protocolRegex);
  ($name, $punct) = &SplitUrlPunct($rawname);

  # Restricted image URLs so that mailto:foo@bar.gif is not an image
  $protocolRegex = 'http:|https:|ftp:';
  $protocolRegex .= '|file:' if $NetworkFile;

  if ($useImage && ($name =~ /^($protocolRegex).+\.$ImageExtensions$/)) {
    return ("<img src=\"$name\">", $punct);
  return ("<a href=\"$name\">$name</a>", $punct);

sub UrlLink {
  my ($rawname, $useImage) = @_;

  if ($NetworkFile && $rawname =~ m|^file:|) {
    # Only do remote file:// links. No file:///c|/windows.
    return &ImageOrNormalUrl($rawname,$useImage) if $rawname =~ m|^file://[^/]|;
    return $rawname;
  return &ImageOrNormalUrl($rawname,$useImage);

I'll look at this a little more, but I think this code will be part of the next release. --CliffordAdams

Lock files

I've just installed UseModWiki 0.92, and played around a little with things in the System page.

One action, I think it was PageLock?, created a lock file in wikidb/page/other/1001.lock, but not before I manually created the "other" directory. Unless I did that, there was an error message.

Normally one would create pages before locking them, so the directory would always exist before the lock was created. Still, I should probably check for this case.

Also, I found no action to remove the lock. It worked for me to remove the files 1001.lock and wikidb/noedit manually. Is there any action to remove the lock, that can be used from a browser? --HelgeStenstrom?--

Yes, you can add "&set=0" to the URL, like UseMod:action=pagelock&id=MyPage&set=0 (you can also use set=0 for the global wiki lock). --CliffordAdams

TeX is a valid Wiki Name

This should not be a valid Wiki name because it is a single word. Even interpreted as two words, it would be Te-X, and one-letter words such as X are not supposed to be allowed in valid Wiki names, either. This is probably a one-line fix.

So is SSLCertificateFile?.

This is not a bug. I allow 1-letter "words" in wikinames. (Part of the reason is to avoid the ugly workarounds like Wiki:CeeLanguage.) One can use the "nowiki" tag to display such words without linking. --CliffordAdams

UseLookup = 0 does not detect logins (old Perl version?)

If setting UseLookup off with multi-Wikis on one site. All sites will lose the ablity to detect logins. It assumes new logins are the same person as last login.

using UseModWiki Version 0.92 perl version 5.005_03 under freeBSD(Oh never mind, old version of perl :-( ) --SuperLinux

Global Edit Lock Does Not Prevent Creation of New Pages

This is really funny because it says "Describe the new page here." and "This page is read-only" at the same time.

Further investigation reveals that the page may not actually be created until somebody edits and saves it. It displays the "Describe the new page here" message even though it has not been created. Maybe this isn't a bug.

Reverse Links Are Not Strict

If you have a page called WikiName and a page called OtherWikiName?, and you click the title of WikiName, you'll also dredge up pages that refer to OtherWikiName? even if they do not refer to WikiName.

UseModWiki pages fail HTML validation

Some of the problems are specific to the configuration of this site (for example DOCTYPE doesn't specify correct HTML version), while others are bugs in the code (for example using "&" in query links instead of "&amp;"... hmm why do I have to escape that?). There is a useful tool at http://validator.w3.org/.

file://home/myself/file makes faulty link

UseMod 0.92:

At least on Netscape 4.7 on Unix, the format is file:/path, not file://path. But UseMod needs two slashes to the link to be recognized as a NetworkFile link. So: Wiki text file://path should produce html code file:/path for the link to be usable.

You are wrong. According to RFC 1738, the format of a file link is file://host/path. The host part can be localhost or the empty string. So, file:///usr/local/doc/mydoc.html is a valid file URI, bot UseModWiki does not accept it as one. file:/path is not a valid URI. --LarsChristensen?

Create non-linkable page

Bug or obscure feature?

If you enter the url by hand, with

wiki allows creation of the page, which is then unlinkable with standard wiki links as it has only one capital letter.

This is not really a problem, and will affect only users like myself who try to be too clever by half. Maybe it's a quirk rather than a bug. Certainly don't spend more than a few minutes on it. --RiVer

The page is linkable if when you specify the link from somewhere else, you enclose the name around double brackets, like [[Sandbox]]. The Wiki will then interpret it as the name of a page and accomplish what you wanted. -- Angelique

Not sure if this counts as a bug. My host www.bluegenesis.com didn't allow the script to be run because it had a 'bareword' HTML at line 696 (return statement in GetRcHtml). I changed all the references to $lmth and it fixed the 'bug'. Is this a common security measure, or is it just my host? -- Wiki:RobHarwood

Some minor bugs related to initial setup before any pages are added:

i tried to save a bug notice twice here, but it wouldn't take ?? instead, it can be found now [at the end of this page] DeadLink

Do you want to say that you can not save changes here for any reason? is that? (if it's that, there is anti spam for that reason, i'm not sure, but for an amount of links per change (for example three links added in the same change, or so) you can not save the page. --JuanmaMP

UseModWiki | UseModWiki | RecentChanges | Preferences
Edit text of this page | View other revisions | Search MetaWiki
Last edited July 14, 2009 1:02 am by JuanmaMP (diff)