phpwiki-talk

[Phpwiki-talk] SourceForge: PROJECT DOWNTIME NOTICE (fwd)

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

Note Sourceforge is working on infrastructure. There will be outages this
Friday Dec. 15. See below for specifics.

sw

...............................ooo0000ooo.................................
   Hear FM quality freeform radio through the Internet: http://wcsb.org/
                     home page: www.wcsb.org/~swain 

---------- Forwarded message ----------
Date: Tue, 12 Dec 2000 11:48:00 -0800
From: no...@so...
To: no...@so...
Subject: SourceForge: PROJECT DOWNTIME NOTICE

ATTENTION SOURCEFORGE PROJECT ADMINISTRATORS

This update is being sent to project administrators only and contains
important information regarding your project. Please read it in its
entirety.


INFRASTRUCTURE UPGRADE, EXPANSION AND RELOCATION

As noted in the sitewide email sent this week, the SourceForge.net
infrastructure is being upgraded (and relocated). As part of this
projects, plans are underway to further increase capacity and
responsiveness.

We are scheduling the relocation of the systems serving project
subdomain web pages.


IMPORTANT:

This move will affect you in the following ways:

1. Service and availability of SourceForge.net and the development
tools provided will continue uninterupted.

2. Project page webservers hosting subdomains
(yourprojectname.sourceforge.net) will be down Friday December 15 from
9PM PST (12AM EST) until 3AM PST.

3. CVS will be unavailable (read only part of the time) from 7PM
until 3AM PST

4. Mailing lists and mail aliases will be unavailable until 3AM PST


---------------------
This email was sent from sourceforge.net. To change your email receipt
preferences, please visit the site and edit your account via the
"Account Maintenance" link.

Direct any questions to ad...@so..., or reply to this email.

Re: [Phpwiki-talk] nl.po update

[Arno H. <aho...@in...>]

> Just a quick language update.

committed. Thank you!
/Arno

[Phpwiki-talk] nl.po update

[Jan N. <ja...@gn...>]

Hi list,

Just a quick language update.

Greetings,
Jan.

--- ./locale/po/nl.po.orig	Mon Dec 11 14:30:10 2000
+++ ./locale/po/nl.po	Mon Dec 11 14:30:54 2000
@@ -10,7 +10,7 @@
 msgid ""
 msgstr ""
 "Project-Id-Version: phpwiki 1.1.7\n"
-"POT-Creation-Date: 2000-11-13 12:30+0100\n"
+"POT-Creation-Date: 2000-12-11 14:30+0100\n"
 "PO-Revision-Date: 2000-09-30 02:23+0200\n"
 "Last-Translator: Jan Nieuwenhuizen <ja...@gn...>\n"
 "Language-Team: Dutch <nl...@li...>\n"
@@ -22,52 +22,52 @@
 
 #: admin.php:26
 msgid "You entered an invalid login or password."
-msgstr ""
+msgstr "Je hebt een ongeldige gebruikersnaam of wachtwoord ingevoerd."
 
 #: admin.php:47
 #, c-format
 msgid "You are about to remove '%s' permanently!"
-msgstr ""
+msgstr "Je staat op het punt '%s' voorgoed te verwijderen!"
 
 #: admin.php:50
 #, c-format
 msgid "Click %shere%s to remove the page now."
-msgstr ""
+msgstr "Klik %shier%s om de pagina nu te verwijderen."
 
 #: admin.php:53
 msgid "Otherwise press the \"Back\" button of your browser."
-msgstr ""
+msgstr "Druk anders op de \"Terug\" knop van je bladeraar."
 
 #: admin.php:55
 msgid "Function not yet implemented."
-msgstr ""
+msgstr "Functie nog niet geïmplementeerd."
 
 #: admin.php:57 admin.php:65
 msgid "Remove page"
-msgstr ""
+msgstr "Verwijder pagina"
 
 #: admin.php:63
 #, c-format
 msgid "Removed page '%s' succesfully."
-msgstr ""
+msgstr "Pagina '%s' verwijderd."
 
-#: lib/config.php:159
+#: lib/config.php:162
 msgid "templates/browse.html"
 msgstr "locale/nl/templates/browse.html"
 
-#: lib/config.php:160
+#: lib/config.php:163
 msgid "templates/editpage.html"
 msgstr "locale/nl/templates/editpage.html"
 
-#: lib/config.php:161
+#: lib/config.php:164
 msgid "templates/editlinks.html"
 msgstr "locale/nl/templates/editlinks.html"
 
-#: lib/config.php:162
+#: lib/config.php:165
 msgid "templates/message.html"
 msgstr "locale/nl/templates/message.html"
 
-#: lib/config.php:178
+#: lib/config.php:181
 msgid "./pgsrc"
 msgstr "locale/nl/pgsrc"
 
@@ -162,16 +162,16 @@
 msgid "Searching for \"%s\" ....."
 msgstr "Zoeken naar \"%s\" ..."
 
-#: lib/fullsearch.php:44
+#: lib/fullsearch.php:45
 #, c-format
 msgid "%d matches found in %d pages."
 msgstr "%d keer gevonden in %d pagina's."
 
-#: lib/fullsearch.php:47
+#: lib/fullsearch.php:48
 msgid "Full Text Search Results"
 msgstr "Volledige tekst zoek resultaten"
 
-#: lib/msql.php:29 lib/mysql.php:35
+#: lib/msql.php:29 lib/mysql.php:36
 msgid "Cannot establish connection to database, giving up."
 msgstr "Kan verbinding naar data base niet tot stand brengen, geef op."
 
@@ -180,7 +180,7 @@
 msgid "Error message: %s"
 msgstr "Foutboodschap: %s"
 
-#: lib/msql.php:35 lib/mysql.php:41
+#: lib/msql.php:35 lib/mysql.php:42
 #, c-format
 msgid "Cannot open database %s, giving up."
 msgstr "Kan data base %s niet openen, geef op."
@@ -200,20 +200,20 @@
 msgid "Insert into %s failed: %s"
 msgstr "Insert in %s gefaald: %s"
 
-#: lib/mysql.php:37 lib/mysql.php:43 lib/mysql.php:117 lib/mysql.php:156
+#: lib/mysql.php:38 lib/mysql.php:44 lib/mysql.php:118 lib/mysql.php:158
 #, c-format
 msgid "MySQL error: %s"
 msgstr "MySQL fout: %s"
 
-#: lib/mysql.php:115
+#: lib/mysql.php:116
 #, c-format
 msgid "Error writing page '%s'"
 msgstr "Fout bij schrijven pagina `%s'"
 
-#: lib/mysql.php:154
+#: lib/mysql.php:156
 #, c-format
 msgid "Cannot delete '%s' from table '%s'"
-msgstr ""
+msgstr "Kan '%s' niet verwijderen uit tabel '%s'"
 
 #: lib/pageinfo.php:9
 msgid "Enter a page name"
@@ -333,12 +333,12 @@
 
 #: lib/stdlib.php:207 lib/stdlib.php:215
 msgid "Search"
-msgstr ""
+msgstr "Zoek"
 
 #: lib/stdlib.php:330
 msgid "Stack bounds exceeded in SetHTMLOutputMode"
-msgstr ""
+msgstr "Stack grenzen overschreden in SetHTMLOutputMode"
 
-#: lib/stdlib.php:384 lib/stdlib.php:447
+#: lib/stdlib.php:384 lib/stdlib.php:445
 msgid "RecentChanges"
 msgstr "RecenteVeranderingen"


-- 
Jan Nieuwenhuizen <ja...@gn...> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien       | http://www.lilypond.org

[Phpwiki-talk] Re: |'s

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

On Sat, 9 Dec 2000, Stephan Marzi - MIG wrote:

> its perfect that the script works now without problems, but is there may
> also a possibility to remove the "|" function. I don't like to write a |
> in every line. I will use a javascript html editor and its nearly
> imopossible to insert |'s on every line.  What can I do? 

| <joke>
| Use Emacs ;^)
| </joke>

WELL... we have no plans to do away with the |, and in the one year that
this project has existed you're the first person to use HTML, AFAIK.

But there is the issue also of: putting program code into the Wiki.
Recently a user wanted to put bash scripts into pages, but this means he
has to indent every single line with a space so the formatting is
preserved. There is a way to introduce something like <pre></pre> tags
into PhpWiki.

This would apply to your problem too. I want to add it but it won't happen
anytime soon (OTOH it might happen right away if someone sends a patch).

The central technical problem here is that we process the Wiki markup one
line at a time, instead of as one big blob of text. This usually means one
line doesn't know what markup other lines contain; for example,

''this will not
appear in italics
because it spans lines''

whereas ''this would'' because it's self contained. This is the technical
reason why eliminating leading bars or spaces is a problem.

It's always been the case that users want more markup; we've received
three patches to add tables, and to date we've not added them. I've always
said from the outset that I will not reinvent HTML, which is the end
result of adding more markup constructs to the language.

However I'll look into the matter, because it's an interesting technical
challenge and we might be able to extend the list processing (how we
handle <ul>, <ol> etc) to support <pre> and <inline-html>.

cheers
sw


> 
> Steve Wainstead wrote:
> 
> > Does so :-) Check the link again. Lines with HTML have to start with a bar
> > (|). This is explained in TextFormattingRules.
> >
> > cheers
> > sw
> >
> > On Fri, 8 Dec 2000, Stephan Marzi - MIG wrote:
> >
> > > Iam sorry but I uncommented the line and it didnt work - also the <blink> tag
> > > didnt work ;-)
> > >
> > > What can I do now? See the prob at:
> > > http://mig.ready4surf.de:80/phpwiki/index.php
> > >
> > > Steve Wainstead wrote:
> > >
> > > > In lib/transform.php, line 58, you will see:
> > > >
> > > > /* If your web server is not accessble to the general public, you may
> > > > allow this code below, which allows embedded HTML. If just anyone can
> > > > reach
> > > > your web server it is highly advised that you do not allow this.
> > > >
> > > >       elseif (preg_match("/(^\|)(.*)/", $tmpline, $matches)) {
> > > >          // HTML mode
> > > >          $html .= SetHTMLOutputMode("", ZERO_DEPTH, 0);
> > > >          $html .= $matches[2];
> > > >          continue;
> > > >       }
> > > > */
> > > >
> > > > Uncomment this block and you can then use a bar | at the start of a line
> > > > to inline HTML. I haven't done this in ages, let me see if it still
> > > > works... yep, blink tags work just fine ;-)
> > > >
> > > > cheers
> > > > sw
> > > >
> > > > On Thu, 7 Dec 2000, Steve wrote:
> > > >
> > > > > Nice Wiki, but how can I enable the support of html tags?
> > > > >
> > > > > Regards
> > > > > Steve
> > > > >
> > > >
> > > > ...............................ooo0000ooo.................................
> > > >    Hear FM quality freeform radio through the Internet: http://wcsb.org/
> > > >                      home page: www.wcsb.org/~swain
> > >
> > > --
> > > Mit freundlichen Grüßen /  Best Regards
> > >
> > > Stephan Marzi
> > > Marzi Internet Gruppe [Group]
> > > http://www.MarziInternetGroup.com/
> > > The MIG project alliance.
> > >
> > >
> >
> > ...............................ooo0000ooo.................................
> >    Hear FM quality freeform radio through the Internet: http://wcsb.org/
> >                      home page: www.wcsb.org/~swain
> 
> --
> Mit freundlichen Grüßen /  Best Regards
> 
> Stephan Marzi
> Marzi Internet Gruppe [Group]
> http://www.MarziInternetGroup.com/
> The MIG project alliance.
> 
> 

...............................ooo0000ooo.................................
   Hear FM quality freeform radio through the Internet: http://wcsb.org/
                     home page: www.wcsb.org/~swain 

[Phpwiki-talk] function overloading

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

It appears to work in PHP4:


   class foo {
	function blippy() {
		echo "Boy howdy!";
	}
   }

   class bar extends foo {
	function blippy() {
		echo "hello, sailor!";
	}
   }

   $foovar = new foo;
   $barvar = new bar;
   $foovar->blippy();
   $barvar->blippy();

This does what I'd want:

Boy howdy!hello, sailor!

That opens the possibility of having one base class for the database
functionality. It would need more research of course... but the advantage
might be to have one pure class to define the interface, rather than
cloning the DBM or mysql implementations.

sw

...............................ooo0000ooo.................................
   Hear FM quality freeform radio through the Internet: http://wcsb.org/
                     home page: www.wcsb.org/~swain 

Re: [Phpwiki-talk] Template scripting

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

On Fri, 8 Dec 2000, Jan Hidders wrote:

> Once people start really using it, it will be very hard to get it out again.
> By the way, what *are* the urgent problems? Is the list on sourceforge
> correct?

Except for the lead issue, which is:

1. Steve stops being lazy :-)

Other than that, we are almost good to go with 1.2, and then we can break
backwards compatibility and move on. I think we should not support php3 in
1.3.x and onwards.

Also, the database libraries issue: it occurred to me that this is the
kind of problem virtual base classes were meant to solve. I don't suppose
PHP supports this kind of OOP?

I'll check the manual now...

sw

...............................ooo0000ooo.................................
   Hear FM quality freeform radio through the Internet: http://wcsb.org/
                     home page: www.wcsb.org/~swain 

Re: [Phpwiki-talk] Template scripting

[Jan H. <hi...@wi...>]

On Fri, Dec 08, 2000 at 12:47:33AM +0100, Arno Hollosi wrote:
> > > Nested IF-blocks work already. The only thing you can't nest is twice
> > > the same condition, i.e. ###IF:ADMIN### .... ###IF:ADMIN###
> > > But I can't think of a case where such a construct is necessary.
> >
> > When you also introduce blocks for ###IF:COPY### and ##IF:LOCK## then the
> > problem will appear.
> 
> Why do I get the feeling that you didn't read the manual? ;)

I only did a grep "IF:". That's what happens if you try to be clever. :-}

> a) these if-blocks already exist
> b) there is no problem mixing them (unless there is some bug), because
>    if you look at the corresponding endif it says ###ENDIF:COPY###,
>    ###ENDIF:LOCK### -- no problems with a simple straight-forward regexp.

Hm. Now I see that you are matching the blocks seperately, once for COPY,
once for LOCK and once for ADMIN. And that *does* work correctly unless you
are nesting a COPY block inside a COPY block, but that would be nonsense
anyway. So, yes, you are right, there will not be any problems with that.

> I start to like this IF-less idea more and more. Maybe we should migrate?
> I don't know - it's not such an urgent problem.

Once people start really using it, it will be very hard to get it out again.
By the way, what *are* the urgent problems? Is the list on sourceforge
correct?

-- Jan Hidders

Re: [Phpwiki-talk] Template scripting

[Arno H. <aho...@in...>]

> > Nested IF-blocks work already. The only thing you can't nest is twice
> > the same condition, i.e. ###IF:ADMIN### .... ###IF:ADMIN###
> > But I can't think of a case where such a construct is necessary.
>
> When you also introduce blocks for ###IF:COPY### and ##IF:LOCK## then the
> problem will appear.

Why do I get the feeling that you didn't read the manual? ;)
a) these if-blocks already exist
b) there is no problem mixing them (unless there is some bug), because
   if you look at the corresponding endif it says ###ENDIF:COPY###,
   ###ENDIF:LOCK### -- no problems with a simple straight-forward regexp.

> I know, but thats just *two* flags. Three will be a problem.

I cannot see a difference between the case of 2 or 3 or 100 flags.
Could you give an example?

> But why then not be radical about it and say "no IFs" (and BUTs :-)).

You do have a point there. And maybe this would be the more logical way.
Unfortunately, I didn't give this option much thought when I had to deal 
with the problem at hand and thus IF and later IF-blocks creeped in. I feel 
guilty and ashamed. I start to like this IF-less idea more and more. Maybe 
we should migrate? I don't know - it's not such an urgent problem.

/Arno

Re: [Phpwiki-talk] Template scripting

[Jan H. <hi...@wi...>]

>On Thu, Dec 07, 2000 at 03:14:38PM -0500, Steve Wainstead wrote:
> 
> And then one comes right back to the problem of "display logic," and
> ###IF### creeps in, and then there is a call for ELSE, FOREACH, WHILE etc.
> and we've come full circle.

I think I am beginning to catch on. But why then not be radical about
it and say "no IFs" (and BUTs :-)). Can the problem not be solved by
introducing two browsing templates; one for normal users and one for
administrators? Moreover, you could simply offer something like
###EDITLINK### that shows up as either the link to the edit page or as a
message "page locked" and ###COPYLINK### that shows up as either a link to
the the copy or a message "no copy available". I think that would cover al
the IFs that are used now in the templates.

But something tells me that Arno has probably already thought about this. :-)

-- Jan Hidders

Re: [Phpwiki-talk] Template scripting

[Jan H. <hi...@wi...>]

On Thu, Dec 07, 2000 at 08:20:13PM +0100, Arno Hollosi wrote:
> 
> > But as you saw yourself, you are now forced to do this anyway. And I am
> > very convinced that there is more to come.
> 
> I'm not so convinced :o)

Only the future will tell. Anyway, I said I would shut up, so I will. :-)
Just a few minor points:

> > Regular expressions are going to break down if you get things like nested
> > IF-blocks. Or are you going to introduce a different type of IF-block for
> > every possible combination of flags?
> 
> Nested IF-blocks work already. The only thing you can't nest is twice the 
> same condition, i.e. ###IF:ADMIN### .... ###IF:ADMIN###
> But I can't think of a case where such a construct is necessary.

When you also introduce blocks for ###IF:COPY### and ##IF:LOCK## then the
problem will appear.

> > The nested IF-blocks would probably be one.
> > You need that if you want
> > something inserted only if three flags are true.
> 
> That works already. See browse.html for an example (IF LOCK inside IF ADMIN)

I know, but thats just *two* flags. Three will be a problem.
 
> > If phpwiki really takes off (and that is what I expect)
> > then these [user accounts et cetera] things will be added sooner or later.
> 
> There are many other wiki-clones out there, so it's unlikely that phpwiki 
> will achieve world-domination.

Er, world domination is not what I had in mind. :-)

> E.g. tclwiki already has user identification, complete diff archive, and
> more goodies.

I didn't see that one. Is it the same as WiKit? And does it have database
support? Because I see that as very important.

> > PS. Can I ask you to just send replies to the mailing list? Right now, I
> > am getting two replies every time. Or does Kmail not have that option?
> 
> Odd - I thought the list-prog doesn't send emails to people listed in To/CC.
> At least it does not send me an email if my address is inside To/CC.

Hm. I have seen this reply only once, and now that I think of it, the one before
the previous one also just once. It was only the last one that I received twice.
So, never mind. If it happens again, I will say so.

Re: [Phpwiki-talk] Template scripting

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

On Thu, 7 Dec 2000, Arno Hollosi wrote:

> > Ah, but that is the beauty of it all. All you have to do is say at the
> > end of index.php
> >   include('templates/template.html');
> 
> Again: no it's not as easy as this. I want to have a string returned!
> (e.g. dump html files in a ZIP file) so it basically becomes some form
> of "eval('templates/template.html')" - and that means (among other things) 
> no echo, print, printf (not that that would be a major problem).

Right... at one point it became necessary to stop generating HTML
on-the-fly, and build the page in a string. Then the page is returned to
the user in a single "echo" statement.

The irony has never been lost on me that we took PHP and separated the
display and logic the way we did, undoing exactly what PHP was meant to
do. But this is a common theme; the JSP crowd have struggled with the same
problem in the last year++ and have come up with the idea of "template
engines" ala Cocoon from apache.org.

And then one comes right back to the problem of "display logic," and
###IF### creeps in, and then there is a call for ELSE, FOREACH, WHILE etc.
and we've come full circle.

The problem is not really mixing display and logic; it's a people problem.
We have designers who know HTML and can't/won't deal with <?php echo "foo"
?> constructs... and programmers who love to write recursive descent
parsers in XSSI if possible, but couldn't match colors to save their
lives. So the call to separate display and logic goes on, and the desire
to unite them pushes back.

> I don't know Steve's plans for phpwiki, but I guess 1.3.x will go into this 
> direction: keeping the core as simple as possible and make phpwiki more 
> modular (so that people can add their favourite extension easily without 
> bloating the core).

Right... like so many great tools do. My model would be Emacs: with four
or five basic commands, anyone can edit text files in Emacs. Simple. Over
time you can write expert systems and even Wikis in Emacs Lisp. Powerful,
simple, accessible.


> > PS. Can I ask you to just send replies to the mailing list? Right now, I
> > am getting two replies every time. Or does Kmail not have that option?
> 
> Odd - I thought the list-prog doesn't send emails to people listed in To/CC.
> At least it does not send me an email if my address is inside To/CC.

I will reconfigure phpwiki-talk to reply-to the list, not the sender.
We'll try it for a while and see how it works.

sw


...............................ooo0000ooo.................................
   Hear FM quality freeform radio through the Internet: http://wcsb.org/
                     home page: www.wcsb.org/~swain 

Re: [Phpwiki-talk] Template scripting

[Jan H. <hi...@wi...>]

On Thu, Dec 07, 2000 at 07:02:05PM +0100, Jan Hidders wrote:
> On Thu, Dec 07, 2000 at 05:49:24PM +0100, Arno Hollosi wrote:
> > 
> > - you can't use "echo" inside templates. You want the whole page
> >   returned as string, so that you can mangle it further, or do e.g. an
> >   HTML dump of the entire wiki.
> 
> Ah, but that is the beauty of it all. All you have to do is say at the end
> of index.php

*slap* Sorry, sorry. Then the result goes to the output and cannot be put in
a string. I thought this could be easily solved with 'eval' but that only
works in PHP4. I think I will just shut up now :-/.

-- Jan Hidders

Re: [Phpwiki-talk] Template scripting

[Arno H. <aho...@in...>]

> But as you saw yourself, you are now forced to do this anyway. And I am
> very convinced that there is more to come.

I'm not so convinced :o)

> Ah, but that is the beauty of it all. All you have to do is say at the
> end of index.php
>   include('templates/template.html');

Again: no it's not as easy as this. I want to have a string returned!
(e.g. dump html files in a ZIP file) so it basically becomes some form
of "eval('templates/template.html')" - and that means (among other things) 
no echo, print, printf (not that that would be a major problem).

> Regular expressions are going to break down if you get things like nested
> IF-blocks. Or are you going to introduce a different type of IF-block for
> every possible combination of flags?

Nested IF-blocks work already. The only thing you can't nest is twice the 
same condition, i.e. ###IF:ADMIN### .... ###IF:ADMIN###
But I can't think of a case where such a construct is necessary.

> [user accounts]
> Don't you think that it is safe to say that these things *will* be added
> in the future?

No. They won't come in 1.3.x (and therefore in 1.4.x)
And what is beyond that is pure imagination. For all I know, the internet 
might no longer exist at that point.

> If phpwiki really takes off (and that is what I expect)
> then these things will be added sooner or later.

There are many other wiki-clones out there, so it's unlikely that phpwiki 
will achieve world-domination. E.g. tclwiki already has user 
identification, complete diff archive, and more goodies. 

You can find a wiki-clone for every problem you need - from basic ones to 
very sophisticated ones. phpwiki is somewhere in the middle. Offering nice 
features, but with a simple backend. And it's this simplicity of the 
backend that draws people to phpwiki.

I don't know Steve's plans for phpwiki, but I guess 1.3.x will go into this 
direction: keeping the core as simple as possible and make phpwiki more 
modular (so that people can add their favourite extension easily without 
bloating the core).


> The nested IF-blocks would probably be one.
> You need that if you want
> something inserted only if three flags are true.

That works already. See browse.html for an example (IF LOCK inside IF ADMIN)


> PS. Can I ask you to just send replies to the mailing list? Right now, I
> am getting two replies every time. Or does Kmail not have that option?

Odd - I thought the list-prog doesn't send emails to people listed in To/CC.
At least it does not send me an email if my address is inside To/CC.

/Arno

Re: [Phpwiki-talk] Template scripting

[Jan H. <hi...@wi...>]

On Thu, Dec 07, 2000 at 05:49:24PM +0100, Arno Hollosi wrote:
> 
> On Thursday 07 December 2000 15:14, Jan Hidders wrote:
> > So why not simply use PHP [for templates] to do this
> > in stead of trying to write your own script interpreter?
> 
> Because
> > - the templates become less readable if you don't know any PHP

Well, yes, I know, obviously. :-) But do you really think that the example
that I gave is really so much harder to read that the original? Remember
that the maintainer of a phpwiki-site is going to have to do some
configuaration in PHP files anyway.

> and:
> - you move back code into the templates - the exact opposite of what
>   templates are for, no?

But as you saw yourself, you are now forced to do this anyway. And I am
very convinced that there is more to come.

> - you can't use "echo" inside templates. You want the whole page
>   returned as string, so that you can mangle it further, or do e.g. an
>   HTML dump of the entire wiki.

Ah, but that is the beauty of it all. All you have to do is say at the end
of index.php

---
  include('templates/template.html');
?>
---

and that's it!! You don't even have to start the template with "<?" because
the include takes care of that. Of course I am simplifying here because you
have to decide which template to include et cetera, but you get the point.

> > + phpwiki code gets simpeler
> Not necessarily. Only some functionality of GeneratePage is moved to the 
> template. Not much saving in complexity here. All you do is saving a few 
> str_replace. Worth the hassle?

Not right now. But as you will add more features this will happen. Regular
expressions are going to break down if you get things like nested IF-blocks.
Or are you going to introduce a different type of IF-block for every
possible combination of flags?

> We don't even have per-user customization or user accounts at all for that 
> matter. Unless we introduce user accounts (and a right-managament system) I 
> don't think there is need for a more sophisticated templating language.

Don't you think that it is safe to say that these things *will* be added in
the future? If phpwiki really takes off (and that is what I expect) then
these things will be added sooner or later. And at that stage you would have
a bigger problem because you would have many site-maintainers that would
hate to give up their old templates when upgrading to the latest version.

> You may start to wonder if I am opposed to every and all idea you propose.
> But please understand that I'm just arguing my point of view. I may be
> wrong, and I don't have the final word. Try to convince me, come up with a
> killer example.

The nested IF-blocks would probably be one. You need that if you want
something inserted only if three flags are true. And you already said
yourself that in the near future there will be more flags and the templates
will become more complex.

> You know, in your first email you wrote:
> > I have used phpwiki a little now and really like it,
> > especially its simplicity and accessability.
> 
> That's what I'm trying to protect here.

I know, and I respect that. It is not my intention to start a big longdrawn
debate here, or anything. (But I cannot really promise that it won't. :-})
You have clearly listened to and thought about my proposal and that is all
that I can expect. This is your project and I am just peeping around the
corner. I only found one bug and this was mainly due to your excellent
coding style. :-)

Kind regards,

-- Jan Hidders

PS. Can I ask you to just send replies to the mailing list? Right now, I am
    getting two replies every time. Or does Kmail not have that option?

Re: [Phpwiki-talk] Template scripting

[Arno H. <aho...@in...>]

On Thursday 07 December 2000 15:14, Jan Hidders wrote:
> So why not simply use PHP [for templates] to do this
> in stead of trying to write your own script interpreter?

Because
> - the templates become less readable if you don't know any PHP
and:
- you move back code into the templates - the exact opposite of what
  templates are for, no?
- you can't use "echo" inside templates. You want the whole page
  returned as string, so that you can mangle it further, or do e.g. an
  HTML dump of the entire wiki.

> + phpwiki code gets simpeler
Not necessarily. Only some functionality of GeneratePage is moved to the 
template. Not much saving in complexity here. All you do is saving a few 
str_replace. Worth the hassle?

> + future extensions for templates will be far more easy to program (just
>   define some new PHP variables and functions)

This is exactly the same amount of work needed in its current form. Plus 
one str_replace per extension.


Actually, I was very upset that I had to introduce ###IF### into the 
templates. But it looked like the only reasonable choice. Note that I 
didn't even bother to include an ###ELSE### directive.

I have given the idea of using PHP inside templates some thought, before I 
implemented the current template form. For me it boils down to simplicity -
meaning simplicity for the user and not for us programmers. And I think 
from the standpoint of simplicity the current form wins hands down against 
using PHP. (one may argue about ###IF###, I agree)

Of course, if we ever needed more complex directives such as for, while, 
variables ... I would rethink my position again and go for PHP I think. But 
currently I don't see a need for it.

We don't even have per-user customization or user accounts at all for that 
matter. Unless we introduce user accounts (and a right-managament system) I 
don't think there is need for a more sophisticated templating language.


You may start to wonder if I am opposed to every and all idea you propose.
But please understand that I'm just arguing my point of view. I may be 
wrong, and I don't have the final word. Try to convince me, come up with a 
killer example.

You know, in your first email you wrote:
> I have used phpwiki a little now and really like it,
> especially its simplicity and accessability.

That's what I'm trying to protect here.

/Arno

[Phpwiki-talk] Template scripting

[Jan H. <hi...@wi...>]

When browsing through Arno's code for interpreting the templates I came up
with a new idea. What is now happening is that you are basically trying to
reinvent your own HTML scripting language with "IF"s et cetera. But that is
exactly how PHP started! So why not simply us PHP to do this in stead of
trying to write your own script interpreter? All you would have to do in
your code is define the PHP variables and function that can be used in the
template, and then simply include the template at the end of the code.

A template like browse.html could then look like this:

----
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
  <title><?  echo $page;  ?></title>
</head>

<body bgcolor=ivory text=black alink=red link=darkblue vlink=darkmagenta>
<h1>
  <a href="<?   echo $scripturl;   ?>">
    <img src="<?   echo $logo;   ?>"border=0 alt="[phpwiki]" align=middle
         width=50 height=50>
  </a>
  <a href="<?   echo $scripturl;   ?>?full=<?   echo $pageurl;   ?>">
    <?   echo $page;   ?>
  </a>
</h1>

<? if ($admin) { ?>

  <FORM ACTION="<? echo $scripturl; ?>" METHOD=POST>

  <? if ($lock) { ?>

    [<a href="<? echo $scripturl; ?>?unlock=<? echo $pageurl; ?>">Unlock page</a>]

  <? } else { ?>

    [<a href="<? echo $scripturl; ?>?lock=<? echo $pageurl; ?>">Lock page</a>]

<?   } ?>
- - 
[<a href="<? echo $scripturl; ?>?remove=<? echo $pageurl; ?>">Remove page</A>]
<hr noshade>

<? } ?>

<P>

<? echo $content; ?>

<hr noshade>
...
----

Well, you get the point. Time for some pro's and con's:

+ phpwiki code gets simpeler
+ future extensions for templates will be far more easy to program (just
  define some new PHP variables and functions)
+ administrator can define very powerfull templates

- the templates become less readable if you don't know any PHP
- no backwards compatability

So what do you guys think? If you think this is a good idea I would be quite
willing to spend some time on this during the coming holidays.

-- Jan Hidders

[Phpwiki-talk] phpwiki passes first birthday

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

I meant to send out a message on 12/3, which is the first date in the
HISTORY file. PhpWiki is one year old now!

Thanks again to all of you who are helping out... 1.2 will be out this
month. Hopefully we can beat the Linux kernel 2.4 ;-)

sw

...............................ooo0000ooo.................................
   Hear FM quality freeform radio through the Internet: http://wcsb.org/
                     home page: www.wcsb.org/~swain 

Re: [Phpwiki-talk] latest build

[Arno H. <aho...@in...>]

> I have found the problem. In the function _iftoken in stdlib.php the
> removal of line based directives is done with
> But the brackets around $lineno and $lineyes are wrong. It should be

Aha. Are you using PHP3? I'm using PHP4 and the PHP4 manual says to put the 
'$' inside the brackets. I guess this is why I cannot see the problem. 
Fortunately, PHP4 also accepts the '$' outside the brackets which seems to 
be the PHP3 way.

> I don't know why you didn't notice anything. The problem is only visible
> for directives that are "false" and are not within a block directive that
> is "false". Perhaps you only checked pages where there are no such
> directives.

The directives are inside the browse.html template. So the directives occur 
on every page. Especially the ###IF ADMIN### stuff.

I've commited your change - thanks for spotting the error.

/Arno

Re: [Phpwiki-talk] latest build

[Jan H. <hi...@wi...>]

On Wed, Dec 06, 2000 at 09:30:28PM +0100, Arno Hollosi wrote:
> On Wednesday 06 December 2000 20:09, Steve Wainstead wrote:
> > Oh yes, I saw that too last night and forgot to report it.
> > sw
> >
> > On Wed, 6 Dec 2000, Jan Hidders wrote:
> > > I tried the latest nightly build (December 6) and now I see in my pages
> > > things like ³#IF ADMIN³# and ³#IF LOCK³#. But perhaps this is a matter
> > > of work in progress?
> 
> I cannot verify this. I just downloaded the latest tarball and did a clean 
> install and cannot find any of this.

I have found the problem. In the function _iftoken in stdlib.php the
removal of line based directives is done with

  	    $page = ereg_replace("{$lineno}[^\n]*\n", '', $page);
and

	    $page = ereg_replace("{$lineyes}[^\n]*\n", '', $page);

But the brackets around $lineno and $lineyes are wrong. It should be

  	    $page = ereg_replace("${lineno}[^\n]*\n", '', $page);
and

	    $page = ereg_replace("${lineyes}[^\n]*\n", '', $page);

I don't know why you didn't notice anything. The problem is only visible for
directives that are "false" and are not within a block directive that is
"false". Perhaps you only checked pages where there are no such directives.

-- Jan Hidders

Re: [Phpwiki-talk] latest build

[Arno H. <aho...@in...>]

On Wednesday 06 December 2000 20:09, Steve Wainstead wrote:
> Oh yes, I saw that too last night and forgot to report it.
> sw
>
> On Wed, 6 Dec 2000, Jan Hidders wrote:
> > I tried the latest nightly build (December 6) and now I see in my pages
> > things like ³#IF ADMIN³# and ³#IF LOCK³#. But perhaps this is a matter
> > of work in progress?

I cannot verify this. I just downloaded the latest tarball and did a clean 
install and cannot find any of this.

It looks like you are using old template files.
Read /templates/README for the new format of ###IF### directives if you use 
a custom-modified template.

Otherwise I suggest using the new template files.

/Arno

Re: [Phpwiki-talk] latest build

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

Oh yes, I saw that too last night and forgot to report it.
sw

On Wed, 6 Dec 2000, Jan Hidders wrote:

> I tried the latest nightly build (December 6) and now I see in my pages
> things like ³#IF ADMIN³# and ³#IF LOCK³#. But perhaps this is a matter of
> work in progress?
> 
> -- Jan Hidders
> 
> 
> 
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> http://lists.sourceforge.net/mailman/listinfo/phpwiki-talk
> 

...............................ooo0000ooo.................................
   Hear FM quality freeform radio through the Internet: http://wcsb.org/
                     home page: www.wcsb.org/~swain 

Re: [Phpwiki-talk] translation (was: wiki with https)

[Arno H. <aho...@in...>]

> On Fri, 1 Dec 2000, Olivier Kaloudoff wrote:
> > ps: I can give you a french translation
> > for wiki in a few days, if you want.

Go ahead and send it in :o)

/Arno

[Phpwiki-talk] latest build

[Jan H. <hi...@wi...>]

I tried the latest nightly build (December 6) and now I see in my pages
things like ³#IF ADMIN³# and ³#IF LOCK³#. But perhaps this is a matter of
work in progress?

-- Jan Hidders

Re: [Phpwiki-talk] some questions

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

On Wed, 6 Dec 2000, Jan Hidders wrote:

> > This bug has been fixed since stdlib.php v1.12 from November 16th.
> > Are you sure you tested the latest build?
> 
> Oops. I didn't. My apologies. The latest nightly build in the FTP
> directroy seems to be the one of Nov. 5. But I will probably be able to get
> it by CVS.

Fixed. I removed a tmp/ directory that the script was using. Nightly
builds are available again, and I put a new tarball up.

> link names?". :-) But seriously, no, I have no concrete example of a useful
> link name with brackets in it. But then again, I am also not really sure
> that no-one is ever going to need one. 

I have been reading "Extreme Programming Explained" and "Pragmatic
Programmer," and both urge you to avoid adding things you think might be
needed in the future... when there is a compelling reason to add it, we
will; this includes "pure hack value" as well, so if I'm stuck home for a
few days with a cold, it might get added ;-)

sw

................................ooo0000ooo.................................
   Hear FM quality freeform radio through the Internet: http://wcsb.org/
                     home page: www.wcsb.org/~swain 

Re: [Phpwiki-talk] some questions

[Jan H. <hi...@wi...>]

On Wed, Dec 06, 2000 at 12:18:23PM +0100, Arno Hollosi wrote:
> 
> > > During my efforts to get this done I noticed a minor bug in the
> > > function ExtractWikiPageLinks. If you have something in your text like
> > > "[[not a link]" then the page name "[not a link" is extracted as a link
> > > name and turns up, for example, in MySQL in the table wikilinks. My
> > > patch also fixes this.
> >
> > Confirmed on my Postgresql installation... nice catch!
> 
> This bug has been fixed since stdlib.php v1.12 from November 16th.
> Are you sure you tested the latest build?

Oops. I didn't. My apologies. The latest nightly build in the FTP
directroy seems to be the one of Nov. 5. But I will probably be able to get
it by CVS.

> > > 3. Are square brackets in page names allowed?
> 
> Currently: no.
> And yes, any attempt to use "]" inside links has unpredicted consequences.

Well, a single "]" is predictable; it always closes the link. And a single
"[" does also what you would expect. Its when you use "]]" or "[[" that things
become funny. But this is besides the point.
 
> > Well, can you give some reasons why it should be allowed?

Well, in a FAQ I would expect link names like "Why can't I have ']'s in my
link names?". :-) But seriously, no, I have no concrete example of a useful
link name with brackets in it. But then again, I am also not really sure
that no-one is ever going to need one. 

> Me wonders too. You know, for my petproject "Sensei's Library" I have 
> modified it the following way. Bracketlinks are possible, but they have a 
> restricted regexp. Basically it boils down to that [some page] is equal to 
> SomePage or [yet another page] == YetAnotherPage. I.e. it is only used for 
> readability purposes. Well, ok I filter out some chars as well so that
> e.g. [Sensei's Library] == SenseisLibrary.

But wouldn't then the title of the page show up as "Senseis Library"?

> > > solve this I would suggest that closing brackets should also be
> > > escaped, i.e., ']' should be written as ']]' if it is not meant as an
> > That's logically consistent... What do you think Arno?
> 
> [..]
> 
> I assume that allowing those brackets causes more trouble for casual 
> visitors seeing and trying to recreate links like "cool [awesome] page".

Hm. Maybe, but if you are going to recreate something, you can always easily
check how the original was done. In fact, if I hadn't seen the example of
[[link name] I probably would have tried [[link name]] first.

> A straight-forward failure to use "]" is easier to understand. And don't 
> tell me it can be found in the manual somewhere. People don't read manuals.

In the edit page it now says 'escape "[" with "[["'. You could simply change
that into escape '"[" and "]" with "[[" and "]]"'. I don't think that is
really hard to understand.

And the way that things are currently implemented (replacing escaped things
with tokens) the standard example of "[[link name]" would still work. The
only thing that would really change is that "bla ]] bla"" will be
transformed to "bla ] bla". But how often do you write something like that?

The only two difficulties that I see are that
1. during transformation you have to take into account that link names may
   contain tokens
2. when extracting links you have to take into acount that link names may
   contain escaped symbols such as [[ and ]]

-- Jan Hidders