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: Jeff D. <da...@da...> - 2001-09-18 15:08:43
|
On Sep 18, 2001, Reini Urban said: > > I don't know why now, but I have added "ellemtel" somewhen: > > phpwiki-footer: > // For emacs users > // Local Variables: > // mode: php > // tab-width: 8 > // c-basic-offset: 4 > // c-hanging-comment-ender-p: nil > // indent-tabs-mode: nil > // c-file-style: "ellemtel" > // End: > ?> That's my fault, probably. Ellemtel's (whoever he was) style matches the _old_ PhpWiki style best, but does not work so well for the new, PEAR indentation style. 'Gnu' (which is the default for php-mode) is the style I've been using as of late. But, note also that you can't use 'c-file-style: gnu' in the file local variable hooks section. If you do, (c-set-style 'gnu') which gets called after the other file local variables get set up, resets c-basic-offset (and others) to the defaults for the style. (The default is c-basic-offset=2 for the gnu style.) Jeff |
From: Reini U. <ru...@x-...> - 2001-09-18 11:16:38
|
Jeff Dairiki schrieb: > Here's what I'm proposing we use: > // Local Variables: > // mode: php > // tab-width: 8 > // c-basic-offset: 4 > // c-hanging-comment-ender-p: nil > // indent-tabs-mode: nil > // End: I don't know why now, but I have added "ellemtel" somewhen: phpwiki-footer: // For emacs users // Local Variables: // mode: php // tab-width: 8 // c-basic-offset: 4 // c-hanging-comment-ender-p: nil // indent-tabs-mode: nil // c-file-style: "ellemtel" // End: ?> W:\XEmacs\xemacs-packages\lisp\cc-mode\cc-styles.el defines this: ("ellemtel" (c-basic-offset . 3) (c-comment-only-line-offset . 0) (c-hanging-braces-alist . ((substatement-open before after))) (c-offsets-alist . ((topmost-intro . 0) (topmost-intro-cont . 0) (substatement . +) (substatement-open . 0) (case-label . +) (access-label . -) (inclass . ++) (inline-open . 0) )) ) We could add a "PEAR" style table to cc-styles.el somewhen later. But local overrides are always better. ("PEAR" (tab-width . 8) (indent-tabs-mode . nil) (c-basic-offset . 4) (c-hanging-comment-ender-p . 0) (c-comment-only-line-offset . 0) (c-hanging-braces-alist . ((substatement-open before after))) (c-offsets-alist . ((topmost-intro . 0) (topmost-intro-cont . 0) (substatement . +) (substatement-open . 0) (case-label . +) (access-label . -) (inclass . ++) (inline-open . 0) )) ) -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ |
From: Reini U. <ru...@x-...> - 2001-09-18 11:00:14
|
Jeff Dairiki schrieb: > I recently had an idea: require every registered user to have a > WikiHomepage. The user's userid would be the same as the pagename > of their homepage. > Is this a crackpot idea or a stroke of genious? More the latter. But a user table is still needed for the password, email and page change notifications. I wouldn't store this in the homepage as metadata. Or do you have an idea to protect it for other users? (not viewable metadata, but editable for the owner...) -- Reini Urban |
From: J C L. <cl...@ka...> - 2001-09-18 07:52:31
|
On Mon, 17 Sep 2001 11:09:39 -0700 Jeff Dairiki <da...@da...> wrote: > What to do? Should you be allowed to take over the existing > page as your homepage? (What if you were trying to register under > the userid of FrontPage or CategoryNextWiki?) This becomes easier if you make add support for a hierarchial namespace (SubNodes) and then make people's pages bot a subnodes of a common node (eg People), and then disallow other than automatic creation of pages there. This has the pleasant side effect of allowing the person's own page to (depending on your clocking choices) to be under their control, which other pages out in the publicly controlled namespace are more laissez faire. -- J C Lawrence ---------(*) Satan, oscillate my metallic sonatas. cl...@ka... He lived as a devil, eh? http://www.kanga.nu/~claw/ Evil is a name of a foeman, as I live. |
From: Steve W. <sw...@pa...> - 2001-09-18 04:09:13
|
On Tue, 18 Sep 2001, Pablo Roca wrote: > I'm just thinking in implementing a better auth system, but I don't know > if doing this in the 1.2 stable or wait till 1.3 this will depend on the > timeline for having 1.3 released. Don't make any major changes to a 1.2 version, please... I would rather stick to minor bug fixes or small changes for 1.2 and put the new features into 1.3. cheers ~swain --- http://www.panix.com/~swain/ "Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid." -- Frank Zappa http://pgp.document_type.org:11371/pks/lookup?op=get&search=0xF7323BAC |
From: Pablo R. <pr...@cl...> - 2001-09-18 02:53:56
|
> de Adam Shand > Enviado el: lunes, 17 de septiembre de 2001 23:09 > another feature that might be nice would be if a page could > have multiple owners or maybe a group owner (and people can > belong to a group). this all starts to get more complex but > could be really useful. Yes this can be done but using two tables: user & groups, is more complex but more flexible, sure. A small intro is done here: http://www.opengate-team.org/phpwiki.php?OpenGate%20authorisation And here: http://postnuke.omaja.com/wiki/?UserAuthSystem Saludos, Pablo Roca |
From: Pablo R. <pr...@cl...> - 2001-09-18 02:44:14
|
> de Steve Wainstead > Enviado el: lunes, 17 de septiembre de 2001 19:29 > What I would really like to see added is user registration, > where users must have a valid email address to register with > the Wiki. This would be useful for a public wiki that only > allows members to edit pages, and guests can only browse. In > corporate intranets this would be essential. Yes, totally agreed. Time ago I did a hack in the phpwiki 1.2 for auth into PHPNuke 4.4, you can test at: http://www.opengate-team.org/phpwiki.php If you are not a registered member you can't edit pages, and also the user name is registered after a change. And only the admins are allowed to edit locked pages. I'm just thinking in implementing a better auth system, but I don't know if doing this in the 1.2 stable or wait till 1.3 this will depend on the timeline for having 1.3 released. The better way at all, would be having a funtion is_user() or similar, that any intranet or portal developer, can change for having is own authetification. Saludos, Pablo Roca |
From: Pablo R. <pr...@cl...> - 2001-09-18 02:44:14
|
> de Philip J. Hollenback > Enviado el: lunes, 17 de septiembre de 2001 20:27 > 1. file uploads. > 2. tables. Good points, I also want to add one more: - Subscribing for page changes. Posibility to subscribe to a page and if this page changes send an email alert to the user for going to the page. But I think this could belong to auth. Saludos, Pablo Roca |
From: Pablo R. <pr...@cl...> - 2001-09-18 02:30:52
|
> de Jeff Dairiki > Enviado el: lunes, 17 de septiembre de 2001 19:19 > I recently had an idea: require every registered user to have a > WikiHomepage. Hum .. Jeff .. Not a bad idea at all, but I rather prefer to have a user table, cause some users are very lazy for putting the needed info. Or putting an invalid email ..., and this will increase the wikidb for the pages. And ... How will you store the passwords there? Pablo Roca |
From: Pablo R. <pr...@cl...> - 2001-09-18 02:25:17
|
> de Jeff Dairiki > Enviado el: lunes, 17 de septiembre de 2001 19:19 > I recently had an idea: require every registered user to have a > WikiHomepage. Hum ... Sorry for saying this Jeff, I'm totally disagree with this. Think that many users (err. Well for one of my webs, dont have a Wiki, don't know how to set a Pablo Roca |
From: Pablo R. <pr...@cl...> - 2001-09-18 02:20:27
|
Reini wrote: > I'm not really familiar with the term "ticket tracking". Agreed Reini. I also don't understand what Joe is trying to do. Maybe I'm not english spoken ... Pablo Roca |
From: Steve W. <sw...@pa...> - 2001-09-18 00:31:08
|
The code, of course, is already out there... http://www.phpbuilder.com/columns/bealers20000904.php3 This could be tied to a special form for uploading files... how to reference them, though, would have to be worked out. Possibly we could just allow the filename in brackets [foo.jpg] to look in the directory where image files are uploaded, and it gets dropped in. ~swain On Mon, 17 Sep 2001, Philip J. Hollenback wrote: > Thanks for the info. Does anyone have any suggestions for how to > implement file uploads given the current phpwiki framework? ftp or > something? > > If I can figure that out, phpwiki will really work great as a web > photo album. As it is right now I have to manually upload all my > images to the server first before I can use them in my wiki. > > It sounds like I should stay with 1.2 until the development branch > stabilizes a bit. I will perhaps apply the tables patch for 1.2 as > that seems to work ok. > > P. > > On Setting Orange, the 41st of Bureaucracy, Jeff Dairiki spake: > > On Sep 17, 2001, "Philip J. Hollenback" said: > > > > > > So are these two things available in the development version? I know > > > there is a patch available for tables, but has it been integrated? > > > > The current CVS code does include the table mark-up. It does not > > include support for file uploads. > > > > > Is the development version usable and stable? > > > > It's usable now. As for stable: it's about to go through a very large > > refactoring, involving big changes to the php code as well as > > the database schema. So no, it's not stable, at least not for long. > > > > Jeff > > > > > > -- > Philip J. Hollenback > ph...@po... > http://www.hollenback.net > > _______________________________________________ > Phpwiki-talk mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwiki-talk > --- http://www.panix.com/~swain/ "Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid." -- Frank Zappa http://pgp.document_type.org:11371/pks/lookup?op=get&search=0xF7323BAC |
From: Adam S. <ad...@pe...> - 2001-09-17 23:13:30
|
> If I can figure that out, phpwiki will really work great as a web > photo album. As it is right now I have to manually upload all my > images to the server first before I can use them in my wiki. I've been trying to figure out how to turn a wiki into a *good* photo album for a while. I think the plugin stuff and file uploads could do most of it. For file uploads i'd like files associated with a particular page, and each page should have a list of the files associated at the bottom (the way twiki does it is pretty cool). Then for the actual gallery maybe a new page type (maybe pages like this GalleryAdamBirthday2001) and then have the gallery plugin parse the attached files into a gallery format. The best I can think of is have the plugin automatically generate thumbnails if they don't already exist and then take arguemtns for display values: <?plugin Gallery AutoThumb=yes Columns=4 Thumbs=128x128 ?> Clicking on a thumbnail would then pop the full size picture up in a new window, and the new window would also allow you to go from picture to picture slide show fashion. having some way to reference images in the gallery could also be useful (maybe via some InterWiki magic?) so you can referrence full size pictures or the thumbnails via wiki links for inclusion in other pages. anyway, still just thinking outloud. adam. |
From: Philip J. H. <ph...@ho...> - 2001-09-17 22:55:06
|
Thanks for the info. Does anyone have any suggestions for how to implement file uploads given the current phpwiki framework? ftp or something? If I can figure that out, phpwiki will really work great as a web photo album. As it is right now I have to manually upload all my images to the server first before I can use them in my wiki. It sounds like I should stay with 1.2 until the development branch stabilizes a bit. I will perhaps apply the tables patch for 1.2 as that seems to work ok. P. On Setting Orange, the 41st of Bureaucracy, Jeff Dairiki spake: > On Sep 17, 2001, "Philip J. Hollenback" said: > > > > So are these two things available in the development version? I know > > there is a patch available for tables, but has it been integrated? > > The current CVS code does include the table mark-up. It does not > include support for file uploads. > > > Is the development version usable and stable? > > It's usable now. As for stable: it's about to go through a very large > refactoring, involving big changes to the php code as well as > the database schema. So no, it's not stable, at least not for long. > > Jeff > > -- Philip J. Hollenback ph...@po... http://www.hollenback.net |
From: Adam S. <ad...@pe...> - 2001-09-17 21:09:31
|
> Both seem like clean solutions to the partial locking problem. (Of > course they are of limited use until user authentication is > implemented more completely.) another feature that might be nice would be if a page could have multiple owners or maybe a group owner (and people can belong to a group). this all starts to get more complex but could be really useful. i've had thoughts about tying this into a weblogs karma system, so that any user with positive karma can edit the wiki pages. this provides a way for the community to deal with wiki spammers, and also makes it harder for someone brand new to the page to trash stuff, they have to hang around a little and contribute a bit to get privledges. > Disadvantages: Somewhat kludgy, perhaps. Somewhat restrictive: if a > pagename already exists, one must somehow usurp it (perhaps with admin > assistance ?) to use it as a userid. i don't see that as a problem, it just means that that username is unavailable, which could hapen anyway if there are two AdamShand's on the wiki. if the page name is taken you need to choose a new username. > Is this a crackpot idea or a stroke of genious? i think this is a good idea. adam. |
From: Steve W. <sw...@pa...> - 2001-09-17 19:17:43
|
On Mon, 17 Sep 2001, Jeff Dairiki wrote: > > Hmm. As a serialized string? You might want to expand on this. I think the > > idea of them having a home page on the wiki is a natural. > > The new database API allows (more-or-less) for arbitrary key/value pairs > to be attached to pages as meta-data. This data is accessed via the > WikiDB_Page::get() and WikiDB_Page::set() methods. (And yes, the > implementation involves storing a serialized hash.) So this is a real > quick-and-dirty place to store user meta-data if we establish a > correspondence > between users and pages. OK... my experience has been, whenever you denormalize the database design, you wind up wanting to get at the info that's no longer atomic. In this case it might be better to just go ahead and create a user table, since we will have one anyhow, no matter what. User auth is coming and storing users and pages in the same table will cause problems. > Yes, my main point of concern/confusion right now concerns the > following scenario: > > You attempt to register (via some automatic scheme, like the one > you've outlined below) as a new user with the userid SteveWainstead. > > The page SteveWainstead already exists. > > What to do? Should you be allowed to take over the existing page > as your homepage? (What if you were trying to register under the > userid of FrontPage or CategoryNextWiki?) > > (I guess this scenario addresses a more generic issue than that of just > user registration --- more that of page ownership. Who should be > allowed > to own/lock which (pre-existing) pages?) For now we might just let the username link to a page of the same name, and if they want to be called HomePage, well, what can one do. > Yes. This is what has been in the back of mind (I think you planted > the seed there) for awhile now. I keep hoping to find some > pre-written library which handles the details, but I don't think > were going to find one... I haven't looked... there must be something like this. On a similar note, how hard would it be to make the diff engine a module people could reuse? ~swain --- http://www.panix.com/~swain/ "Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid." -- Frank Zappa http://pgp.document_type.org:11371/pks/lookup?op=get&search=0xF7323BAC |
From: Steve W. <sw...@pa...> - 2001-09-17 18:59:22
|
On Mon, 17 Sep 2001, Adam Shand wrote: > > are probably not a good idea, unfortunately. Hash marks are already > > used by PhpWiki for numbered lists... how about: > > > > %% > > @@ > > what about a semi-colon? at least that is used for comments in somethings > so should be kinda intuitive. or maybe two semi-colons? otherwise it > doesn't really matter. ;; this is a comment in lisp ; so is this ;-) ~swain --- http://www.panix.com/~swain/ "Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid." -- Frank Zappa http://pgp.document_type.org:11371/pks/lookup?op=get&search=0xF7323BAC |
From: Jeff D. <da...@da...> - 2001-09-17 18:48:49
|
On Sep 17, 2001, "Philip J. Hollenback" said: > > So are these two things available in the development version? I know > there is a patch available for tables, but has it been integrated? The current CVS code does include the table mark-up. It does not include support for file uploads. > Is the development version usable and stable? It's usable now. As for stable: it's about to go through a very large refactoring, involving big changes to the php code as well as the database schema. So no, it's not stable, at least not for long. Jeff |
From: Adam S. <ad...@pe...> - 2001-09-17 18:47:09
|
> Wikis are commonly used by development folks as a sort of > whiteboard/on the fly documentation system. This means any common > comment tokens like probably a good point. > are probably not a good idea, unfortunately. Hash marks are already > used by PhpWiki for numbered lists... how about: > > %% > @@ what about a semi-colon? at least that is used for comments in somethings so should be kinda intuitive. or maybe two semi-colons? otherwise it doesn't really matter. oh, and i thought of another good reason for category/sub-category metadata. in intranet environments (cause i'm working on getting a wiki installed at work to replace our existing intranet). if category information is meta data then you could use it for governing permissions to view/edit/etc a page, it also means it's easier to enforce some structure on a wiki ... which i know is wiki ananthma :-) but it's also really useful for some settings. maybe you could have the drop box either be dynamically generated based off page names (preserving traditional wiki anarchy), or it could have to updated on a special page or config file (which would be great for more structured environments). anyway, just yell at me if you get sick of me spouting ideas and not contributing anything. i'm working on it. adam. |
From: Seth C. <se...@eu...> - 2001-09-17 18:40:27
|
Ah ha, and here I was going to post a suggestion already.... I am getting ahold of a PHPwiki 'port' that works with PHPNuke/PostNuke. I should have a copy of the code in a few days. The author hasn't cleaned it up, but he says it works. This would allow the use of a wiki module with a Slashdot-ish environment. This would fit some people's need for a more structured webspace, but still have wiki elements. I am also working with PHPgroupware, which is amazingly good with a firm API. PHPGroupware has trouble tickets, and much much more. PHPGW is fast becoming popular, and I for one, will be using it in a great many business environments. To port PHPWiki into a PHPGroupware module seems to make a great deal of sense. With Jeff's hack, a simple plugin would allow links back and forth I'd suspect, with a minimum of problems or coding needed. A PHPGroupware API plugin would give all of the features of PHPgroupware to PHPWiki. (imagine embedding a calendar or todo list). This might also solve the user auth issues we are talking about. Joe, if you are interested in, I suspect making PHPWiki into a PHPgroupware module would give you troubletickets without having to recode a complete trouble ticket system from scratch, and also all sorts of other possiblities with the same codebase. In other words, you'd be adding _far_ more than troubletickets with less work. I suspect we could find people on the other side of the coin, PHPGW coders who would be interested in helping on this too. links: http://www.phpgroupware.org also http://www.phpnuke.com http://www.postnuke.org > On Sat, 8 Sep 2001, Joe Edelman wrote: > > > Hello. I'm a new person interested in hacking on phpWiki. > > > > I have a bit of an agenda, though: I want to use it as an intranet for a > > non-profit I'm putting together, so I want to add some business/intranet > > features. > > > > The only thing I want to add that's not already on your 1.3 to-do list is a > > ticket tracking system. I'd like to be able to embed tickets in wiki pages, > > using a syntax like "((finance:approve))", and then have them visible from a > > ticket tracking system. This could be seen as an extension of what you're > > already doing with search and "CategoryCategory" tags: a new mechanism for > > letting people list and sort pages by certain criteria. > > > > I'm also interested in and willing to help with user authentication and the > > weblog/templating facility you describe. > > > > It seems like I can do these tickets using this new plugin system that Jeff > > has made, although it needs to be extended in a small way. > > > > I'm not quite sure how to proceed: can I assume that Jeff's changes will > > probably become the HEAD? Should I write a proposal about how I might > > implement these tickets, then, and post it to the mailing list fpr review? > > > > Thanks, and thanks for putting this project and this software together-- > > it's something to be proud of. > > |
From: Philip J. H. <ph...@ho...> - 2001-09-17 18:27:08
|
I'm running a 1.2 phpwiki on my site, www.hollenback.net. I am very interested in upgrading to the develomment version for two reasons: 1. file uploads. I want to be able to upload files (pictures) through the wiki and then use them in wiki pages. 2. tables. I'm putting a lot of pictures in my wiki, and not having tables makes the layout very difficult. Since this is a public site, I'm not going to turn on html in pages either. So are these two things available in the development version? I know there is a patch available for tables, but has it been integrated? Is the development version usable and stable? I'm trying to determine if it is worthwile to upgrade at this point to get the new features, or if I should wait and work with what I have now. Thanks, P. -- Philip J. Hollenback ph...@po... http://www.hollenback.net |
From: Jeff D. <da...@da...> - 2001-09-17 18:09:41
|
> Hmm. As a serialized string? You might want to expand on this. I think the > idea of them having a home page on the wiki is a natural. The new database API allows (more-or-less) for arbitrary key/value pairs to be attached to pages as meta-data. This data is accessed via the WikiDB_Page::get() and WikiDB_Page::set() methods. (And yes, the implementation involves storing a serialized hash.) So this is a real quick-and-dirty place to store user meta-data if we establish a correspondence between users and pages. I'm thinking that pages which serve as user homepages would have additional meta-data something like: is_homepage: 1 password: md5:12ef... user_email: <da...@da...> This is data that would otherwise be stored in a separate user database (e.g. /etc/passwd). > Like I said, it just seems like a natural. I would use SteveWainstead or > just 'wainstead' as an ID and would want my name to hyperlink to a page > about me. Yes, my main point of concern/confusion right now concerns the following scenario: You attempt to register (via some automatic scheme, like the one you've outlined below) as a new user with the userid SteveWainstead. The page SteveWainstead already exists. What to do? Should you be allowed to take over the existing page as your homepage? (What if you were trying to register under the userid of FrontPage or CategoryNextWiki?) (I guess this scenario addresses a more generic issue than that of just user registration --- more that of page ownership. Who should be allowed to own/lock which (pre-existing) pages?) > What I would really like to see added is user registration, where users > must have a valid email address to register with the Wiki. This would be > useful for a public wiki that only allows members to edit pages, and > guests can only browse. In corporate intranets this would be essential. Yes. This is what has been in the back of mind (I think you planted the seed there) for awhile now. I keep hoping to find some pre-written library which handles the details, but I don't think were going to find one... |
From: Gary B. <ga...@in...> - 2001-09-17 17:33:02
|
On Mon, 17 Sep 2001, Steve Wainstead wrote: > What I would really like to see added is user registration, where users > must have a valid email address to register with the Wiki. This would be > useful for a public wiki that only allows members to edit pages, and > guests can only browse. In corporate intranets this would be essential. And then you could make it mangle email addresses if you weren't logged in -- instant spam filtering! Gary [ ga...@in... ][ GnuPG 85A8F78B ][ http://inauspicious.org/ ] |
From: Steve W. <sw...@pa...> - 2001-09-17 17:28:43
|
On Mon, 17 Sep 2001, Jeff Dairiki wrote: > I think it was Reini who, some time ago, suggested a couple of ideas: > 1. Append-only pages. > 2. Partially locked pages --- only the part after the first <hr> > ("--------" ) > can be edited. (Except by the page owner, of course.) > Both seem like clean solutions to the partial locking problem. (Of > course > they are of limited use until user authentication is implemented more > completely.) I think it's inevitable that we have append-only mode. It will have many uses. > Which brings us to user authentication. > > I recently had an idea: require every registered user to have a > WikiHomepage. > The user's userid would be the same as the pagename of their homepage. > This accomplishes several things: > 1. Each user has a homepage (which would be linked to from > RecentChanges, etc..) > My guess is that most on wikis with authenticated users, each of > the > authenticated users would have a WikiHomepage with personal > thoughts, > contact information, etc. in any case. > 2. We could store the users meta-data (password, e-mail, etc...) as > part of > their homepages meta-data. This eliminates the need for a > separate > user database. Hmm. As a serialized string? You might want to expand on this. I think the idea of them having a home page on the wiki is a natural. > Disadvantages: Somewhat kludgy, perhaps. Somewhat restrictive: if a > pagename > already exists, one must somehow usurp it (perhaps with admin > assistance ?) > to use it as a userid. > > Is this a crackpot idea or a stroke of genious? Like I said, it just seems like a natural. I would use SteveWainstead or just 'wainstead' as an ID and would want my name to hyperlink to a page about me. What I would really like to see added is user registration, where users must have a valid email address to register with the Wiki. This would be useful for a public wiki that only allows members to edit pages, and guests can only browse. In corporate intranets this would be essential. ~swain --- http://www.panix.com/~swain/ "Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid." -- Frank Zappa http://pgp.document_type.org:11371/pks/lookup?op=get&search=0xF7323BAC |
From: Steve W. <sw...@pa...> - 2001-09-17 17:22:34
|
On Mon, 17 Sep 2001, Jeff Dairiki wrote: > To restate and (hopefully) clarify once again: > > My only beef is with tab-width=4. Setting indent-tabs-mode to nil is, > I think, a fine way to go. But even with that setting, it's almost > inevitable that some real tabs will make their way into the source code. > (The PEAR source code demonstrates this quite well.) I just think those > tabs that do make it into the source code should always be rendered as > eight-space tabs, rather than funky four-space tabs. Aha! OK, now I see what you mean. I thought you wanted to indent code with tabs, which I still have serious misgivings about. tab-width=8 is preferable, indeed, if we are using indent-tabs-mode=nil. > > Here's what I'm proposing we use: > > // Local Variables: > // mode: php > // tab-width: 8 > // c-basic-offset: 4 > // c-hanging-comment-ender-p: nil > // indent-tabs-mode: nil > // End: > > If we include the above cruft in our source code, then you (probably) > don't even need to fix your .emacs. Perfect. We are in agreement and everyone is happy. :-) ~swain --- http://www.panix.com/~swain/ "Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid." -- Frank Zappa http://pgp.document_type.org:11371/pks/lookup?op=get&search=0xF7323BAC |