Menu
▾
▴
sfwiki-devel
|
From: Todd L. M. <tm...@ha...> - 2001-03-12 05:54:26
|
I think there are only two things left to do before 'releasing' (official opening wiki.jos.org) this version of sfWiki. First, some high-speed editing protection needs to be added. Second, when the wiki.jos.org site is updated, I need to add logic to put the user stuff on the menu, change colors when the user is logged in (or out, whatever :)), and indicate who the user is logged in as. AFAIK, that is the entire list. I just requested a beat-down, so now's your chance to execute your nit-picking skills. -jQuinn |
|
From: Todd L. M. <tm...@ha...> - 2001-03-12 05:58:30
|
> AFAIK, that is the entire list. I just requested a beat-down, so > now's your chance to execute your nit-picking skills. Actually, I just realized: the WikiTopic tree about the Wiki (instructions, et al) needs to imported into wiki.jos.org before it's officially opened, and that these topics should also go into the official release and documentation manager. -_Quinn |
|
From: Iain S. <iai...@ya...> - 2001-03-12 21:35:45
|
At 01:00 AM 3/12/2001 -0500, Todd L. Miller wrote: > > AFAIK, that is the entire list. I just requested a beat-down, so > > now's your chance to execute your nit-picking skills. > > Actually, I just realized: the WikiTopic tree about the Wiki >(instructions, et al) needs to imported into wiki.jos.org before it's >officially opened, and that these topics should also go into the official >release and documentation manager. Agreed. You may also want to exclude the Development and Support parts of the navigation bar if there are not going to be links there. As far as layout goes, I'd probably recommend that we settle on a common header. I of course like mine better! :) At least I think we should include the JOS logo in the header. I think the three links in the very top of the header should be the same except we substitute wiki with home page for yours. Wiki Search should probably move down to the header next to the "topic go to" so its like: Topic: [box] or <a>Search</a> Otherwise, looks good. -iain |
|
From: Todd L. M. <tm...@ha...> - 2001-03-12 23:15:53
|
I should stick in this the wiki so could update it there, but I'm probably going to be cleaning the database out as part of the deployment testing, so... do (fix) for this (#3) release * put help -- using the Wiki, the WikiFormatting, etc -- into the wiki; distribute in tarballs and CVS as .txt files, and insert instructions about using import.php3 to get them into the wiki. * establish a cron job/script for doing regular database backups. * implement defense against "spider bombs" editing pages * list the last editor of the page on info.php3 do (fix) for the next (#4) release/ * offsite backup script; an 'export.php3' script would be nice, but a script doing MySQL database dumps would be OK also. * list of orphan pages page (orphans.php; integrate with web admin in wishlist...) wishlist/ * diffs between revisions. (Leverage SourceForge's cvsweb.cgi?) * delete wiki pages (part of web-based admin?) * web-based (user) admin * common (XML) format for wiki metadata; standard for wiki bookmarks? investigate/ * TWiki-style tree structure to the Wiki for autogenerated directory pages * url-rewriting implementation for less implementation-dependent bookmarking of wiki pages -_Quinn |
|
From: Iain S. <iai...@ya...> - 2001-03-15 17:59:10
|
At 06:18 PM 3/12/2001 -0500, Todd L. Miller wrote: >I should stick in this the wiki so could update it there, but I'm probably >going to be cleaning the database out as part of the deployment testing, >so... Excellent. An option may be to try using their new tracker system and put this in as bugs/feature requests. I'm of the opinion that the wiki may be better if the list remains minimal and the # of bugs is small. With more though, it may be easier to manage in the sf tracker. >do (fix) for this (#3) release > >* put help -- using the Wiki, the WikiFormatting, etc -- into the wiki; > distribute in tarballs and CVS as .txt files, and insert > instructions about using import.php3 to get them into the wiki. > >* establish a cron job/script for doing regular database backups. > >* implement defense against "spider bombs" editing pages Seems reasonable. >* list the last editor of the page on info.php3 Probably can be moved to v4 unless its easy to do. I don't think its necessary for this version. >do (fix) for the next (#4) release/ > >* offsite backup script; an 'export.php3' script would be nice, but a > script doing MySQL database dumps would be OK also. > >* list of orphan pages page (orphans.php; integrate with web admin in > wishlist...) Yes. Sounds very good. >wishlist/ > >* diffs between revisions. (Leverage SourceForge's cvsweb.cgi?) > >* delete wiki pages (part of web-based admin?) Perhaps just delete pages that have no text in them? That way users delete pages by simply clearing the text? I believe the current behavior is just to store a completely blank page which seems weird/wrong anyhow. >* web-based (user) admin > >* common (XML) format for wiki metadata; standard for wiki bookmarks? Perhaps the above should be two separate issues. I can imagine different usages for both. I'll take this opportunity to add: Export static "snapshot" of wiki. This would be a zip or tar.gz of static html files representing the wiki (with working relative links and the "dynamic" aspects disabled/removed). A static shot would allow people with expensive connections (europe) or mobile people (laptop) to download all the wiki content at once and have it available for browsing. extensive wiki statistics. Pages, edits per month, # of members, size (MB), total outgoing links, total interwiki links, etc etc etc. Most of its probably just foo-foo statistics but should be relatively easy to gather when doing one of your backups/snapshots since you'll be touching all the pages anyhow. I'd be interested to see if we could get some useful numbers that correlate to the liveliness, freshness, connectedness, value or "knowledge content" of a wiki. Mostly just something I'm interested in and has no immediate practical application that I can see. (that's why its on the wish list). >investigate/ > >* TWiki-style tree structure to the Wiki for autogenerated directory pages > >* url-rewriting implementation for less implementation-dependent > bookmarking of wiki pages File uploads? Image uploads at least? It's a common request although I think fraught with peril. Link maps/site maps/graphical representations of the wiki. I think navigation and finding info in the wiki is its greatest weakness so providing as many alternative ways to get around in it will probably add significant value to the wiki. -iain |
|
From: Todd L. M. <tm...@ha...> - 2001-03-16 23:16:32
|
> Excellent. An option may be to try using their new tracker system and put > this in as bugs/feature requests. I'm of the opinion that the wiki may be > better if the list remains minimal and the # of bugs is small. With more > though, it may be easier to manage in the sf tracker. I stuck them all in as feature requests. We can move them to bugs later, if necessary. I decide to stick them in the sf tracker to inflate our statistics :) > Perhaps just delete pages that have no text in them? That way users delete > pages by simply clearing the text? I believe the current behavior is just > to store a completely blank page which seems weird/wrong anyhow. Good point. I added this, and will think about if for a while. > extensive wiki statistics. Pages, edits per month, # of members, size > (MB), total outgoing links, total interwiki links, etc etc etc. Most of > its probably just foo-foo statistics but should be relatively easy to > gather when doing one of your backups/snapshots since you'll be touching > all the pages anyhow. I'd be interested to see if we could get some useful > numbers that correlate to the liveliness, freshness, connectedness, value > or "knowledge content" of a wiki. Mostly just something I'm interested in > and has no immediate practical application that I can see. (that's why its > on the wish list). Well, it shouldn't be too hard to add. We'll see how my voluminous spare time slices. -_Quinn |
|
From: Iain S. <iai...@ya...> - 2001-03-19 22:04:54
|
At 06:19 PM 3/16/2001 -0500, Todd L. Miller wrote: > > Excellent. An option may be to try using their new tracker system and put > > this in as bugs/feature requests. I'm of the opinion that the wiki may be > > better if the list remains minimal and the # of bugs is small. With more > > though, it may be easier to manage in the sf tracker. > > I stuck them all in as feature requests. We can move them to bugs >later, if necessary. I decide to stick them in the sf tracker to inflate >our statistics :) :) Sounds good. And its not inflating the stats! You're reflecting the true traffic and work of the project! :) Now if you start putting your grocery lists and tv watching schedule in there, then we'll start talking about stuffing the stats... :) > > extensive wiki statistics. Pages, edits per month, # of members, size > > Well, it shouldn't be too hard to add. We'll see how my >voluminous spare time slices. Thanks. It really is on the "boy wouldn't it be neat" side of things so I wouldn't waste too many slices on it! -iain |
|
From: Robert F. <ro...@27...> - 2001-03-15 21:23:30
|
Hi Todd I just got a evil on the sfwiki trying to break it, and it looks like I did. :( <quote url="http://sfwiki.sourceforge.net/edit.php?topic=+%3C%2Ftd%3E+%3C%2Ftd%3E+%3C%2Ftd%3E+%25%3E%3C%3C%3F%3F%25&web=Main"> Thiss sfWiki's database has returned an error, " Got error 'repetition-operator operand invalid' from regexp (1139)", and mail has been sent to the administrator. Warning: Cannot add header information - headers already sent by (output started at /home/groups/sfwiki/sfWiki/portal/htdocs/wiki/query_failed.ihtml:3) in /home/groups/sfwiki/sfWiki/htdocs/edit.php on line 41 </quote> It looks like we need to limit the characters that can be in a wikiname and any user input, limiting it to "a-zA-Z -_." would be a good start. I'm sure with the right type of quoting someone could get the database to do something bad. It's also possible to break a page by writing special characters "?%><", so maybe we should quote anything that's not safe or a correct html tag? Robert Fitzsimons ro...@27... On Mon, Mar 12, 2001 at 12:56:44AM -0500, Todd L. Miller wrote: > I think there are only two things left to do before 'releasing' > (official opening wiki.jos.org) this version of sfWiki. First, some > high-speed editing protection needs to be added. Second, when the > wiki.jos.org site is updated, I need to add logic to put the user stuff on > the menu, change colors when the user is logged in (or out, whatever :)), > and indicate who the user is logged in as. > > AFAIK, that is the entire list. I just requested a beat-down, so > now's your chance to execute your nit-picking skills. > > -jQuinn > > > _______________________________________________ > sfWiki-devel mailing list > sfW...@li... > http://lists.sourceforge.net/lists/listinfo/sfwiki-devel |
|
From: Todd L. M. <tm...@ha...> - 2001-03-16 23:38:29
|
> It looks like we need to limit the characters that can be in a wikiname > and any user input, limiting it to "a-zA-Z -_." would be a good start. > I'm sure with the right type of quoting someone could get the database > to do something bad. > > It's also possible to break a page by writing special characters > "?%><", so maybe we should quote anything that's not safe or a correct > html tag? OK, I can't even get edit.php to show up using the URL you posted, for some reason, though just chopping off the stuff after `topic=' makes it work fine. WikiNames are limited to alphabetical and numerical characters, but I do need to filter the topic and web (etc) variables to make sure they're OK, especially before passing them to the database. I thought I had already quoted out unrecognized HTML tags, but I'll check again and make sure, and take a look at % and ? as well. Thanks for your help, Robert. You find anything else worth mentioning? -_Quinn |
|
From: Todd L. M. <tm...@ha...> - 2001-03-20 07:45:08
|
Well, I /think/ I got the trapping code right. Anyway, I'd like you to go ahead and try and nuke it; see how I need to tighten up the filters. Also, I included a draft of Wiki documentation; feel free to add to it, I'll incorporate the changes into the next draft. -_Quinn |
Thanks for helping keep SourceForge clean.
X