phpwiki-talk

Re: [Phpwiki-talk] About languages

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

On Wed, 28 Nov 2001 10:08:36 +0000
"Lawrence Akka" <la...@20...> wrote:

> A few thoughts -
> 
> 1)  The language of the interface should be user-selectable.  Just
because 
> the [web|wiki]master has decided to set the locale as Italian, doesn't
mean 
> that everyone wants to see Italian links/instructions.

Yes, once we have real users and user preferences, that's probably a fine
idea.
 
> 2)  Is gettext the best solution for Multi-languages?  It requires php
to 
> be complied in a particular way.  Not everyone can specify how php is 
> compiled.

One of the big advantages of using gettext is the development tools that
are available for it.  (I.e. there is a program which scans through all
the source code and pulls out strings which are used as arguments to
gettext; another program merges any changes in that set of strings with
the editable translation map (.po) files; and there's a po-mode for
emacs.)

PhpWiki does not require gettext support to be compiled in to PHP.  It
provides a pure PHP replacement if it's not.  (I haven't tested that in
awhile, so it may well be broken...)

The only downside I see is that one is required to have the gettext tools
installed (and have some idea of how to use them) to be able to edit or
customize the translations. 

We need to use the standard setlocale() stuff anyway to get date formats
right.  Gettext is the natural way to handle translated strings.

>     define ('_MUST_BE_AUTH', 'You must be authorised to do that');

This is a nightmare to maintain.  Imagine:

  In somefile.php:
      $msg = sprintf(_MUST_BE_AUTH_TO_EDIT, $pagename);

  In somelang.php:
      define ('_MUST_BE_AUTH_TO_EDIT', "Ogg frrble MOTU erg '%s' frk.");

  In deflang.php:
      if (! defined('_MUST_BE_AUTH_TO_EDIT'))
           define ('_MUST_BE_AUTH_TO_EDIT', "You must be god to edit
'%s'.");

The gettext development tools handle all this for you.

> Another problem with gettext is that if you mistype the original
> language in the code (and some of the phrases are quite long),
> gettext is unable to find the translation.

If/when the language becomes user selectable, I think the selection will
be made via a <select> field in a <form>.  (The local admin will have to
make sure the the choices presented are all valid on the local system.)

On the administration side: it is very confusing to figure out which LANG
settings work on a particular system.  We should probably code in a list
of alternatives to try for each language which PhpWiki supports.  I.e. in
the config file, the admin sets $LANG='german'; the php code then tries
LANG='de_DE.ISO-8859-1', LANG='de_DE', LANG='de', LANG='deutsch',
LANG='german' until it finds one which works.

> 3)  It seems to me to be asking for trouble to have to translate the 
> templates for each language.  Each time the template changed, the 
> translations would have to be updated.  Wouldn't it be better to have 
> language defines (as above), or even template variables in the template,

> which are replaced by the Template munger appropriately, eg:

Yes.  Good idea.

This can more-or-less be done now (in 1.3), in an ugly fashion, as
follows: 

   <a href="http://..."><?php echo gettext("Some text."); ?></a>

Perhaps we could support a more compact syntax...


And while on the subject, my one nit about gettext is:

For it's compactness, I much prefer 
   $msg = _("string");
to
   $msg = gettext("string");

The _() abbreviation is standard usage --- the gettext tools support it by
default.  (PHP, if gettext support is compiled in, supports the _() syntax
already.  We'd have to define the '_' replacement function when there's no
PHP gettext support if we were to start using it in PhpWiki code.)

Does anyone have objections to the abbreviated syntax?

RE: [Phpwiki-talk] About languages

[Lawrence A. <la...@20...>]

A few thoughts -

1)  The language of the interface should be user-selectable.  Just because 
the [web|wiki]master has decided to set the locale as Italian, doesn't mean 
that everyone wants to see Italian links/instructions.

2)  Is gettext the best solution for Multi-languages?  It requires php to 
be complied in a particular way.  Not everyone can specify how php is 
compiled.  What about a file with defined constants, eg:

    define ('_MUST_BE_AUTH', 'You must be authorised to do that');

We could then translate the file for each language, and include the 
appropriate one, depending on the user's selection.  Another problem with 
gettext is that if you mistype the original language in the code (and some 
of the phrases are quite long), gettext is unable to find the 
translation.  Perhaps the answer is that I should type more carefully!

3)  It seems to me to be asking for trouble to have to translate the 
templates for each language.  Each time the template changed, the 
translations would have to be updated.  Wouldn't it be better to have 
language defines (as above), or even template variables in the template, 
which are replaced by the Template munger appropriately, eg:

     <a href=blah.blah>{GETTEXT: _EDITLINK}</a>

Lawrence Akka

-------------------------------------------------
FROM: nada.kth.se
DATE: 11/27/2001 10:09:21
SUBJECT: RE: [Phpwiki-talk] About languages

--azLHFNyN32YCQGCU
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by my.nada.kth.se id 
TAA14304

On Tue, Nov 27, 2001 at 09:29:45AM -0800, Jeff Dairiki wrote:

 > Yes, all the non-english templates are currently broken in PhpWiki 1.3.

I've just made a small update (po, pgrsc, and templates) to the
Swedish translation of 1.2 (attached, I hope it's ok?) and I'll fix it
for the 1.3 line as well, but not tonight.



==========NOTICE==========
Internet e-mail is not necessarily secure or reliable.  Please let us know if you would like to establish a secure channel of communication.
This e-mail and any attachments are confidential and may be legally privileged. They are intended only for the use of the named recipient. If you are not the named or intended recipient, please notify us immediately. In such an event, you should not disclose the contents of this e-mail or any attachments to any other person, nor copy, print, store or use them in any manner whatsoever. Thank you for your co-operation.
Although we have taken precautions to minimize the risk of transmitting software viruses, you are advised to carry out your own virus checks on any attachments to this message.
Tel: +44 (0)207 842 1200
http://www.20essexst.com
pos...@20...

Re: [Phpwiki-talk] XML?

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

On Wed, 28 Nov 2001 02:07:59 +0000 
Reini Urban <ru...@x-...> wrote:
> J C Lawrence schrieb:

> Jabber look's good, but I personally don't like jabber that much.

Any reasons other than your problems with client install?

> Tried some days to install a jabber based chat client on my Suse
> 7.2 and 7.0 but failed. 

Gabber is the most actively developed OSS Jabber client, but is
(unfortunately) heavily Gnome oriented.  Jarl is a CLI and Perl/TK
cleitn that is essentially trivially self-installing.  Not fully
featured, but works reliably here.

Then there's things like EveryBuddy which have Jabber compatability.

-- 
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.

Re: [Phpwiki-talk] XML?

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

J C Lawrence schrieb:
> Support for an XML/RPC layer would be more interesting, especially
> something that can integrate with Jabber ala Jogger:
> 
>   http://jogger.jabber.org/

Jabber look's good, but I personally don't like jabber that much. 

Tried some days to install a jabber based chat client on my Suse 7.2 
and 7.0 but failed. The simple ircd server worked out of the box.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

RE: [Phpwiki-talk] XML?

[Lawrence A. <Law...@th...>]

What I had in mind was something along the lines of an Wiki XML 
DTD.  I know that a huge amount of work has gone into the new 
MIME format, but what about storing pages as XML?  They could 
then be rendered by XSLT on the client side (if available) or on the 
server side if not.

It would be much easier to access pages using other tools.

There is some discussion about this (and much interest in it) at 

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

Also, http://openwiki.com/ seems to use XML quite effectively.  

Just a thought.  Any views?

Lawrence Akka

Re: [Phpwiki-talk] Re: need help with cvs, unable to move a directory :-(

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

> Ooph.  {{{text}}} is ugly.

yep.  maybe |text| or will that mess with table rendering?  or >text< i'm
just trying to think of what could be used.  &text& or %text% none are
particularly intuitive.  at least ``text`` kinda fits in with past schemes
though it also lends to confusion since most people are bad at spotting
the differences and in fact some browser font rendering makes it almost
impossible to tell the difference.

> Usemod supports <tt></tt>, <b></b>, <i></i>, <em></em>,
> <strong></strong>, and also supports the legacy ''italic'' and
> '''bold'''.  I don't know if there are alternate forms for <tt> (I
> don't think so).

that would work though i like not having to type html tags.

another thought, i don't like the leading whitespace for mono-spaced text
at all because it means that "^ *" doesn't begin a list and that's pretty
confusing i think.  if supporting <tt>text</tt> could mean doing away
leading white space for mono that would be great and leading whitespace
could stop being significant.

> Maybe not.  I think the above syntaxes could be added without breaking
> the older syntaxes (at least not much), so we could have it all.

maybe an option to activate old syntax and at some point make the new
syntax standard?  there's a lot of good thoughts on meatball about wiki
syntax ... i think a lot of this stuff has evolved since wiki markup was
first invented and certainly the purposes for which wiki's have used do
to.

another thing i'd really like is an alternate table syntax i stubled
across on NiKki (a moin spin off).  the way all the wiki's i know of
renders tables gets *really* hard to maintain as tables get more complex.
if you want an example check this page and edit it:

  http://www.personaltelco.net/index.cgi/Prism2Card

i like the idea of treating tables like lists so you could make a table
like this:

* table heading
** row one
*** column one
*** column two
** row two
*** etc ...

i'm not sure of the exact syntax that NiKki uses and you'd have to make
sure that it was able to tell teh difference between lists and tables, but
i think it would be *much* nicer to maintain tables that way, and
sometimes tables are the only way to effectively present data.  on the
prism2card page we started with lists and it was visually overwhelming and
hard to find the information you wanted (let alone cross reference it with
anything else).

> It's true that I can't imagine very many circumstances where one would
> want monospaced WikiWords.  However, I think it's just plain confusing
> if italicizing and emboldening behave differently than monospacing.
> (Unless the markup gives more specific hints that other magic is going
> on, e.g. <code>ThisIsNotaWikiWord</code>.)

fair enough.  maybe limited support for certain html tags would make sense
then?

adam.

Re: [Phpwiki-talk] XML?

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

On Tue, 27 Nov 2001 09:44:19 -0800 
Jeff Dairiki <da...@da...> wrote:
> On Thu, 22 Nov 2001 22:57:51 -0000 "Lawrence Akka"
> <Law...@th...> wrote:

>   Consideration for ability to edit wiki pages via XML-ized
> methods: Think about SOAP?  How does this tie in with WebDAV?

Support for an XML/RPC layer would be more interesting, especially
something that can integrate with Jabber ala Jogger:

  http://jogger.jabber.org/

It would also be interesting/useful to extend the auth model to use
Jabber as a federated auth mechanism (a number of CMS tools such as
Drupal are already doing this).
 
  http://www.drop.org/node.php?id=531&cid=1166
  http://www.drop.org/node.php?id=672

And on an Apache-specific level:

  http://research.covalent.net/mod_auth_jabber/

-- 
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.

Re: [Phpwiki-talk] Re: need help with cvs, unable to move a directory :-(

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

On Tue, 27 Nov 2001 12:09:22 -0800 (PST)
"Adam Shand" <ad...@pe...> wrote:

> there was some brief discussion, i believe the only reason it was chosen
> is that no one could think of anything else that was available.  moin
uses
> {{{text}}} which isn't great, i'm not sure what usemod uses.

Ooph.  {{{text}}} is ugly.

Usemod supports <tt></tt>, <b></b>, <i></i>, <em></em>, <strong></strong>,
and also supports the legacy ''italic'' and '''bold'''.  I don't know if
there are alternate forms for <tt> (I don't think so).

> > (I'm not sure I like the current __ and '' syntax either, but it's
> > kind of late to change that.  If I had the chance to do it over again
> > today, I think I would do (more or less UseMod style):
> >
> >   Support <i>italic</i>, <b>bold</b>, <tt>fixed</tt>.
> >
> >   Support also some e-mail heuristic style markup:
> >      *bold*, _italic_, etc.
> 
> i like /italic/ though i'm not sure if that conflicts with anything.  is
> there any reason to support _underline_?  or is that deemed confusing.
> i've certainly never missed it anyway.
>
> is it really too late?

Maybe not.  I think the above syntaxes could be added without breaking the
older syntaxes (at least not much), so we could have it all.


> > I think I'm against disabling WikiWord linkage within <tt>, though I
do
> > like UseMods <pre> and <nowiki> tags to help with that problem.
> 
> how come?  in what situations do you want monospaced text and WikiWords?

It's true that I can't imagine very many circumstances where one would
want monospaced WikiWords.  However, I think it's just plain confusing if
italicizing and emboldening behave differently than monospacing.  (Unless
the markup gives more specific hints that other magic is going on, e.g.
<code>ThisIsNotaWikiWord</code>.)

Re: [Phpwiki-talk] Re: need help with cvs, unable to move a directory :-(

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

> It's already (sort of) there in PageNamesInPathInfo.  (Not that that's
> any better of a name.)

ah, i figured it was there somewhere ...

> Yes.  I've fixed it in CVS, but the fix hasn't made it to the /wiki
> wiki yet. I'll work on it today.

great, thanks.

> You can't put blank lines between items.  (A blank link starts a whole
> new <ol>.)  PhpWiki has always been this way, I think.  I don't like
> it either.  The fix is not completely trivial, I think, so I've been
> putting it off (and, I think I'll continue to do so.)

<laugh> ... okay.  shame though it's awkward.

> Personally, I'm somewhat undecided.  I would like the ability to
> include <tt> text inline.  I'm not sure I like the syntax.  (I don't
> like the backticks, and would rather see nearly any other character
> used for the escape.)

there was some brief discussion, i believe the only reason it was chosen
is that no one could think of anything else that was available.  moin uses
{{{text}}} which isn't great, i'm not sure what usemod uses.

> (I'm not sure I like the current __ and '' syntax either, but it's
> kind of late to change that.  If I had the chance to do it over again
> today, I think I would do (more or less UseMod style):
>
>   Support <i>italic</i>, <b>bold</b>, <tt>fixed</tt>.
>
>   Support also some e-mail heuristic style markup:
>      *bold*, _italic_, etc.

i like /italic/ though i'm not sure if that conflicts with anything.  is
there any reason to support _underline_?  or is that deemed confusing.
i've certainly never missed it anyway.

is it really too late?  i think some of the wiki syntax phpwiki uses could
be refined a lot.  the alpha tree is already a large change, would some
changes in hwo it works be possible or is that breaking too much backwards
compatibility.

> At least that's what I think today.

i agree with you.

> I think I'm against disabling WikiWord linkage within <tt>, though I do
> like UseMods <pre> and <nowiki> tags to help with that problem.

how come?  in what situations do you want monospaced text and WikiWords?

> It's already there, I think.  (In slightly modified form --- I've
> changed it so that the rhs can't contain punctuation.)

great, thanks.

adam.

Re: [Phpwiki-talk] Re: need help with cvs, unable to move a directory :-(

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

On Tue, 27 Nov 2001 09:44:29 -0800 (PST)
"Adam Shand" <ad...@pe...> wrote:

> i added this info the the /wiki wiki under the name PrettyWiki (sorry
for
> the bad name choice, I'm at work and will ponder a proper name later).
> however i noticed two things:

It's already (sort of) there in PageNamesInPathInfo.  (Not that that's 
any better of a name.)
 
>  * the full text search is broken (i wanted to search to see if this
info
>    was already on the wiki)

Yes.  I've fixed it in CVS, but the fix hasn't made it to the /wiki wiki
yet.
I'll work on it today.
 
>  * numeric lists don't work properly i don't think.  i think they should
>    be more generous about continuing a list, otherwise listing technical
>    docs like this is really hard (cause it keeps resetting to 1.).

You can't put blank lines between items.  (A blank link starts a whole
new <ol>.)  PhpWiki has always been this way, I think.  I don't like
it either.  The fix is not completely trivial, I think, so I've been
putting
it off (and, I think I'll continue to do so.)

>  * it would be nice if ``WikiWord`` acted as a <tt></tt>.  this was
>    discussed a while ago.  i believe the patch is trivial can we add it?
>    i also think it would be nice if the monospace tags (leading
whitespace
>    and maybe ``) escaped automatic linking of WikiWords.  i use
monospace
>    almost exclusively for technical snippets and having all the apache
>    directives show up as links is annoying.

What's the general concensus on this?  (Yes, the patch is trivial.)

Personally, I'm somewhat undecided.  I would like the ability to include
<tt> text inline.  I'm not sure I like the syntax.  (I don't like the
backticks, and would rather see nearly any other character used for the
escape.)

(I'm not sure I like the current __ and '' syntax either, but it's kind of

late to change that.  If I had the chance to do it over again today, I
think
I would do (more or less UseMod style):

  Support <i>italic</i>, <b>bold</b>, <tt>fixed</tt>.

  Support also some e-mail heuristic style markup:
     *bold*, _italic_, etc.
  (In these cases the escape characters have to be properly nestled up
  to words: * bold * doesn't work, and there's no italics in
a_packed_word.)

At least that's what I think today.


I think I'm against disabling WikiWord linkage within <tt>, though I do
like UseMods <pre> and <nowiki> tags to help with that problem.

> finally and unrelated, could the patch you sent me to allow non-wiki
word
> right had sides of interwiki links be included in cvs please?

It's already there, I think.  (In slightly modified form --- I've changed
it
so that the rhs can't contain punctuation.)


Jeff

Re: [Phpwiki-talk] About languages

[Jon <d9...@na...>]

On Tue, Nov 27, 2001 at 09:29:45AM -0800, Jeff Dairiki wrote:

> Yes, all the non-english templates are currently broken in PhpWiki 1.3.

I've just made a small update (po, pgrsc, and templates) to the
Swedish translation of 1.2 (attached, I hope it's ok?) and I'll fix it
for the 1.3 line as well, but not tonight.

--=20
___\ Jon =C5slund

Re: [Phpwiki-talk] Re: need help with cvs, unable to move a directory :-(

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

> >      Alias /wiki3/ "/Library/WebServer/Documents/phpwiki-1.3/index.php/"
> >      Alias /wiki3  "/Library/WebServer/Documents/phpwiki-1.3/index.php"
>
>   Just as an aside: aren't these two lines redundant?  I think if you
> have the latter, you don't need the former.  (I haven't tested this
> though.)

yep, you're right.

> I should rewrite the comments in index.php.  I no longer use the
> SetHandler method (though it works).  Here's what I do (assumes Apache
> with appropriate permissions):

i added this info the the /wiki wiki under the name PrettyWiki (sorry for
the bad name choice, I'm at work and will ponder a proper name later).
however i noticed two things:

 * the full text search is broken (i wanted to search to see if this info
   was already on the wiki)

 * numeric lists don't work properly i don't think.  i think they should
   be more generous about continuing a list, otherwise listing technical
   docs like this is really hard (cause it keeps resetting to 1.).

 * it would be nice if ``WikiWord`` acted as a <tt></tt>.  this was
   discussed a while ago.  i believe the patch is trivial can we add it?
   i also think it would be nice if the monospace tags (leading whitespace
   and maybe ``) escaped automatic linking of WikiWords.  i use monospace
   almost exclusively for technical snippets and having all the apache
   directives show up as links is annoying.

finally and unrelated, could the patch you sent me to allow non-wiki word
right had sides of interwiki links be included in cvs please?

> This method has the advantage, that one can run several different
> wikis sharing all the PhpWiki code.  (E.g. copy /htdocs/wiki to
> /htdocs/wiki2. Edit $DBParams in wiki2 so that it uses a different
> database.  Now you have two wikis running off the same code.)

yah, i got three phpwiki's running on my server with this method.  works
good ;)

adam.

Re: [Phpwiki-talk] XML?

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

On Thu, 22 Nov 2001 22:57:51 -0000
"Lawrence Akka" <Law...@th...> wrote:

> Just wondering what the position was on XML dumps.  I see some 
> refs to in in the code, but it obvously isn't complete.

Yes, that's my fault.

I started to add XML dumps (mostly to replace the zip-dump functionality),
then
got bogged down while trying to decide on the syntax.

  Should RDF be used for the page meta-data?  (RDF having been designed
    for that purpose.)  (This would also fit in well with RSS generation.)

  Consideration for ability to edit wiki pages via XML-ized methods:
    Think about SOAP?  How does this tie in with WebDAV?

  Or just use a more ad hoc document-like syntax.  Neither RDF nor SOAP
are
    very document-like in structure.

At this point, I know nothing about WebDAV, not much about SOAP, and a
little
about RDF and RSS.  That's where I stopped.

(See http://www.usemod.com/cgi-bin/mb.pl?RssExtensionModuleForWikis for
the latest
news on the wiki RSS front.)


So, if we're serious about XML dumps, I think we need to put some serious
thought
and discussion into the format of the dumps.  If you want to pick up the
ball
on that, that would be great.  (I don't mind doing the coding, once
there's
agreement on a suitable XML syntax.)

Jeff

Re: [Phpwiki-talk] About languages

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

On Thu, 22 Nov 2001 12:41:56 -0600
"Victor A. Jimenez Valdez" <vji...@ci...> wrote:

> Hi,
> 
> I'm trying to install phpwiki in Spanish but I get the '#' symbols on 
> the templates, for example:
> 
> ###ROBOTS_META###

Yes, all the non-english templates are currently broken in PhpWiki 1.3.

I've changed the template syntax from what it was in 1.2, and none of the
templates (except the default, english ones) have been updated to the
new syntax.

The pgsrc also needs to be updated for 1.3.  There are a number of new
magic 
pages (like TitleSearch, LikePages, ...) which need to be added, and some
of 
the existing magic pages need to be updated (RecentChanges, FindPage,
...).

Finally, the .po files (which contain the translations for the
gettextified
phrases) also need to be updated.  This isn't a showstopper, however ---
if
some of the translations in the .po file are out of date, the worst that
will
happen is that some of the PhpWiki output will come out in English...

Sorry.  (But it is alpha code...)

[Phpwiki-talk] Re: need help with cvs, unable to move a directory :-(

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

On Tue, 27 Nov 2001 02:11:46 -0500
"Carsten Klapp" <car...@ma...> wrote:

> I tried to move some files in phpwiki but it isn't working as I
expected. 
> Would you help?

Sure.  Glad to.

The root of the problem, I think, is that CVS really doesn't support
moving
files.  The only way to do it is to delete ("remove") the old file, and
create
("add") a new one.  (I'd guess that your CVS client is trying to be smart,
and offering to fake the process for you --- but it's not smart enough to
pull
it off correctly...)  (This also explains why the revision gets reset to
1.0.
Don't worry about that --- it's unavoidable.)

Try just "removing" the old file and "adding" the new one.

======

As for the changes you're making, I think generally they're fine ideas.  I
do have a few comments/suggestions, though:

There are two sorts of files which need to be "found" during the execution
of PhpWiki: 

  1. PHP source files (including non-PHP code which gets read by the PHP
     code like the templates, interwiki.map, pgsrc, and the entire locale
     subtree)

  2. Files which need to be directly accessible via HTTP.

  The two sets do not overlap (except for index.php, sort of).

  It is somewhat dangerous, security-wise, to have the PHP source code
  directly accesible via HTTP, so it's best if things can be easily
  arranged to deny that.

  Currently (pre your changes) the only files which needed to be HTTP
  accessible were in the top PhpWiki install directory and in images.

  I think it would be best to keep these two classes of files in 
  separate directories (as much as possible) specifically so that
  it's easier to administer, security-wise.  (This would argue against
  putting the style sheets in the templates sub-tree.)

 
> 2. Move nonessentials out of the root directory into a subdirectory 
> already known to wiki. We can eliminate the extra code for data_path vs.

> virtual-path, and hopefully make it easier to use virtual paths.

  I think moving the style sheets into a subdirectory is a fine idea.
  (Perhaps the 'images' subdirectory should be renamed 'data' for this
  purpose.)

  (As a nit, I think the first theme should be called 'default' rather
than
  'vanilla'.)

  I don't think we can eliminate data_path vs virtual_path in all cases
  though.  Not everyone has access to apache's Alias directive (it has
  to go in httpd.conf, and therefore requires root privs;  and, not
everyone
  runs on an apache server...)

  There are several other ways to get the "nice" URLs.  Most involve
  being able to set DATA_PATH.

>      Alias /wiki3/                 
"/Library/WebServer/Documents/phpwiki-1.
> 3/index.php/"
>      Alias /wiki3                  
"/Library/WebServer/Documents/phpwiki-1.
> 3/index.php"

  Just as an aside: aren't these two lines redundant?  I think if you have
the latter, you don't need the former.  (I haven't tested this though.)
 
>      Alias /wiki3admin/       
> "/Library/WebServer/Documents/phpwiki-1.3/admin.php/"
>      Alias /wiki3admin        
> "/Library/WebServer/Documents/phpwiki-1.3/admin.php"

  (There is no admin.php in 1.3.)

  
> - define(data_path..) and associated code is eliminated or reduced, now 
> resolves to Virtual_Path/templates.

As I said, some people will still need DATA_PATH.

I should rewrite the comments in index.php.  I no longer use the 
SetHandler method (though it works).  Here's what I do (assumes
Apache with appropriate permissions):

1) Assuming /htdocs is the  document root for the web server,
   install PhpWiki in e.g. /htdocs/phpwiki-1.3
2) Copy (or symlink) /htdocs/phpwiki-1.3/index.php to /htdocs/wiki.
3) Add the following to /htdocs/.htaccess:
      <Files wiki>
          SetHandler application/x-httpd-php
      </Files>
   (This tells apache that /htdocs/wiki is really a php script.)
4) Edit /htdocs/wiki:
   Set PHP's 'include_path' so that the rest of the PHP code can be found:
       ini_set('include_path', '/htdocs/phpwiki-1.3:/path/to/pear/code');
   Set DATA_PATH so data can be found:
       define('DATA_PATH', '/phpwiki-1.3');

This method has the advantage, that one can run several different wikis
sharing all the PhpWiki code.  (E.g. copy /htdocs/wiki to /htdocs/wiki2.
Edit $DBParams in wiki2 so that it uses a different database.  Now you
have two wikis running off the same code.)




Another thing to keep in mind is that style-sheets will, in the future,
probably become user selectable --- each wiki user can set in their 
preferences which style sheet they like best....  (Themes, as I understand
them, will probably not be user selectable, but rather one will be chosen
(then customized) by the wiki-admin when setting up the wiki.)

(i.e. I foresee selection of style sheets will become somewhat orthogonal
to selection of theme.)


Also, think about how the theme selection is going to interact with the
i18n support in PhpWiki. Currently templates are in locale/$LANG/templates
for each of the supported non-english languages.  (Currently all the
non-english templates are severely broken --- but that's neither here
nor there.... :-)

Would it be best to do away with the templates in the locale subtree, and
instead have each theme be language specific?  E.g. there will be themes 
with names like 'default', (or 'vanilla'), 'default-de', 'default-sv',
'psychedelic', 'psychedelic-nl', etc.  (The locale subtree would still
contain the pgsrc and gettext stuff for the different languages.)

=====

Having rambled through all this now, here's how I would refactor things:

 1) Rename the 'images' subdirectory to 'data'.

 2) Move phpwiki.css to data/default.css, phpwiki-heavy.css to
data/default-heavy.css.

    If there are HTTP accessible files which are specific to certain
themes, put
    them in appropriately named subdirectories of data.  Wikibase.png, on
the
    other hand, I would guess would be used by several themes, so I'm not
sure it
    should go in a theme-specific subdirectory.

 3) Move the theme specific parts of index.php into
themes/<theme-name>.php.  This
    would include pretty much everything in "Part Three" and "Part Four"
of index.php.
    I'm assuming here that themes will be language specific --- otherwise
the
    language config stuff should stay in index.php (or move to
lang/<lang-name>.php?).

 4) Templates for different themes would be in subdirectories
templates/<theme-name>/.

This does do away with your "one directory per theme" paradigm, which is
attractive... 

      
(I've posted this note to phpwiki-talk too, as I'm sure others will have
useful comments
to make on the matter.  If you're not subscribed to phpwiki-talk, you
should be...
  http://lists.sourceforge.net/lists/listinfo/phpwiki-talk
)

[Phpwiki-talk] Re: [phpwiki-checkins] CVS: phpwiki/lib WikiCallback.php,1.1,1.2

[Joe E. <jo...@or...>]

WikiClosures!

Rock on!

    Joe


----- Original Message ----- 
From: "Geoffrey T. Dairiki" <da...@us...>

> New class: WikiAnonymousCb

[Phpwiki-talk] XML?

[Lawrence A. <Law...@th...>]

Just wondering what the position was on XML dumps.  I see some 
refs to in in the code, but it obvously isn't complete.  Can't seem to 
find any info anywhere.

Anyone help?

Lawrence

[Phpwiki-talk] Auth libraries

[Lawrence A. <Law...@th...>]

Just reading the archives to catch up a bit.

I noticed a discussion a few weeks back about about login libraries 
to use.

Postnuke ( http://www.postnuke.com ) has just implemented its 
own.  Its fairly comprehensive and finegrained.  It allows user and 
group permissions for different activities.

If you'd like to know more, please ask, or have a look at the 
postnuke dev mailing list (groups.yahoo.com/pndev)

Lawrence Akka

Re: [Phpwiki-talk] Suggestion - new page templates

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

Joe Edelman schrieb:
> This is a very simple approach;  there has been talk of making a templating
> system more sophisticated than this for use in weblogs.

which weblogging software? 
I only know helma
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] About languages

[Victor A. J. V. <vji...@ci...>]

Hi,

I'm trying to install phpwiki in Spanish but I get the '#' symbols on 
the templates, for example:

###ROBOTS_META###


  [[phpwiki]]
  <http://vic.pcs.amh/phpwiki-1.3.1/###BROWSE###P%C3%A1ginaPrincipal>
  ###PAGE###

###CONTENT###


I've already set the variable LANG to 'es (i.e. $LANG='es';) and I think 
I made all the steps that are mentioned on
the INSTALL file, I'm planning to use it with postgreSQL but first I 
have to solve this ploblem, I'm running under Linux
Red Hat 7.1 and PHP 4..... Can someone help????

Thnks in advance

Greetings

Victor


-- 
Victor Antonio Jiménez                  CIE Desarrollo / Sistemas
Gerente desarrollo                      http://www.cie-mexico.com.mx
Tel. directo: +(52) 2122 15 65          Fax: +(52) 5387 0653 
Conmutador: 53 87 06 00 ext.1565

Re: [Phpwiki-talk] Suggestion - new page templates

[Joe E. <jo...@or...>]

> What do people think of this idea?

I think it's a great idea, and I may implement it myself in a month or two
if no one else has before then.

It looks like you could just add an if statement testing a "copy" parameter
to lib/editpage.php which, if triggered, would use another page's content in
the edit form.  Then you could either:

    (a) modify the EDITPAGE template to include links which reload the edit
page with copy=X set; or
    (b) create a small plugin called TotallyNewPage which displays a
(possibly dynamic) list of templates for the user to choose from with links
into action=edit&copy=X, and rig the ?MissingPageLinks to point to that
intermediate plugin page instead of "&action=edit" in LinkUnknownWikiWord()
in lib/stdlib.php.

This is a very simple approach;  there has been talk of making a templating
system more sophisticated than this for use in weblogs.

    Joe

[Phpwiki-talk] welcome to...

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

Joe Edelman, who will be developing the email notification, and Jeb
Bateman, as a tester, to the PhpWiki development team! I've added them to
the developer list on Sourceforge.

~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] Suggestion - new page templates

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

Lawrence Akka schrieb:
> I was looking at WikkiTikkiTavi this morning for feature ideas.  One thing
> they have just implemented is new page templates.  You can click a link to
> create a new page in the usual way, or you can select (from an appropriate
> index page) from a list of templates.  If you choose a template (eg,
> FAQpage, HomePage, MeetingNote etc), the default text in the edit box
> (currently 'Describe [....] here', for us) is filled in accordingly.  You
> can then edit it as you wish.

very good.
I would use it.

BTW: Steve, cannot this list be managed to reply to list per default 
and not reply to poster. seems to be mailman.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] Suggestion - new page templates

[Lawrence A. <la...@20...>]

Hi,

I have been following this list for a while, and have been annoying people 
with bug reports, but I have never posted here before.  Please be gentle 
with me :-)

I was looking at WikkiTikkiTavi this morning for feature ideas.  One thing 
they have just implemented is new page templates.  You can click a link to 
create a new page in the usual way, or you can select (from an appropriate 
index page) from a list of templates.  If you choose a template (eg, 
FAQpage, HomePage, MeetingNote etc), the default text in the edit box 
(currently 'Describe [....] here', for us) is filled in accordingly.  You 
can then edit it as you wish.

This is very helpful for stie admins running eg documentation projects, 
where they want to achieve some consistent look and feel.

We could implement this with a plugin, which takes as its argument the 
default text to appear in the edit box.  Alternatively perhpas, the admin 
could set up a list of predefined templates, and then create a link (using 
a plugin with the template name as an argument) which when clicked creates 
a new page with the right default text.


What do people think of this idea?

Lawrence Akka


==========NOTICE==========
Internet e-mail is not necessarily secure or reliable.  Please let us know if you would like to establish a secure channel of communication.
This e-mail and any attachments are confidential and may be legally privileged. They are intended only for the use of the named recipient. If you are not the named or intended recipient, please notify us immediately. In such an event, you should not disclose the contents of this e-mail or any attachments to any other person, nor copy, print, store or use them in any manner whatsoever. Thank you for your co-operation.
Although we have taken precautions to minimize the risk of transmitting software viruses, you are advised to carry out your own virus checks on any attachments to this message.
Tel: +44 (0)207 842 1200
http://www.20essexst.com
pos...@20...

Re: [Phpwiki-talk] RFC: EmailNotification Syntax and Link.ctime

[Joe E. <jo...@or...>]

TALKING SYNTAX

Jeff, although it's great for content expansions, I don't think your
<?plugin?> syntax is a good candidate for EmailNotification for the
following reasons:

1) While it would suffice for NotifyAboutChanges, the NotifyAboutLinks
plugin has to run some code on every new link, even those made while editing
pages that never mention NotifyAboutLinks-- we still need the event stuff.

2) I don't see the "NotifyAboutChanges:\n\n{list}\n\n" construct as defining
new syntax so much as offering a new convention.  It is outside the reach of
the transform/link code and renders the same as anything else.  Event-based
plugins that hook 'onMajorRevision' can presumably use their handlers to
look for anything, even a person's name or a certain pattern of dialogue.
This one happens to look for the words "NotifyAboutChanges" followed by a
list.

3) The <?plugin?> approach would presumably hide the data inside the plugin
from the user during an ordinary render.  From the user's perspective, I bet
this will feel more like voodoo than the PlainEnglish alternative.  One of
Wiki's strengths is that, when you hit EDIT, you get something that looks a
lot like BROWSE.  I think we should act to minimize those surprises and keep
edit looking very much like browse.

4) Tooling around wikis in the last month or so I've been really impressed
by the plaintext aesthetic.  With my newfound design sensibilities, a
"notify me when this page is edited" button in the middle of things seems
like an unnecessary and disruptive doodad in an otherwise tranquil sea of
hypertext.  I'd rather they just edit and add their name to the list.


AND NOW BACK TO LINK.CTIME

Alarms can definitely replace page_expire.  Forget you ever heard the words
page_expire.  I have found the new religion of WikiTimerManager!

BUT...

I'm not sure whether the same thing can work on a link level.  You see, I
don't want to send an email per stale link, I want to send an email per
"NotifyAboutLinks (older than):" block.  Each of these emails will inform
about all of the links that are unnotified and older than the block's
threshold.  The only way I can think to do this with alarms & callbacks at
the link level would be to have the callback function add the links into a
big data structure in memory which is kept sorted by (page,
older_than_block) and then step through this sorted structure after
$am->run().  But this uses a lot of memory for large updates.

An alternative would be to build some way to group the alarms based on their
metadata and $am->run() the groups, but that seems like an abuse of the
WikiTimerManager concept.

So it looks like we're back to link.ctime, unless you see something that I
don't see.

Regards,

 Joe