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
(3) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: John K. <jo...@ke...> - 2002-11-13 00:05:56
|
(Sorry - this should've gone to the list not just Jeff). >Probably not yet. What's the general feeling of everyone else regarding >how long we should keep old-style markup around? Forever? I looked at a whole bunch of wikis and chose phpwiki because of the simplicity of the markup. A lot of my wikis are used by schoolkids aged 7-11 and simple markup makes the difference between them having a go at making themselves a page and not doing. I'm also looking into the possibility of using phpwiki with people with learning difficulties and for building a community reminiscences site for old people in our area. Both of these projects are only feasible with phpwiki's very simple markup. I'm currently at 1.3.2 because I was waiting to see whether old-style markup would stay around for the next stable release. If it's at all possible to keep old-style, please do :) John. -- ------------------------------------ 0113 2289316 / 07944 755613 jo...@ke... / www.kershaw.org AOL johnkershaw / Y! john_m_kershaw ------------------------------------ |
From: Jeff D. <da...@da...> - 2002-11-12 22:59:24
|
> >how long we should keep old-style markup around? > > Forever? That's certainly a possibility, I think. (Another arguement for keeping the old-style markup is that it's certainly more traditional wiki-ish.) > I looked at a whole bunch of wikis and chose phpwiki > because of the simplicity of the markup. A lot of my wikis are used > by schoolkids aged 7-11 and simple markup makes the difference > between them having a go at making themselves a page and not doing. Note that the (or at least my) main motivation for moving to the new markup was to make the syntax more intuitive (i.e. more WYSIWYGish). E.g. you make indented paragraphs like: Here's an idented paragraph. (The old markup involves a leading ";:".) Nested lists are layed out like: * Item 1 * Subitem 1.1 * Subitem 1.2 * Item 2 * Subitem 2.1 |
From: Jeff D. <da...@da...> - 2002-11-12 22:30:03
|
> There still seems to be some bugs > lurking for your fixing pleasure - see > http://mairas.net/wiki/NewTextFormattingRules. _*bold italic*_ doesn't > work yet. Okay. I guess I'll fix things so that _*this*_, *_this_*, (and maybe **this** ?) all mark-up as bold italic. > Unrelated to that, anchor references are rendered with the preceding > hash visible. See the above link for an example as well. You mean that [#anchor] gets marked up as <a href="#anchor">#anchor</a>? That's deliberate --- so you can visually tell [anchor] (link to page) from [#anchor] (link to anchor), and for consistency with [page#anchor] (which shows up as "page#anchor"). You can always use [name|#anchor] (or [anchor|#anchor]) to over-ride the default text... |
From: Matti A. <ma...@ik...> - 2002-11-12 22:11:27
|
Jeff Dairiki wrote: >>is, should I fix NewTextFormattingRules to use the old-style markup, or >>do you think the new markup is going to get reliable enough for real >>use? > I'm not sure I understand that part of your question. > I think the new markup is reliable enough now (at least a reliable as > the rest of the newer features). There may be small changes in > the markup syntax, but I don't envision any wholesale changes... Oh, sorry... I hadn't noticed you already had updated InlineParser.pm. I referred to those parsing bugs. There still seems to be some bugs lurking for your fixing pleasure - see http://mairas.net/wiki/NewTextFormattingRules. _*bold italic*_ doesn't work yet. Unrelated to that, anchor references are rendered with the preceding hash visible. See the above link for an example as well. > (Perhaps also a configuration option to disable the new markup > altogether?) Maybe, but would that hinder the gradual deprecation of old markup? I don't think it'd be a good long-term goal to support both markup versions indefinitely. > When we get to that point, we can either auto-convert old to new > markup upon zip/pgsrc import, or upon page edit... That'd be great! m. |
From: Joby W. <joby@u.washington.edu> - 2002-11-12 21:59:17
|
Jeff Dairiki wrote: >>Jeff, should I consider the old emphasis markup obsolete or not? > > > Probably not yet. What's the general feeling of everyone else regarding > how long we should keep old-style markup around? > > I will be using it for awhile for an interanl app. There is no reason that we shouldn't deprecate it though -- leave the ability (checkbox) to select an old markup in the code, but remove the display of the checkbox from the default theme. Probably should wait until Markup 2 is set and relatively final for a couple increments. jbw |
From: Jeff D. <da...@da...> - 2002-11-12 21:46:38
|
On Tue, 12 Nov 2002 15:45:31 -0500 "Marjorie Roswell" <mro...@ma...> wrote: > I finally found this previous post. Confusing as all heck, I must say, > but I'll be happy to help edit TextFormattingRules and HowToUseWiki. In addition to Matti's NewTextFormattingRules, (which will be making their way into the CVS repository soon) I also wrote some notes in an attempt to clear up the new/old table confusion: http://phpwiki.sourceforge.net/phpwiki/TableMarkup (Please do feel free to add/edit/rewrite/contribute any existing or non-existing documentation as you think is needed.) |
From: Jeff D. <da...@da...> - 2002-11-12 21:39:26
|
> Jeff, should I consider the old emphasis markup obsolete or not? Probably not yet. What's the general feeling of everyone else regarding how long we should keep old-style markup around? > That > is, should I fix NewTextFormattingRules to use the old-style markup, or > do you think the new markup is going to get reliable enough for real > use? I'm not sure I understand that part of your question. I think the new markup is reliable enough now (at least a reliable as the rest of the newer features). There may be small changes in the markup syntax, but I don't envision any wholesale changes... > Maybe there could be a configuration option to disable UI for the old > markup altogether? Yes. That's my vision of where we're heading. (Perhaps also a configuration option to disable the new markup altogether?) > In that case all pages in pgsrc would have to be translated > to new markup, though. That's probably not a big problem. As of a few weeks ago, that's what the CVS code does anyway. (The old markup code is no longer used, instead the old-markup converted to new markup, then run through the new markup engine...) When we get to that point, we can either auto-convert old to new markup upon zip/pgsrc import, or upon page edit... |
From: Matti A. <ma...@ik...> - 2002-11-12 21:12:33
|
Margie, I recently announced documentation for the new formatting rules (see the archives for the whole thread, maybe a week ago). The version is available at http://mairas.net/wiki/NewTextFormattingRules. See also http://mairas.net/wiki/DynamicTextFormattingHelp. Please edit them as you see fit. Jeff, should I consider the old emphasis markup obsolete or not? That is, should I fix NewTextFormattingRules to use the old-style markup, or do you think the new markup is going to get reliable enough for real use? Maybe there could be a configuration option to disable UI for the old markup altogether? That way new setups would avoid the markup hassle altogether. In that case all pages in pgsrc would have to be translated to new markup, though. Cheers, Matti |
From: Marjorie R. <mro...@ma...> - 2002-11-12 20:45:41
|
I finally found this previous post. Confusing as all heck, I must say, but I'll be happy to help edit TextFormattingRules and HowToUseWiki if there is a natural point at which that seems like a good idea. (i.e. a point at which development seems to have slowed down on these markup changes?) My 1.3.3 wikis really aren't usable by the average person until the dual-personality of two different markup styles is mostly gone. At least the documentation needs fixing, at a minimum. Let me know if I can be helpful in that regard. Best, Margie ---------- Original Message ---------------------------------- From: Jeff Dairiki <da...@da...> Date: Fri, 1 Nov 2002 07:59:38 -0800 >> Maybe a silly question, but I am using php1.3.3 and I cannot format >> tables. Is there something I need to setup from default? The >> 'textformattingrules' page works with table formatting but not my normal >> pages. > >(This should go in the FAQ if it's not there already...) > >We're in the midst of a (very slow) transition to a new set of >markup rules. Starting in 1.3.3 there's a checkbox on the edit >form which determines whether the page is displayed using the old >or new rules. The default for new pages is to use the new rules. >(TextFormattingRules describes the old markup rules.) > >The new rules are described, more or less, at > http://phpwiki.sf.net/phpwiki/NewBlockMarkup >and > http://phpwiki.sf.net/phpwiki/NewInlineMarkup > >The new rules are not backwards-compatible with the old rules. >(Though backward-compatibility is kept, as much as is possible.) > >One of the big differences, which you've discovered, is that the >old-style tables don't work with the new formatting rules. > >You have several choices on how to get tables: > > 1. Use the old formatting rules (uncheck the checkbox on the > edit-page form) and use old-style tables. > > 2. Use the new formatting rules, and use the new > "definition list" style tables. Not all table structures > can be represented, but if they can, the new syntax is, > IMHO, much more natural and cleaner... > > Type 1 | > Variation A | > Description of type A-1. > Variation B | > Or you can use type B-1. > Type 2 | > And so forth. > > gets you > > +---------+---------------+---------------------------+ > | | Variation A | Description of type A-1. | > | Type 1 +---------------+---------------------------+ > | | Variation B | Or you can use type B-1. | > +---------+---------------+---------------------------+ > | Type 2 | And so forth. | > +---------+-------------------------------------------+ > > 3. The current CVS code (but not 1.3.3) has an OldStyleTable > plugin which can be used to include old-style tables > within new-style pages. > > <?plugin OldStyleTable > | Col 1 | Col 2 > | a | b > ?> > > > >------------------------------------------------------- >This sf.net email is sponsored by: See the NEW Palm >Tungsten T handheld. Power & Color in a compact size! >http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en >_______________________________________________ >Phpwiki-talk mailing list >Php...@li... >https://lists.sourceforge.net/lists/listinfo/phpwiki-talk > |
From: Jeff D. <da...@da...> - 2002-11-12 19:29:09
|
On Tue, 12 Nov 2002 14:17:00 -0500 "Russ Miller" <rm...@no...> wrote: > maybe there could be a hack to give each separate > wiki a prefix for table names? Does that seem reasonable? PhpWiki can already do this (via $DBParams['prefix'] in the config file). The only minor catch is that you have to manually edit the table prefixes in the appropriate schemas/*.sql. |
From: Russ M. <rm...@no...> - 2002-11-12 19:17:02
|
From: "Reini Urban" <ru...@x-...> > A WikiFarm may share config variables, but not the page database. > So you have to setup an external user/group database table to share the > users and groups. But the page permissions are completely seperate. Generally, I like all the thinking going on for permissions. In the WikiFarm instance, it might be nice if there were a convenient way to map different wikis to permission groups. Another thought I had for the WikiFarm -- it might be nice if different wikis could live separately, but in the same actual database. Commercial providers often only give you one db (in my case, one MySQL db) for a certain pricing point... maybe there could be a hack to give each separate wiki a prefix for table names? Does that seem reasonable? When I get around to my implementation (heh), I'd be happy to submit a patch to do so. russ |
From: Joby W. <joby@u.washington.edu> - 2002-11-12 18:08:00
|
I've never used Portland so this is from a quick review... Marjorie Roswell wrote: > Hello, > > I didn't like the default 1.3.3 template, so I changed it to the Portland theme. I want to retain two things: > > 1. Text across the top of each page > 2. An edit box for a search (of the full wiki, not just text titles) > > In my old 1.2 wiki, I edited the browse.hmtl file to add text to the top of every page. > > In 1.3.3. default, the navbar is at the top. In Portland it's at the bottom. > > How do add text links to the top of every page? body.tmpl -> browse.tmpl/viewsource.tmpl/editpage.tmpl -> page content -> actionbar.tmpl -> navbar.tmpl You could in body.tmpl move <?= Template('navbar') ?> above <?= $CONTENT ?>. > How do I add an edit box for a full wiki text search in there, too? > My FullTextSearch box: <?=$s?><input type="hidden" name="auto_redirect" value="1" /> <input type="text" name="s" size="15" maxlength="256" title='<?=_("Quick Search")?>' onmouseover="window.status='<?=_("Quick Search")?>'; return true;" onmouseout="window.status=''; return true;" value="FullTextSearch" /> > While I'm at it, how do I change the location for the default database? > I see these options. Is they what I change? > //define('ACCESS_LOG', '/tmp/wiki_access_log'); > //ini_set('session.save_path', 'some_other_directory'); > Last time, folks might remember, all was going great for months, until everything got deleted from /tmp. I don't want that to happen again. > index.php: section 2 (Database) change the 'directory' value (by default /tmp). jbw |
From: Reini U. <ru...@x-...> - 2002-11-12 16:06:31
|
Russ Miller schrieb: >>see SubPages or http://phpwiki.sourceforge.net/phpwiki/WikiFarm > > Any idea how user permissions will work across multiple wikis? A WikiFarm may share config variables, but not the page database. So you have to setup an external user/group database table to share the users and groups. But the page permissions are completely seperate. I don't think that SubPages should inherit some permissions unlike a unix fs. The "x" in the permission bit would be for administrative tasks like remove/rename/ and some other "ActionPlugins". (e.g. EmailNotify, WikiAdmin*). -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ |
From: Russ M. <rm...@no...> - 2002-11-11 20:42:46
|
> > - With the current PHPwiki, there's no topic separation: if you want to have > > one wiki per topic, you need to install one PHPwiki for each topic. > > Being able to manage multiple wikis (topics) with one PHPwiki installation > > would be great. > > see SubPages or http://phpwiki.sourceforge.net/phpwiki/WikiFarm Any idea how user permissions will work across multiple wikis? russ |
From: Reini U. <ru...@x-...> - 2002-11-11 18:08:46
|
arthur.chereau schrieb: > Hi, > > I now have a working PHPwiki. I've read all the released docs, but I still have > some questions/suggestions/problems. > > I use PHPwiki for my personal use. The Web server is Apache and my site is > protected by HTTP auth (and SSL). I use the latest PHPwiki from cvs, as it's a > long time since the latest release. > > 1) Questions > > - I'd like PHPwiki to automatically sign me in with my HTTP auth login. > I tried setting ALLOW_HTTP_AUTH_LOGIN to true but it didn't work. > Maybe it's because my login name is not a WikiWord ? try to unset ALLOW_BOGO_LOGIN also theoretically it should work: // HTTP Authentification elseif (ALLOW_HTTP_AUTH_LOGIN and !empty($PHP_AUTH_USER)) { // if he ignored the password field, because he is already authentificated // try the previously given password. if (empty($passwd)) $passwd = $PHP_AUTH_PW; } maybe $PHP_AUTH_PW is not global. I'll check this. > - Does the WikiFormPlugin exist ? It would be great to include forms to search > Google, etc. in wiki pages. yes. but WikiForm is only for internal administrative purposes. We had some phpwiki: syntax before for these types of forms. > - Where can I find a good doc about themes ? I'd like to create my own theme > but I can't find any doc, I have to look at the other themes. I started to fix the old themes docs. See themes/default/templates/README. The template API has completely changed with 1.3.3. Templates may be nested. Usage sample: <?= Template('browse') ?> See lib/Template.php for more, esp. the defined global php variables. ($request, $user, $page, $Theme and some action specific local vars.) There's no ###<variable>### markup anymore, instead normal php variables, constants and code can be used. > 2) Suggestions > > Please excuse me if some features are already implemented, I didn't find them. > > - Login names should not have to be WikiWords. A WikiWord could be associated > with a login name when creating a homepage. That is: > - get the login from the Web server and use it for authoring > (eg: page modified by <login> from <hostname>) ALLOW_HTTP_AUTH_LOGIN or ExtAuth is for this. unset ALLOW_BOGO_LOGIN and set ALLOW_USER_LOGIN. > - in the UserPreferences page, let the user create/remove his homepage and > supply/modify a WikiWord identifying that page I will finish this if I get some air in my current work. > - UserPreferences should be saved in the database or in a flat file, > so that the user could keep its preferences when using different computers UserPreferences are stored in his homepage (if exists), in a seperate database (if defined), or in a cookie. > - There should be a "Rename" and a "Remove" button with the "Edit" button > for each page. An index.php option could tell PHPwiki to > - ask the user to confirm and perform the operation (for private wikis) > - send a mail to the administrator for confirmation (for public wikis) Only the admin may do this. With PagePermissions (later this year) the PageOwner or WikiAdmin may do this or may give others extended rights. > - History and Diffs could be merged and improved. What about this: > - use a unique History button (no more Diffs button) > - in the History page, show all revisions > - let the user select two revisions and then see the diffs > - put a "Revert" button after each revision to immediately revert to it > (without having to see it, edit it and save it) good idea. > - A SiteMap plugin would be helpful for large wikis. Already in CVS. We just have to use bread-first search instead of the current depth-first search and cut off the first page. http://phpwiki.sourceforge.net/demo/en/SiteMap > - It would be great to be able to organize some pages in a hierarchical manner > (à la Yahoo) and then move them in the hierarchy and create links between > directories. All the pages should not have to be placed in the hierarchy. see http://phpwiki.sourceforge.net/phpwiki/SubPages or http://phpwiki.sourceforge.net/phpwiki/PageGroup > - With the current PHPwiki, there's no topic separation: if you want to have > one wiki per topic, you need to install one PHPwiki for each topic. > Being able to manage multiple wikis (topics) with one PHPwiki installation > would be great. see SubPages or http://phpwiki.sourceforge.net/phpwiki/WikiFarm > - I like to start with an empty wiki. PHPwiki should have an "empty wiki" admin > button, or if topics are implemented, they should start empty (with a form > asking for the first WikiWord). see http://phpwiki.sourceforge.net/demo/en/WikiAdminRemove (when it is fixed) > 3) Problems > > - My index.php contains "define('ENABLE_REVERSE_DNS', true);" but I only get IP > addresses even if a reverse DNS exists. strange. is there a nameserver in your /etc/resolv.conf? > - I had to comment "ob_start('ob_gzhandler');" in lib/Request.php to make > PHPwiki work with Galeon (see previous post). thanks. -- Reini Urban http://xarch.tu-graz.ac.at/home/rurban/ |
From: Jeff D. <da...@da...> - 2002-11-11 17:41:24
|
Thanks for all the suggestions! > - Where can I find a good doc about themes ? I'd like to create my own > theme > but I can't find any doc, I have to look at the other themes. There is none. If someone want to write some that would be great. Otherwise the only hint is "Use the source, Luke!", and ask here if you get stuck. > - Login names should not have to be WikiWords.=20 Yes. That requirement is/should be just for bogo-logins, I think. The user authentication code is currently under development (by Reini Urban). I think it's currently somewhat broken --- but I haven't played with it much, so I could be wrong. > - UserPreferences should be saved in the database or in a flat file, > so that the user could keep its preferences when using different > computers Yes, that's the plan. See above. > - There should be a "Rename" and a "Remove" button with the "Edit" > button > for each page. "Rename" functionality is tricky (have to rename all the links in all pages). "Remove" functionality is there, but the remove button only shows up if you have permission to use it (currently that means it only shows up if you're logged in as the admin user.) > - ask the user to confirm and perform the operation (for private > wikis) Note that if you delete all text from a page (via the edit form), it acts (for the most part) as if the page were deleted. (Links to the page wil= l have the question mark.) I've always planned (though it's not implemented yet) to have a mechanism whereby empty/deleted pages which have been empty for N days get automatically fully deleted. (More traditional wiki methods of handling messages to the admin is a RequestForPageDeletion page or some such, or a DeleteMe tag on the page.) > - History and Diffs could be merged and improved. What about this: > - use a unique History button (no more Diffs button) > - in the History page, show all revisions > - let the user select two revisions and then see the diffs We have this, right? > - put a "Revert" button after each revision to immediately revert to > it > (without having to see it, edit it and save it) I think that would make it too easy for vandals (or edit wars). ("Revert"ion shouldn't, I think, be a very frequent operation.) > - It would be great to be able to organize some pages in a hierarchical > manner > (=E0 la Yahoo) and then move them in the hierarchy and create links > between directories. All the pages should not have to be placed in th= e > hierarchy. The wiki solution to this is to use Category tags. Personally, before adding mechanisms to make this more explicit I'd rather add mechanisms to enable "book-style" hierarchies of pages (parent/ordered-sibling relationships) ("Up", "Next", "Prev"). It's not clear to me how to do either of these cleanly. > - With the current PHPwiki, there's no topic separation: if you want to > have > one wiki per topic, you need to install one PHPwiki for each topic. > Being able to manage multiple wikis (topics) with one PHPwiki > installation would be great. You only have to replicate the config file (currently index.php), and the page database. You can, of course, share the rest of the PhpWiki source between multiple distinct wikis (on the same server). There's information on this on the FrequentlyAskedQuestions and PrettyWiki pages of the PhpWiki wiki. > - I like to start with an empty wiki. PHPwiki should have an "empty > wiki" admin > button, or if topics are implemented, they should start empty (with a > form asking for the first WikiWord). You can, of course, adjust the definition of WIKI_PGSRC (or delete all but the HomePage from the pgsrc directory) before firing up PhpWiki the first time... > - My index.php contains "define('ENABLE_REVERSE_DNS', true);" but I onl= y > get IP > addresses even if a reverse DNS exists.=20 Currently the ENABLE_REVERSE_DNS only affects the output in the=20 PhpWiki generated access_log (which is only generated if ACCESS_LOG is defined in the config file.) |
From: Jeff D. <da...@da...> - 2002-11-11 17:17:14
|
> I'm using Galeon 1.2.6 compiled with Mozilla 1.1. Just another data point: I, too, primarily use Galeon, and have experienced no problems with compressed garbage. Currently running PHP 4.1.2 (Redhat). But have had no problems on, e.g., the SourceForge wikis either... Does anyone know the details of the problems PHP ob_gzhandler() was having? |
From: <art...@vo...> - 2002-11-11 15:13:44
|
> Which browser are you using? I'm using Galeon 1.2.6 compiled with Mozilla 1.1. > > > > No, I'm using apache 1.3.27. > > > > I'm using PHP 4.2.3, which is supposed to have to the bug fixed. > > > >> To fix it, I commented out the guts of compress_output() in > >> lib/Request.pm. ------------------------------------------ Faites un voeu et puis Voila ! www.voila.fr |
From: Carsten K. <car...@ya...> - 2002-11-11 15:07:10
|
Hi, (I see you are running Galeon, you can ignore my previous message.) I=20 have a feeling Galeon will have to be updated or some setting changed=20 in it to overcome the gzip problem. Maybe PhpWiki can be modified check=20= for Galeon then not enable compression? I can answer some of your questions, I'll leave the rest for others to=20= respond: - A new plugin called "ExternalSearch" is available to create forms for=20= redirecting to external web sites. - There is really no documentation for themes yet aside from the=20 comments inside the themeinfo.php file, so the following might help: LinkIcons are set in themeinfo.php. Just comment them out to disable=20 linkicons: /* * Link icons. */ //$Theme->setLinkIcon('http'); etc. To create your own theme, duplicate the folder which most closely=20 resembles the layout you want to modify. - For example, copy the "Portland" directory to "Arthur" then modify=20= the themeinfo.php file and other files inside. - Set your theme in index.php: if (!defined('THEME')) define('THEME',=20= 'Arthur'); - When PhpWiki does not find a file in your theme it then looks for it=20= in "default", but don't change any files in the default theme. Copy=20 "login.tmpl" (or whatever) from "default" into your theme then make=20 your changes there. Use this method to override the default theme rather than editing=20 "default" directly. If you change your mind you can easily delete a=20 file from your theme and everything will still work without any need to=20= reinstall. Regarding some of your other suggestions: The History screen now does allow you to select two revisions for=20 comparison, you can remove the Diff link/button from the theme template=20= if you're happy using only a History link. Multiple Wikis are possible but I can't remember how to do it, I think=20= the instructions are written somewhere in <http://phpwiki.sf.net>.=20 Basically it involves duplicating only index.php but not the whole=20 phpwiki. An empty wiki can be started by renaming or moving the pgsrc directory=20= (and locale pgsrc directory if not using english), but you must create=20= HomePage before moving the directories back. An easier way to do this=20 might be nice to have for those experienced Wiki admins who don't want=20= all the PhpWiki documentation inside their personal wiki. Carsten On Monday, November 11, 2002, at 08:15 AM, arthur.chereau wrote: > Hi, > > I now have a working PHPwiki. I've read all the released docs, but I=20= > still have > some questions/suggestions/problems. > > I use PHPwiki for my personal use. The Web server is Apache and my=20 > site is > protected by HTTP auth (and SSL). I use the latest PHPwiki from cvs,=20= > as it's a > long time since the latest release. > > > 1) Questions > > - I'd like PHPwiki to automatically sign me in with my HTTP auth = login. > I tried setting ALLOW_HTTP_AUTH_LOGIN to true but it didn't work. > Maybe it's because my login name is not a WikiWord ? > > - Does the WikiFormPlugin exist ? It would be great to include forms=20= > to search > Google, etc. in wiki pages. > > - Where can I enable/disable LinkIcons ? > > - Where can I find a good doc about themes ? I'd like to create my own=20= > theme > but I can't find any doc, I have to look at the other themes. > > > 2) Suggestions > > Please excuse me if some features are already implemented, I didn't=20 > find them. > > - Login names should not have to be WikiWords. A WikiWord could be=20 > associated > with a login name when creating a homepage. That is: > - get the login from the Web server and use it for authoring > (eg: page modified by <login> from <hostname>) > - in the UserPreferences page, let the user create/remove his=20 > homepage and > supply/modify a WikiWord identifying that page > > - UserPreferences should be saved in the database or in a flat file, > so that the user could keep its preferences when using different=20 > computers > > - There should be a "Rename" and a "Remove" button with the "Edit"=20 > button > for each page. An index.php option could tell PHPwiki to > - ask the user to confirm and perform the operation (for private=20 > wikis) > - send a mail to the administrator for confirmation (for public=20 > wikis) > > - History and Diffs could be merged and improved. What about this: > - use a unique History button (no more Diffs button) > - in the History page, show all revisions > - let the user select two revisions and then see the diffs > - put a "Revert" button after each revision to immediately revert to=20= > it > (without having to see it, edit it and save it) > > - A SiteMap plugin would be helpful for large wikis. > > - It would be great to be able to organize some pages in a=20 > hierarchical manner > (=E0 la Yahoo) and then move them in the hierarchy and create links=20= > between > directories. All the pages should not have to be placed in the=20 > hierarchy. > > - With the current PHPwiki, there's no topic separation: if you want=20= > to have > one wiki per topic, you need to install one PHPwiki for each topic. > Being able to manage multiple wikis (topics) with one PHPwiki=20 > installation > would be great. > > - I like to start with an empty wiki. PHPwiki should have an "empty=20 > wiki" admin > button, or if topics are implemented, they should start empty (with=20= > a form > asking for the first WikiWord). > > > 3) Problems > > - My index.php contains "define('ENABLE_REVERSE_DNS', true);" but I=20 > only get IP > addresses even if a reverse DNS exists. > > - I had to comment "ob_start('ob_gzhandler');" in lib/Request.php to=20= > make > PHPwiki work with Galeon (see previous post). |
From: Carsten K. <car...@us...> - 2002-11-11 14:33:42
|
Hi Arthur, Which browser are you using? Carsten On Sunday, November 10, 2002, at 08:47 AM, arthur.chereau wrote: >> Are you using Apache 2.0.x? I am, and I got the same results > > No, I'm using apache 1.3.27. > >> It's a known bug in all but the latest PHP > > I'm using PHP 4.2.3, which is supposed to have to the bug fixed. > Either it's not > correctly fixed or it's a PHPwiki bug. > >> To fix it, I commented out the guts of compress_output() in >> lib/Request.pm. > > That solved the problem, but there should be a better way ;) > |
From: Carsten K. <car...@us...> - 2002-11-11 14:14:31
|
Hi Patrick, Yes that version is actually 1.3.3, we had forgotten to increment the version number in index.php before packing up that archive. If you like you can change the version displayed on the html output, look for the line in index.php in Part Null: define ('PHPWIKI_VERSION', '1.3.2-jeffs-hacks'); Sorry for the confusion. :) Carsten On Monday, November 11, 2002, at 04:27 AM, Patrick Coffman wrote: > hello gentlepersons > > i was wondering if i am missing something, or what might be the case > > when downloading > http://prdownloads.sourceforge.net/phpwiki/phpwiki- > 1.3.3.tar.gz?download > and unzipping/tarring > > > i get a directory full of files but the version says 1.3.2-jeffs-hacks > in all of the source files. > > is this actually 1.3.3? or is there a mistake in the posted tar.gz > file? or am i just missing something? > > thanks much in advance > patrick > |
From: <art...@vo...> - 2002-11-11 13:16:02
|
Hi, I now have a working PHPwiki. I've read all the released docs, but I still have some questions/suggestions/problems. I use PHPwiki for my personal use. The Web server is Apache and my site is protected by HTTP auth (and SSL). I use the latest PHPwiki from cvs, as it's a long time since the latest release. 1) Questions - I'd like PHPwiki to automatically sign me in with my HTTP auth login. I tried setting ALLOW_HTTP_AUTH_LOGIN to true but it didn't work. Maybe it's because my login name is not a WikiWord ? - Does the WikiFormPlugin exist ? It would be great to include forms to search Google, etc. in wiki pages. - Where can I enable/disable LinkIcons ? - Where can I find a good doc about themes ? I'd like to create my own theme but I can't find any doc, I have to look at the other themes. 2) Suggestions Please excuse me if some features are already implemented, I didn't find them. - Login names should not have to be WikiWords. A WikiWord could be associated with a login name when creating a homepage. That is: - get the login from the Web server and use it for authoring (eg: page modified by <login> from <hostname>) - in the UserPreferences page, let the user create/remove his homepage and supply/modify a WikiWord identifying that page - UserPreferences should be saved in the database or in a flat file, so that the user could keep its preferences when using different computers - There should be a "Rename" and a "Remove" button with the "Edit" button for each page. An index.php option could tell PHPwiki to - ask the user to confirm and perform the operation (for private wikis) - send a mail to the administrator for confirmation (for public wikis) - History and Diffs could be merged and improved. What about this: - use a unique History button (no more Diffs button) - in the History page, show all revisions - let the user select two revisions and then see the diffs - put a "Revert" button after each revision to immediately revert to it (without having to see it, edit it and save it) - A SiteMap plugin would be helpful for large wikis. - It would be great to be able to organize some pages in a hierarchical manner (=E0 la Yahoo) and then move them in the hierarchy and create links between directories. All the pages should not have to be placed in the hierarchy. - With the current PHPwiki, there's no topic separation: if you want to have one wiki per topic, you need to install one PHPwiki for each topic. Being able to manage multiple wikis (topics) with one PHPwiki installation would be great. - I like to start with an empty wiki. PHPwiki should have an "empty wiki" admin button, or if topics are implemented, they should start empty (with a form asking for the first WikiWord). 3) Problems - My index.php contains "define('ENABLE_REVERSE_DNS', true);" but I only get IP addresses even if a reverse DNS exists. - I had to comment "ob_start('ob_gzhandler');" in lib/Request.php to make PHPwiki work with Galeon (see previous post). ------------------------------------------ Faites un voeu et puis Voila ! www.voila.fr |
From: Marjorie R. <mro...@ma...> - 2002-11-10 17:45:48
|
Hello, I didn't like the default 1.3.3 template, so I changed it to the Portland theme. I want to retain two things: 1. Text across the top of each page 2. An edit box for a search (of the full wiki, not just text titles) In my old 1.2 wiki, I edited the browse.hmtl file to add text to the top of every page. In 1.3.3. default, the navbar is at the top. In Portland it's at the bottom. How do add text links to the top of every page? How do I add an edit box for a full wiki text search in there, too? While I'm at it, how do I change the location for the default database? I see these options. Is they what I change? //define('ACCESS_LOG', '/tmp/wiki_access_log'); //ini_set('session.save_path', 'some_other_directory'); Last time, folks might remember, all was going great for months, until everything got deleted from /tmp. I don't want that to happen again. Best Regards, Margie |
From: <art...@vo...> - 2002-11-10 13:48:33
|
> Are you using Apache 2.0.x? I am, and I got the same results No, I'm using apache 1.3.27. > It's a known bug in all but the latest PHP I'm using PHP 4.2.3, which is supposed to have to the bug fixed. Either it's not correctly fixed or it's a PHPwiki bug. > To fix it, I commented out the guts of compress_output() in lib/Request.pm. That solved the problem, but there should be a better way ;) ------------------------------------------ Faites un voeu et puis Voila ! www.voila.fr |
From: Aredridel <rs...@nb...> - 2002-11-09 18:56:54
|
On Sat, Nov 09, 2002 at 08:32:39AM -0800, Jeff Dairiki wrote: > > If I then click on a link, I get a page full of junk characters. > > > > Are you using Apache 2.0.x? I am, and I got the same results. The reason > > > > apparently is that PhpWiki turns HTTP gzip compression on whether the > > client supports it or not. To fix it, I commented out the guts of > > compress_output() in lib/Request.pm. > > Hrmph. Yes this has come up before. I suppose we should > make the compression a config option (and probably disable it > by default.) It's a known bug in all but the latest PHP -- the latest ob_gzhandler works as it should. Detecting the PHP version should be easy... Ari |