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: 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:50:00
|
I (think) I just fixed all the places where %links with spaces in them% broke things/were broken, so I'd appreciate it if you could go pound on them (and the rest of the sfWiki) for a while. Thanks. -jQuinn |
|
From: Todd L. M. <tm...@ha...> - 2001-03-11 06:54:00
|
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?) * set up a cron job to automate database backup, if possible * implement anti-mass-edit stuff Needs to be checked: * extra tab in edit fields * other prior requests Please go bang on the sfWiki at SF for a while, and see what I've missed. Known bug: * %Topics With Spaces% don't link right. SF has this bug. feature for the next release: * add who last-edited a page to its _info_ page. -_Quinn |
|
From: Todd L. M. <tm...@ha...> - 2001-02-23 07:17:27
|
> Details details. :) Yeah. I think it should be broken into multiple pages
> one for each function when you get the chance (except login and logout
> which can be moved to the nav bar or header/footer).
Maybe. I've always found page-per-function vaguely irritating for
some reason. Maybe all user.php, but with the op=... changing how the
page looks...
> The logged in or logged out status needs to be better indicated so its
> clear if you are or are not logged in. Perhaps a color change in a menu
> bar or a highlighted button/area to indicate login status. Probably
> something to do with header/footer/navbar after you figure out how to
> integrate this with the prerendered stuff.
I'm going to check what exactly the difference between the static
and dynamic headers/footers actually are. Since adding login status to a
pre-rendered page will require some processing on views anyway, I think I
might eliminate the static/dynamic distinction, and just include the
static around every page, eliminating the dynamic in the database. This
will let me do what I want, which is put user operations in the left-hand
menu bar for JOS.
> I also think that being able to see who you are logged in as would be nice.
True. :) Maybe in the menu bar, I'll underlined 'User'
section change to underlined <UserName> section when logged in (color
change, too?) and the links underneath shift appropriately.
> When I create an account (actually anytime i get the login screen) the user
> and email fields have a tab appended to the data (a blank form has a single
> tab in there. I'm not sure what this does when you update an account (i
> imagine it at least appends things to the email. Anyhow, you may want to
> fix that...
Yeah, probably. I'm not sure /where/ the tab is coming from, but
I'll hammer away at it for a while.
> Your error checking is pretty good. However, i could create accounts
> without an email. Is this proper?
Doh! Not really. I should also check and make sure that what the
WikiRenderer recognizes as an e-mail is placed in the e-mail field.
> When a form has bad data and you re-present the form, could you refill the
> fields with the entered data so I don't have to reenter it?
Yes. For some reason, Netscape did this by itself when I tested
it locally, but not remotely. I think it's a header-cache thing. (It
only checks the database right now, but it should also check the POSTed
information.)
> The password fields should be made password fields rather than text. I
> assume this is only done this way right now to make it easier to test.
It certainly wasn't because I donn't know how to make password
fields! (Hint, hint. :))
So for new users, automagically dump them into editing their
WikiHomePage? Should I put the please-subscribe message into the default
body text, or send an e-mail? ("Your account 'IainShig' with password
'IHaventCompletedMyHalfOfTheDealYet' and this e-mail address has been
confirmed. $wikiGreetingText"?)
> To do that you really need to watch for high speed edits coming from
> the same address and auto-refuse them.
Hm. This may be decidedly non-trivial. You got any ideas on
coding it?
> I think its good if the wiki gets spidered and we get into search
> engines but only if its done nicely.
Yeah. Right now, both wiki.jos.org and sfwiki.sourceforge.net
have robots.txt files disallowing all sfWiki links except view.php3; the
Janurary webalizer data should be up pretty soon, and hopefully we'll see
how much that cut down on the spidering. Google-ing 'MainWebHome' is
interesting, though...
> Whew. That's quite a list. Sorry about that.
S'okay. I'm just the developer here. :)
> Looks great though.
Thanks. :)
> I can already feel the sigh of relief from my metamech server when the
> wiki is moved off of there! :)
But then you will groan in terror when you realize that you need
to clean up the jos.org site (and do that other stuph you mentioned)!
-_Quinn
|
|
From: Iain S. <iai...@ya...> - 2001-02-23 06:36:07
|
At 09:18 PM 2/21/2001 -0500, Todd L. Miller wrote: > http://sfwiki.sourceforge.net is running the new authentication >(et al) code, so go beat on it for a while. I /know/ the user page is Cool. >ugly; please donate pretty PHP. I also know that only having the user Details details. :) Yeah. I think it should be broken into multiple pages one for each function when you get the chance (except login and logout which can be moved to the nav bar or header/footer). >edit/logout | create/logout stuff at the bottom of the view pages is a >horrible place to put it, but it was /much/ easier that way for this test >run. (I would like to put in the JOS menu when I do that, but that could >get tricky, because of the pre-rendering.) While I haven't bothered to >migrate the topics from release 2-0-x into the sfWiki Wiki yet, I haven't >deleted them, and the migration should be a simple SELECT INTO; I don't >think I've changed the topics table format. (May want to include a >last-edited-by, and then a %AUTHORSHIP% variable for UserPages.) Yeah. Cool. I have some small nits to pick. I realize this is a functional demo so I'm only mentioning them here so I make sure its integrated into the final version rather than going another review round... :) I'm sure most of these you already know about: The logged in or logged out status needs to be better indicated so its clear if you are or are not logged in. Perhaps a color change in a menu bar or a highlighted button/area to indicate login status. Probably something to do with header/footer/navbar after you figure out how to integrate this with the prerendered stuff. I also think that being able to see who you are logged in as would be nice. When I create an account (actually anytime i get the login screen) the user and email fields have a tab appended to the data (a blank form has a single tab in there. I'm not sure what this does when you update an account (i imagine it at least appends things to the email. Anyhow, you may want to fix that... Your error checking is pretty good. However, i could create accounts without an email. Is this proper? When a form has bad data and you re-present the form, could you refill the fields with the entered data so I don't have to reenter it? The password fields should be made password fields rather than text. I assume this is only done this way right now to make it easier to test. When I create an account, it provides a very useful line saying "Please edit your user page" that is excellent. I would also add a, please subcribe to our mailing lists (or just take my wiki reg boiler plate appended to the bottom of this email). This informational info is very useful. However, the link for editing your wiki page doesn't have the topic (my wiki name) filled in. And I think it should actually point to an edit page not the view page. As it is right now, it goes to the default webhome which confused me for a bit (I thought it was my page for a second). > Since the registration is done automagically, I'm thinking we may >want to put a delay of some kind in there to get graffiti artists >bored. Maybe /force/ a UserPage edit first? Yes. Force them to edit a user page (perhaps boilerplate in basic info about the person based on what they entered in the registration form). This will not prevent graffiti artists though. To do that you really need to watch for high speed edits coming from the same address and auto-refuse them. It may not be a bad idea to try and get that kind of capability in there anyhow for other improper usage. Otherwise, we run the risk of getting spider bombed (the reason we got kicked off helmut's machine). I think its good if the wiki gets spidered and we get into search engines but only if its done nicely. Whew. That's quite a list. Sorry about that. Looks great though. I can already feel the sigh of relief from my metamech server when the wiki is moved off of there! :) -iain |
|
From: Todd L. M. <tm...@ha...> - 2001-02-22 02:21:21
|
http://sfwiki.sourceforge.net is running the new authentication (et al) code, so go beat on it for a while. I /know/ the user page is ugly; please donate pretty PHP. I also know that only having the user edit/logout | create/logout stuff at the bottom of the view pages is a horrible place to put it, but it was /much/ easier that way for this test run. (I would like to put in the JOS menu when I do that, but that could get tricky, because of the pre-rendering.) While I haven't bothered to migrate the topics from release 2-0-x into the sfWiki Wiki yet, I haven't deleted them, and the migration should be a simple SELECT INTO; I don't think I've changed the topics table format. (May want to include a last-edited-by, and then a %AUTHORSHIP% variable for UserPages.) Since the registration is done automagically, I'm thinking we may want to put a delay of some kind in there to get graffiti artists bored. Maybe /force/ a UserPage edit first? -jQuinn |
|
From: Iain S. <iai...@ya...> - 2001-02-21 23:37:10
|
At 04:18 PM 2/21/2001 -0500, Todd L. Miller wrote: > Well, I found a little problem with authentication for >editing. Basically, the edit links are generated when the page is saved, >which means they can't append the PHP session id, so I'd have to use >cookies to allow people to edit w/o entering their password every new >edit, or alter PrintWikiTopic to substitute the session id, if available, >where it needed to go. This method has the disadvantage of requiring a >potentially expensive search & replace every time a logged-in user views a >page. Cookies have their obvious dis/advantages, but one advantage: I >won't have to go through sfWiki and make sure every link in it or link >that it produces has the session id hanging off of it. Thoughts? Use cookies. Just one "per session cookie" that only holds a session id. Anyone without cookies turned on can't edit. It's a bit hardline but its the easiest to implement and support and is a common tactic now days (sourceforge itself requires cookies for this reason...). URL rewriting is a pain in the tuckis and I'd only support that if i was doing a major commercial site where i couldn't afford to alienate anyone. Anyone technical enough to know what cookies really are (or are willing to learn) knows that they aren't any more a security/privacy risk than url rewriting... and that is currently the jos members (i hope they're at least that technical). :) -iain |
|
From: Todd L. M. <tm...@ha...> - 2001-02-21 21:20:46
|
Well, I found a little problem with authentication for editing. Basically, the edit links are generated when the page is saved, which means they can't append the PHP session id, so I'd have to use cookies to allow people to edit w/o entering their password every new edit, or alter PrintWikiTopic to substitute the session id, if available, where it needed to go. This method has the disadvantage of requiring a potentially expensive search & replace every time a logged-in user views a page. Cookies have their obvious dis/advantages, but one advantage: I won't have to go through sfWiki and make sure every link in it or link that it produces has the session id hanging off of it. Thoughts? -_Quinn |
|
From: Todd L. M. <tm...@ha...> - 2001-01-28 23:55:49
|
Well, I took a look at how two other people implemented database sessions, and rewrote one of them to fit in with sfWiki, and it seems to be working. I'll be trying it w/ multiple simultaneous sessions when I get the test pages set up for non-cookie operation. Now it should just be a matter of grunt work to user auth and the like. -jQuinn |
|
From: Todd L. M. <tm...@ha...> - 2001-01-27 21:57:32
|
> So if you're using wiki related information to generate the timestamp > on imports, you're probably running into an existing w2k problem with > the old wiki. No, I was just using the 'last-modified' dates on the .txt files. We'll see what happens. :) -_Quinn |
|
From: Iain S. <iai...@ya...> - 2001-01-27 21:16:19
|
On 27 Jan 01, at 1:00, Todd L. Miller wrote: > formatting timestamp, so that's OK. The question is how the timestamp > came to be that way on these certain pages. The only thing that seems to > be common between them is that the last edit is was in 2000 (And probably Hmm. Not entirely sure. I do know that the current jos wiki is not w2k compliant (there are a couple w2k bugs in there). So if you're using wiki related information to generate the timestamp on imports, you're probably running into an existing w2k problem with the old wiki. -iain |
|
From: Todd L. M. <tm...@ha...> - 2001-01-27 06:00:28
|
If you poke around wiki.jos.org for long enough, you'll notice that some of the pages aren't being rendered in the yellow-on-yellow style. The timestamps for all of them are all rather more recent than the formatting timestamp, so that's OK. The question is how the timestamp came to be that way on these certain pages. The only thing that seems to be common between them is that the last edit is was in 2000 (And probably the date when they were all imported.) Anyone have any idea what could be causing this? The problem does show up on the copy I'm running locally, so it's not something transiently flaky about SF, though I did run the import locally and then transfer it SourceForge. Maybe I'll just clean out my local copy, re-run the import script and see what happens... -jQuinn |
|
From: Todd L. M. <tm...@ha...> - 2001-01-26 19:26:08
|
Unfortunately (:)), sfWiki is not the official SourceForge Wiki, the SourceForge's project Wiki, or actually even ready to be either -- I'm still hacking away at it*. If you want bzflag to have its own Wiki (e.g. http://bzflag.sourceforge.net/sfWiki/), (try to) follow the instructions (at ftp://sfwiki.sourceforge.net/pub/sfwiki/INSTALL) to install a wiki specifically for your project. If you have problems, or the instructions aren't clear, etc, please let me (us) know. > Is the wiki link going to be linked from the project page someday? I hope so. :) Not any time soon, though, I'd imagine. As I said above, sfWiki is not part of SourceForge in the same way that, say, the Project Manager is, though I hope it joins in some day. You're welcome to start adding pages to the sfWiki Wiki, but it's intended to be a wiki for the sfWiki project, rather than for all of SourceForge. I'd like to know, though, how you learned about sfWiki. -jQuinn * It really should have some revision control, and also some user authentication, especially if you expect a lot of traffic, to handle grafitti and 'click-by' destruction of pages. The sfWiki site itself hasn't had many problems, but other more noticeable Wikis have. I'm hoping to add some of that this weekend, but we'll see -- I haven't been able to get SourceForge's PHP sessions to work. |
|
From: Tim R. <Ti...@Ri...> - 2001-01-26 19:02:53
|
What needs to be done to get a new project into the wiki? I'd like to add BZFlag. http://sourceforge.net/projects/bzflag/ Is the wiki link going to be linked from the project page someday? Can we just add pages starting at: http://sfwiki.sourceforge.net/view.php3?topic=WebHome Thanx. -- Tim Riker - http://rikers.org/ - short SIGs! <g> All I need to know I could have learned in Kindergarten ... if I'd just been paying attention. |
|
From: Todd L. M. <tm...@ha...> - 2001-01-22 02:07:49
|
> <URL:http://wiki.jos.org/view.php3?topic=DownloadStaticWiki#jos1h> > > How do I link one article to a specific anchor in another article using the > sfWiki software? The above (re-cast as an HREF) should work just fine. However, it should be possible to WikiLink to anchors, as well, I suppose, viz: WikiLink#WikiAnchor. Thoughts? Should #WikiAnchor# be converted to an HTML anchor? -_Quinn |
|
From: Iain S. <iai...@ya...> - 2000-12-16 18:47:09
|
At 11:43 PM 12/7/00 -0500, Todd L. Miller wrote: >[Poll: Should the topics page be converted to list N topics at a time with > scroll links for the other N topics?] Yes. -iain |
|
From: Todd L. M. <tm...@ha...> - 2000-12-08 04:36:46
|
It's probably not ready for prime-time, but it has all 1700-odd topics from the metamech Wiki. Not everything is working exactly right*, but I'd like to people to poke around / beat on it for a while and see what other problems they can find. Thanks! And be careful about viewing the topic list if you've got a slow netlink -- the page is /huge/ now :) [Poll: Should the topics page be converted to list N topics at a time with scroll links for the other N topics?] -_Quinn *: Notably: any links to (images, usually) on the metamech server using local paths won't work, since I don't that data handy to migrate; (sometimes?) acronyms (e.g. JOS) won't link -- this is to avoid linking HTML attributes -- edit the page and change to e.g. %JOS%; implicit image links aren't implemented; '--WikiLink' doesn't link (makes .sigs look odd -- should --WikiLink link?); and the order-by-last-edit listings are deceptive; UPDATEing the link-to count currently counts as a page edit. I'll correct this once I figure out how. That covers all the problems I know of and hopefully all the problems, period. |
|
From: Todd L. M. <tm...@ha...> - 2000-12-07 01:03:45
|
I've completed adding in spaces as an option before lists, as well as # as an optional way of specifying ordered list items. I'll start playing with the imports from the current JOS wiki now. -jQuinn |
|
From: Iain S. <iai...@ya...> - 2000-12-06 20:58:52
|
At 02:08 PM 12/6/00 -0500, Todd L. Miller wrote: > > I like using spaces rather than tabs because some browsers don't let tabs > > into the text area. > > Ah. Hadn't realized that. I'll look into doing either/or, then. Cool. I think this is best. > > This will be incompatible with most of the wiki lists though won't it? > > I'm not sure -- I haven't looked at the source. If it is, I'll >make it either/or, unless you think using # is a bad idea. I think the # is a very good idea. Perhaps you just make it part of the filter to look for the old style and convert it to the new # style then only use the # style thereafter? The differences between tabs and spaces and having to do a multiple of three spaces really made the old style non-intuitive. > > I will try and get the tarball to you asap. You should get an email > with a > > link to my xdrive account where you can get the tarball. > > Got it. I'll play with it a while locally -- maybe make some of >the changes outlined about -- before u/l'ing it to SourceForge. cool. -iain |
|
From: Todd L. M. <tm...@ha...> - 2000-12-06 19:02:04
|
> I like using spaces rather than tabs because some browsers don't let tabs > into the text area. Ah. Hadn't realized that. I'll look into doing either/or, then. > This will be incompatible with most of the wiki lists though won't it? I'm not sure -- I haven't looked at the source. If it is, I'll make it either/or, unless you think using # is a bad idea. > I will try and get the tarball to you asap. You should get an email with a > link to my xdrive account where you can get the tarball. Got it. I'll play with it a while locally -- maybe make some of the changes outlined about -- before u/l'ing it to SourceForge. -jQuinn |
|
From: Iain S. <iai...@ya...> - 2000-12-06 18:53:58
|
At 10:42 PM 12/5/00 -0500, you wrote: > I've implemented lists as they are implemented in TWiki. What >this means, essentially, is two things: > >(1) Lists are now noted by tab characters I like using spaces rather than tabs because some browsers don't let tabs into the text area. >(2) <number>. notates ordered lists > > My implementation as a problem, (A), that when nesting lists of > dissimilar >types, it doesn't close them off at the proper level of nesting. Now, >Netscape doesn't seem to mind, I think things both end up looking right, >and they do end up being fully closed off, but I'd like other >browser-users to test things for me, because fixing it will be an >enourmous pain. I'm a netscape user too but will try and fire up ie and check it out. > However, I'm strongly tempted to ditch (2) and replace it with the >notation that %RobertFitzsimons% uses, that is, with a pound sign, viz: > > # List item > # list item This will be incompatible with most of the wiki lists though won't it? >where the whitespace is a tab. However, I kind of like (1). Anyway, >please go beat on sfwiki some more, particularly absurd lists. And send >commentary. OK. I don't think I'll get to it until next week unfortunately because I'm out of town until Dec 16th! Sorry. > If it holds up, I think this will become the legendary release 2, >and I'll do the import from the current JOS wiki (to jos.sourceforge.net) >when I get the tarball (from Ian?). Cross your fingers :) It probably >shouldn't go 'live' as the official Wiki until we've got some user auth >going, though. I will try and get the tarball to you asap. You should get an email with a link to my xdrive account where you can get the tarball. -iain |
|
From: Todd L. M. <tm...@ha...> - 2000-12-06 03:37:18
|
I've implemented lists as they are implemented in TWiki. What this means, essentially, is two things: (1) Lists are now noted by tab characters (2) <number>. notates ordered lists My implementation as a problem, (A), that when nesting lists of dissimilar types, it doesn't close them off at the proper level of nesting. Now, Netscape doesn't seem to mind, I think things both end up looking right, and they do end up being fully closed off, but I'd like other browser-users to test things for me, because fixing it will be an enourmous pain. However, I'm strongly tempted to ditch (2) and replace it with the notation that %RobertFitzsimons% uses, that is, with a pound sign, viz: # List item # list item where the whitespace is a tab. However, I kind of like (1). Anyway, please go beat on sfwiki some more, particularly absurd lists. And send commentary. If it holds up, I think this will become the legendary release 2, and I'll do the import from the current JOS wiki (to jos.sourceforge.net) when I get the tarball (from Ian?). Cross your fingers :) It probably shouldn't go 'live' as the official Wiki until we've got some user auth going, though. -jQuinn |
|
From: Todd L. M. <tm...@ha...> - 2000-12-02 01:29:17
|
> What's the size of the resulting page? Over 100K. I forget the exact size. -jQuinn |
|
From: Iain S. <iai...@ya...> - 2000-12-02 01:04:01
|
At 07:22 PM 12/1/00 -0500, Todd L. Miller wrote: > Should this query jump mysqld's CPU usage to 99% on a celeron 400, >and cause the page to to take ten minutes to generate when run on all the >pages from the JOSwiki (archive from jos.org)? I can see this being true (although 10 minutes does seem wrong) because your result set should be over a thousand records. Hence, it should be done once in a long while, or done incrementally (so you only get the full hit once when first doing the import). I would also imagine php may be inefficient at such a large operation... What's the size of the resulting page? -iain |
|
From: Todd L. M. <tm...@ha...> - 2000-12-02 00:21:11
|
The link in my previous email was wrong. Try: http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/sfWiki/portal/htdocs/wiki/TopicBody.ihtml?rev=1.4&content-type=text/x-cvsweb-markup&cvsroot=sfwiki -jQuinn |
13 messages has been excluded from this view by a project administrator.
