phpwiki-talk

Re: [Phpwiki-talk] root .htaccess file

[Carsten K. <car...@ma...>]

Yeah the solution you gave of including both also causes the failure. I'm 
going to check their web site to see if this is a known problem with 
Apache before we change PhpWiki's .htaccess.

Carsten

On Sunday, January 13, 2002, at 06:54  pm, Jeff Dairiki wrote:

> ...as long as mod_nonexiting_module.c really doesn't exist, it shouldn't
> bother Apache at all.
>
>
> If sometimes PHP4 is in mod_php4.c and sometimes in mod_php.c, it seems
> the correct solution is:
>
> <IfModule mod_php4.c>
>    php_flag register_globals off
>    php_flag track_vars on
>    php_flag allow_url_fopen off
> </IfModule>
> <IfModule mod_php.c>
>    php_flag register_globals off
>    php_flag track_vars on
>    php_flag allow_url_fopen off
> </IfModule>
>
> But, if I understand you correctly, you're saying this causes problems for
> you?

Re: [Phpwiki-talk] root .htaccess file

[Jeff D. <da...@da...>]

On Sun, 13 Jan 2002 14:53:21 -0500
"Carsten Klapp" <car...@ma...> wrote:

> The server encountered an internal error or misconfiguration and was 
> unable to complete your request.
> 
> The problem is the first line:
> 
> <IfModule mod_php4.c>

It doesn't seem right that this should cause an internal server error by
itself.  One should be able to do:

<IfModule mod_nonexisting_module.c>
  All kinds of terrible things,
  which apache normally would,
  not like at all
</IfModule>

...as long as mod_nonexiting_module.c really doesn't exist, it shouldn't
bother Apache at all.


If sometimes PHP4 is in mod_php4.c and sometimes in mod_php.c, it seems
the correct solution is:

<IfModule mod_php4.c>
   php_flag register_globals off
   php_flag track_vars on
   php_flag allow_url_fopen off
</IfModule>
<IfModule mod_php.c>
   php_flag register_globals off
   php_flag track_vars on
   php_flag allow_url_fopen off
</IfModule>

But, if I understand you correctly, you're saying this causes problems for
you?

Maybe we should comment out everything in the distributed .htaccess file,
and encourage people to adjust as appropriate for their
installation.(PhpWiki, in stock configuration, runs fine even without an
.htacess, right?)

PS: according to comments in my RedHat distributed httpd.conf, mod_php.c
is PHP/FI (PHP2). 

Re: [Phpwiki-talk] Something very weird has happened to my Wiki

[Adam S. <ad...@pe...>]

> Are we talking about try to release a useable 1.3.x "development
> snapshot", or are we talking about a 1.4 release?  (A 1.4 release implies
> that there will one more branch of code for us to maintain.)

i was talking about a 1.4 release, something that people could use in
production services.  i'm really enjoying watching the improvements
being made in the 1.3 tree though.  this was more a question of "should
i wait for 1.4 or should i just plunge in and deal with 1.3 cause 1.4 is
a long way away :-).

> Forms based login.  We don't necessarily have to implement any more
> functionality than we have now (admin login & bogo-login), but the
> HTTP-auth based login mechanism is not available to everyone, and I think
> we need to get to where every wiki admin can use the admin functions on
> their wiki.

i think this would be very nice to have.  when this happens does that
mean that we will be storing metadata about usernames?  eg. could the
config file now contain an list of usernames that have admin privledges?

> More testing.  We/I really need to write more (some) unit tests, etc... 
> (I have a hard time getting very enthusiastic about it though, so don't
> hold your breath...)

i'm not (much of) a programmer, but i will be happy to install and test
everything i can think of.
 
> Code cleanup.  Experimental, not-fully functional code (mostly I'm
> thinking plug-ins here) should be removed from (or disabled in) the stable
> dist.  There's some other code (e.g. lib/Toolbar.php) that's still in
> transition --- it would be nice to stabilize these before a release.

yep i think that'd be cool. as a side note, i was quietly (and slowly)
working on an upload file mechanism when i saw a discussion on this on
the wiki which involved restructuring the wikidb.  

my simple approach to the problem was to write two plugins.  UploadFile
which allows a file to be uploaded to PageName/filename via a simple
form, and another plugin called ShowAttachments which shows all the
files attached to the current page (by simply doing a listing of the
directory which matches the current page name).

is it worth me continuing to work on this?  the idea discussed on the
wiki seemed much more complete but also like it was probably a ways off
in the future.

> So, I guess I think we can do it but it will take a deliberate decision to
> do so, as well as a fair amount of effort.  I guess the fact that we've
> already converted the PhpWiki wiki to 1.3 indicates that it is time...

fwiw, the other things i'd like to see would be:

 * allow html on locked pages (useful for the admin to embed forms etc)
 * standardize on a wiki syntax.  if we're going to change the standard
   wiki syntax (i think some of the discussions on this were a "good
   thing") then the sooner those changes are made the better (saving
   painful upgrades for people in the future.

once again, that's for all the hard work guys, phpwiki is great!

adam.

Re: [Phpwiki-talk] locale/Makefile

[Jeff D. <da...@da...>]

On Sun, 13 Jan 2002 10:16:30 -0800
Jeff Dairiki <da...@da...> wrote:

On further thought, it might be best to hardcode the list of files
which need to be xgettext()ed into the Makefile.  Certainly, it's the
most portable plan.  I'll work on it now.

Re: [Phpwiki-talk] French L10N & other stuff

[Jeff D. <da...@da...>]

On Wed, 26 Dec 2001 23:44:55 +0100
"S. Delahaye" <del...@fr...> wrote:

> I  wanted  to  know  if anybody was working on a same l10n,
> because it would be too bad to have the work done twice :)
> I just looked at the archives of this list, and saw nothing related to
> a french l10n in december, but I prefer asking.

S=E9bastien,

I'm sorry this response is so late.  I was away on holiday when your
posted your message.

There are (or at least were,) at least two other French translation
efforts underway.  I don't know much about the status of the other
efforts, but I've created a wiki-page with what I know:
http://phpwiki.sf.net/phpwiki/FrenchTranslations.

(I've CC:ed the other French translators on this message, so you can pick
their e-mail addresses out of the mail headers.)

Again, sorry for the late reply.
Jeff

[Phpwiki-talk] root .htaccess file

[Carsten K. <car...@ma...>]

The current .htaccess file in the root phpwiki directory causes problems 
for me in Apache/1.3.22:

Internal Server Error

The server encountered an internal error or misconfiguration and was 
unable to complete your request.

The problem is the first line:

<IfModule mod_php4.c>
   php_flag register_globals off
   php_flag track_vars on

   php_flag allow_url_fopen off
</IfModule>

When the "4" is removed it is fine. The newer Apache servers assume php is 
version 4 by default, and would require mod_php3.c if using php3.

Can / should we change this?

Carsten

Re: [Phpwiki-talk] locale/Makefile

[Carsten K. <car...@ma...>]

Another option would be that email notification could be suppressed for 
directories named LC_MESSAGES. This is determined by the CVSROOT/loginfo 
file. Currently it contains:

CVSROOT $CVSROOT/CVSROOT/syncmail %{sVv} sw...@wc...
DEFAULT $CVSROOT/CVSROOT/syncmail %{sVv} phpwiki-
che...@li...

# The "loginfo" file controls where "cvs commit" log information
# is sent.  The first entry on a line is a regular expression which must 
match
# the directory that the change is being made to, relative to the
# $CVSROOT.  If a match is found, then the remainder of the line is a 
filter
# program that should expect log information on its standard input.
#
# If the repository name does not match any of the regular expressions in 
this
# file, the "DEFAULT" line is used, if it is specified.

We just need to come up with a line containing a regexp for LC_MESSAGES to 
insert between the first two lines shown above, maybe redirect to 
/dev/null.

Carsten

On Sunday, January 13, 2002, at 01:16  pm, Jeff Dairiki wrote:

> On Sun, 13 Jan 2002 15:47:21 +0000
> "Reini Urban" <ru...@x-...> wrote:

> I propose we remove all the dynamically generated files from the CVS.
> (They should still be generated and included in all tar-balls, including
> nightly snapshot tarballs.)  There's no point in having these under
> version control, and I'm getting sick of seeing all the "remake in locale"
> messages on phpwiki-checkins.
>
> The files I propose removing from CVS ar:
>   locale/*/LC_MESSAGES/*
>   locale/po/phpwiki.pot
>
> The only draw-back to this plan is that anyone who gets their PhpWiki
> direct from CVS will need to have the gettext utils installed in order to
> use i18n.
>
> Steve, where is the nightly tar-ball script run?  Would the tar-ball
> script have any trouble in locale/Makefile?

Re: [Phpwiki-talk] locale/Makefile

[Carsten K. <car...@ma...>]

I have no more German or locale stuff to commit so it's all yours.
:-)
Carsten
On Sunday, January 13, 2002, at 10:47  am, Reini Urban wrote:

>
> If not I'll commit. I'll doing more changes on the de.po and german pages,
> and I want to generate the mo's by myself, not to conflict with carsten 
> again.

Re: [Phpwiki-talk] Something very weird has happened to my Wiki

[Jeff D. <da...@da...>]

On Sun, 13 Jan 2002 12:51:26 +0000
"Reini Urban" <ru...@x-...> wrote:

> Adam Shand schrieb:
> > what are peoples thoughts on the timeline for this?  do we have a
> > tenative roadmap for what features we're trying to get ready for the
> > next stable release?


Are we talking about try to release a useable 1.3.x "development
snapshot", or are we talking about a 1.4 release?  (A 1.4 release implies
that there will one more branch of code for us to maintain.)


> 
> imho it's almost ready. 1-2 weeks?

Maybe, if we declare a feature freeze, and only work on testing, fixing
bugs, and a strict set of tasks deemed necessary for release.

Off the top of my head, some things I think we really need before a 1.4
release:

Forms based login.  We don't necessarily have to implement any more
functionality than we have now (admin login & bogo-login), but the
HTTP-auth based login mechanism is not available to everyone, and I think
we need to get to where every wiki admin can use the admin functions on
their wiki.

I'd like to clean up the default phpwiki.css a bit.

Either implement a kludgy fix for known PEAR bugs (I think probably by
including our own version of PEAR code in the distrib) or convert to ADODB
(or some other) not-so-buggy DB lib.

More testing.  We/I really need to write more (some) unit tests, etc... 
(I have a hard time getting very enthusiastic about it though, so don't
hold your breath...)

Code cleanup.  Experimental, not-fully functional code (mostly I'm
thinking plug-ins here) should be removed from (or disabled in) the stable
dist.  There's some other code (e.g. lib/Toolbar.php) that's still in
transition --- it would be nice to stabilize these before a release.


So, I guess I think we can do it but it will take a deliberate decision to
do so, as well as a fair amount of effort.  I guess the fact that we've
already converted the PhpWiki wiki to 1.3 indicates that it is time...

Re: [Phpwiki-talk] locale/Makefile

[Jeff D. <da...@da...>]

On Sun, 13 Jan 2002 15:47:21 +0000
"Reini Urban" <ru...@x-...> wrote:

> Any objections to use
>   ~$ make -f locale/Makefile

If make has to be run in the top level directory, I'd prefer the Makefile
also be in the top level directory.  (Perhaps named "locale.mk".)

Better still, let's see if we can find a way to work around the
$(wildcard) problems.

See if this works for you:

PHP_SRC := $(shell find  .. -name "*.html" -o -name "*.php")

It might be good to eliminate the GNU-Make-isms in the makefile.  That
means doing away with $(shell), $(wildcard) and $(patsubst).  We would
probably have to introduce another ancillary shell script to be able to do
without those.


======
And while we're on the subject:

I propose we remove all the dynamically generated files from the CVS. 
(They should still be generated and included in all tar-balls, including
nightly snapshot tarballs.)  There's no point in having these under
version control, and I'm getting sick of seeing all the "remake in locale"
messages on phpwiki-checkins.

The files I propose removing from CVS ar:
  locale/*/LC_MESSAGES/*
  locale/po/phpwiki.pot

The only draw-back to this plan is that anyone who gets their PhpWiki
direct from CVS will need to have the gettext utils installed in order to
use i18n.

Steve, where is the nightly tar-ball script run?  Would the tar-ball
script have any trouble in locale/Makefile? 

Re: [Phpwiki-talk] Something very weird has happened to my Wiki

[Jeff D. <da...@da...>]

On Sun, 13 Jan 2002 14:29:36 +0100
"Tara Star" <te...@cl...> wrote:

> forgive the clueless... (with an absent sysadmin) - how do I backup the 
> wiki? *cringe*

Good Question: I've just started a new page, with some notes.  See
  http://phpwiki.sf.net/phpwiki/BackupStrategies

[Phpwiki-talk] locale/Makefile

[Reini U. <ru...@x-...>]

I had unsolvable problems on cygwin's make with locale/Makefile,
re-generating the po's from the sources. 
the problem is probably $(wildcard ../<stuff>/*).
With $(wildcard locale/<stuff>/*) it works fine.

So I converted the makefile to be called from the basedir. 
This works fine now. I'm just finishing the WantedPages plugin.

Any objections to use
  ~$ make -f locale/Makefile
instead of
  ~/locale/$ make

If not I'll commit. I'll doing more changes on the de.po and german pages, 
and I want to generate the mo's by myself, not to conflict with carsten again.
-- 
Reini Urban
  http://atelier.akbild.ac.at/ (soon)
  http://xarch.tu-graz.ac.at/home/rurban/ (big)
  http://tv.mur.at/ (kulturelles)

Re: [Phpwiki-talk] Something very weird has happened to my Wiki

[Reini U. <ru...@x-...>]

Adam Shand schrieb:
> what are peoples thoughts on the timeline for this?  do we have a
> tenative roadmap for what features we're trying to get ready for the
> next stable release?

imho it's almost ready. 1-2 weeks?

-- 
Reini Urban
  http://atelier.akbild.ac.at/ (soon)
  http://xarch.tu-graz.ac.at/home/rurban/ (big)
  http://tv.mur.at/ (kulturelles)

Re: [Phpwiki-talk] Something very weird has happened to my Wiki

[Adam S. <ad...@pe...>]

> (Furthermore, 1.3 is really, truly still alpha code --- even more reason
> for backups.) 

something i'd been thinking about.  i'd like to see a stable release of
1.3 in the nearish (weeks to months?) future as it has a lot of features
and improvements in it that i'd like to use, but i need something that
has been cleaned up and debugged a little more then the current alpha?

what are peoples thoughts on the timeline for this?  do we have a
tenative roadmap for what features we're trying to get ready for the
next stable release?

adam.

Re: [Phpwiki-talk] Something very weird has happened to my Wiki

[Jeff D. <da...@da...>]

On Sat, 12 Jan 2002 01:31:59 +0000
"Steven Murdoch" <st...@mu...> wrote:

> Do you think it would be worthwhile to send out a "security
announcement" > or similar covering this feature?

I think you just announced it. :-)

A public wiki is a public wiki.  By definition, anyone is allowed to edit
it.  An attacker could write a fairly trivial script which would overwrite
every page in your wiki (repeatedly).  The only real defense against this
is good backups.

(Furthermore, 1.3 is really, truly still alpha code --- even more reason
for backups.) 

I make daily backups of my wikis, and suggest that everyone who runs a
wiki with anything important on it should do the same.  I suppose we
should add a note in the README.


On the other hand, this certainly is a bug, and it does provide an
entirely too easy way to trash a wiki.

Lawrence's suggestion of implementing an "undo" function which would undo
all recent edits from a particular host would help in this situation.


Your fix of removing all but HomePage from pgsrc is a good one.
Alternatively, to get the same effect without deleting files: (after the
wiki is initialized) one can edit index.php as set PGSRC to
"pgsrc/HomePage".


> Also does anyone know how 1.2 will respond to this type of action?

I think 1.2 is safe.  (Blank pages are not treated as "deleted" in 1.2.)

Re: [Phpwiki-talk] thanks for the favicon

[Jeff D. <da...@da...>]

On Sat, 12 Jan 2002 01:42:34 +0000
"Steven Murdoch" <st...@mu...> wrote:

> Oops, it seems that the kicon .ico file is not the same as the Windows
.ico > file. While the MurdoMedia logo looked great with Mozillia, IE
messes it > up. I used a Windows convertor to fix it, and I don't know of
any Linux > tools that can do this.

If you still have the before and after versions, would you mind sending
them to me? I'd be interested in seeing what the difference is. 
> If you find out then please let me know. It would be useful for future 
> reference.

The online editor (http://www.favicon.com/) worked very well for me.  It
can load images from a URL in many formats (at least GIF), and mails you
the resulting .ico.  Of course, I haven't yet tested any of the icons I've
generated with it on a Windows box...

If it's convenient for anyone to test the new phpwiki favicon.ico under
windows, that would be great!  (It's installed on the phpwiki wiki at
http://phpwiki.sf.net/phpwiki/ --- if you bookmark any pages there, the
bookmarks should show up with the new icon.)

Re: [Phpwiki-talk] thanks for the favicon

[Steven M. <st...@mu...>]

At 00:14 12/01/02 +0000, Steven Murdoch wrote:
>At 15:51 11/01/02 -0800, you wrote:
>> > I was trying to make one of these too since Mozilla now supports
>> > favicons,
>> > but the Mac OS tools I have for making windows icons are not
>> > very good.
>>
>>I have yet to find any linux tools which will write an .ico file...
>>I used the online (java applet) editor at http://www.favicon.com/.
>
>I used Gimp to produce the 16x16 MurdoMedia logo, then used kiconedit (or 
>maybe it was called kiconeditor?) to convert it into an .ico file.

Oops, it seems that the kicon .ico file is not the same as the Windows .ico 
file. While the MurdoMedia logo looked great with Mozillia, IE messes it 
up. I used a Windows convertor to fix it, and I don't know of any Linux 
tools that can do this.

If you find out then please let me know. It would be useful for future 
reference.

Thanks,
Steven.

--
email: st...@mu...
web: http://www.murdomedia.net/
PGP/GnuPG keys: http://www.murdomedia.net/keys.html

Re: [Phpwiki-talk] Something very weird has happened to my Wiki

[Steven M. <st...@mu...>]

Thanks for the help Jeff and Lawrence.

At 11:59 11/01/02 -0800, you wrote:
>On Fri, 11 Jan 2002 19:33:25 -0000
>"Lawrence Akka" <Law...@th...> wrote:
>
> > Actually, Jeff, if you delete HomePage, all the Virgin pages are
>reloaded
>
>Aha!  Yes, of course.

I think Lawrence has got it :-) Someone 
(16-181.E.dial.o-tel-o.net/212.144.16.181) deleted the contents of HomePage 
and saved the changes. It then seems that if HomePage is either empty or 
not present (I'm not even sure if there is a distinction between these 
two), then all the original files are loaded from pgsrc.

When I was upgrading from 1.2 to 1.3, I had problems importing serialised 
files, so instead I overwrote the files in pgsrc which were either new, or 
updated from the 1.2 base package. Then when I first started PhpWiki the 
files were loaded properly. Since then I had simply forgotten about them, 
but when the HomePage was emptied today, these were reloaded.

Fortunately the replacement files in pgsrc were loaded on top of the 
existing (more up to date pages), so I lost nothing. All I had to do was 
bring every page, which was in the 1.2 wiki but had been updated since it 
was imported, back one version. Since my Wiki is small this was not major 
undertaking and is now complete.

I agree that this is an undesirable feature, so while there are long term 
solutions for this, in the short term I think some remedial action is 
necessary on any "live" PhpWiki 1.3 sites. One possibility is to lock the 
HomePage, but I would rather not do that for my site, and also I can't 
unlock locked pages (has this been fixed, I'm using quite an old version 
with a few random patches?).

My solution has been to empty all contents from pgsrc, except from HomePage 
itself, then if HomePage is deleted, it will be replaced by the original, 
but no other pages are affected. Also I set the pgsrc/HomePage to contain a 
message stating the site was undergoing technical difficulties and to 
contact me, hence if HomePage is wiped I would hopefully get an email, then 
I could restore HomePage and the rest of the Wiki would be unchanged.

Do you think it would be worthwhile to send out a "security announcement" 
or similar covering this feature? While my Wiki is small, if this were to 
happen to a large Wiki then there would be a lot of work restoring it. I 
know there aren't that many 1.3 Wikis about, and they should be regularly 
backed up, but there are a few out there and this feature allows a 
malicious user to cause a significant amount of damage to the site. This is 
just a suggestion so feel free to ignore it.

Also does anyone know how 1.2 will respond to this type of action?

I have no idea who deleted HomePage, I don't know anyone on that ISP. I'm 
also not sure whether they made a mistake or were being malicious, although 
the fact that he/she deleted the HomePage twice does make me suspicious. 
Never mind, no harm done.

>When one upgrades to a new release of PhpWiki, in general one does not
>want to replace most of the pgsrc.  On the other hand, sometimes upgrading
>PhpWiki will break some of the "magic pages" (PhpWikiAdministration,
>RecentChanges, TitleSearch, etc...)  If each page in the distributed pgsrc
>had a pgsrc_version meta-data, then there could be an option to only
>update the page if the pgsrc_version is greater than that currently in the
>database.  (The "major" part of pgsrc_version should be incremented when
>there are functional changes to the page, the "minor" version gets bumped
>everytime the pgsrc is modified.)

This would be a very good feature. When upgrading from 1.2 to 1.3 I spent 
some time working out which pages in my 1.2 wiki should be transferred 
over, which should be replaced by those in the 1.3 package, and those which 
should be based on 1.3 pages, but have the same changes added to them which 
I had made to the 1.2 pages. Any features which would help in this process 
would be greatly appreciated.

Thanks again,
Steven.

--
email: st...@mu...
web: http://www.murdomedia.net/
PGP/GnuPG keys: http://www.murdomedia.net/keys.html

Re: [Phpwiki-talk] thanks for the favicon

[Steven M. <st...@mu...>]

At 15:51 11/01/02 -0800, you wrote:
> > I was trying to make one of these too since Mozilla now supports
> > favicons,
> > but the Mac OS tools I have for making windows icons are not
> > very good.
>
>I have yet to find any linux tools which will write an .ico file...
>I used the online (java applet) editor at http://www.favicon.com/.

I used Gimp to produce the 16x16 MurdoMedia logo, then used kiconedit (or 
maybe it was called kiconeditor?) to convert it into an .ico file.

Hope this helps,
Steven.



--
email: st...@mu...
web: http://www.murdomedia.net/
PGP/GnuPG keys: http://www.murdomedia.net/keys.html

Re: [Phpwiki-talk] Recent Changes - Summary disappears?

[Jeff D. <da...@da...>]

On Fri, 11 Jan 2002 18:05:48 -0500
"Carsten Klapp" <car...@ma...> wrote:

> Note that the ||= for variable substitution only works for one variable
at > this time (used by Show changes for: 1 day, etc.)

Really?  It works for me, I think.

Regarding these comments from lib/WikiPlugin.php:

   // FIXME: doesn't work for multiple args
   // e.g. <plugin RecentChanges days||=1 show_all||=0 show_minor||=0>
   //      url: RecentChanges?days=1+show_all=1+show_minor=0

You know this, but note that you need to use a '&' to separate query args
instead of a '+'.   ('+' is the url-encoding for ' ' --- a space.)
So you want a URL like:
  http://phpwiki.sf.net/wiki/RecentChanges?day=1&show_all=1&show_minor=0

Re: [Phpwiki-talk] Recent Changes - Summary disappears?

[Jeff D. <da...@da...>]

On Fri, 11 Jan 2002 23:02:37 -0000
"Lawrence Akka" <la...@us...> wrote:

> If there is more than one edit to a page on any given day, 
> RecentChanges only seems to show the most recent one.  Is that 
> deliberate?

Yes.  That's the default behavior of most, if not all wikis everywhere.

As everyone else has noted, you can change that behavior by adjusting
the plugin arguments (and you can pass arguments to plugins via
HTTP query args, e.g.:
  http://phpwiki.sf.net/phpwiki/RecentChanges?show_all=1
will give you what you want.)

See http://phpwiki.sf.net/phpwiki/RecentChangesPlugin for more details.

Re: [Phpwiki-talk] thanks for the favicon

[Jeff D. <da...@da...>]

On Fri, 11 Jan 2002 18:14:36 -0500
"Carsten Klapp" <car...@ma...> wrote:

> This favicon is cool!
> 
> I was trying to make one of these too since Mozilla now supports
favicons,>   but the Mac OS tools I have for making windows icons are not
very good.

I have yet to find any linux tools which will write an .ico file...
I used the online (java applet) editor at http://www.favicon.com/.

Re: [Phpwiki-talk] Recent Changes - Summary disappears?

[Adam S. <ad...@pe...>]

> I would prefer this as the default behaviour for RecentChanges too, so 
> when two people edit the same page on the same day you can see both in 
> RecentChanges.

it's a hard call.  for wiki regulars it's nice to see all the edits of a
given page so you can get a feel for how much is actually going on, but
in that case you should probably be using RecentEdits right?

if you aren't a wiki regular (or RecentChangesJunkie) then my guess is
that seeing that a file has been updated that day is probably sufficient
and the extra information isn't worth the clutter on the page.

i actually replied to this to agree with you, but i think i now disagree
and think it should stay the way it is.  certainly AllRecentChanges is
useful and should stay as well (maybe FullRecentChanges or another name
though, it took me a while to figure out what the difference was when i
was first looking at it).

adam.

[Phpwiki-talk] thanks for the favicon

[Carsten K. <car...@ma...>]

This favicon is cool!

I was trying to make one of these too since Mozilla now supports favicons,
  but the Mac OS tools I have for making windows icons are not very good.

Carsten

[Phpwiki-talk] =?UTF-8?Q?Re:=5F[Phpwiki-talk]=5F[=3DEA=3DB4=3D91=3DEA=3DB3=3DA?= =?UTF-8?Q?0]=5F=3DED=3D95=3D9C=3DEB=3DB2=3D88=3DEC=3D97=3D90=5F?= =?UTF-8?Q?=3DEB=3DB3=3DB4=3DEB=3D82=3DB4=3DEB=3D8A=3D94=5F=3DED?= =?UTF-8?Q?=3D95=3DB8=3DEB=3D93=3D9C=3DED=3D8F=3DB0=5F=3DEB=3DAC?= =?UTF-8?Q?=3DB8=3DEC=3D9E=3D90=3DEB=3DA9=3D94=3DEC=3D84=3DB8=3D?= =?UTF-8?Q?EC=C2=A7=C2=80_=EB=8C=80=EB=9F=89_=EB=B0=9C=EC=86=A1_?= =?UTF-8?Q?=EC=8B=9C=EC=8A=A4=ED=85=9C?=

[Carsten K. <car...@ma...>]

A network TOILET ?!?! Now I really have seen everything!

** Please remove us from your advertising list. **

Carsten Klapp

On Friday, January 11, 2002, at 11:49  am, =EC=A0=95=EC=84=9D=EC=A7=84 =
wrote: