phpwiki-talk

[Phpwiki-talk] internationalization

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

Hi all,    (Jeff - see bottom)

I've brought Jan's patch in sync with the latest changes (lib/, etc.) and 
would be ready to commit the patch to CVS.

The last open point was how we should handle templates.
I've pondered this question for some time and came to the conclusion, that we 
should keep it in it's latest form, i.e. different template files for 
different languages.

pros: easy and straight-forward, no change of code necessary
cons: once we support 15 languages changing a template becomes awkward.

Alternatives are:

1) do a gettext() on the template:
   $page = gettext (join('',file($templates[$template])));
   This doesn't change much - just moves the data into a different location.
   One might argue that it's more consistent though. It becomes less
   user-friendly -- I don't recommend this.

2) invent additional markup for the templates and let GeneratePage() handle
   the rest. Possible, but I don't like this at all - GeneratePage() will
   become bloated.

3) switch templates to php files. Possible, but makes writing the templates a
   pain. You have to escape characters, rewrite the placeholder system to use
   functions etc. Loses the appeal of the current simplistic approach to
   templates, which makes it very easy even for newbies to create a new layout
   for phpwiki.

4) similar to above, but the template files are processed by doing eval().
   Placeholders remain like they are now. Only change: gettext() appears in
   the templates. Con: eval()'s output cannot be redirected to a string. Thus
   we lose the ability to e.g. make a clean HTML dump from within phpwiki.
   (this problem can be solved in php4 by using output-buffers, in php3
   there's no solution I'm aware of.)


I'd like to hear which approach should be taken, so that I then can commit 
the patch to CVS.

/Arno

p.s. directory structure would be as follows:

./pgsrc		-- default
./pgsrc/nl/	-- language specific
./templates/	-- default
./templates/nl/	-- language specific
./locale/	-- locale directory
./locale/translate.sh -- script for translators
./locale/po/	-- .po files for gettext
./locale/nl/LC_MESSAGES/ -- .mo & .php files

pp.s. if Jeff is reading this: while thinking about this issue I revisited 
your template system - why didn't you use php files + eval() but invented 
your own syntax instead? 

Re: http: ... was: Re: more on Re: [Phpwiki-talk] ...

[Neil B. <ne...@cs...>]

On Wednesday October 11, sw...@wc... wrote:
> On Thu, 12 Oct 2000, Neil Brown wrote:
> 
> > Yes.. If we don't urlencode above we do need to do more work here.
> > If we are checking the prefx, would it be sensible to include that
> > into the 'protocol'. e.g.
> >    wikidiff:
> >    wikiedit:
> >    wikisearch:
> >    wikifile:
> > 
> > etc.  Which doesn't seem very elegant to me.
> > 
> > On the whole, I think I would go back to
> >    wiki:diff=url-encoded-wikiname
> > 
> > and people who choose wierd wikinames live with the consequenses.
> > 
> > Anyone else have an opinion?
> 
> Yes, I think we should leave it as an administrator configuration option;
> at the moment the default is to dynamically determine the host name.
> Admins can set the $ServerName to either the full URL or http: based on
> their needs. I think this works for all cases, the choice is not hard to
> make, and we don't have to risk introducing more bugs. Keep the details
> out of the code and in the config file.

yes....but.....

This means that RecentChanges will have absolute URLs hard coded into
it, so once the ServerName has been set for a wiki, it cannot be
easily changed.  I want to keep the detail out of the Wiki database
too.

NeilBrown

Re: http: ... was: Re: more on Re: [Phpwiki-talk] ...

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

On Thu, 12 Oct 2000, Neil Brown wrote:

> Yes.. If we don't urlencode above we do need to do more work here.
> If we are checking the prefx, would it be sensible to include that
> into the 'protocol'. e.g.
>    wikidiff:
>    wikiedit:
>    wikisearch:
>    wikifile:
> 
> etc.  Which doesn't seem very elegant to me.
> 
> On the whole, I think I would go back to
>    wiki:diff=url-encoded-wikiname
> 
> and people who choose wierd wikinames live with the consequenses.
> 
> Anyone else have an opinion?

Yes, I think we should leave it as an administrator configuration option;
at the moment the default is to dynamically determine the host name.
Admins can set the $ServerName to either the full URL or http: based on
their needs. I think this works for all cases, the choice is not hard to
make, and we don't have to risk introducing more bugs. Keep the details
out of the code and in the config file.

sw

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

Re: http: ... was: Re: more on Re: [Phpwiki-talk] ...

[Neil B. <ne...@cs...>]

On Wednesday October 11, aho...@in... wrote:

> 
> > or maybe even
> > 		wiki:diff=SomePage
> > which can apply more generally than just diff.
> > I like this last one the most.
> 
> This looks like a clean solution. Your patch has some subtle bugs though.
> 
> > --- /home/src/phpwiki/lib/stdlib.php	Mon Oct  9 04:33:26 2000
> > +++ lib/stdlib.php	Wed Oct 11 09:35:43 2000
> > -	 $diffurl = "$ScriptUrl?diff=" . rawurlencode($pagename);
> > +	 $diffurl = "wiki:diff=" . rawurlencode($pagename);
> >           $newpage[$k++] = "\t* [$pagename] ([diff|$diffurl]) .....
> 
> The pagename must not be rawurlencoded now. We want the real(tm) pagename 
> within the wikipage. Encoding should be done when creating the link. 
> Otherwise people would have to rawurlencode by hand if they would like to add 
> such a link to a wikipage.

My reasoning went that other URLs must already be urlencoded, so this
one should too.  However I acknowledge that there is a small
awkwardness in people needing to hand-urlencode wikinames.  I'm
probably happy to not urlencode here.

> 
> About names for the link-type: you name both 'meta-wiki' which is not 
> consistent with the naming scheme. I suggest: 'wiki-meta' and 
> 'wiki-meta-named'.

There is a consistent naming scheme ;-?  I couldn't pick it, though I
didn't try very hard.  
After poking around in the code a bit more, I am quite happy with
wiki-meta and wiki-meta-named.

> 
> Also, doing
> > +	 if (preg_match("#wiki:(.*)#", $URL, $umatch)) {
> > +	    $link['type'] = 'meta-wiki';
> > +	    $link['link'] = "<a
> > href=\"$ScriptUrl?".$umatch[1]."\">$linkname</a>"; +	 } elseif
> 
> seems too simplistic. Assuming that the link has to be encoded here, you must 
> ensure that there's always a sub-type (diff=, edit=, search=) so that 
> encoding works. This means that another type has to be introduced: 'page='
> Those types should be checked for. Everything following the subtype can then 
> be safely urlencoded.

Yes.. If we don't urlencode above we do need to do more work here.
If we are checking the prefx, would it be sensible to include that
into the 'protocol'. e.g.
   wikidiff:
   wikiedit:
   wikisearch:
   wikifile:

etc.  Which doesn't seem very elegant to me.

On the whole, I think I would go back to
   wiki:diff=url-encoded-wikiname

and people who choose wierd wikinames live with the consequenses.

Anyone else have an opinion?

NeilBrown

[Phpwiki-talk] patches etc.

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

Hi,

I added the two simple patches by Neil: searchtype and nested definition 
lists. Not yet done: tab-less markup for definition lists.

I will have a look at Jan's internationalization patch next.

Btw, we use exit() quite often within phpwiki.
I suggest we add a function to stdlib.php called ExitWiki() or similar, in 
order to exit cleanly from phpwiki. Things coming to mind: ending the file 
with proper HTML, closing the database. If I find the time today I will add 
this function.

/Arno

http: ... was: Re: more on Re: [Phpwiki-talk] ...

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

> > Well, this might not count for much, but the http: solution does not work
> > in Emacs' w3 mode. This makes me nervous that it will break other

I tried: Netscape, lynx, Konqueror (KDE's browser), Mozilla.
They all are able to use http: -- looks to me that Emcas got it wrong.

> or maybe even
> 		wiki:diff=SomePage
> which can apply more generally than just diff.
> I like this last one the most.

This looks like a clean solution. Your patch has some subtle bugs though.

> --- /home/src/phpwiki/lib/stdlib.php	Mon Oct  9 04:33:26 2000
> +++ lib/stdlib.php	Wed Oct 11 09:35:43 2000
> -	 $diffurl = "$ScriptUrl?diff=" . rawurlencode($pagename);
> +	 $diffurl = "wiki:diff=" . rawurlencode($pagename);
>           $newpage[$k++] = "\t* [$pagename] ([diff|$diffurl]) .....

The pagename must not be rawurlencoded now. We want the real(tm) pagename 
within the wikipage. Encoding should be done when creating the link. 
Otherwise people would have to rawurlencode by hand if they would like to add 
such a link to a wikipage.

About names for the link-type: you name both 'meta-wiki' which is not 
consistent with the naming scheme. I suggest: 'wiki-meta' and 
'wiki-meta-named'.

Also, doing
> +	 if (preg_match("#wiki:(.*)#", $URL, $umatch)) {
> +	    $link['type'] = 'meta-wiki';
> +	    $link['link'] = "<a
> href=\"$ScriptUrl?".$umatch[1]."\">$linkname</a>"; +	 } elseif

seems too simplistic. Assuming that the link has to be encoded here, you must 
ensure that there's always a sub-type (diff=, edit=, search=) so that 
encoding works. This means that another type has to be introduced: 'page='
Those types should be checked for. Everything following the subtype can then 
be safely urlencoded.


/Arno

Re: more on Re: [Phpwiki-talk] phpwiki - I like it. (fwd)

[Neil B. <ne...@cs...>]

On Monday October 9, sw...@wc... wrote:
> 
> Well, this might not count for much, but the http: solution does not work
> in Emacs' w3 mode. This makes me nervous that it will break other
> browsers... it also won't let me use lwp-rget to write a regression test,
> since the URLs all come out like this:
> 

Ho hum.... There is an RFC which describes what different URLs and
URIs are, or should be, valid! However I think it is an
after-the-fact RFC which is a suggesting of how things should be done
and not a standard which everybody already adheres to....


> 
> 
> I'm looking for another solution. Perhaps the way the diffurl is encoded
> can be changed:
> 
>       if($isnewpage) {
>          $newpage[$k++] = "\t* [$pagename] (new) ..... $remoteuser\r";
>       } else {
> 	 $diffurl = "$ScriptUrl?diff=" . rawurlencode($pagename);
>          $newpage[$k++] = "\t* [$pagename] ([diff|$diffurl])
> ..... $remoteuser\r";
>       }
> 
> but I don't think there's an easy answer there either, and I don't want to
> kluge it with an if/else...
> 

I agree that the diffurl needs to be different.
On reflection, putting something like

   http://myserver.mdomain.thing/thisbit/wiki/?diff=SomePage

in a wikipage is not a  good idea as it means that the wiki cannot be
moved without changing the RecentChanges page.
Having:
	index.php?diff=SomePage
is a problem because it doesn't look distictively enough like a url
for transform.php to recognise it.
Having
	http:index.php?diff=SomePage
is a bit better, but stuff would break if the index file name changed,
and doesn't work for w3 mode or lwp-rget, and probably others....

My first thought was to have

	diff:SomePage

and have transform.php recognise this inside [] and convert it to

    $ScriptUrl?diff=SomePage

An alternative would be to have

	        http:?diff=SomePage
or maybe even
		wiki:diff=SomePage

which can apply more generally than just diff.
I like this last one the most.
The follow patch effects it. 

With this patch, setting 
     $ServerAddress="";

works fine for diffs an emacs-w3 and lpw-rget.

WhaDaYaThink?

NeilBrown



--- /home/src/phpwiki/lib/stdlib.php	Mon Oct  9 04:33:26 2000
+++ lib/stdlib.php	Wed Oct 11 09:35:43 2000
@@ -360,7 +362,7 @@
       if($isnewpage) {
          $newpage[$k++] = "\t* [$pagename] (new) ..... $remoteuser\r";
       } else {
-	 $diffurl = "$ScriptUrl?diff=" . rawurlencode($pagename);
+	 $diffurl = "wiki:diff=" . rawurlencode($pagename);
          $newpage[$k++] = "\t* [$pagename] ([diff|$diffurl]) ..... $remoteuser\r";
       }
 
@@ -383,7 +385,7 @@
 
 
    function ParseAndLink($bracketlink) {
-      global $dbi, $AllowedProtocols;
+      global $dbi, $AllowedProtocols, $ScriptUrl;
 
       // $bracketlink will start and end with brackets; in between
       // will be either a page name, a URL or both separated by a pipe.
@@ -417,7 +419,10 @@
          $URL = trim($matches[3]);
          $linkname = htmlspecialchars(trim($matches[1]));
          // assert proper URL's
-         if (preg_match("#^($AllowedProtocols):#", $URL)) {
+	 if (preg_match("#wiki:(.*)#", $URL, $umatch)) {
+	    $link['type'] = 'meta-wiki';
+	    $link['link'] = "<a href=\"$ScriptUrl?".$umatch[1]."\">$linkname</a>";
+	 } elseif (preg_match("#^($AllowedProtocols):#", $URL)) {
             $link['type'] = 'url-named';
 	    $link['link'] = "<a href=\"$URL\">$linkname</a>";
          } else {
@@ -437,6 +442,9 @@
          if (IsWikiPage($dbi, $linkname)) {
             $link['type'] = 'wiki';
             $link['link'] = LinkExistingWikiWord($linkname);
+	 } elseif (preg_match("#^wiki:(.*)#", $linkname, $umatch)) {
+	    $link['type'] = 'meta-wiki';
+	    $link['link'] = "<a href=\"$ScriptUrl?".$umatch[1]."\">".urldecode($umatch[1])."</a>";
          } elseif (preg_match("#^($AllowedProtocols):#", $linkname)) {
             // if it's an image, embed it; otherwise, it's a regular link
             if (preg_match("/jpg$|png$|gif$/i", $linkname)) {

[Phpwiki-talk] PHP Congress

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

Interesting overview:

http://www.koehntopp.de/kris/artikel/php-kongress/

sw

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

[Phpwiki-talk] simple regression test

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

I found lwp-rget, which will fetch all the pages and write them in the
current directory. It's bundled with the Perl LWP, so if you have the LWP
installed you probably have lwp-rget (plus others).

using this like so:

lwp-rget --verbose http://wcsb.org/~swain/tmp/phpwiki/

dumps all my pages into the current directory. By dumping into a temporary
directory, making code/page changes, and then dumping into a second
temporary directory, I can run diff on the two directories and see the
difference in page output. 

It could use some refinement, but it's a start.

sw

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

more on Re: [Phpwiki-talk] phpwiki - I like it. (fwd)

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

Well, this might not count for much, but the http: solution does not work
in Emacs' w3 mode. This makes me nervous that it will break other
browsers... it also won't let me use lwp-rget to write a regression test,
since the URLs all come out like this:

[swain@localhost tmptmp]$ lwp-rget --verbose
http://127.0.0.1:8080/phpwiki/
Use of uninitialized value at /usr/bin/lwp-rget line 222.
START     = http://127.0.0.1:8080/phpwiki/
MAX_DEPTH = 5
MAX_DOCS  = 50
PREFIX    = http://127.0.0.1:8080/phpwiki/
http://127.0.0.1:8080/phpwiki/ ............................. index.html
 http:index.php ............................................ *outsider*
 http://127.0.0.1:8080/phpwiki/images/wikibase.png ......... wikibase.png
 http:index.php?full=FrontPage ............................. *outsider*
 http:index.php?WikiWikiWeb ................................ *outsider*
 http:index.php?HowToUseWiki ............................... *outsider*
 http:index.php?AddingPages ................................ *outsider*
 http:index.php?SandBox .................................... *outsider*
 http:index.php?RecentVisitors ............................. *outsider*
 http:index.php?RecentChanges .............................. *outsider*
 http:index.php?MostPopular ................................ *outsider*
 http:index.php?ReleaseNotes ............................... *outsider*
 http:index.php?edit=FrontPage ............................. *outsider*
 http:index.php?info=FrontPage ............................. *outsider*
 http:index.php?diff=FrontPage ............................. *outsider*
 http:index.php?FindPage ................................... *outsider*
index.html


I'm looking for another solution. Perhaps the way the diffurl is encoded
can be changed:

      if($isnewpage) {
         $newpage[$k++] = "\t* [$pagename] (new) ..... $remoteuser\r";
      } else {
	 $diffurl = "$ScriptUrl?diff=" . rawurlencode($pagename);
         $newpage[$k++] = "\t* [$pagename] ([diff|$diffurl])
..... $remoteuser\r";
      }

but I don't think there's an easy answer there either, and I don't want to
kluge it with an if/else...


sw

On Tue, 10 Oct 2000, Neil Brown wrote:

> On Monday October 9, aho...@in... wrote:
> > Steve,
> > 
> > > This patch sounds like a good idea: no default server name. Another "why
> > > didn't I think of that?" idea. Anybody see any holes in it?
> > 
> > this breaks the diff links in RecentChanges.
> > Unless we invent a new wiki-syntax they will remain broken.
> > 
> > /Arno
> 
> Ahhh.. that was the problem with my diff links.  I hadn't had a chance
> to look into them, and it didn't click that the break might be related
> to that change.
> Instead of
> 	   $ServerAddress = "";
> use
> 	   $ServerAddress = "http:";
> 
> That has the same effect of using relatvie URI's, doesn't break the
> diff links in RecentChanges
> 
> NeilBrown
> _______________________________________________
> 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] phpwiki - I like it. (fwd)

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

Done. Ran tests on all the pages (I hope) and found no errors.

It has occurred to me lately that a Perl-based regression test is
possible... using the LWP one would only have to enter the FrontPage, and
let the script retrieve all pages and compare them to a previous set. A
diff output would show any changes in the way pages render. It would
remove the uncertainty of whether you tested all the pages or not...

sw


On Tue, 10 Oct 2000, Neil Brown wrote:

> On Monday October 9, aho...@in... wrote:
> > Steve,
> > 
> > > This patch sounds like a good idea: no default server name. Another "why
> > > didn't I think of that?" idea. Anybody see any holes in it?
> > 
> > this breaks the diff links in RecentChanges.
> > Unless we invent a new wiki-syntax they will remain broken.
> > 
> > /Arno
> 
> Ahhh.. that was the problem with my diff links.  I hadn't had a chance
> to look into them, and it didn't click that the break might be related
> to that change.
> Instead of
> 	   $ServerAddress = "";
> use
> 	   $ServerAddress = "http:";
> 
> That has the same effect of using relatvie URI's, doesn't break the
> diff links in RecentChanges
> 
> NeilBrown
> _______________________________________________
> 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] misc pending patches / restructuring

[Neil B. <ne...@cs...>]

On Monday October 9, sw...@wc... wrote:
> On Mon, 9 Oct 2000, Arno Hollosi wrote:
> 
> > 
> > Nested DefinitionLists by Neil Brown:
> > Looks ok.
> > Note: this still relies on tabs. I think we should get rid of tabs ASAP.
> 
> When I added tabless syntax, I skipped term/defs because there was no
> clear solution, and nobody uses them (even on c2.com, and in regular HTML
> pages). Ward probably coded them in in 1995 when people were still
> exploring HTML and might have used them. Anyhow, I will take a look at
> that too tonight. There should be a simple syntactic solution.

Gee.. I use defintion lists all the time!!!  Must just be the way my
brain works.

The meatball wiki
  (  http://www.usemod.com/cgi-bin/mb.pl?TextFormattingRules ) 
uses:

   Term with indented definition: [without a blank line between term and definition] 
   
   ;Term:Definition (indented)
   ;;Term (indented):Definition (indented two levels)
   ;;;Term (indented twice):Definition (indented to third level)
   
   ...which looks like: 
   
   Term
         Definition (indented) 
         Term (indented)
               Definition (indented two levels) 
               Term (indented twice)
                     Definition (indented to third level) 

This looks like a reasonable syntax and is in-line with the *** and
### syntaxes for other nested  lists.

>  
> > SearchType patch by Neil Brown:
> > The actual patch is ok. If a search box should be included in the default 
> > browse.html should be discussed.

I'm quite happy with leave browse.html alone.  I just included it in the
patch to demonstrate how I would use the extra functionality.

NeilBrown

Re: [Phpwiki-talk] phpwiki - I like it. (fwd)

[Neil B. <ne...@cs...>]

On Monday October 9, aho...@in... wrote:
> Steve,
> 
> > This patch sounds like a good idea: no default server name. Another "why
> > didn't I think of that?" idea. Anybody see any holes in it?
> 
> this breaks the diff links in RecentChanges.
> Unless we invent a new wiki-syntax they will remain broken.
> 
> /Arno

Ahhh.. that was the problem with my diff links.  I hadn't had a chance
to look into them, and it didn't click that the break might be related
to that change.
Instead of
	   $ServerAddress = "";
use
	   $ServerAddress = "http:";

That has the same effect of using relatvie URI's, doesn't break the
diff links in RecentChanges

NeilBrown

Re: [Phpwiki-talk] misc pending patches / restructuring

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

On Mon, 9 Oct 2000, Arno Hollosi wrote:

> 
> Nested DefinitionLists by Neil Brown:
> Looks ok.
> Note: this still relies on tabs. I think we should get rid of tabs ASAP.

When I added tabless syntax, I skipped term/defs because there was no
clear solution, and nobody uses them (even on c2.com, and in regular HTML
pages). Ward probably coded them in in 1995 when people were still
exploring HTML and might have used them. Anyhow, I will take a look at
that too tonight. There should be a simple syntactic solution.
 
> SearchType patch by Neil Brown:
> The actual patch is ok. If a search box should be included in the default 
> browse.html should be discussed.

I'm leary of adding much to browse.html. I have played with it quite a bit
and never liked additions. Jakob Neilsen (useit.com) recommends that the
logo be in the upper left and link to the home page, and the search box be
in the upper right (based on convention and usability studies.) I haven't
worked out a layout like that yet.

Search should be redesigned as well; page title searches are somewhat
unconventional (then again, so are Wikis) and there is no sophistication
to the full text search... but then I may be speculating about gold
plating, and PhpWiki does well where it's simple. I will go into more
detail on this at at later date.

> Email notification of page changes by Jochen Causemann:
> Jochen's solution has some merits, but drawbacks as well. In his patch email 
> addresses are stored in the WikiPage themselves. This means that not only are 
> these email addresses public, but anyone can remove other's addresses by 
> editing the page. 

and worse, adding other people's emails...

> I opt for the PyWiki approach, in which addresses are 
> stored outside the document. Also, I'd like to have the option to either 
> receive wiki-markup or html emails. And (for those wiki addicts): the 
> possibility to subscribe to all pages / or given sets of pages.
> I think we should hold off this feature for some more time.. First we should 
> get other things in order, then add user-management (which will also include 
> email notification).

Agreed; would you object to including the patch but leaving it disabled by
default? Wikis on intranets would not face malicious user problems (in
theory ;-)
 
> I think the next thing we should do is clean up the db interface (borrow the 
> good stuff from Jeff's branch) and integrate Jan's localization patch. Wrt 
> Jan's patch the open question is still how we should deal with templates. I'm 
> not convinced yet, that turning the templates into php files is a good thing.

I have to extract Jeff's branch again and recommit it... CVS removes a
file for all branches, so as it is right now you cannot really check out
Jeff's copy. It will just require some magic CVS incantations.

sw

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

[Phpwiki-talk] misc pending patches / restructuring

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

Nested DefinitionLists by Neil Brown:
Looks ok.
Note: this still relies on tabs. I think we should get rid of tabs ASAP.

SearchType patch by Neil Brown:
The actual patch is ok. If a search box should be included in the default 
browse.html should be discussed.

Email notification of page changes by Jochen Causemann:
Jochen's solution has some merits, but drawbacks as well. In his patch email 
addresses are stored in the WikiPage themselves. This means that not only are 
these email addresses public, but anyone can remove other's addresses by 
editing the page. I opt for the PyWiki approach, in which addresses are 
stored outside the document. Also, I'd like to have the option to either 
receive wiki-markup or html emails. And (for those wiki addicts): the 
possibility to subscribe to all pages / or given sets of pages.
I think we should hold off this feature for some more time. First we should 
get other things in order, then add user-management (which will also include 
email notification).


About the lib/ and image/ changes:
No objections here. I checked a clean install from latest CVS with mySQL and 
it worked ok.

I think the next thing we should do is clean up the db interface (borrow the 
good stuff from Jeff's branch) and integrate Jan's localization patch. Wrt 
Jan's patch the open question is still how we should deal with templates. I'm 
not convinced yet, that turning the templates into php files is a good thing.

/Arno

Re: [Phpwiki-talk] phpwiki - I like it. (fwd)

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

I'll fix it when I get home tonight...

sw

On Mon, 9 Oct 2000, Arno Hollosi wrote:

> Steve,
> 
> > This patch sounds like a good idea: no default server name. Another "why
> > didn't I think of that?" idea. Anybody see any holes in it?
> 
> this breaks the diff links in RecentChanges.
> Unless we invent a new wiki-syntax they will remain broken.
> 
> /Arno
> 

http://wcsb.org/~swain/ | "In a calendar year, America's entire
  *   *   *   *   *   * | recorded music industry has revenues
*   *   *   *   *   *   | roughly equal to one month's sales by
  *   *   *   *   *   * | IBM." --Philip Greenspun

Re: [Phpwiki-talk] phpwiki - I like it. (fwd)

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

Steve,

> This patch sounds like a good idea: no default server name. Another "why
> didn't I think of that?" idea. Anybody see any holes in it?

this breaks the diff links in RecentChanges.
Unless we invent a new wiki-syntax they will remain broken.

/Arno

[Phpwiki-talk] images moved

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

... to a new subdirectory, images/ and lib/config.php has been updated to
match.

sw

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

[Phpwiki-talk] project restructuring

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

I've moved all wiki_*.php3 files to lib/*.php. I've also renamed
index.php3 to index.php. I haven't touched admin/ yet though, and a couple
other files (test_dbmlib.php3).

I've gone though the INSTALL and README files, and some of the default
pages as well hunting down occurances of *php3 and updating them.


CVS moves "removed" files to the "attic" and you can see the log files for
the wiki_*.php3 files here:
http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/phpwiki/Attic/?cvsroot=phpwiki&sortby=date

(the lib/*php files start with new logs, since CVS does not have a good
mechanism for renaming the files, this was the best way).

To update your private CVS tree, be sure to do:

cvs update -d -P

-d will add new directories 
-P will prune empty directories

I think both get new pages/delete old pages as well.

So far I've tested the new setup from a clean checkout of the sources, on
DBM and Postgresql, and it looks good. On a stock RedHat box, I had to
edit the httpd.conf so Apache recognizes .php as well as php3 (the
default). I think the new builds of Apache have .php already.

flame me as needed
sw

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

[Phpwiki-talk] Cutover from wiki_*php3 to lib/*.php

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

Tomorrow I am going to make some filename changes:

All wiki_*php3 files will live in lib/*.php. This was discussed on the
list months ago, and can provide for better security *if* the admin blocks
browser access to the directory. I found that naming the files *.inc
allows browsers to see the plain text of the files, and that's a little
too "open source" for my comfort. As .php files they are executed, as they
would be now as wiki_*php3, but the source cannot be viewed.

index.php3 will become index.php; this is for consistency, bringing the
project "up to date" and to please the several requests I've gotten for
this.

Voice objections/criticisms by then, or request a delay if you don't have
time to make one.

cheers
sw

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

[Phpwiki-talk] [Fwd: Mail-distribution-list for Wiki]

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

-- 
http://wcsb.org/~swain/ | "In a calendar year, America's entire
  *   *   *   *   *   * | recorded music industry has revenues
*   *   *   *   *   *   | roughly equal to one month's sales by
  *   *   *   *   *   * | IBM." --Philip Greenspun

[Phpwiki-talk] [Fwd: Mail-distribution-list for Wiki]

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

The idea of subscribing to a page for change notifications has been
implemented in other Wikis, PyWiki being one of them...

sw


-- 
http://wcsb.org/~swain/ | "In a calendar year, America's entire
  *   *   *   *   *   * | recorded music industry has revenues
*   *   *   *   *   *   | roughly equal to one month's sales by
  *   *   *   *   *   * | IBM." --Philip Greenspun

[Phpwiki-talk] PATCH - search from each page.

[Neil B. <ne...@cs...>]

Another patch for phpwiki.

I like to be able to have a search form on each browser page (instead
of having to go to a special search page.
You can currently do this by customising browse.html.
However you either have to choose beteen titlesearch and fullsearch,
which is restruictive, or have two entry fields, which is noisy.

The following patch allows you to have submit buttons (or even an
option menu) that select which type of search by setting $searchtype,
and provides a sample usage in browse.html

NeilBrown



--- ./templates/browse.html	2000/10/06 02:38:48	1.1
+++ ./templates/browse.html	2000/10/06 02:45:57	1.3
@@ -19,6 +19,12 @@
 [<a href="###SCRIPTURL###?diff=###PAGEURL###">diff</a>])
 <br>
 <a href="###SCRIPTURL###?FindPage">FindPage</a> by browsing or searching
+<form action="###SCRIPTURL###">
+Search:
+<input type='text' size=40 name=searchstring>
+<input type=submit value=search name=searchtype>
+<input type=submit value=full name=searchtype>
+</form>
 <hr noshade>
 <small>###RELATEDPAGES###</small>
 
--- ./index.php3	2000/10/06 02:21:24	1.1
+++ ./index.php3	2000/10/06 02:45:21	1.2
@@ -13,6 +13,15 @@
    $dbi = OpenDataBase($WikiPageStore);
 
 
+   // To allow choice of submit buttons to determine type of search:
+   if ($searchtype == "search") {
+	$search = $searchstring;
+   } else if ($searchtype == "full") {
+	$full = $searchstring; 
+   } else if ($searchstring) {
+	// default to plain search
+	$search = $searchstring;
+   }
 
    if ($edit) {
       $admin_edit = 0;

[Phpwiki-talk] PATCH - nested DefinitionLists

[Neil B. <ne...@cs...>]

Steve,
 here is another patch, which I am cc:ing to phpwiki-talk (I hope that
 is not inappropriate).

 It allows DefinitionLists to be nested in the same what at Orders and
 Unordered Lists can be.

 I really wanted this for 
    http://kernelbook.sourceforge.net:80/wiki/?DentryStructure
 (see the definition of d_flags)
 so I thought I would try to make sure that it is available in the
 next version.

NeilBrown


--- ./wiki_transform.php3	2000/10/06 02:21:24	1.1
+++ ./wiki_transform.php3	2000/10/06 02:25:45	1.2
@@ -200,9 +200,10 @@
       }
 
       // HTML modes: pre, unordered/ordered lists, term/def
-      if (preg_match("/(^\t)(.*?)(:\t)(.*$)/", $tmpline, $matches)) {
+      if (preg_match("/(^\t+)(.*?)(:\t)(.*$)/", $tmpline, $matches)) {
          // this is a dictionary list item
-         $html .= SetHTMLOutputMode("dl", SINGLE_DEPTH, 1);
+         $numtabs = strlen($matches[1]);
+         $html .= SetHTMLOutputMode("dl", SINGLE_DEPTH, $numtabs);
          $tmpline = "<dt>" . $matches[2] . "<dd>" . $matches[4];
 
       // oops, the \d needed to be \d+, thanks al...@mi...

[Phpwiki-talk] Wiki (fwd)

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

Another customized PhpWiki.

http://wcsb.org/~swain/ | "In a calendar year, America's entire
  *   *   *   *   *   * | recorded music industry has revenues
*   *   *   *   *   *   | roughly equal to one month's sales by
  *   *   *   *   *   * | IBM." --Philip Greenspun

---------- Forwarded message ----------
Date: Mon, 02 Oct 2000 08:11:57 +0200
From: Thomas Hoog <th...@4h...>
To: sw...@pa...
Subject: Wiki

Hi Steve

I have set up a wiki on http://www.4high.com

I made some changes.

The wiki is categorized and you must login before updating anything
and browsing any *Privat*. Anything marked *Public* could be changed
by anybody.

/Thomas Höög (high in english)
mailto:th...@4h...