phpwiki-talk

Re: [Phpwiki-talk] Re: Object Oriented Wiki in PHP

[Ori F. <or...@co...>]

Hi

As you and Arno said, OOP is not appropiate for a wiki. In fact, I have
ceased development of my own version and hope to contribute to phpwiki
instead.

What I hoped to achieve with my wiki, and this has little to do with OOP, is
modularity. I not only wanted a different data storage approach, but also a
different parser and a few more advanced features. I felt that a wiki which
will be easy to install and configure and yet offer a lot of the possible
wiki features would be a good idea.

As to an abstract database interface, I find that the one that comes with
PHPLib is easy to use. My wiki should work fine with any of the RDBMS's
supported by PHPLib (well, maybe the random page feature will fail since it
relies on a specific MySQL feature). There is also a DBI-like class being
worked on as part of PEAR, the future PHP version of CPAN, you might want to
look for that.


- Calanya, aka Ori Folger
 "Don't anthropomorphize computers -- they hate it."

Re: [Phpwiki-talk] Re: Object Oriented Wiki in PHP

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

> We have an extensive rewrite in OO as well, done by Jeff Dairiki. Have
> you seen it? It has all the features (I think) of the 1.1.7 release plus
> some improvements.

Yes, Jeff has done some outstandig work within very short time.

> Couple this with the problem that object systems can be much harder to
> understand than procedural ones, and that gives me second thoughts about
> introducing OO into PhpWiki.

The problem I see with OO in phpwiki is this: most of the time we only have 
one instance per class - so what do we gain by using OO? What makes
$data->function() better than function($data) ?

In other cases like e.g. the iterator class in Jeff's branch OO can be very 
useful. And I guess in 1.3.x we will use OO to some extension where it 
makes sense but keep to the procedural approach otherwise.

OO excels when you can take advantage of inheritance and other more 
sophisticated features. But those cases are hardly needed in phpwiki. 
Unless you can convince me otherwise I think a 100% OO approach has more 
cons than pros.

/Arno

[Phpwiki-talk] offline this weekend again

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

I'm offline again until Sunday night. I think we have plenty of new things
in the code that we should get 1.1.9 out. I can do this Sunday night.

Commit what you want and complain otherwise... I'll see you all Sunday.

cheers
sw

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

[Phpwiki-talk] Re: Object Oriented Wiki in PHP

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

Hi Ori! Sorry for the long wait in replying.

I'd love to see it. I hope I have time to read it properly. I'm interested
in your comments on PHP's object model too; I have read recently that it's
too immature (after the PHP Kongress in Colonge). 

We have an extensive rewrite in OO as well, done by Jeff Dairiki. Have you
seen it? It has all the features (I think) of the 1.1.7 release plus some
improvements.

I've added the task to our Task List on Sourceforge to objectify the
database access. This generally makes things easier for the developer:
packaging data and the functions that operate on that data. But PHP
doesn't seem to offer much more after that.

Couple this with the problem that object systems can be much harder to
understand than procedural ones, and that gives me second thoughts about
introducing OO into PhpWiki.

In a well designed OO system, the classes are loosely coupled, they form
subsystems that are easy to understand, and they are easy to discover and
modify. If we only objectify one interface, we would have to do quite a
bit of surgery on the code (if we stick with the current code base, and I
don't see why not) for what might be little gain.

What would be infinitely better is if we used some kind of generic DB
library, like Perl's DBI/DBD. Then PhpWiki could run on any relational
database, and we would only have to maintain one interface and the various
schemas. If we were really lucky, this library would support flat file and
DBM access as well, but we can wish all day for PHP to be Perl and it's
not going to happen ;-)

cheers
sw


On Wed, 1 Nov 2000, Ori Folger wrote:

> Hi
> 
> I have written an OOP based Wiki in PHP a while back, before I knew of
> phpwiki. It's not as feature rich as phpwiki, but I think it's a good start.
> 
> Would you be interested in seeing it?
> 
> Ori
> 

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

[Phpwiki-talk] Spanish copy of PhpWiki

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

As a test I downloaded the latest nightly build and edited the config to
use Spanish. You can see it at:

http://wcsb.org:80/~swain/es/phpwiki/index.php

It's running on DBM.
sw

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

Re: [Phpwiki-talk] Spanish translation

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

> Completed the translation of the spanish file names and some contents.

I have comitted the patch. Thanks a lot Sandino.
Check out the latest CVS to test it out - or wait till tomorrow and 
download the nightly tarball.

Also, I have comitted the inital set for a German translation.

To the lurkers on this list: if you speak Dutch, Spanish, or German then 
you can help us translating. If you speak another language you would like 
to see included in phpwiki then just go ahead and send in your patch.

/Arno

Re: [Phpwiki-talk] RFC - markup changes for list items.

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

Neil,

could you point me to a patch so that I can look at your changes?

>  So, I would prefer that list items could continue onto multiple
>  lines. I have implemented a change that achieves this and it works quite
>  well.  When transform.php finds a line that starts with normal text,
>  it just includes it in the current context.  To terminate a list, you
>  just need a blank line, and this feels quite natural.

Hm, but you still could not indent the following lines, right? Or is this 
allowed as well? If so, is it then a <pre> block, or just normal text?
If you can't indent the lines, what's the difference? It wouldn't be 
visually more appealing, or am I wrong?

> ... add a new markup which means "paragraph break at this level"
>   1/ ";;;" is currently line break, so maybe ";;;;" could be new-para,

You mean "%%%" right?

>   2/ "." on a line by itself or at the start of a line might be good
>       as it is visually similar to the required concept:

Looks better, but generally speaking I'm no fan of creating too much new 
markup. After all, we don't want to reinvent HTML. We will modularize 
lib/transform.php in 1.3.x so it will be easier to integrate such custom 
markup.

>   Somewhat related to this, consider the lists in TextFormattingRules.
>   That are actually sequences of singleton lists.

That's true. Actually, I'm not too happy about the current state of 
SetHTMLOutputMode() but for different reasons. But apart from that, why is 
the current HTML that bad? It makes no difference to browsers, unless you 
are handicapped of some sort and rely on proper lists. In that case just 
include a style-sheet that spreads list-items. Not everything has to be 
done within wiki.

/Arno

[Phpwiki-talk] Spanish translation

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

Some postgres fixes which Arno already included
Completed the translation of the spanish file names and some contents.
Patch against 1.1.8

http://sandino.net/patch/phpwiki-1.1.8-pgsql-patch-8.patch

--
Sandino Araico Sánchez
Diga no a la piratería, use software libre.

[Phpwiki-talk] RFC - markup changes for list items.

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

Hi,
 I would like comments on a couple of changes that I would like for
 handling of list items.

 I like using lists a lot, and it bothers me that a single list item
 must currently be entirely on one line.
 I find this particularly irksome when editing in the netscape
 <textarea wrap="virtual">  box, you cannot visually distinguish
 between a wrapped line and two lines where the second is not
 indented.

 So, I would prefer that list items could continue onto multiple
 lines.
 I have implemented a change that achieves this and it works quite
 well.  When transform.php finds a line that starts with normal text,
 it just includes it in the current context.  To terminate a list, you
 just need a blank line, and this feels quite natural.

 This change is not backwards compatible and would need to be
 considered carefully, but I think that it is for the good.  After
 all, paragraphs can be continued on the next line, why not paragraphs
 within lists.


 My other change is along the same lines, but a bit more interesting.

 I would like to be able to have multiple paragraphs within a list
 item.  
 I have implemented this by interpreting a single blank line as a
 paragraph break at the current level, and a double blank line as an
 end-of-list marker.
 This allows me to have multiple paragraphs in lists, but it has
 turned out in practice to be a bit awkward.  It is easy to forget the
 two blank lines that are needed to end a list.
 My thought is to add a new markup which means "paragraph break at
 this level", and leave the blank line meaning "break out of any list
 context".

 The question is, what should the new markup be?

  1/ ";;;" is currently line break, so maybe ";;;;" could be new-para,
      but it is kind of ugly
  2/ "." on a line by itself or at the start of a line might be good
      as it is visually similar to the required concept:

       .A dot at the start of 
       a line makes that line
       intent slightly. 
       .This is just what happens
       at the start of a paragraph
       in some formating style.

  Does anyone know if there is any precedent in other wikis?


  Somewhat related to this, consider the lists in TextFormattingRules.
  They look like a nicely spaced unordered lists.  But if you look at
  the generated html, you will find that there are not.  That are
  actually sequences of singleton lists.  If you chose to make them
  ordered lists, you would find that every item is number '1'.
  If we want to be able to provide nice spacing in lists, maybe
  defining "." as a local paragraph break would be a good way to
  achieve this.

You comments appreciated,
NeilBrown

Re: [Phpwiki-talk] another phpwiki 1.1.8 proposed change

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

> On my system I have PHP set to show non-critical warning, like referring to
> a variable before defining its value.
> phpwiki emits a lot of these.

I think it's better to remove the cause of these notices, instead of just 
suppressing them. Thus I fixed 99.9% of those warnings just now.
Actually this revealed some serious errors, like e.g. $FieldSeparator not 
defined as "global" in some functions, or e.g. dbm not closing the dbm-files.

> ini_set("error_reporting", ini_get("error_reporting") & 2039);
> It is also php4 specific.

I added "error_reporting(E_ALL ^ E_NOTICE)" to index.php which is useable for 
both php3 and php4.

I suggest that everyone on this list removes "^ E_NOTICE" when testing 
phpwiki.


> I'd like to suggest that on lines 30 and 33 of lib/config.php $REQUEST_URI
> be replaced with $SCRIPT_NAME. The REQUEST_URI environment variable is

Done.

/Arno

[Phpwiki-talk] another phpwiki 1.1.8 proposed change (fwd)

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

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

---------- Forwarded message ----------
Date: Tue, 31 Oct 2000 21:43:09 +0200
From: Ori Folger <or...@co...>
To: Steve Wainstead <sw...@wc...>
Subject: another phpwiki 1.1.8 proposed change

Hi

On my system I have PHP set to show non-critical warning, like referring to
a variable before defining its value.

phpwiki emits a lot of these.

The following line turns off these non-critical warnings:

ini_set("error_reporting", ini_get("error_reporting") & 2039);

It should be line 10 of index.php.

It is also php4 specific.

Ori Folger

Re: [Phpwiki-talk] todo list for 1.2.0?

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

I added two today in fact:

# clean up config.php
# bring the other databases in line with mysql.php

Those two should not be that hard. Once that's done and debugged, there is
not much left to do.

also:
# new logo -- it's bad form to use images that are larger than the space
they fit into, as the logo does now. 

# update the wiki pages -- All the pages that are loaded by default should
be looked at again. I noticed today that WikiWikiWeb says "this Wiki has
no theme," which we should not presume. ReleaseNotes is out of date. A lot
of the new markup syntax is not documented and there is still talk about
tabs. Embedding images needs to be documented. (I think). 

# add a file called UPGRADE -- if people are upgrading to 1.1.8 or later
they need to add tables to their databases. This was the source of one bug
I was emailed about recently. Also they need to be warned about just
running a commmand like:

bash$ xxsql -db wiki < schemas/schema.foo 

which will wipe out their pages.

# reread all other documentation

# put docs in the Docs section on SF, maybe -- I know I like to read the
INSTALL notes before I install something, and if they are online it's
faster. Linking to them would be good enough since the documentation is
all on SF in phpwiki/ anyhow.

But that should be it. Mostly cleanup work.

sw

On Tue, 31 Oct 2000, Arno Hollosi wrote:

> Subject says it all:
> What needs to be done before we release 1.2.0?
> 
> Many tasks/bugs listed at SF are post 1.2.0, no?
> 
> Let me know what you think.
> 
> /Arno 
> _______________________________________________
> 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 

[Phpwiki-talk] Re: phpwiki 1.1.8 lib/config.php suggest change

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

Hi Ori!

Thanks for the idea... we'll probably implement it.

sw

On Tue, 31 Oct 2000, Ori Folger wrote:

> Hi
> 
> I'd like to suggest that on lines 30 and 33 of lib/config.php $REQUEST_URI
> be replaced with $SCRIPT_NAME. The REQUEST_URI environment variable is
> Apache specific and is not part of the CGI 1.1 standard
> (http://hoohoo.ncsa.uiuc.edu/cgi/env.html). $SCRIPT_NAME works just as fine
> and with all web servers.
> 
> Ori
> 
> 

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

[Phpwiki-talk] todo list for 1.2.0?

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

Subject says it all:
What needs to be done before we release 1.2.0?

Many tasks/bugs listed at SF are post 1.2.0, no?

Let me know what you think.

/Arno 

[Phpwiki-talk] nightly builds

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

Nightly builds should now be available 2AM EDT every night. If this is not
a good time (it seems to be between when I go to bed and Arno gets up) let
me know.

The nightly build will be at:

ftp://phpwiki.sourceforge.net/pub/phpwiki/phpwiki.nightly.tar.gz
http://phpwiki.sourceforge.net/nightly/phpwiki.nightly.tar.gz

sw


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

[Phpwiki-talk] Re: phpwiki, 1.1.8

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

Hello Donncha, thank you for the kind words!

I cannot reproduce this. Did you upgrade an existing Wiki, or do a clean
install (including a new database?)

That would be most helpful.

thx
sw

On Fri, 27 Oct 2000, Donncha O Caoimh wrote:

> Hey Steve,
> 
> Just noticed a little bug with the new version.
> 
> The recent changes page links to index.php3 for the "diff" but only an
> index.php exists. A symlink fixes it of course but thought you should
> know.
> 
> As ever, good stuff!
> 
> Donncha.
> 

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

Re: [Phpwiki-talk] help police the site please

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

> I am about to post the announcement for 1.1.8 on freshmeat.net, whcih
> always brings a lot of new people, including people who erase pages.

Ok, so I got tired of restoring FrontPage. I did it 4 times within 2 
hours - now I have locked it.


/Arno

p.s. actually there's a loophole that allows editing a page without 
unlocking it. One might call it a bug - naaa :)

[Phpwiki-talk] help police the site please

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

I am about to post the announcement for 1.1.8 on freshmeat.net, whcih
always brings a lot of new people, including people who erase pages.

For convenience I've made a FrontPageBackup
(http://phpwiki.sourceforge.net/phpwiki/index.php?FrontPageBackup).

I am going on a trip tomorrow morning and will be offline until Sunday
night; please keep an eye on the site in case someone wipes out any pages
(just keep checking RecentChanges).

thx again
sw

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

[Phpwiki-talk] 1.1.8 live now on SF

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

Tonight I mv'd the old phpwiki/ and installed a fresh copy of 1.1.8. I
created an index.php3 to redirect to index.php. Could one of you double
check my work, since I haven't written one in PHP before:

<?php
   /* build the cgi data into a string */
   $query = implode('&', $argv);

   /* Redirect browser to PHP web site */
   header("Location: 
http://phpwiki.sourceforge.net/phpwiki/index.php?$query");

   /* Make sure that code below does not get executed when we redirect. */
   exit;
?>


It's right out of the PHP manual (in function.header.html). I added the
GET data string.

thx
sw


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

Re: [Phpwiki-talk] tranform.php patch

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

Neil,

> I would like to suggest the following patch (against current CVS)
> less likely.  To me, it makes the code a whole lot cleaner, but may

I really like that one and have committed it already. Nicely done!
Sometimes it seems we don't see the forrest because of the trees.

/Arno

[Phpwiki-talk] PhpWiki 1.1.8 out

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

It's finally here, after three whole months! 

http://download.sourceforge.net/phpwiki/phpwiki-1.1.8.tar.gz
ftp://phpwiki.sourceforge.net/pub/phpwiki/


From the HISTORY file:

1.1.8 10/25/00: 
* Internationalization, with support for Dutch, and an architecture
  to add more languages easily
* Term/defintion tags updated to nest and use tabless markup
* MostPopular works for all implementations, except flat files
* Flat file database support; it's not yet complete but the basic Wiki
  functionality is there, thanks to Ari
* New zip file format for page dumps follows standard email format
* Removed tabs from all default pages
* Added whitespace padding to pages after they are serialized and
  written to the DBM file; this goes a long way towards fixing the
  memory leak problems for DBM-based Wikis.
* Numerous bug fixes, as always
* Some refactoring of the database interface


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

Re: [Phpwiki-talk] Re: info page translations & WikiLinkWithSameStem

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

On Tuesday October 24, aho...@in... wrote:
> 
> 
> > I'll maybe have a quick look at these too...
> > 7.And what about a WikiLink? and another WikiLink?WithSameStem on one line?
> > 8.Other way around: WikiLink?WithSameStem plus WikiLink?
> 

I would like to suggest the following patch (against current CVS)
which takes a different approach which makes this sort of bug much
less likely.  To me, it makes the code a whole lot cleaner, but may
it's just me.

The basic approach is to cope the line up while matching rather than
extracting strings and then searching for those strings.

It also fixes a bug whereby

;WikiWord: definition there-of
;OtherWikiWord: other definition

gets converted into bad html because the WikiWord gets converted into
a full reference (containing a :) before the search for /^;+.*?:/ is
done.
I simple delay replacing the token until (nearly) the last moment.

Let me know what yo think?

NeilBrown

Index: lib/transform.php
===================================================================
RCS file: /cvsroot/phpwiki/phpwiki/lib/transform.php,v
retrieving revision 1.4
diff -u -r1.4 transform.php
--- lib/transform.php	2000/10/24 10:32:37	1.4
+++ lib/transform.php	2000/10/25 01:58:48
@@ -1,5 +1,23 @@
 <!-- $Id: transform.php,v 1.4 2000/10/24 10:32:37 ahollosi Exp $ -->
 <?php
+   function tokenize($str, $pattern, &$orig, &$ntokens) {
+      global $FieldSeparator;
+      // Find any strings in $str that patch $pattern and
+      // store them in $tokens[], replacing them with a token
+      $new = "";      
+      while (preg_match("/^(.*?)($pattern)/", $str, $matches)) {
+         $linktoken = $FieldSeparator . $FieldSeparator . ($ntokens++) . $FieldSeparator;
+         $new .= $matches[1].$linktoken;
+	 $orig[] = $matches[2];
+         $str = substr($str, strlen($matches[0]));
+      }
+      $new .= $str;
+      return $new;
+   }
+
+
+
+
    // expects $pagehash and $html to be set
 
    // Set up inline links and images
@@ -29,6 +47,7 @@
       unset($tokens);
       unset($replacements);
       $ntokens = 0;
+      $replacements = array();
       
       $tmpline = $pagehash["content"][$index];
 
@@ -54,70 +73,40 @@
       //////////////////////////////////////////////////////////
       // New linking scheme: links are in brackets. This will
       // emulate typical HTML linking as well as Wiki linking.
+	
+      // First need to protect [[. 
+      $tmpline = tokenize($tmpline, "\[\[", $replacements, $ntokens);
+
 
-      // match anything between brackets except only numbers
-      // trying: 
-      $numBracketLinks = preg_match_all("/\[.+?\]/", $tmpline, $brktlinks);
-      /* On 12 Jul,2000 Jeff <da...@da...> adds:
-       *
-       * Simple sorting doesnt work, since (in ASCII) '[' comes between
-       * the upper- and lower-case characters.
-       *
-       * Using sort "[[Link] [Link]" will come out wrong, using
-       * rsort "[[link] [link]" will come out wrong.
-       * (An appropriate usort would work.)
-       *
-       * I've added a look-behind assertion to the preg_replace which,
-       * I think, fixes the problem.  I only hope that all PHP versions
-       * support look-behind assertions....
-      // sort instead of rsort or "[[link] [link]" will be rendered wrong.
-      sort($brktlinks[0]);
-      reset($brktlinks[0]);
-       */
-
-      for ($i = 0; $i < $numBracketLinks; $i++) {
-         $brktlink = preg_quote($brktlinks[0][$i]);
-         $linktoken = $FieldSeparator . $FieldSeparator . ++$ntokens . $FieldSeparator;
-	 /* PS:
-	  * If you're wondering about the double $FieldSeparator,
-	  * consider what happens to (the admittedly sick):
-	  *   "[Link1] [Link2]1[Link3]"
-	  *
-	  * Answer: without the double field separator, it gets
-	  *  tokenized to "%1% %2%1%3%" (using % to represent $FieldSeparator),
-	  *  which will get munged as soon as '%1%' is substituted with it's
-	  *  final value.
-	  */
-         $tmpline = preg_replace("|(?<!\[)$brktlink|",
-                                 $linktoken,
-                                 $tmpline);
-
-	 $tokens[] = $linktoken;
-	 $link = ParseAndLink($brktlinks[0][$i]);
-         $replacements[] = $link['link'];
+      // Now process the [\d+] links which are numeric references	
+      $oldn = $ntokens;
+      $tmpline = tokenize($tmpline, "\[\d+\]", $replacements ,$ntokens);
+      while ($oldn < $ntokens) {
+	    preg_match("/\[(\d+)\]/", $replacements[$oldn], $m);
+	    $num = $m[1];
+            if (! empty($embedded[$num])) {
+               $replacements[$oldn] = $embedded[$num];
+            }
+	    $oldn++;
+      }
+      // match anything else between brackets 
+
+      $oldn = $ntokens;
+      $tmpline = tokenize($tmpline, "\[.+?\]", $replacements, $ntokens);
+      while ($oldn < $ntokens) {
+	$link = ParseAndLink($replacements[$oldn]);	
+	$replacements[$oldn] = $link['link'];
+	$oldn++;
       }
 
       //////////////////////////////////////////////////////////
       // replace all URL's with tokens, so we don't confuse them
       // with Wiki words later. Wiki words in URL's break things.
-
-      $hasURLs = preg_match_all("/\b($AllowedProtocols):[^\s\<\>\[\]\"'\(\)]*[^\s\<\>\[\]\"'\(\)\,\.\?]/", $tmpline, $urls);
 
-      // have to sort, otherwise errors creep in when the domain appears
-      // in two consecutive URL's on the same line, but the second is
-      // longer e.g. http://c2.com followed by http://c2.com/wiki 
-      rsort($urls[0]);
-      reset($urls[0]);
-
-      for ($i = 0; $i < $hasURLs; $i++) {
-         $inplaceURL = preg_quote($urls[0][$i]);
-         $URLtoken = $FieldSeparator . $FieldSeparator . ++$ntokens . $FieldSeparator;
-         $tmpline = preg_replace("|$inplaceURL|",
-                                 $URLtoken,
-                                 $tmpline);
-
-	 $tokens[] = $URLtoken;
-         $replacements[] = LinkURL($urls[0][$i]);
+      $tmpline = tokenize($tmpline, "\b($AllowedProtocols):[^\s\<\>\[\]\"'\(\)]*[^\s\<\>\[\]\"'\(\)\,\.\?]", $replacements, $ntokens);
+      while ($oldn < $ntokens) {
+	$replacements[$oldn] = LinkURL($replacements[$oldn]);
+        $oldn++;
       }
 
       // escape HTML metachars
@@ -154,56 +143,20 @@
 
       // Link Wiki words
       // Wikiwords preceeded by a '!' are not linked
-      if (preg_match_all("#!?\b(([A-Z][a-z]+){2,})\b#",
-                         $tmpline, $link)) {
-         // uniq the list of matches
-         unset($hash);
-         for ($i = 0; $link[0][$i]; $i++) {
-	    if(strstr($link[0][$i], '!'))	// hashval sports a value
-	       $hashval = "0000:".$link[0][$i];	// in front that guarantees
-	    else				// correct sorting
-	       $hashval = sprintf("%04d:%s", 9876-strlen($link[0][$i])
-					  , $link[0][$i]);
-            $hash[$hashval] = 1;
-         }
-
-	 // all '!WikiName' entries are sorted first
-         ksort($hash);
-         while (list($realfile, $val) = each($hash)) {
-	    $realfile = substr($realfile, 5);	// get rid of sort value
-	    $token = $FieldSeparator . $FieldSeparator . ++$ntokens . $FieldSeparator;
-	    $tmpline = str_replace($realfile, $token, $tmpline);
-
-	    $tokens[] = $token;
-	    if (strstr($realfile, '!')) {
-	       $replacements[] = substr($realfile, 1);
-	    }	       
-            elseif (IsWikiPage($dbi, $realfile)) {
-	       $replacements[] = LinkExistingWikiWord($realfile);
-            } else {
-	       $replacements[] = LinkUnknownWikiWord($realfile);
-            }
-         }
+      $oldn = $ntokens;
+      $tmpline = tokenize($tmpline, "!?\b(([A-Z][a-z]+){2,})\b", $replacements, $ntokens);
+      while ($oldn < $ntokens) {
+        $old = $replacements[$oldn];
+        if (substr($old,0,1)=='!') {
+	  $replacements[$oldn] = substr($old,1);
+	} elseif (IsWikiPage($dbi, $old)) {
+	  $replacements[$oldn] = LinkExistingWikiWord($old);
+	} else {
+	  $replacements[$oldn] = LinkUnknownWikiWord($old);
+	}
+	$oldn++;
       }
 
-      ///////////////////////////////////////////////////////
-      // Replace tokens
-      for ($i = 0; $i < $ntokens; $i++)
-	  $tmpline = str_replace($tokens[$i], $replacements[$i], $tmpline);
-      
-
-      // match and replace all user-defined links ([1], [2], [3]...)
-      preg_match_all("|\[(\d+)\]|", $tmpline, $match);
-      if (count($match[0])) {
-         for ($k = 0; $k < count($match[0]); $k++) {
-            if (! empty($embedded[$match[1][$k]])) {
-               $linkpattern = preg_quote($match[0][$k]);
-               $tmpline = preg_replace("|$linkpattern|",
-                                       $embedded[$match[1][$k]],
-                                       $tmpline);
-            }
-         }
-      }
 
       // HTML modes: pre, unordered/ordered lists, term/def  (using TAB)
       if (preg_match("/(^\t+)(.*?)(:\t)(.*$)/", $tmpline, $matches)) {
@@ -279,6 +232,11 @@
          // it's ordinary output if nothing else
          $html .= SetHTMLOutputMode("", ZERO_DEPTH, 0);
       }
+
+      ///////////////////////////////////////////////////////
+      // Replace tokens
+      for ($i = 0; $i < $ntokens; $i++)
+	  $tmpline = str_replace($FieldSeparator.$FieldSeparator.$i.$FieldSeparator, $replacements[$i], $tmpline);
 
       $tmpline = str_replace("%%Search%%", $quick_search_box, $tmpline);
       $tmpline = str_replace("%%Fullsearch%%", $full_search_box, $tmpline);

[Phpwiki-talk] new site up

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

The Adirondack Adventure Club has set up PhpWiki on top of mSQL
(http://adirondackadventureclub.com/info/TheAdirondacks/). I helped the
developer when he had problems with 1.1.7; I made a tarball called
pre1.1.8 and posted it for him.

He has the site up and running now, but reported there was a problem with
gettext(). Unfortunately he did not elaborate. Text of our discussion is
at
http://phpwiki.sourceforge.net:80/phpwiki/index.php3?Known%20bugs%20in%201.1.6
(at the bottom). I asked him nicely to file a bug report. Unfortunately I
cannot find his email address anywhere.

(This is probably more exciting for me since I love to go hiking/camping
in the Adirondack Mountains).

sw

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

Re: [Phpwiki-talk] 1.2.0

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

Yes, I like the idea a lot (the second one :-)

I was going to put out 1.1.8 last night but was too busy; tonight for
certain. I need to take one last look at the documentation and then make
the tarball, and post to freshmeat.net, c2.com and the annoucement list
(and anything else I can think of).

1.2 should be out in early November, and then we can throw out backwards
compatibility once again and start on 1.3 :-)

sw

On Tue, 24 Oct 2000, Arno Hollosi wrote:

> An idea that just struck me:
> 
> why not release this version (or the next version in e.g. 2-4 weeks) as 
> version 1.2.0?
> 
> We could put off major changes like db interface / transform until then, and 
> do some touch-up (e.g. documentation). phpwiki seems rather stable currently, 
> so why not give it a bigger userbase by releasing it as a stable version?
> 
> Then we could define some goals for 1.4.x -- and slowly work our way torwards 
> 2.0.x :o)
> 
> What do you think about it?
> 
> Has anyone seen the "LikePages" feature on c2.com? I really like that 
> idea, e.g. http://www.c2.com/cgi/like?WhyEdit
> 
> /Arno
> _______________________________________________
> 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 

[Phpwiki-talk] Re: info page translations & WikiLinkWithSameStem

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

On Tue, 24 Oct 2000, Arno Hollosi wrote:

> Where the @$#! came this bug from? We've killed it a number of times already.
> Anyway, I've fixed it for good now (a hack - but it has its merrits). My 
> solution limits WikiNames to 9876 characters, though. I hope that doesn't 
> disturb anyone :o)

Too bad it's not shorter; WikiWords over 256 chars are a problem for the
mSQL version. Ah, something for the task list!

sw

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