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
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?
Fix:
![[Home]](/wiki.gif)
--- 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'));
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.
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";
}
...to:
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
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;
}
to:
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
[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?
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
--StevenPearson?
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.]
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 --
Nesting works, but it would be better with a (selectable option) default letter enumeration when sublisted in a numbered list. -- jerry
1159c1159,1161
< if ($depth > 0) {
---
> if ($depth > 0 && @htmlStack == $depth && $htmlStack[$#htmlStack] ne $code) {
> $pageHtml .= "</" . pop(@htmlStack) . ">\n";
> }
1161,1167d1162
< if (@htmlStack) { # Non-empty stack
< $oldCode = pop(@htmlStack);
< if ($oldCode ne $code) {
< $pageHtml .= "</$oldCode><$code>\n";
< }
< push(@htmlStack, $code);
< }
1172d1166
< }
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
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)
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?
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
news:comp.lang.c++"" news:comp.lang.c++
[news:comp.lang.c++] [1]
[news:comp.lang.c++ comp.lang.c++] [comp.lang.c++]
news:comp.lang.c%2B%2B news:comp.lang.c%2B%2B
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?
[[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);
2111
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
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
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.
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
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
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
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 {
s/----+/<hr>/g;
}
Should turn into:
if ($ThinLine) {
s/^----+/<hr noshade size=1>/g;
s/^====+/<hr noshade size=2>/g;
} else {
s/^----+/<hr>/g;
}
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
Yep--that looks like a bug--I'll need to strip the descriptions out of described links before the main processing. --CliffordAdams
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
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.
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
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>.
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'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.
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
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?.
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
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.
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.
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 "&"... hmm why do I have to escape that?). There is a useful tool at http://validator.w3.org/.
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.
Bug or obscure feature?
If you enter the url by hand, with
?action=edit&id=Sandboxwiki 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
Some minor bugs related to initial setup before any pages are added: