Menu
▾
▴
sfwiki-devel
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(36) |
Jun
(5) |
Jul
(5) |
Aug
|
Sep
(6) |
Oct
|
Nov
(20) |
Dec
(12) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(7) |
Feb
(5) |
Mar
(25) |
Apr
(18) |
May
(2) |
Jun
(8) |
Jul
(2) |
Aug
(2) |
Sep
|
Oct
|
Nov
(3) |
Dec
(1) |
| 2002 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2003 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
(2) |
Jun
(5) |
Jul
(3) |
Aug
(9) |
Sep
|
Oct
(1) |
Nov
(5) |
Dec
|
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Iain S. <iai...@ya...> - 2001-04-02 20:06:43
|
Sorry. I was sick and offline this weekend! Feelin better now though. At 08:34 PM 3/30/2001 -0500, Todd L. Miller wrote: > Iain, I just realized that by putting the topic box / search link >in the third bar down, you're preventing me from using that space for the >'am I logged in or not' links. Also, the width of the menu bar to the >right means we waste a lot of space for longer articles. Furthermore, >'hot spots in the wiki' doesn't make sense if one's already in the wiki, >so I changed it to a link to the Wiki WebHome. > > So. Should I just drop the browse bar entirely, since all of its >functions, except for the link to the <webname>WebHome (and since we don't >seem to be using webs very much) are duplicated elsewhere, and replace it >with the user links? > > The other thing: with the big header and footer and sidebar, do >you think that the amount of orange and yellow is getting a bit >overwhelming, especially on short pages? Maybe restructing the sidebar >(more vertical, one entry/line) would be helpful, or maybe it should be >done in a different color scheme? (Like the tables?) Yes. I've been looking around and doing some sketches (that's about all I could do this weekend since my body hurt too much to sit at a computer). I want to do the following: One simple (and much smaller) header. The header will have the logo, and a simple bar with one line of major categories, and a second line with sub-categories for them. The wiki will be a subcategory of the documentation main category. So, for the entire wiki, you will use one, static JOS header (that ties the wiki into the rest of the jos site). I'll get the header to you as soon as I have the time to make it. In the meantime, you can just assume there is a standard, JOS header at the top as a single table that you don't have to change anywhere in the wiki. I think the best for the wiki, is to add another "bar" under the standard header that contains the wiki search, "goto topic", and login links. Finally, under that bar, I would add another horizontal bar that contains say 5 main category links or something like that. Or maybe links to each main web, WebHome (listed as the webs themselves). We do have crosslinking between webs right (one WikiName in one web, will autolink when in another web)? So a page in "intro" web to JosKernel will autolink to the actual page in the "dev" web if it exists. Or is the behavior otherwise? And what happens when mulitple pages in multiple webs have the same name? If web crosslinking works, then we should be able to use the webs to help organize content and reduce the need for the navigation bar. The reason the nav bar was added in the first place was it was too hard to move around the wiki so if we can make the wiki easier to navigate, then we won't need it. So, finally, I think it may be best to simply eliminate the left navigation bar, and put that information in the main webhome for each web. I think it may be also possible to move the links at the bottom of the page (the footer links) up to the top and make a single, compact "control panel bar" as that top, wiki bar. Then the bottom only contains the copyright and the sourceforge logo. If you want, I can mock up what I have in mind and send it to you. > Anyway, wiki.jos.org is now running the latest sfWiki code out of >the CVS, which means it should be hunky-dory, except that it can be >spider-bombed. Iain, I can't find the link I seem to remember you >forwarding me about how to take care of that. Could you send it again? Sorry. I can't seem to locate it. I guess you'll just have to start looking at sourceforge.net/projects/twiki and browse around. It was actually the cron job that ward cunningham uses at the original c2 wiki to prevent this problem (if that helps the search). It may be OK to simple put up a decent robots.txt file and monitor what goes on. Since your wiki is database backed (rather than the old file-based wiki) and searches aren't huge cpu drains like it was on the old jos wiki we may not have the same problems. I imagine that if a spider starts wacking on the sourceforge machines, sourceforge itself may have automatic defenses (preventing a single address to request pages at too fast a rate). To stop my babbling, if you can find the spider bomb prevention script, then great. Otherwise, I think we can go with the system, and develop our own if the need arises. If I recall, his cron job was simply every X minutes, check the web logs for too many requests from the same address, if there are, then block that address from requests for x hours. I'm not a unix guru but if you are or can find one, I bet they could write that script in a minute or two. -iain |
|
From: Iain S. <iai...@ya...> - 2001-04-02 20:05:12
|
At 12:56 AM 4/1/2001 -0500, Todd L. Miller wrote: > Should be ready to rumble, except for the high-speed edit refusal >stuff. I've modified the WikiRenderer to replace <script> tags with ><script>, so as to prevent 'malicous' (sp?) HTML. (If there's other >stuff that should be disallowed, or if only certain tags should be >allowed, please weight in.) I haven't re-imported the files from >metamech, pending a review. :) Cool. It looks great. Let's polish up the look and feel (as per the other email I just sent). I was also wondering if we shouldn't go the other way when it comes to allowing HTML. Unless the HTML is explicitly allowed, its filtered out (the brackets turned to < and >). Then we can create a list of allowed html that we're pretty sure is safe and not have to worry if we missed adding something crucial. So, table, font, etc may be allowed. It's a little more work as we'll have to create a list for the parser to parse, but also gives is better control/security. And we can start with a really small list, and slowly add tags when people complain (and they can justify why its needed and safe). I prefer this approach because its safer, and will hopefully encourage people to use wiki tags instead of html (there should be no reason to need bold tag support for example because wiki tags support this). my 2cents at least -iain |
|
From: Todd L. M. <tm...@ha...> - 2001-04-01 05:58:38
|
Should be ready to rumble, except for the high-speed edit refusal stuff. I've modified the WikiRenderer to replace <script> tags with <script>, so as to prevent 'malicous' (sp?) HTML. (If there's other stuff that should be disallowed, or if only certain tags should be allowed, please weight in.) I haven't re-imported the files from metamech, pending a review. :) -_Quinn |
|
From: Todd L. M. <tm...@ha...> - 2001-03-31 01:36:26
|
Iain, I just realized that by putting the topic box / search link in the third bar down, you're preventing me from using that space for the 'am I logged in or not' links. Also, the width of the menu bar to the right means we waste a lot of space for longer articles. Furthermore, 'hot spots in the wiki' doesn't make sense if one's already in the wiki, so I changed it to a link to the Wiki WebHome. So. Should I just drop the browse bar entirely, since all of its functions, except for the link to the <webname>WebHome (and since we don't seem to be using webs very much) are duplicated elsewhere, and replace it with the user links? The other thing: with the big header and footer and sidebar, do you think that the amount of orange and yellow is getting a bit overwhelming, especially on short pages? Maybe restructing the sidebar (more vertical, one entry/line) would be helpful, or maybe it should be done in a different color scheme? (Like the tables?) Anyway, wiki.jos.org is now running the latest sfWiki code out of the CVS, which means it should be hunky-dory, except that it can be spider-bombed. Iain, I can't find the link I seem to remember you forwarding me about how to take care of that. Could you send it again? -jQuinn |
|
From: <no...@so...> - 2001-03-30 23:24:06
|
Feature Requests item #410077, was updated on 2001-03-20 09:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355181&aid=410077&group_id=5181 Category: User (Layout) Group: Current Release >Status: Closed Priority: 8 Submitted By: Iain Shigeoka (shigeoka) Assigned to: Todd L. Miller (jquinn) Summary: Browser-friendly page titles Initial Comment: Change the sfWiki page titles to be browser bookmark friendly. The friendliest makes sense even in a minimized browser or in the "favorites" bar. Proposed title layouts are: PageName.WikiName.WebName PageName [WikiName] WebName PageName.WebName.WikiName [WikiName] PageName.WebName WikiName:PageName.WebName Probably favoriting the PageName first so even at the most truncated title, it still tells you essentially what is pointed to. ---------------------------------------------------------------------- >Comment By: Todd L. Miller (jquinn) Date: 2001-03-30 15:23 Message: Logged In: YES user_id=21436 PageName.WebName :: WikiName for now. -jQuinn ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355181&aid=410077&group_id=5181 |
|
From: <no...@so...> - 2001-03-30 23:09:27
|
Feature Requests item #410077, was updated on 2001-03-20 09:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355181&aid=410077&group_id=5181 Category: User (Layout) Group: Current Release Status: Open >Priority: 8 Submitted By: Iain Shigeoka (shigeoka) >Assigned to: Todd L. Miller (jquinn) Summary: Browser-friendly page titles Initial Comment: Change the sfWiki page titles to be browser bookmark friendly. The friendliest makes sense even in a minimized browser or in the "favorites" bar. Proposed title layouts are: PageName.WikiName.WebName PageName [WikiName] WebName PageName.WebName.WikiName [WikiName] PageName.WebName WikiName:PageName.WebName Probably favoriting the PageName first so even at the most truncated title, it still tells you essentially what is pointed to. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355181&aid=410077&group_id=5181 |
|
From: <no...@so...> - 2001-03-20 17:30:19
|
Feature Requests item #410077, was updated on 2001-03-20 09:32 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355181&aid=410077&group_id=5181 Category: User (Layout) Group: Current Release Status: Open Priority: 5 Submitted By: Iain Shigeoka (shigeoka) Assigned to: Nobody/Anonymous (nobody) Summary: Browser-friendly page titles Initial Comment: Change the sfWiki page titles to be browser bookmark friendly. The friendliest makes sense even in a minimized browser or in the "favorites" bar. Proposed title layouts are: PageName.WikiName.WebName PageName [WikiName] WebName PageName.WebName.WikiName [WikiName] PageName.WebName WikiName:PageName.WebName Probably favoriting the PageName first so even at the most truncated title, it still tells you essentially what is pointed to. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355181&aid=410077&group_id=5181 |
|
From: <no...@so...> - 2001-03-20 17:26:57
|
Feature Requests item #410075, was updated on 2001-03-20 09:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355181&aid=410075&group_id=5181 Category: User (Layout) Group: Investigate Status: Open Priority: 5 Submitted By: Iain Shigeoka (shigeoka) Assigned to: Nobody/Anonymous (nobody) Summary: "Standard" wiki linking Initial Comment: Change the "form" links http://site/action.php?topic=PageName&web=WebName to "standard" wiki links: http://site/action/WebName/PageName This will help standardize linking and help bookmarks survive between wiki technologies (say if the site migrates between the current php wiki to a java wiki). ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=355181&aid=410075&group_id=5181 |
|
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 |
|
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: 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-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: 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: 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: Iain S. <iai...@ya...> - 2001-03-15 17:57:53
|
At 03:59 PM 3/13/2001 -0500, Todd L. Miller wrote: > > Something is weird then. I don't see it. I reloaded and checked the html > > and still don't see it. I suppose it could by a proxy caching thing but I > > had seen the login link from the previous version and then it went away so > > I would suspect its something else. Can you recheck to make sure its > there > > on your version? > > OK, we're both looking at sfwiki.sourceforge.net, correct? I just >checked from a machine which I hadn't used before, and I see the login >link on the browswebar. (NS 4.5 and IE 4.0) Not sure what the problem >is... Doh. I was looking at wiki.jos.org. Yes, sorry about that. I guess some of the things fixed in sfwiki are also in wiki.jos.org (like spaces in names). I really like the sfwiki site! Seems to work no problem. -iain |
|
From: Todd L. M. <tm...@ha...> - 2001-03-13 20:56:57
|
> Something is weird then. I don't see it. I reloaded and checked the html > and still don't see it. I suppose it could by a proxy caching thing but I > had seen the login link from the previous version and then it went away so > I would suspect its something else. Can you recheck to make sure its there > on your version? OK, we're both looking at sfwiki.sourceforge.net, correct? I just checked from a machine which I hadn't used before, and I see the login link on the browswebar. (NS 4.5 and IE 4.0) Not sure what the problem is... -_Quinn |
|
From: Iain S. <iai...@ya...> - 2001-03-13 04:38:13
|
At 05:00 PM 3/12/2001 -0500, Todd L. Miller wrote: > > Does this mean returns in the edit box to cause the form to submit? This > > is dangerous/bad because when typing in there, I often hit the <return> > key > > for newlines! > > No. For /just/ the actions on user.php -- logging in, requesting >password be emailed, creating a new user, changing user information -- >actions which should never allow newlines -- allow 'return' to do logins. Ah. Makes sense now. > > ? Not sure what this means. > > You phrased it as 'high-speed edit refusal' IIRC -- to prevent >spider bombs. :) Yeah. Ok. That makes sense too! I would say this is probably a "good idea" as I'm not sure what SourceForge will do if they see our site freaking out. ;) -iain |
|
From: Iain S. <iai...@ya...> - 2001-03-13 04:38:12
|
At 04:57 PM 3/12/2001 -0500, Todd L. Miller wrote: > > Sounds good. I just want to re-iterate that the login stuff is gone right > > now... :) Not sure if this is intentional or not. > > Hm. Look at the right-hand side of the 'browse' bar. I know the >colors are horrible, but you should be able to see the links. Maybe you >caught me in the middle of an upgrade? Something is weird then. I don't see it. I reloaded and checked the html and still don't see it. I suppose it could by a proxy caching thing but I had seen the login link from the previous version and then it went away so I would suspect its something else. Can you recheck to make sure its there on your version? -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: Todd L. M. <tm...@ha...> - 2001-03-12 21:57:35
|
> Does this mean returns in the edit box to cause the form to submit? This > is dangerous/bad because when typing in there, I often hit the <return> key > for newlines! No. For /just/ the actions on user.php -- logging in, requesting password be emailed, creating a new user, changing user information -- actions which should never allow newlines -- allow 'return' to do logins. > ? Not sure what this means. You phrased it as 'high-speed edit refusal' IIRC -- to prevent spider bombs. -_Quinn |
|
From: Todd L. M. <tm...@ha...> - 2001-03-12 21:55:22
|
> Sounds good. I just want to re-iterate that the login stuff is gone right > now... :) Not sure if this is intentional or not. Hm. Look at the right-hand side of the 'browse' bar. I know the colors are horrible, but you should be able to see the links. Maybe you caught me in the middle of an upgrade? -_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: Iain S. <iai...@ya...> - 2001-03-12 21:35:39
|
At 12:56 AM 3/12/2001 -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. Sounds good. I just want to re-iterate that the login stuff is gone right now... :) Not sure if this is intentional or not. -iain |
|
From: Iain S. <iai...@ya...> - 2001-03-12 21:35:34
|
At 01:56 AM 3/11/2001 -0500, you wrote: > I did quite a bit of work on sfWiki. Things I still want to do >before release: > > * get <return> to work for user.php form submits, if possible > (suggestions?) Does this mean returns in the edit box to cause the form to submit? This is dangerous/bad because when typing in there, I often hit the <return> key for newlines! > * set up a cron job to automate database backup, if possible Probably a good idea. > * implement anti-mass-edit stuff ? Not sure what this means. > Needs to be checked: > > * extra tab in edit fields > * other prior requests Seems to be repaired. > Please go bang on the sfWiki at SF for a while, and see what I've >missed. While banging around, I noticed I'm not prompted for logging in any more. I also don't see a login link anywhere. Is this disabled for now? > Known bug: > * %Topics With Spaces% don't link right. SF has this bug. As per your comment, this appears to be fixed. > feature for the next release: > * add who last-edited a page to its _info_ page. Sounds good. -iain |
|
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 |
13 messages has been excluded from this view by a project administrator.
