phpwiki-talk

Re: [Phpwiki-talk] Older versions?

[J C L. <cl...@ka...>]

On Sat, 9 Jun 2001 20:48:24 -0700 (PDT) 
Adam Shand <la...@sp...> wrote:

> the archiving scheme i'd like to see used is the one described
> here:

Given the plumetting cost/MB I'd be more interested in implementing
a hierarchial storage system where sufficiently old and non-current
versions of content is moved to a secondary backing store, away from
the primary copy, yet still accessible.

Heck, 20Gig of RW SCSI II is less than $200 no, even less if you're
silly enough to go with IDE on a server.

-- 
J C Lawrence                                       cl...@ka...
---------(*)                          http://www.kanga.nu/~claw/
The pressure to survive and rhetoric may make strange bedfellows

Re: [Phpwiki-talk] Older versions?

[Adam S. <la...@sp...>]

> http://www.usemod.com/cgi-bin/mb.pl?KeptPages
> There's nothing at the one you gave.

sorry you are correct, i must have fat fingered the cut and paste of the
url.

adam.

Re: [Phpwiki-talk] Older versions?

[Joel U. <uck...@no...>]

Quoth Adam Shand:
[snip]
> the archiving scheme i'd like to see used is the one described here:
> 
> 	http://www.usemod.com/cgi-bin/mb.pl?KeptPage

Is this the URL you wanted?

http://www.usemod.com/cgi-bin/mb.pl?KeptPages

There's nothing at the one you gave.

-- 
J.

Re: [Phpwiki-talk] Older versions?

[Adam S. <la...@sp...>]

> Just let me get this properly: we only store two versions of each
> page, and writing from the same host (taking into account time
> interval?) is considered to be a change that replaces the current
> version? My personal experience with phpwiki indicated it's true
> (which means I need to start backing stuff up today :-) but I was
> under the impression we had levels of undo like we have in swiki.

the archiving scheme i'd like to see used is the one described here:

	http://www.usemod.com/cgi-bin/mb.pl?KeptPage

basically old versions are kept for a fixed amount of time rather then a
fixed number of copies.  the main advantage of this is that if a malicious
user comes in and starts trashing a page (or pages) you always have X
amount of time to recover old data.  i'd think that a month would be
reasonable though it would probably need to be tuned for high volume
sites.

sorry if this has alrady been discussed.

adam.

Re: [Phpwiki-talk] dbx

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

I've started a page in the phpwiki wiki on the various PHP RDBMS abstraction
libraries.  I haven't looked very deeply at any of the choices yet,
but feel free to add your comments:
  http://phpwiki.sourceforge.net/phpwiki/index.php?PhpDatabaseAccessLibraries

Jeff

Re: [Phpwiki-talk] dbx

[Christian R. R. <ki...@as...>]

On Sat, 9 Jun 2001, Steve Wainstead wrote:

> The downside is dbx has to be compiled in, of course. I suppose this is
> the tradeoff we face: PhpWiki 1.4 could use such a database abstraction,
> and that makes it work with more databases; but the users have to have the
> abstraction layer compiled in. I wonder why the PHP maintainers don't
> automatically add dbx when any database supported by dbx is compiled in?

Of course, the other downside is that it's currently only available in CVS
PHP4 and as such is virtually non-deployed :-)

Take care,
--
/\/\ Christian Reis, Senior Engineer, Async Open Source, Brazil
~\/~ http://async.com.br/~kiko/ | [+55 16] 274 4311

Re: [Phpwiki-talk] PHPWiki accent support

[Christian R. R. <ki...@as...>]

On Sat, 9 Jun 2001, Sandino Araico S=E1nchez wrote:

> Instead of using foreach you can pass the array as parameter to strtr(). =
Look
> for details in the strtr() manual.

Quite correct. Attached new version of transform.php patch (renamed brlo
to entitymap).

Take care,
--
/\/\ Christian Reis, Senior Engineer, Async Open Source, Brazil
~\/~ http://async.com.br/~kiko/ | [+55 16] 274 4311

[Phpwiki-talk] dbx

[Steve W. <sw...@pa...>]

It appears the database abstraction library that ships with PHP is dbx:

http://www.php.net/manual/en/ref.dbx.php

The downside is dbx has to be compiled in, of course. I suppose this is
the tradeoff we face: PhpWiki 1.4 could use such a database abstraction,
and that makes it work with more databases; but the users have to have the
abstraction layer compiled in. I wonder why the PHP maintainers don't
automatically add dbx when any database supported by dbx is compiled in?

The function library is extremely limited... while this means more work on
the app end instead of the database, I guess it would be a win overall.
I'll compile it in and try it out.

~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

Re: [Phpwiki-talk] PHPWiki accent support

[Christian R. R. <ki...@as...>]

On Sat, 9 Jun 2001, Sandino Araico S=E1nchez wrote:

> Maybe use soundex() for string matching?
> A soundexed version should be sotred in parallel.

Hmmm. AFAIK soundex doesn't exist for every language, and you still need
to be able to do raw string matching, for which the encoding will matter.

Take care,
--
/\/\ Christian Reis, Senior Engineer, Async Open Source, Brazil
~\/~ http://async.com.br/~kiko/ | [+55 16] 274 4311

Re: [Phpwiki-talk] PHPWiki accent support

[Sandino A. <sa...@sa...>]

Christian Robottom Reis wrote:

> And the database, if it does string matching, additionally (using LIKE,=
 ~
> and whatnot).
>

Maybe use soundex() for string matching?
A soundexed version should be sotred in parallel.


--
Sandino Araico S=E1nchez
Si no eres parte de la soluci=F3n, entonces eres parte del precipitado.

Re: [Phpwiki-talk] PHPWiki accent support

[Sandino A. <sa...@sa...>]

Jeff Dairiki wrote:

>
> I suppose entitizing upon output as you suggest doesn't hurt anything,
> but it still seems unnecessary to me.

Entitizing has a big performance cost. An optional pre-entitized cache sh=
ould
be used to avoid entitizing every time the page is displayed.

>
>
> Is anyone using PhpWiki with any other non ISO-8859-1 eight-bit charset=
?

ISO-8859-15

>
> (I know there have been many requests for multi-byte character support,
> but that's not an easy fix.   I think that pretty much requires switchi=
ng
> to using unicode/UTF-8 internally, and this won't be practical without
> unicode support compiled into PHP and its regexp libraries.)
>

--
Sandino Araico S=E1nchez
Si no eres parte de la soluci=F3n, entonces eres parte del precipitado.

Re: [Phpwiki-talk] PHPWiki accent support

[Sandino A. <sa...@sa...>]

Christian Robottom Reis wrote:

>                  Name: config-new
>    config-new    Type: Plain Text (TEXT/PLAIN)
>              Encoding: BASE64
>
>                      Name: transform-diff
>    transform-diff    Type: Plain Text (TEXT/PLAIN)
>                  Encoding: BASE64

Instead of using foreach you can pass the array as parameter to strtr(). =
Look
for details in the strtr() manual.

--
Sandino Araico S=E1nchez
Si no eres parte de la soluci=F3n, entonces eres parte del precipitado.

[Phpwiki-talk] Older versions?

[Christian R. R. <ki...@as...>]

(Seen today's thread here)

Just let me get this properly: we only store two versions of each page,
and writing from the same host (taking into account time interval?) is
considered to be a change that replaces the current version? My personal
experience with phpwiki indicated it's true (which means I need to start
backing stuff up today :-) but I was under the impression we had levels of
undo like we have in swiki.

I'm using flat-file storage here, if it makes a difference.

Take care,
--
/\/\ Christian Reis, Senior Engineer, Async Open Source, Brazil
~\/~ http://async.com.br/~kiko/ | [+55 16] 274 4311

Re: [Phpwiki-talk] page archiving

[Joel U. <uck...@no...>]

Quoth Steve Wainstead:
[snip]
> Archiving is in the to-do list
> https://sourceforge.net/pm/task.php?group_project_id=7691&group_id=6121&func=
> browse
> 
> This list is really part to-do, part wish list. Archiving is def. one of
> the top priorities for the next release.
> 
> ~swain

I read the to-do entry for archiving, and have a few thoughts and questions.

1. The level of archiving should be wiki-owner-configurable, obviously. The 
number of page versions kept should be open-ended, from zero to all. That 
way, users with little disk space can limit the number of versions kept, 
while those who want to archive everything can do so as well.

2. How does phpwiki store previous versions now? Would it be feasible 
simply to extend that? If not, what sort of thing do you think would work 
best? CVS or RCS, perhaps? Keeping a database of numbered diffs?

3. I know phpwiki is divided into the database interface code and the wiki 
code. It sounds like archiving would mostly affect the wiki code, and the 
database interface code only if something like CVS or RCS were used.

Anyway, I'd appreciate hearing what you guys think would be the most 
fruitful approach.

-- 
J.

Re: [Phpwiki-talk] page archiving

[Steve W. <sw...@pa...>]

Since 1.2 was released, development has slowed down with Jeff doing 99% of
the work. I'm just starting to get back into it again after a month of
waiting to get DSL set up... it's too painful to do anything at 28.8
anymore.

Archiving is in the to-do list
https://sourceforge.net/pm/task.php?group_project_id=7691&group_id=6121&func=browse

This list is really part to-do, part wish list. Archiving is def. one of
the top priorities for the next release.

~swain

On Fri, 8 Jun 2001, Joel Uckelman wrote:

> I remember a while back (December?) there being some discussion on the list
> of ways to archive old wiki pages more extensively than phpwiki does it
> now. Did anything ever come of that? I'm interested to know, since I I'm
> currently hosting two wikis for which more complete archiving would be
> useful. If nothing has been done regarding archiving, I might even be
> interested in doing a little coding to bring it off.
>
> --
> J.
>
>
>
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> http://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

[Phpwiki-talk] page archiving

[Joel U. <uck...@no...>]

I remember a while back (December?) there being some discussion on the list 
of ways to archive old wiki pages more extensively than phpwiki does it 
now. Did anything ever come of that? I'm interested to know, since I I'm 
currently hosting two wikis for which more complete archiving would be 
useful. If nothing has been done regarding archiving, I might even be 
interested in doing a little coding to bring it off.

-- 
J.

Re: [Phpwiki-talk] PHPWiki accent support

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

>And the database, if it does string matching, additionally (using LIKE, ~
>and whatnot).

Another good point.  (I suspect it will be quite awhile before PhpWiki
supports unicode.)

Re: [Phpwiki-talk] PHPWiki accent support

[Christian R. R. <ki...@as...>]

On Fri, 8 Jun 2001, Jeff Dairiki wrote:

> PhpWiki specifies the charset in a <meta http-equiv> tag
> in the HTML headers on each and every page:
>
>   <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
>
> As you note, the charset currently is not specified in the HTTP headers.
> If that is causing problems with some browsers (is it?), that's easy enough
> to fix (we should probably fix that anyway).

It doesn't break any browser that _looks for_ Content-Type _and_ supports
Latin-1, which probably makes this a non-issue. There could be browsers
that ignore the META tags and thus need the HTTP headers, but since META
is defined in everything since HTML2.0 I deem these browsers as broken.
Your point is taken.

> I suppose entitizing upon output as you suggest doesn't hurt anything,
> but it still seems unnecessary to me.

Apparently (and to me, surprisingly), you're right (as far as you set
Content-Type, which we do). It's probably just one of those pedanticisms
you acquire over time. :-)

> (I know there have been many requests for multi-byte character support,
> but that's not an easy fix.   I think that pretty much requires switching
> to using unicode/UTF-8 internally, and this won't be practical without
> unicode support compiled into PHP and its regexp libraries.)

And the database, if it does string matching, additionally (using LIKE, ~
and whatnot).

Take care,
--
/\/\ Christian Reis, Senior Engineer, Async Open Source, Brazil
~\/~ http://async.com.br/~kiko/ | [+55 16] 274 4311

Re: [Phpwiki-talk] PHPWiki accent support

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

>Does & still have to be a magic character if it is only generated on
output? I am not advocating writing (entering data in the form) entitized
>-- this is broken and counter-productive; only displaying entitized, to
>allow a wider audience with less breakage. This is _almost_ a non-issue
>with Latin-1, since most browsers render that by default, but on
>non-Latin-1 charsets (and thus, locales and languages), this _will_ be an
>issue. Is this besides the point?

Okay, I see that perhaps I misunderstood your initial suggestion.

Stock PhpWiki really only supports ISO-8859-1.  (Though I suppose
it would be easy enough to hack it to support any other single
eight-bit character set.)

PhpWiki specifies the charset in a <meta http-equiv> tag
in the HTML headers on each and every page:

  <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">

As you note, the charset currently is not specified in the HTTP headers.
If that is causing problems with some browsers (is it?), that's easy enough
to fix (we should probably fix that anyway).

I suppose entitizing upon output as you suggest doesn't hurt anything,
but it still seems unnecessary to me.

Is anyone using PhpWiki with any other non ISO-8859-1 eight-bit charset?

(I know there have been many requests for multi-byte character support,
but that's not an easy fix.   I think that pretty much requires switching
to using unicode/UTF-8 internally, and this won't be practical without
unicode support compiled into PHP and its regexp libraries.)

Re: [Phpwiki-talk] gettext problems

[Sergio A. K. <ser...@ho...>]

----- Original Message ----- 
From: "Jeff Dairiki" <da...@da...>

hi jeff,

> >I agree 100% with you, while I can see the point on using gettext with
> >a languaje like C, I still cannot see the point on using gettext on
> >a languaje like PHP.
> 
> Not that I'm completely sold on gettext either, but one big advantage
> of using gettext (particularly for developers/translators who use emacs)
> is the ability to use the GNU gettext tools to do things like
> find new strings to be translated in (changed) source code, and
> merge those new strings into the translation (.po) files.

this can be done with a simple perl script I suppose...

> Note that PhpWiki _should_ (is designed to) work even if
> PHP was compiled without gettext support.  If it doesn't, that's
> a bug.  Report it.

well, the fact is, I do have php with gettext support,
but with the recent gettext changes, php changes and so on
I ended up with a semi-working gettext support in php

and I reported my problem to nalin at redhat who confirmed
the problem...

and the fact is that a dictionary-based translation Just Work (tm),
translations with gettext, work if you are lucky...

> >a solution based on $HTTP_SERVER_VARS["HTTP_ACCEPT_LANGUAGE"]
> >(ie. the client browser languaje) ... is IMO better ...
> 
> 
> 1. You wouldn't want HTTP_ACCEPT_LANGUAGE to affect the default
>    pgsrc.
> 
> 2. Since the page content of a particular wiki are (most often)
>    primarily in one language, there's not a whole lot of point
>    in allowing the viewer to select various languages for the
>    templates/dates...

yeah, that may be a problem, but the root problem is that there are
different templates for every languaje, and *that* is what is wrong
IMHO...
and another thing that is wrong is that phpWiki treat english like
a special languaje, there is no need to, "en" should be in locale
like everybody else...

/sergio

Re: [Phpwiki-talk] PHPWiki accent support

[Steve W. <sw...@pa...>]

On Fri, 8 Jun 2001, Jeff Dairiki wrote:

> One cheap solution which might help a few people would be to add a
> line containing the funky characters to the editpage.html form.
> That way, people who can't figure out how to type in an accented
> character could at least cut and paste the one they want.

This is a neat idea... although most people who use accented/umlatted/etc
chars probably have them on their keyboard. I had to use a French keyboard
once and it blew my mind.

~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

RE: [Phpwiki-talk] PHPWiki accent support

[Christian R. R. <ki...@as...>]

(I hate not being subscribed to a list. Fixing that..)

Jeff writes:

	Yes, but you can type them in as ISO-8859-1 eight-bit characters
	just fine.  (What you have to do to type these in depends on your
	OS & browser &c.)

	Do we want to support entities in the page text?  If we do then
	'&' suddenly becomes a magic character.  (I vote against it.)

Hey Jeff, thanks for the answer.

Now that's a good question. By using non-entitized characters that are
supported in Latin-1 (aka ISO-8859-1) and other character sets, you do
create a problem of backwards compatibility with browsers that have no
support for selecting (or discovering, if the standard indication
Content-Type: text/html; charset=foobar is used) character sets.

This might and might not be an issue depending on the specifics of your
application, but the truth is that very few sites today issue
Content-type: lines that specify the correct charset, and international
browsers do break (I've seen this over in Asia, and so do we when visiting
Japanese sites in Netscape).

Now using entities makes this very simple (which is why I've done the
conversion here, myself) and avoids any sort of encoding problem. I don't
understand the point that & suddenly becomes a magic character -- why?
(Perhaps more importantly; what is a magic character?). If this means it
has to be allowed inside the regexp, for example, I disagree, though
perhaps I'm viewing this incompletely:

I only do entitizing on HTML output; internally, they are stored as
Latin-1 characters (actually, whatever you specify your browser and
database to handle AFAICS) and they are converted inside transform.php,
which makes all internal handling treat Latin-1. I can't see at this point
how this affects other character sets, but perhaps this is an alternative
view from yours?

Does & still have to be a magic character if it is only generated on
output? I am not advocating writing (entering data in the form) entitized
-- this is broken and counter-productive; only displaying entitized, to
allow a wider audience with less breakage. This is _almost_ a non-issue
with Latin-1, since most browsers render that by default, but on
non-Latin-1 charsets (and thus, locales and languages), this _will_ be an
issue. Is this besides the point?

Take care,
--
/\/\ Christian Reis, Senior Engineer, Async Open Source, Brazil
~\/~ http://async.com.br/~kiko/ | [+55 16] 274 4311

Re: [Phpwiki-talk] etc/*

[Steve W. <sw...@pa...>]

This is something that's been on my mind since Jeff moved all the config
into index.php and all the main functionality into main.php.

I think this is the old argument about where does main() go: at the top,
in the first file, or at the bottom after you've declared everything? I
miss having index.php contain all the main functionality (the program
flow) and all config info off in a config file.

Sergio is following a standard practice of putting config info in etc/,
and that's admirable. I would argue that PhpWiki is small enough that
it's not necessary, but it couldn't hurt to have lib, etc, var or whatever
is needed. An etc/ could hold a config file and a style sheet.

~swain

On Fri, 8 Jun 2001, Sergio A. Kessler wrote:

> ----- Original Message -----
> From: "Jeff Dairiki" <da...@da...>
>
>
> > >putting the code where my mouth is, this patch create
> > >a etc/* directory to put cfg there, so cleaning up index.php
> > >
> > >comments ?
> >
> > All you've done is split index.php into four separate files.
> > What does this buy you?
>
> some cleanup, IMO having the cfg in index.php, and even worse
> when you put all cfg in there, all togheter...
>
> well, maybe is my coding style, I prefer to have ten files
> which do ten differents things, and not one file that does
> ten differents things...
>
> /sergio
>
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> http://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

Re: [Phpwiki-talk] etc/*

[Sergio A. K. <ser...@ho...>]

----- Original Message ----- 
From: "Jeff Dairiki" <da...@da...>


> >putting the code where my mouth is, this patch create
> >a etc/* directory to put cfg there, so cleaning up index.php
> >
> >comments ?
> 
> All you've done is split index.php into four separate files.
> What does this buy you?

some cleanup, IMO having the cfg in index.php, and even worse
when you put all cfg in there, all togheter...

well, maybe is my coding style, I prefer to have ten files
which do ten differents things, and not one file that does
ten differents things...

/sergio

Re: [Phpwiki-talk] gettext problems

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

>I agree 100% with you, while I can see the point on using gettext with
>a languaje like C, I still cannot see the point on using gettext on
>a languaje like PHP.

Not that I'm completely sold on gettext either, but one big advantage
of using gettext (particularly for developers/translators who use emacs)
is the ability to use the GNU gettext tools to do things like
find new strings to be translated in (changed) source code, and
merge those new strings into the translation (.po) files.

Note that PhpWiki _should_ (is designed to) work even if
PHP was compiled without gettext support.  If it doesn't, that's
a bug.  Report it.

>a solution based on $HTTP_SERVER_VARS["HTTP_ACCEPT_LANGUAGE"]
>(ie. the client browser languaje) ... is IMO better ...


1. You wouldn't want HTTP_ACCEPT_LANGUAGE to affect the default
   pgsrc.

2. Since the page content of a particular wiki are (most often)
   primarily in one language, there's not a whole lot of point
   in allowing the viewer to select various languages for the
   templates/dates...

(see also
  <http://phpwiki.sourceforge.net/phpwiki/index.php?MultiLingualWiki>)