You can subscribe to this list here.
2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
(103) |
Jul
(105) |
Aug
(16) |
Sep
(16) |
Oct
(78) |
Nov
(36) |
Dec
(58) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(100) |
Feb
(155) |
Mar
(84) |
Apr
(33) |
May
(22) |
Jun
(77) |
Jul
(36) |
Aug
(37) |
Sep
(183) |
Oct
(74) |
Nov
(235) |
Dec
(165) |
2002 |
Jan
(187) |
Feb
(183) |
Mar
(52) |
Apr
(10) |
May
(15) |
Jun
(19) |
Jul
(43) |
Aug
(90) |
Sep
(144) |
Oct
(144) |
Nov
(171) |
Dec
(78) |
2003 |
Jan
(113) |
Feb
(99) |
Mar
(80) |
Apr
(44) |
May
(35) |
Jun
(32) |
Jul
(34) |
Aug
(34) |
Sep
(30) |
Oct
(57) |
Nov
(97) |
Dec
(139) |
2004 |
Jan
(132) |
Feb
(223) |
Mar
(300) |
Apr
(221) |
May
(171) |
Jun
(286) |
Jul
(188) |
Aug
(107) |
Sep
(97) |
Oct
(106) |
Nov
(139) |
Dec
(125) |
2005 |
Jan
(200) |
Feb
(116) |
Mar
(68) |
Apr
(158) |
May
(70) |
Jun
(80) |
Jul
(55) |
Aug
(52) |
Sep
(92) |
Oct
(141) |
Nov
(86) |
Dec
(41) |
2006 |
Jan
(35) |
Feb
(62) |
Mar
(59) |
Apr
(52) |
May
(51) |
Jun
(61) |
Jul
(30) |
Aug
(36) |
Sep
(12) |
Oct
(4) |
Nov
(22) |
Dec
(34) |
2007 |
Jan
(49) |
Feb
(19) |
Mar
(37) |
Apr
(16) |
May
(9) |
Jun
(38) |
Jul
(17) |
Aug
(31) |
Sep
(16) |
Oct
(34) |
Nov
(4) |
Dec
(8) |
2008 |
Jan
(8) |
Feb
(16) |
Mar
(14) |
Apr
(6) |
May
(4) |
Jun
(5) |
Jul
(9) |
Aug
(36) |
Sep
(6) |
Oct
(3) |
Nov
(3) |
Dec
(3) |
2009 |
Jan
(14) |
Feb
(2) |
Mar
(7) |
Apr
(16) |
May
(2) |
Jun
(10) |
Jul
(1) |
Aug
(10) |
Sep
(11) |
Oct
(4) |
Nov
(2) |
Dec
|
2010 |
Jan
(1) |
Feb
|
Mar
(13) |
Apr
(11) |
May
(18) |
Jun
(44) |
Jul
(7) |
Aug
(2) |
Sep
(14) |
Oct
|
Nov
(6) |
Dec
|
2011 |
Jan
(2) |
Feb
(6) |
Mar
(3) |
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2012 |
Jan
(11) |
Feb
(3) |
Mar
(11) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(4) |
Dec
|
2013 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(4) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(8) |
Dec
(1) |
2015 |
Jan
(3) |
Feb
(2) |
Mar
|
Apr
(3) |
May
(1) |
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
2016 |
Jan
|
Feb
(4) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
(5) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2021 |
Jan
|
Feb
(4) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(6) |
Sep
(3) |
Oct
|
Nov
|
Dec
|
2022 |
Jan
(11) |
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2023 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(3) |
Dec
(3) |
2024 |
Jan
(7) |
Feb
(2) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2025 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Steve W. <sw...@wc...> - 2000-08-15 03:31:19
|
OK, after a lot of hair pulling I've done some (imperfect) refactoring of the database interface: SaveCopyToArchive is now in the database libraries (out of stdlib) because it will be implementation dependent. I've added IsInArchive() which works the same as IsWikiPage(). RetrievePage() now takes a third argument, the table name (or page store if you prefer). This is kind of unfortunate but can be remedied, because SaveCopyToArchive is really just a copy now of InsertPage, and I should have written a RetrieveCopy() instead. That is, InsertPage is to SaveCopyToArchive IsWikiPage is to IsInArchive RetrievePage stands alone But after a day of dead ends and testing, testing, testing it will have to wait. index.php3 just makes one call to open the database. It doesn't matter if the user is editing a live page or a copy. Several other pages no longer make calls to open the database. I've tested this new version on the DBM and Postgresql bases over and over, and it looks good. I can load pages, edit copies, do diffs, info, title and fulltext searches, and RecentChanges works. Now, another thing that has really troubled me over the weekend: On Thu, 10 Aug 2000, Jeff Dairiki wrote: > If we are going to move to a new OO database API, it seems to me that there's > no point in putting too much effort into implementing features in the > old API. I looked through the code base Jeff wrote, and it's so amazing... but it defines 57 classes, and is quite inpenetrable! It works so well though that it really deserves its own release. Jeff, would you like to release this as a special verion of PhpWiki? Perhaps a 1.3 branch? It's so far removed from the 1.1 branch that I don't think they can be merged (which was never your goal anyway). I've really anguished over what to do about the differences between the code bases; I think they both deserve release. 1.1 is so close to being finished, and we have so many ideas it's tempting to keep racing ahead, but I think that's what happened to Project Xanadu, and they never released anything. I'm anxious myself to start on a 2.0 code base. After today's hacking I see the kruft creeping in everywhere in the 1.1 code. sw ...............................ooo0000ooo................................. Hear FM quality freeform radio through the Internet: http://wcsb.org/ home page: www.wcsb.org/~swain |
From: Steve W. <sw...@wc...> - 2000-08-10 15:32:02
|
I've added a new function (a clone of LinkURL called LinkImage) to embed images that appear as [http://foo.com/image.png]. I updated HowToUseWiki as well. sw ...............................ooo0000ooo................................. Hear FM quality freeform radio through the Internet: http://wcsb.org/ home page: www.wcsb.org/~swain |
From: Jeff D. <da...@da...> - 2000-08-10 15:27:27
|
Look at my new database code in the jeffs_hacks-branch. It fully implements MostPopular (& the link tables) both for DBM and MySQL backends. Maybe now's the time to switch to that? (If we don't want to deal with multiple archived pages yet, we could implement a MAX_ARCHIVED_PAGES constant to limit the number of old pages which get kept in the database (to one).) If we are going to move to a new OO database API, it seems to me that there's no point in putting too much effort into implementing features in the old API. Jeff In message <Pin...@bo...>,Steve Wai nstead writes: >I'm having trouble with the DBM version because it would mean some very >messy code; I'd have to open a file in one function and close it in >another. > >It would also mean reworking index.php3 since it wouldn't have to decide >on which db to open (there's only one). It might be simple, or there might >be control flow problems... I'm too sleepy to think it through tonight. > >I have tomorrow off though and will look into it, as well as bring more >stuff up to date for the project. |
From: Steve W. <sw...@wc...> - 2000-08-10 05:03:20
|
I've written the code for MostPopular for the Postgresql library, and it now works/is checked in. I'm having trouble with the DBM version because it would mean some very messy code; I'd have to open a file in one function and close it in another. This is all because of SavePageToArchive, which has a call to open the database to access the archive. We need to get rid of this; for the RDBMSs this means a second unneeded connection to the DB. It would also mean reworking index.php3 since it wouldn't have to decide on which db to open (there's only one). It might be simple, or there might be control flow problems... I'm too sleepy to think it through tonight. I have tomorrow off though and will look into it, as well as bring more stuff up to date for the project. sw ...............................ooo0000ooo................................. Hear FM quality freeform radio through the Internet: http://wcsb.org/ home page: www.wcsb.org/~swain |
From: Steve W. <sw...@wc...> - 2000-08-10 02:52:00
|
Tonight I tried to update the live site on Sourceforge, but for some reason PhpWiki didn't see the pages in the database anymore... it tried to reload the database and broke on a SQL error. I haven't done any more testing yet, but thought I'd bring it up. sw ...............................ooo0000ooo................................. Hear FM quality freeform radio through the Internet: http://wcsb.org/ home page: www.wcsb.org/~swain |
From: Jeff D. <da...@da...> - 2000-08-08 22:31:14
|
>Jeff, can you send a URL for the php-mode extension for emacs? Sure! http://www.ontosys.com/reports/PHP.html (I think there are other implementations of php-mode out there, as well, but don't have any first hand knowledge of them.) Jeff |
From: Steve W. <sw...@wc...> - 2000-08-08 20:11:29
|
Jeff, can you send a URL for the php-mode extension for emacs? thx sw ...............................ooo0000ooo................................. Hear FM quality freeform radio through the Internet: http://wcsb.org/ home page: www.wcsb.org/~swain |
From: Jeff D. <da...@da...> - 2000-08-03 20:22:41
|
>Yeah, PHP has the same weakness with globals as Perl and Tcl. They are >bothersome. At least Perl's got modules. Don't know about Tcl. >> 3. Dump/load serialized (or MIME encoded) pages. Do we need this too? >> My vote is no. > >Hmm. Iffy. Overall, I'd rather not focus too much effort on the admin >tools. Good, I'll ignore that. >> 4. Dump HTML pages. Do we need this? I think this is a low demand item, >> and that it's better done with some external tool (script). > >Imagine a group of >programmers, if you can, who are documenting a system. They won't want to >ship a Wiki to the customer (sadly). Okay, I understand the point now. I think it should wait until after 1.2. >OK... I'd keep the prefixes though. I think there's something about the >way PHP does searches along the include path that any duplicate file names >clobber each other even if they are in different directories. I was actually thinking of not relying on a search path. Just replace "include('wiki_stdlib.php3')" by "include('wiki/stdlib.php3')". (Or perhaps "require('wiki/stdlib.php3')" -- any reason not to?) (Or maybe "require('wiki/stdlib.inc')" which seems to be a more standard naming convention --- not that it matters.) The include path stuff, while slick, is, I think, a portability headache. AFAIK, the path has to be set either in system config files (bad); or in .htaccess files, which can only be done under Apache, and then only if things are configured correctly. >> PATH_INFO? I personally don't really care if this goes into 1.2 or not >> (as long as it makes it in at some point.) > >PATH_INFO is a Good Thing because: it will make URLs a little easier to >read, indexing by search engines a little more likely, and ... well that's >about it. Easier for users to remember/type. Okay I'll probably hack that in then. Hacking in the admin browsing is going to requires messing around with the URLs anyway. >> (Related to admin issue 2, above:) are we going to keep page refs in 1.2? > >Can't we just leave them where they are, and ignore them when exported? >This sounds like a case of Worse Is Better. Refs work now, require no more >thought on our part, and if they are lost when exporting to file, fine. >Not perfect but who wants to put the effort into it? It loses page content, seems bad. At the very least I'd want to add the references as "footnotes" to the bottom of the page content, so they're still there, and can be fixed manually if desired. I'll work on this stuff next week. Jeff |
From: Steve W. <sw...@wc...> - 2000-08-03 19:06:26
|
On Thu, 3 Aug 2000, Jeff Dairiki wrote: > Sorry. When I write new code it tends to come out that way. > I think that some things, like the pagehashes and dbis really are > (already were) objects, and are best expressed explicitly that way. Oh yes, we've gone over that previously. We're totally behind you on the $pagehash and $dbi issues; they are objects and will benefit from OOD. You also made it plain you were hacking experimentally, so I never expected readable/production ready code either. No apologies needed, because no offense was given. > (My motivation in these cases stems mostly from my deep --- at times, > irrational --- loathing of global namespace pollution.) Yeah, PHP has the same weakness with globals as Perl and Tcl. They are bothersome. > As always, feel free to make criticisms --- and to make or suggest changes > --- I'm pretty thick skinned. We'll use blunt instruments ;-) > BTW, do you all use any auto-indentation tools? I've been using php-mode > in emacs, and can't get it to duplicate your style. I use the space bar :-) But I'll check out the php-mode for Emacs since I've been using it lately (Emacs that is). > >of things to do is not very long. Jeff, would it be hard to hack the > >admin design you came up with into the 1.1.7 tree? > > No problem. Tell me though: how much of the admin functionality that's > currently in 1.1.7 do we really want? > > 1. Admin browse mode: lock/unlock pages and edit locked pages. yes... > 2. Zip export. Do you like the current zip file (MIME) format? yep... > 3. Dump/load serialized (or MIME encoded) pages. Do we need this too? > My vote is no. Hmm. Iffy. Overall, I'd rather not focus too much effort on the admin tools. > 4. Dump HTML pages. Do we need this? I think this is a low demand item, > and that it's better done with some external tool (script). low demand; we can wait for someone to contribute it :-) But I do think people will want static HTML snapshots someday. Imagine a group of programmers, if you can, who are documenting a system. They won't want to ship a Wiki to the customer (sadly). > 5. Convert 1.0 DBMs. Currently the code in wiki_setupwiki can load pages > from either a directory ("pgsrc/") or a zip file. The source used is > specified by the setting of WIKI_PGSRC in wiki_config. > > My inclination is to allow WIKI_PGSRC to be set to a version 1.0 DBM as > well. > > I guess the question is whether there should, in addition, be some > method other than WIKI_PGSRC to load pages from zips/dirs/1.0DBMs. > I guess so. Yeah, I can continue responsibility for 1.0 loading; backwards compatibility is a millstone around one's neck though. (It's such a trouble, that is). > Should there be a web-admin option to blow away the current database > contents completely? Or should the new pages always just load over > the old ones, leaving the old contents in the archive? Ouch.. never erase, would be me philosophy. We can't do the admin's job for them, just make it easier. Loading pages should follow the same procedure as any Wiki page insert/update. (InsertPage()) > Other issues for 1.2 (other than whats already in the TODO.) > > Move the lib files to a wiki/ subdirectory (and drop the wiki_ prefix?) > I think this is a win/win proposition, and we should just do it. OK... I'd keep the prefixes though. I think there's something about the way PHP does searches along the include path that any duplicate file names clobber each other even if they are in different directories. > PATH_INFO? I personally don't really care if this goes into 1.2 or not > (as long as it makes it in at some point.) PATH_INFO is a Good Thing because: it will make URLs a little easier to read, indexing by search engines a little more likely, and ... well that's about it. Easier for users to remember/type. > (Related to admin issue 2, above:) are we going to keep page refs in 1.2? > Leave them in the database but hide them from the user? Drop them > completely? > (My vote is leave them in the database, but hide them from the user: > convert them to inline links both when the page is edited, and when > the page is exported to a zip file. This would ease the total abandonment > of page refs in 1.3 and beyond.) Can't we just leave them where they are, and ignore them when exported? This sounds like a case of Worse Is Better. Refs work now, require no more thought on our part, and if they are lost when exporting to file, fine. Not perfect but who wants to put the effort into it? Not us. We are evolving away from Ward Cunningham's classic WikiWikiWeb. > I.e. I'd rather not make page refs part of the "PhpWikiZip standard" if > they're going to be dropped in the next version of PhpWiki. They are going to be dropped, and you have your papal dispensation :-) > I'm going to be on a road trip from tomorrow morning through Monday, so don't > worry if I'm strangely silent. Have fun! Wear your seat belt! :-) sw ...............................ooo0000ooo................................. Hear FM quality freeform radio through the Internet: http://wcsb.org/ home page: www.wcsb.org/~swain |
From: Jeff D. <da...@da...> - 2000-08-03 17:36:13
|
>It is excellent work... and you're not alone when you say OOP designs are >harder to understand. They are. Sorry. When I write new code it tends to come out that way. I think that some things, like the pagehashes and dbis really are (already were) objects, and are best expressed explicitly that way. However, some of the other things which are expressed as classes in my code could be just as clearly expressed without classes. (My motivation in these cases stems mostly from my deep --- at times, irrational --- loathing of global namespace pollution.) As always, feel free to make criticisms --- and to make or suggest changes --- I'm pretty thick skinned. >When I think about PhpWiki's "usability" I think of it in three terms: >* And, how easy is it to understand the program design and modify it? >(hacker usability) I'll be the first to admit that my new code could use some documentation. I'll work on it. Also, I'm still uncomfortable with my new wiki_transform/wiki_renderlib code. I'm happy with it's functionality, but the code is admittedly less than transparent... Some coding standards would be good. BTW, do you all use any auto-indentation tools? I've been using php-mode in emacs, and can't get it to duplicate your style. >We will not abandon 1.1.7 (to be 1.2). I want to finish it up and the list >of things to do is not very long. Jeff, would it be hard to hack the >admin design you came up with into the 1.1.7 tree? No problem. Tell me though: how much of the admin functionality that's currently in 1.1.7 do we really want? 1. Admin browse mode: lock/unlock pages and edit locked pages. 2. Zip export. Do you like the current zip file (MIME) format? 3. Dump/load serialized (or MIME encoded) pages. Do we need this too? My vote is no. 4. Dump HTML pages. Do we need this? I think this is a low demand item, and that it's better done with some external tool (script). 5. Convert 1.0 DBMs. Currently the code in wiki_setupwiki can load pages from either a directory ("pgsrc/") or a zip file. The source used is specified by the setting of WIKI_PGSRC in wiki_config. My inclination is to allow WIKI_PGSRC to be set to a version 1.0 DBM as well. I guess the question is whether there should, in addition, be some method other than WIKI_PGSRC to load pages from zips/dirs/1.0DBMs. I guess so. Should there be a web-admin option to blow away the current database contents completely? Or should the new pages always just load over the old ones, leaving the old contents in the archive? Other issues for 1.2 (other than whats already in the TODO.) Move the lib files to a wiki/ subdirectory (and drop the wiki_ prefix?) I think this is a win/win proposition, and we should just do it. PATH_INFO? I personally don't really care if this goes into 1.2 or not (as long as it makes it in at some point.) (Related to admin issue 2, above:) are we going to keep page refs in 1.2? Leave them in the database but hide them from the user? Drop them completely? (My vote is leave them in the database, but hide them from the user: convert them to inline links both when the page is edited, and when the page is exported to a zip file. This would ease the total abandonment of page refs in 1.3 and beyond.) I.e. I'd rather not make page refs part of the "PhpWikiZip standard" if they're going to be dropped in the next version of PhpWiki. I'm going to be on a road trip from tomorrow morning through Monday, so don't worry if I'm strangely silent. Jeff |
From: Steve W. <sw...@wc...> - 2000-08-03 16:10:38
|
On Thu, 3 Aug 2000, Arno Hollosi wrote: > I'm back from my vacation. Rested or exhausted? ;-) > Jeff's "takeover": :) > Overall I agree with Steve: I've no problem with someone contributing > much more than me or replacing my code and going into a new direction. > Although I'm not too happy about the 100% OOP approach I think I can > live with it once I am familiar with the code. Call me old-fashioned > but I find OOP harder to understand than conventional code. > I had only a brief look at the code so far. Very good work, Jeff. It is excellent work... and you're not alone when you say OOP designs are harder to understand. They are. Even great OOP designs; I think Netscape's approach to the DOM via Javascript is pretty good, but it takes a long time to understand. Perl's CGI.pm was a bad one circa 1996, but I haven't used it since. All of the OOP code I saw at the New York Times on the Web was pretty bad. I think procedural design can be more obvious and intuitive, but don't get me wrong, OOP has long term benefits. LambdaMOO programming also benefits from a really good design. When I think about PhpWiki's "usability" I think of it in three terms: * How easy is it to install and start using? (admin usability) * How easy is it to use the browser interface and navigate/add/edit? (user usability) * And, how easy is it to understand the program design and modify it? (hacker usability) > Tables, and all that fancy stuff: I don't care if this code is > included or not, but I want an easy option to turn that fancy stuff > off (or have it off by default). I think recreating HTML is no > good. It's part of WikiNature to have an easy markup, which newbies > can understand and use without reading any docs. If you want the > HTML-like features then use HTML. Agreed. We'll add tables I suppose. Simple tables. I vow that we will never do nested tables; they can enable HTML in the Wiki if they want that. As long as users can: write paragraphs and LinkToPages they have 90% of what they need, and everything else in the markup language is mostly fluff. > Inline images: > Please leave the markup simple. I opt for > [http://host/inline.jpg] and http://host/as_link.jpg. > I think it's a clear, nice, and above all easy solution. > And no, I don't think the inconsistency with > [http://host/is_a_link.html] hurts. ALT tag? How about just giving > one generic ALT tag to all images? Otherwise allow HTML (see above). Agreed. Images are a low priority, and they can enable HTML if they want. > References: > Well, I guess you know my opinion on these. I see them as burden. > Maybe an option in wiki_config to turn them off? Once I've hacked in [http://inlined.png] and http://linked.png, we can either abandon them or ignore them. We'll drop them in 2.0. > Admin as WikiPages: > Good idea. Yes, it's so simple and perfect I can't believe I didn't think of it! > If I interpret the situation right, then we will abandon 1.1.7 and > switch to Jeff's code instead, right? If that is so, is 1.1.7 in a > state that is suitable to be left as is? Maybe someone else wants > to take this as a base instead of Jeff's code. If we need to do some > cleanup, then we should do it now. We will not abandon 1.1.7 (to be 1.2). I want to finish it up and the list of things to do is not very long. Jeff, would it be hard to hack the admin design you came up with into the 1.1.7 tree? I think Jeff's work may form the basis of 2.0... I want to discuss a few coding guidelines soon, because the "code usability" is important to the hackers out there so they can understand/extend/hack PhpWiki. sw ...............................ooo0000ooo................................. Hear FM quality freeform radio through the Internet: http://wcsb.org/ home page: www.wcsb.org/~swain |
From: Arno H. <aho...@in...> - 2000-08-03 14:28:24
|
Hi folks, I'm back from my vacation. Wow :o) Quite some news since I left. Jeff's "takeover": :) Overall I agree with Steve: I've no problem with someone contributing much more than me or replacing my code and going into a new direction. Although I'm not too happy about the 100% OOP approach I think I can live with it once I am familiar with the code. Call me old-fashioned but I find OOP harder to understand than conventional code. I had only a brief look at the code so far. Very good work, Jeff. I will write another email once I've dived deeper into it. Tables, and all that fancy stuff: I don't care if this code is included or not, but I want an easy option to turn that fancy stuff off (or have it off by default). I think recreating HTML is no good. It's part of WikiNature to have an easy markup, which newbies can understand and use without reading any docs. If you want the HTML-like features then use HTML. Inline images: Please leave the markup simple. I opt for [http://host/inline.jpg] and http://host/as_link.jpg. I think it's a clear, nice, and above all easy solution. And no, I don't think the inconsistency with [http://host/is_a_link.html] hurts. ALT tag? How about just giving one generic ALT tag to all images? Otherwise allow HTML (see above). References: Well, I guess you know my opinion on these. I see them as burden. Maybe an option in wiki_config to turn them off? Admin as WikiPages: Good idea. That's about it for the nitty, gritty details. Steve said: I want PhpWiki to be the best designed, easiest to install and most featureful Wiki out there. Let's keep the big picture in mind. Good design means modularity, easy to configure, easy to administer, easy to extend. It also means good documentation, so that other hackers out there can easily create new modules for their needs. Eventually some of these modules will flow back into the main distribution of phpwiki. I'm not sure the current phpwiki rates high in all these categories. So I suggest to focus our attention more on these issues than fancy new features. Features will creep in without us even noticing :o) If I interpret the situation right, then we will abandon 1.1.7 and switch to Jeff's code instead, right? If that is so, is 1.1.7 in a state that is suitable to be left as is? Maybe someone else wants to take this as a base instead of Jeff's code. If we need to do some cleanup, then we should do it now. /Arno p.s: Jeff wrote (about bold & italics): > Actually, my original intent was to handle this via regexps. > Ie. the regexp for the __Bold__ expressions should have been: > "__[^_'](?:[^_']+|_(?!_)|'(?!'))+(?<!_)__" > There! Haha. Make sense? It does. Although it saddens me to see that I can't do this: "__'cool'__ he said." ;-P |
From: Jeff D. <da...@da...> - 2000-07-29 01:05:51
|
I've checked in my latest (extensive) hacks into the jeffs_hacks-branch of the CVS repository. Take a look. I'm sure there are bugs. Jeff |
From: Steve W. <sw...@wc...> - 2000-07-28 16:09:39
|
On Fri, 28 Jul 2000, Jeff Dairiki wrote: > Once (if) the code is working, I see reason to let paranoia be the motivation > for saving whole pages. I think some criteria like: > > if ( ( [number of lines in diff] < [number of lines in page] / FACTOR ) > || ( version % INTERVAL != 0 ) ) > [Save diff] > else > [Save whole page] > > would work fine. Simple solution. Hard to read though ;-) > >Sure, check it into your hacks branch... I checked it out a couple of days > >ago but was unable to make it work. I like the new switch:case in > >index.php3. > > Why wouldn't it work? Any ideas? Yes: Syntax error on line 286 of wiki_renderlib.php3. I tried to figure out why it thought so but in the 5 minutes I spent it just didn't want to instantiate any objects for some reason. (Line 286 has a call to new for some class and the method has a comment in the param list). > I could take them or leave them personally. I added it is an example > extension module. The idea is that table support (or whatever) can be > added by including a extension module in wiki_config. (Same thing for > inline HTML.) Inline images could be done the same way. I see. Sounds neat! > Speaking of which, another way to handle the inline image idea > is to allow <IMG> tags within the page. (They would have to be parsed > enough to make sure the URL's in them were sane.) Hrmm. In the direction you are going, would it be possible to let the Wiki admin: * choose classic Wiki markup * choose extended Wiki markup * choose basic HTML * or create their own markup as the markup language, when the Wiki is first set up? I wouldn't want to allow them to choose all of them necessarily, if it means conflicts and parsing headaches. > Yes this would require both account and session information to be stored in > the database, but would be straightforward enough. Then one would have the > hooks for other fancy features like "mail me a note whenever this page > changes". People have asked for that, and I think they will be less than happy if the Wiki is really active and they get flooded... for low activity Wikis I think that's fine, and I'd email the whole page plus the diff and a link to edit the page, drawing them back into the Wiki. > And when and if you (all) give the word I'm happy to be the one to merge my > hacks back into the main branch. (Either all of them or some of them.) I'll buy you a beer someday :-) sw ...............................ooo0000ooo................................. Hear FM quality freeform radio through the Internet: http://wcsb.org/ home page: www.wcsb.org/~swain |
From: Steve W. <sw...@wc...> - 2000-07-28 14:07:39
|
On Thu, 27 Jul 2000, Jeff Dairiki wrote: > My guess is that you definitely don't want to apply 100 patches to go back > 100 versions --- I'm sure that would take a while. Applying 10 patches is > probably fine as long as they're reasonable size. > > Now that I've thought about it awhile I don't think you'd want to store > exclusively diffs. I think small diffs should be stored as diffs. For bigger > diffs (the storage gains are smaller compared the speed loss) and one might > as well just store the whole page. Probably there should be some limit on > the diff chain length as well. I've thought along similar lines; there must be a reasonable scheme where every 10th page is whole and the rest are diffs, or author "commits" are diffs but changes between authors are stored as whole pages. > I'm a bit embarrassed to admit it but I've continued hacking here off and > on for the past week, and have gotten PhpWiki to a totally unrecognizable > state. > > Now, in my home version I've: > > Redone the database interface comepletely. I've added support for > multiple archived versions. The links table (MySQL) is now used for > proper and quick backlinks searches. Of course it's object oriented. > The schema are all changed. MySQL and DBM backends are both working. > Then I started worrying about the user interface too. (What I've done so > far is add a history page --- much like the info page, but more compact --- > which lists versions, dates, authors, and has links to views and diffs of > each version.) too cool! > Writing all these pages and links was giving me template headaches so > I started working on a new template scheme. First I tried PHPlib's templates > --- which I think have some good ideas --- but wasn't happy. I'm pretty > happy with what I've got now. Almost all of the HTML and I think all > of the output text is in the templates now. The templates support > conditional chunks of output and loops. > > So I'm not sure any of the original (meaning 1.1.7!) code remains in > my version. As I said, I'm a bit embarrassed. I certainly don't want to > take over your project. However, you're more than welcome to my code. Nah, don't be embarassed! It sounds like you've added some great things. I'd love to see it all in action. > Let me know your level of interest. I can either check it into the CVS, > either in the jeffs_hacks branch, or some other new branch. Or I get > a tar file to you. Sure, check it into your hacks branch... I checked it out a couple of days ago but was unable to make it work. I like the new switch:case in index.php3. > Note that tables are in the jeffs_hacks-branch of the CVS already. > The syntax (copied from some Wiki --- I can't remember which at the moment > is > > || column 1 text || column 2 text || column 3 text > |{ left aligned text || centered text |} right aligned text I guess one cannot hold back the tide ;-) > Another interesting idea I've put into my home hacks is to do away with the > admin page. Instead one can browse the Wiki in admin mode (through admin.php3 > instead of index.php3). It's identical to normal mode, except there is > a button on each page to lock/unlock it, (and you can edit locked pages). This is the best idea yet. It makes great sense and it would greatly reduce the amount of code we have! I wish I'd thought of it. What I want to add eventually is something on the level of a mailing list's authentication: user fills out registration (just a name and email address), a password is mailed to the account, and the user can optionally change it down the road. This simple access allows them to edit pages. A lot of people are sqeamish about using Wikis because they think the pages will be erased and filled with uuencoded warez and pr0n. With version control and auth, they have some peace of mind. I can't speak for Arno but if all of my code is replaced, I could care less (I will just contribute more) because I want PhpWiki to be the best designed, easiest to install and most featureful Wiki out there, and I want you and Arno to get all the credit for your work! I only wish you would have made more stingent demands to objectify pagehash and the database, and I would have listened (or should have?) because I want my codevelopers to be happy... instead of forking the code... but it's never too late :-) sw ...............................ooo0000ooo................................. Hear FM quality freeform radio through the Internet: http://wcsb.org/ home page: www.wcsb.org/~swain |
From: Jeff D. <da...@da...> - 2000-07-28 05:28:36
|
In message <Pin...@bo...>,Steve Wai nstead writes: > >Jeff, I'm adding things to PhpWikiBrainstorm and I'm wondering.. is it >easy to store the diffs instead of the whole pages? And would it be hard >to iterate through the diffs and reconstitute version 5 of a page that's >up to version 7? 10? 30? My guess is that you definitely don't want to apply 100 patches to go back 100 versions --- I'm sure that would take a while. Applying 10 patches is probably fine as long as they're reasonable size. Now that I've thought about it awhile I don't think you'd want to store exclusively diffs. I think small diffs should be stored as diffs. For bigger diffs (the storage gains are smaller compared the speed loss) and one might as well just store the whole page. Probably there should be some limit on the diff chain length as well. >I know we want to store all versions of a page for safety reasons, and I'm >wrangling with what the user interface should look like. I'm a bit embarrassed to admit it but I've continued hacking here off and on for the past week, and have gotten PhpWiki to a totally unrecognizable state. Now, in my home version I've: Redone the database interface comepletely. I've added support for multiple archived versions. The links table (MySQL) is now used for proper and quick backlinks searches. Of course it's object oriented. The schema are all changed. MySQL and DBM backends are both working. Then I started worrying about the user interface too. (What I've done so far is add a history page --- much like the info page, but more compact --- which lists versions, dates, authors, and has links to views and diffs of each version.) Writing all these pages and links was giving me template headaches so I started working on a new template scheme. First I tried PHPlib's templates --- which I think have some good ideas --- but wasn't happy. I'm pretty happy with what I've got now. Almost all of the HTML and I think all of the output text is in the templates now. The templates support conditional chunks of output and loops. So I'm not sure any of the original (meaning 1.1.7!) code remains in my version. As I said, I'm a bit embarrassed. I certainly don't want to take over your project. However, you're more than welcome to my code. Let me know your level of interest. I can either check it into the CVS, either in the jeffs_hacks branch, or some other new branch. Or I get a tar file to you. Note that tables are in the jeffs_hacks-branch of the CVS already. The syntax (copied from some Wiki --- I can't remember which at the moment is || column 1 text || column 2 text || column 3 text |{ left aligned text || centered text |} right aligned text Jeff Another interesting idea I've put into my home hacks is to do away with the admin page. Instead one can browse the Wiki in admin mode (through admin.php3 instead of index.php3). It's identical to normal mode, except there is a button on each page to lock/unlock it, (and you can edit locked pages). The admin page is replaced by a regular Wiki page. There are special tokens like %%WikiZip%% (analagous to %%Search%%) which produce a button which will get you a zip archive. (There's a %%Login%% button which will switch you to browsing through admin.php3, or you could do it by just manually entering the url.) |
From: Steve W. <sw...@wc...> - 2000-07-28 04:11:50
|
Here is a user-contributed patch for tables... and a MySQL bug. What do you guys think of adding tables? sw ---- Okay, this patch includes a fix for MySQL. it calles set_magic_quotes_runtime(0), which was on by default in my php install, and it broke everything. The other few things are just feature enhancements added by me. I added a history to the top (check http://crunchydog.adhesive.com/wiki), and I also added a way to make tables too, this may be a little too complicated for the tidy stripped-down mark-up language you've created, but here's an example: ^^ ^Cell 1|Cell 2|Cell 3$ ^Cell 1|Cell 2|Cell 3$ $$ Anyway, you're free to use any or all of this stuff if you'd like. -- Hawk Newton -- Hawk Newton RHCE ha...@ad... Adhesive R&D 512-647-1200 Adhesive Software http://www.adhesive.com |
From: Steve W. <sw...@wc...> - 2000-07-28 03:50:12
|
Jeff, I'm adding things to PhpWikiBrainstorm and I'm wondering.. is it easy to store the diffs instead of the whole pages? And would it be hard to iterate through the diffs and reconstitute version 5 of a page that's up to version 7? 10? 30? I know we want to store all versions of a page for safety reasons, and I'm wrangling with what the user interface should look like. sw ...............................ooo0000ooo................................. Hear FM quality freeform radio through the Internet: http://wcsb.org/ home page: www.wcsb.org/~swain |
From: Steve W. <sw...@wc...> - 2000-07-27 03:46:40
|
On Wed, 19 Jul 2000, Jeff Dairiki wrote: > On a related note: what about trying to phase out the page references > altogether? As far as I can see (except for the case of inlined > images) [1] with the appropriate entry in the page references is > identical in function to [1|http://www.foo.bar/wazoo.html]. Good point. Again, references were something we inhereted from classic Wiki. Arno made a good case to drop them when we started out on 1.1, but I was stubborn because some people use and like them (that is, people that emailed me, not my imaginary friends ;-) I am intrigued however by a change Ari made in the NBTSC PhpWiki where references are no more, they are instead "footnotes" in the classic sense: http://www.nbtsc.org/wiki/MarkupTest I haven't read the code for this yet. Whether it has value or not, I don't know, but it looks cool at least :-) Another reason I had was that references are the way to embed images... so in the end the compomise we made was to jam the references in one column and get a D- in database design. I guess I was also enamored with backwards compatibility. > If you're going to invent new syntax, how about something that doesn't > create any more special characters. Maybe something like > > [ INLINE | alt text | http://foo.com/img.png ] > > Yeah, it's ugly. There's probably something better. > > A couple of things to think about: > > To by lynx friendly, it would be nice to be able to specify ALT text > for an inlined image. > > One of the reasons I personally don't use the wiki inlined images very > much is that there's currently no way to specify the image size. > With my browser, that means I don't get to see any of the page until > the image loads. I hate that. > > One could create syntax for specifying image size: > > [ INLINE 20x60 | alt text | http://foo.com/img.png ] > > Or to get fancy, one might be able to have PhpWiki fetch the image > once (in a while) and cache the size. Ugh. I should start a WikiPage on ReinventingHtml. How about no embedded images? :-) sw ...............................ooo0000ooo................................. Hear FM quality freeform radio through the Internet: http://wcsb.org/ home page: www.wcsb.org/~swain |
From: Steve W. <sw...@wc...> - 2000-07-27 03:35:37
|
Just catching up on the week's posts... On Tue, 18 Jul 2000, Jeff Dairiki wrote: > 1. Transform "''"s > 2. Transform "'''"s > 3. Transform "__"s > 4. Transform "''"s again > 5. Transform "'''"s again > > This, I think, handles everything that your method does (while eliminating > the possibility of invalid HTML output.) Hmm. Don't forget ''''' :-) sw ...............................ooo0000ooo................................. Hear FM quality freeform radio through the Internet: http://wcsb.org/ home page: www.wcsb.org/~swain |
From: Steve W. <sw...@wc...> - 2000-07-26 04:10:09
|
Michael wrote me with problems using the admin/ tools... he was just getting a server error. It looks like some weirdness with his server configuration, and he ultimately did away with wiki_auth.php3 and installed his own .htaccess file. sw > > >2. If I try to start /admin/index.php3 I get an "error 500: intern > > >server error". > > > > No solution. > > Hmm. It will try to do basic HTTP authentication, promting you for a > login/password. I wonder if your version of Apache has auth enabled? > > You could try commenting out the block that tries to authenticate you > and see if you can access the forms... that would be a big help if we > knew to look for this. Now it works. 1. My ISP has only .php3, not .php included for running PHP. I have altered the file names etc. 2. If I insert a blank line before the first line in admin/index.php3 I don't get the error 500 (strange???) 3. I don't get a prompt for the password, so I think my ISP don't has auth enabled. 4. I have wiki_auth..php3 commented out and a .htaccess included in the admin directory - no sloppy systems administration ;) 5. The directories in wiki_config.php3 don't work for admin/php3. I have included a $AdminArchiveDataBase with a "../" before the path from $ArchiveDataBase. Thank you for the hints. It was a big help! best regards Michael d. Eschner ...............................ooo0000ooo................................. Hear FM quality freeform radio through the Internet: http://wcsb.org/ home page: www.wcsb.org/~swain |
From: Jeff D. <da...@da...> - 2000-07-21 18:45:51
|
I've cleaned up the new wiki_transform code somewhat. I'm still tokenizing the __bold__ and ''italic''s, but I think I've found a cleaner way around the "recursable" problem. I've also added support for pagenames in $PATH_INFO (configurable in wiki_config with the WIKI_PAGENAME_IN_PATHINFO constant.) I've created a new branch ("jeffs_hacks-branch") in the CVS repository which contains both of these hacks. (To get it, you need to add the '-rjeffs_hacks-branch' option to the 'cvs checkout' command.) Comments are hereby solicited. Jeff |
From: Steve W. <sw...@wc...> - 2000-07-20 01:10:36
|
I'll be off the net most of Thursday-Monday, while I'm in Cleveland for a wedding. Just so you know if I'm not at all responsive :-) sw ...............................ooo0000ooo................................. Hear FM quality freeform radio through the Internet: http://wcsb.org/ home page: www.wcsb.org/~swain |
From: Jeff D. <da...@da...> - 2000-07-19 22:19:45
|
On a related note: what about trying to phase out the page references altogether? As far as I can see (except for the case of inlined images) [1] with the appropriate entry in the page references is identical in function to [1|http://www.foo.bar/wazoo.html]. Now... In message <Pin...@bo...>,Steve Wai nstead writes: >But unnamed, bracketed image links do: > >[http://phpwiki.sourceforge.net/phpwiki/png.png] > >Does anyone see any obvious flaws to this? Nothing terrible. But it sort of breaks my intuitive feeling that [http://foo/bar.png] should be equivalent to http://foo/bar.png in the same way that [WikiWord] is equivalent to WikiWord. > Would you rather introduce a > new construct, which might be more intuitive, like: > >{http://phpwiki.sourceforge.net/phpwiki/png.png} If you're going to invent new syntax, how about something that doesn't create any more special characters. Maybe something like [ INLINE | alt text | http://foo.com/img.png ] Yeah, it's ugly. There's probably something better. A couple of things to think about: To by lynx friendly, it would be nice to be able to specify ALT text for an inlined image. One of the reasons I personally don't use the wiki inlined images very much is that there's currently no way to specify the image size. With my browser, that means I don't get to see any of the page until the image loads. I hate that. One could create syntax for specifying image size: [ INLINE 20x60 | alt text | http://foo.com/img.png ] Or to get fancy, one might be able to have PhpWiki fetch the image once (in a while) and cache the size. In other news. The CVS problem appears to be fixed. You can now check out (or otherwise use) named revisions. I've mostly finished hacking in PATH_INFO support (switchable in wiki_config.) Soon (probably tomorrow) I'll check it into a branch ("jeffs_pathinfo_hacks-branch") in the CVS so y'all can inspect it. Jeff |
From: Steve W. <sw...@wc...> - 2000-07-19 21:12:22
|
I helped a PhpWiki user/operator with the hairy process of embedding an image file (which requires the use of "references"). This reminded me of a small change I was thinking of some time ago and I want everyone's feedback before I put it in place: Raw URLs do not get embedded: http://phpwiki.sourceforge.net/phpwiki/png.png Named URLs do not get embedded: [Check out this great art|http://phpwiki.sourceforge.net/phpwiki/png.png] But unnamed, bracketed image links do: [http://phpwiki.sourceforge.net/phpwiki/png.png] Does anyone see any obvious flaws to this? Would you rather introduce a new construct, which might be more intuitive, like: {http://phpwiki.sourceforge.net/phpwiki/png.png} ? The latter approach means that the use of [] is consistent. sw ...............................ooo0000ooo................................. Hear FM quality freeform radio through the Internet: http://wcsb.org/ home page: www.wcsb.org/~swain |