phpwiki-talk

Re: [Phpwiki-talk] task list for 1.3

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

the same as it is for any open source project... when it's ready ;-)

~swain

On Fri, 9 Mar 2001 ph...@de... wrote:

> On Tue, 6 Feb 2001 15:00:48 -0500 (EST), Steve Wainstead wrote:
> => This time I'm trying to keep track of all the ideas for 1.3 with the task
> => list.
>
> 	Is there any timeline at all for the release of 1.3?
>
> 	Some of us are drolling over the expectation of great new
> features and improvements as discussed here.
>
> 	TIA.
>
> 	- Don
>
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> http://lists.sourceforge.net/lists/listinfo/phpwiki-talk
>

---
                  http://www.panix.com/~swain/
"Without music to decorate it, time is just a bunch of boring
production deadlines or dates by which bills must be paid."
                     -- Frank Zappa

Re: [Phpwiki-talk] Bug? Pages unexpectedly deleated...

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

OK, I've reached the point where I could go through all the same steps:

* Jeb was surfing in admin mode when he got no page
* buyorganic.org runs PHP 3.0

Unfortunately I wasn't able to reproduce the bug. The only differences I
see are he's using 3.0.18 and I'm using 3.0.12; and I had to copy the page
source of MountainPeoplesOrder from the [info] link on buyorganic.org, b/c
the page is locked. So I might have a variation in the page source.

Jeb is also using OpenSSL, but I can't see that making any difference. We
could use a listing from phpinfo() to look for other things.

At this point the only thing I can think of is to compile 3.0.18 here and
try it out.

Jeb: what Unix are you running?

~swain

On Fri, 9 Mar 2001, Jeb Bateman wrote:

> Hi, I'm running phpwiki 1.2.0 at http://buyorganic.org/live
> Overall, it's really cool.  However, I have seen some unexpected
> behavior with pages being accidentially deleated when trying to edit.
> I was watching the Apache log while it happened once, so will show the
> relevant log entries below, as I explain the process...
>
> 207.135.238.21 - - [09/Mar/2001:10:08:53 -0800] "GET
> /live?MountainPeoplesOrder HTTP/1.0" 200 5937
> 207.135.238.21 - - [09/Mar/2001:10:09:05 -0800] "GET
> /live?edit=MountainPeoplesOrder HTTP/1.0" 200 5168
>
> [Originally GET and edit of page.]
>
> 63.237.193.173 - - [09/Mar/2001:10:09:30 -0800] "GET
> /wiki/admin.php?MountainPeoplesOrder HTTP/1.1" 200 6093
>
> [I check that it's still there at this point.]
>
> 207.135.238.21 - - [09/Mar/2001:10:13:43 -0800] "POST /live HTTP/1.0"
> 200 5614 "http://buyorganic.org/live?edit=MountainPeoplesOrder"
> 63.237.193.173 - - [09/Mar/2001:10:14:03 -0800] "GET
> /wiki/admin.php?MountainPeoplesOrder HTTP/1.1" 200 2320
>
> User posts edit, and gets 5614 bytes response showing success...
> I reload, and the page ss gone! (2320 bytes is new page template)
>
> 63.237.193.173 - - [09/Mar/2001:10:19:49 -0800] "GET
> /wiki/admin.php?diff=MountainPeoplesOrder HTTP/1.1" 200 838
>
> I check diff, which shows nothing in the database.  (I think it should
> diff an empty pages against the archived copy.  Similarly, I think
> editing a deleated page with a copy in the archive should present the
> option to edit the archive copy...)
>
> 207.135.238.21 - - [09/Mar/2001:10:20:03 -0800] "POST /live HTTP/1.0"
> 200 5724 "http://buyorganic.org/live?edit=MountainPeoplesOrder"
> 63.237.193.173 - - [09/Mar/2001:10:20:57 -0800] "GET
> /wiki/admin.php?MountainPeoplesOrder HTTP/1.1" 200 5655
>
> I walked her through going Back, copying the text (sent to me as email)
> and Saving again.  This time it worked(!!!) even though I expected
> it to warn her that she was editing a previous copy, as I've seen when
> going back before without reloading.
>
> So, the page was unexpectedly lost.  Then, it was recovered by
> effectively posting a first edit to an empty page (which happened to
> luckily be in the browser cache).
>
> The following is a possible clue, which I'm also confused about...
> I did a 'dump serialized pages' to backup, and here is partial output:
>
> SandBox ... 304 bytes written
> MountainPeoplesOrderr ... 5 bytes written
> MountainPeoplesOrderr ... 5 bytes written
> MountainPeoplesOrderr ... 5 bytes written
> MountainPeoplesOrder ... 3785 bytes written
> HowToUseWiki ... 2403 bytes written
>
> What are those three 5 byte pages with an extra 'r'??  They are not
> pages in the site database.  In fact, the first time I did the dump,
> there was only one of these bogus entries in the output.  Since then,
> the page has been  accidentially deleated twice more.  So, I'm thinking
> these  records might be added each time the version is set back to 1
> (after a  page is deleated).
>
> Of course, I plan to study the code to figure out exactly why this is
> happening, but if anyone has ideas, I'd appreciate any clues.
>
> Thanks!
> -jeb
>
>
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> http://lists.sourceforge.net/lists/listinfo/phpwiki-talk
>

---
                  http://www.panix.com/~swain/
"Without music to decorate it, time is just a bunch of boring
production deadlines or dates by which bills must be paid."
                     -- Frank Zappa

Re: [Phpwiki-talk] Bug? Pages unexpectedly deleated...

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

On Fri, 9 Mar 2001, Jeff Dairiki wrote:

> >However, I have seen some unexpected
> >behavior with pages being accidentially deleated when trying to edit.
> > [... rest of scary story omitted...]
>
> Eeek.
>
> Please tell us what backend (what type of database) you are using.
> Also which OS and which version of PHP your server is running might
> be of interest.

I can see he's using the DBM library:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<!-- $Id: index.php,v 1.5 2000/11/08 15:34:06 ahollosi Exp $ -->
<!-- $Id: config.php,v 1.1 2001/03/08 17:51:07 ocha Exp ocha $ -->
<!-- $Id: dbmlib.php,v 1.7 2001/01/31 03:11:25 wainstead Exp $ -->
<!-- $Id: stdlib.php,v 1.21 2001/01/15 12:32:57 ahollosi Exp $ -->
<!-- $Id: display.php,v 1.5 2000/12/30 21:09:13 ahollosi Exp $ -->
<!-- $Id: transform.php,v 1.8 2001/01/04 18:34:15 ahollosi Exp $ -->

I will try to reproduce this here on my box.

~swain


---
                  http://www.panix.com/~swain/
"Without music to decorate it, time is just a bunch of boring
production deadlines or dates by which bills must be paid."
                     -- Frank Zappa

Re: [Phpwiki-talk] task list for 1.3

[<ph...@de...>]

On Tue, 6 Feb 2001 15:00:48 -0500 (EST), Steve Wainstead wrote:
=> This time I'm trying to keep track of all the ideas for 1.3 with the task
=> list.

	Is there any timeline at all for the release of 1.3?

	Some of us are drolling over the expectation of great new
features and improvements as discussed here.

	TIA.

	- Don

Re: [Phpwiki-talk] Bug? Pages unexpectedly deleated...

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

>However, I have seen some unexpected
>behavior with pages being accidentially deleated when trying to edit.
> [... rest of scary story omitted...]

Eeek.

Please tell us what backend (what type of database) you are using.
Also which OS and which version of PHP your server is running might
be of interest.

[Phpwiki-talk] Bug? Pages unexpectedly deleated...

[Jeb B. <je...@oc...>]

Hi, I'm running phpwiki 1.2.0 at http://buyorganic.org/live
Overall, it's really cool.  However, I have seen some unexpected
behavior with pages being accidentially deleated when trying to edit.
I was watching the Apache log while it happened once, so will show the 
relevant log entries below, as I explain the process...

207.135.238.21 - - [09/Mar/2001:10:08:53 -0800] "GET
/live?MountainPeoplesOrder HTTP/1.0" 200 5937
207.135.238.21 - - [09/Mar/2001:10:09:05 -0800] "GET
/live?edit=MountainPeoplesOrder HTTP/1.0" 200 5168

[Originally GET and edit of page.]

63.237.193.173 - - [09/Mar/2001:10:09:30 -0800] "GET
/wiki/admin.php?MountainPeoplesOrder HTTP/1.1" 200 6093

[I check that it's still there at this point.]

207.135.238.21 - - [09/Mar/2001:10:13:43 -0800] "POST /live HTTP/1.0"
200 5614 "http://buyorganic.org/live?edit=MountainPeoplesOrder"
63.237.193.173 - - [09/Mar/2001:10:14:03 -0800] "GET
/wiki/admin.php?MountainPeoplesOrder HTTP/1.1" 200 2320

User posts edit, and gets 5614 bytes response showing success...
I reload, and the page ss gone! (2320 bytes is new page template)

63.237.193.173 - - [09/Mar/2001:10:19:49 -0800] "GET
/wiki/admin.php?diff=MountainPeoplesOrder HTTP/1.1" 200 838

I check diff, which shows nothing in the database.  (I think it should
diff an empty pages against the archived copy.  Similarly, I think 
editing a deleated page with a copy in the archive should present the 
option to edit the archive copy...)

207.135.238.21 - - [09/Mar/2001:10:20:03 -0800] "POST /live HTTP/1.0"
200 5724 "http://buyorganic.org/live?edit=MountainPeoplesOrder"
63.237.193.173 - - [09/Mar/2001:10:20:57 -0800] "GET
/wiki/admin.php?MountainPeoplesOrder HTTP/1.1" 200 5655

I walked her through going Back, copying the text (sent to me as email)
and Saving again.  This time it worked(!!!) even though I expected
it to warn her that she was editing a previous copy, as I've seen when
going back before without reloading.

So, the page was unexpectedly lost.  Then, it was recovered by 
effectively posting a first edit to an empty page (which happened to 
luckily be in the browser cache).

The following is a possible clue, which I'm also confused about...
I did a 'dump serialized pages' to backup, and here is partial output:

SandBox ... 304 bytes written
MountainPeoplesOrderr ... 5 bytes written
MountainPeoplesOrderr ... 5 bytes written
MountainPeoplesOrderr ... 5 bytes written
MountainPeoplesOrder ... 3785 bytes written
HowToUseWiki ... 2403 bytes written

What are those three 5 byte pages with an extra 'r'??  They are not 
pages in the site database.  In fact, the first time I did the dump,
there was only one of these bogus entries in the output.  Since then, 
the page has been  accidentially deleated twice more.  So, I'm thinking 
these  records might be added each time the version is set back to 1 
(after a  page is deleated).

Of course, I plan to study the code to figure out exactly why this is
happening, but if anyone has ideas, I'd appreciate any clues.

Thanks!
-jeb

Re: [Phpwiki-talk] problem with phpwiki using dba.

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

>A word of caution: ndbm on Solaris only supports values of 1000 bytes.
>This means that a page could not exceed 1000 bytes in length or you got an
>internal server error.

Good point.  Also, I suspect the dbm handler suffers all the problems
that the dbm module did in the older PHPs, so both dbm and ndbm
are probably best avoided if possible.

I don't think db2 (or db3) has a limitation and data value size.
(I have not actually tested it though --- I figure Adam will scream
if it turns out to be a problem.)

The db2 and db3 handlers both use the Sleepycat implementation of
the "Berkeley DB" library.  (I am not at all sure what the
differences between db2 and db3 are.)

From http://www.sleepycat.com/docs/ref/program/dbsizes.html:
  "The largest key or data item that Berkeley DB can support
   is largely limited by available memory."

Jeff

Re: [Phpwiki-talk] problem with phpwiki using dba.

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

A word of caution: ndbm on Solaris only supports values of 1000 bytes.
This means that a page could not exceed 1000 bytes in length or you got an
internal server error.

You might want to test this out to see if it's the case, and if so try the
db2, about which I know nothing...

cheers
~swain


On Tue, 6 Mar 2001, Adam Shand wrote:

>
> > The dba_ functions are an interface to several of the dbm-style
> > database libraries.  'Gdbm' is only one of the types of databases
> > possible --- others include 'dbm', 'ndbm', 'db2', db3'.  Which ones
> > are available in your PHP are determined at PHP compile-time.
>
> debian disables gdbm in favor of db2 and ndbm i believe.
>
> > DBA support          |   enabled
> > Supported Handlers   |   gdbm db2 db3
>
> yep ... i get ...
>
> DBA support				enabled
> Supported handlers			ndbm db2
>
> > (Except, I suspect in your case gdbm won't be listed as a supported
> > handler.)
>
> yep, right on the money.
>
> > Change line 39 in dbalib.php from
>
> just like magic!
>
> > I think that should work.  (I've just tested it with 'db2' and that
> > seems to work fine.)
>
> yep please, this is really hard to debug if you aren't very familiar with
> php.
>
> THANK YOU!
> adam.
>
>
>
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> http://lists.sourceforge.net/lists/listinfo/phpwiki-talk
>

---
                  http://wcsb.org/~swain/
"Without music to decorate it, time is just a bunch of boring
production deadlines or dates by which bills must be paid."
                     -- Frank Zappa

Re: [Phpwiki-talk] problem with phpwiki using dba.

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

> The dba_ functions are an interface to several of the dbm-style
> database libraries.  'Gdbm' is only one of the types of databases
> possible --- others include 'dbm', 'ndbm', 'db2', db3'.  Which ones
> are available in your PHP are determined at PHP compile-time.

debian disables gdbm in favor of db2 and ndbm i believe.

> DBA support          |   enabled
> Supported Handlers   |   gdbm db2 db3

yep ... i get ...

DBA support				enabled
Supported handlers			ndbm db2

> (Except, I suspect in your case gdbm won't be listed as a supported
> handler.)

yep, right on the money.

> Change line 39 in dbalib.php from

just like magic!

> I think that should work.  (I've just tested it with 'db2' and that
> seems to work fine.)

yep please, this is really hard to debug if you aren't very familiar with
php.

THANK YOU!
adam.

Re: [Phpwiki-talk] problem with phpwiki using dba.

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

>> Warning: no such handler: gdbm in /var/www/devel.spack.org/phpwiki/lib/dbali
> b.php on line 39
>
>I can't find any reference to this error on the PHP site... perhaps you
>could email the maintainer of the PHP package for Debian? I wish I could
>offer more but at the moment I'm stumped.

The dba_ functions are an interface to several of the dbm-style database
libraries.  'Gdbm' is only one of the types of databases possible --- others
include 'dbm', 'ndbm', 'db2', db3'.  Which ones are available in your
PHP are determined at PHP compile-time.

To see which ones are supported in your php, create a file within
your web document tree called, say, 'info.php' containing one line:

<?php phpinfo(); ?> 

Then browse this file with your browser, you'll get a big page full
of all kinds of information about the configuration of your PHP.

A ways down that page there should be a table labeled 'dba'.  It should
look something like:

DBA support          |   enabled
Supported Handlers   |   gdbm db2 db3

(Except, I suspect in your case gdbm won't be listed as a supported handler.)

Pick one of the handlers which is supported --- I'm not completely up to
snuff on the differences between them all, but my guess is to prefer, in
this order: gdbm, db2, db3, ndbm, dbm.

Change line 39 in dbalib.php from
         while (($dbi[$key] = @dba_open($file, "c", "gdbm")) < 1) {
to
         while (($dbi[$key] = dba_open($file, "c", "db2")) < 1) {

I.e. change the "gdbm" to "db2" (or whatever dba handler your PHP supports.)

I think that should work.  (I've just tested it with 'db2' and that seems
to work fine.)

Jeff


Note to maintainers: We should look into this a bit more.  Also make the
code auto-detect which handlers are supported.

Re: [Phpwiki-talk] problem with phpwiki using dba.

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

Adam Shand wrote:

> Warning: Variable passed to reset() is not an array or object in /var/www/devel.spack.org/phpwiki/lib/dbalib.php on line 52
> Warning: Variable passed to each() is not an array or object in /var/www/devel.spack.org/phpwiki/lib/dbalib.php on line 53
> WikiFatalError
> Cannot open database 'wiki' : '/tmp/wikipagesdb', giving up.

Yes, this is just PHP saying it got a variable that should be an array
but was not.

> > With the '@' removed you will get a verbose error message telling us
> > what the problem is.
> 
> now i get this:
> 
> Warning: no such handler: gdbm in /var/www/devel.spack.org/phpwiki/lib/dbalib.php on line 39
> Warning: no such handler: gdbm in /var/www/devel.spack.org/phpwiki/lib/dbalib.php on line 39
> Warning: no such handler: gdbm in /var/www/devel.spack.org/phpwiki/lib/dbalib.php on line 39

I can't find any reference to this error on the PHP site... perhaps you
could email the maintainer of the PHP package for Debian? I wish I could
offer more but at the moment I'm stumped.

~swain

> Warning: Variable passed to reset() is not an array or object in /var/www/devel.spack.org/phpwiki/lib/dbalib.php on line 52
> Warning: Variable passed to each() is not an array or object in /var/www/devel.spack.org/phpwiki/lib/dbalib.php on line 53
> WikiFatalError
> Cannot open database 'wiki' : '/tmp/wikipagesdb', giving up.

Re: [Phpwiki-talk] problem with phpwiki using dba.

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

> Did you try setting your database type to "dbm" and see if that works?
> If not, the next step is to set it to "dba" again, and edit dbalib.php
> and remove the '@' symbol from the dba_open() call:

err, this was with it set to dbm.  with it set to dba i get the original
error i reported:

Warning: Variable passed to reset() is not an array or object in /var/www/devel.spack.org/phpwiki/lib/dbalib.php on line 52
Warning: Variable passed to each() is not an array or object in /var/www/devel.spack.org/phpwiki/lib/dbalib.php on line 53
WikiFatalError
Cannot open database 'wiki' : '/tmp/wikipagesdb', giving up.

> With the '@' removed you will get a verbose error message telling us
> what the problem is.

now i get this:

Warning: no such handler: gdbm in /var/www/devel.spack.org/phpwiki/lib/dbalib.php on line 39
Warning: no such handler: gdbm in /var/www/devel.spack.org/phpwiki/lib/dbalib.php on line 39
Warning: no such handler: gdbm in /var/www/devel.spack.org/phpwiki/lib/dbalib.php on line 39
Warning: Variable passed to reset() is not an array or object in /var/www/devel.spack.org/phpwiki/lib/dbalib.php on line 52
Warning: Variable passed to each() is not an array or object in /var/www/devel.spack.org/phpwiki/lib/dbalib.php on line 53
WikiFatalError
Cannot open database 'wiki' : '/tmp/wikipagesdb', giving up.

adam.

Re: [Phpwiki-talk] problem with phpwiki using dba.

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

On Mon, 5 Mar 2001, Adam Shand wrote:

> i used apt-get.  when i try dbm i get a blank page in my browser with just
> this when i view source:
>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
> <!-- $Id: index.php,v 1.5 2000/11/08 15:34:06 ahollosi Exp $ -->
> <!-- $Id: config.php,v 1.24 2001/01/31 07:38:10 ahollosi Exp $ -->
> <!-- $Id: dbmlib.php,v 1.7 2001/01/31 03:11:25 wainstead Exp $ -->
> <!-- $Id: stdlib.php,v 1.21 2001/01/15 12:32:57 ahollosi Exp $ -->

Aha. Well, this is some problem with either the dba_ support or the dbm
support; you see, the dbm* functions are deprecated in PHP4.0 in favor of
the dba_* functions, which are a more generic interface. This has caused
us a lot of install problems.

Did you try setting your database type to "dbm" and see if that works? If
not, the next step is to set it to "dba" again, and edit dbalib.php and
remove the '@' symbol from the dba_open() call:

   function OpenDataBase($dbname) {
      global $WikiDB; // hash of all the DBM file names

      reset($WikiDB);
      while (list($key, $file) = each($WikiDB)) {
         while (($dbi[$key] = @dba_open($file, "c", "gdbm")) < 1) {

------------------------------^ right here

            $numattempts++;
            if ($numattempts > MAX_DBM_ATTEMPTS) {
               ExitWiki("Cannot open database '$key' : '$file', giving
up.");
            }
            sleep(1);
         }
      }
      return $dbi;
   }


With the '@' removed you will get a verbose error message telling us what
the problem is.

~swain


---
                  http://wcsb.org/~swain/
"Without music to decorate it, time is just a bunch of boring
production deadlines or dates by which bills must be paid."
                     -- Frank Zappa

Re: [Phpwiki-talk] problem with phpwiki using dba.

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

> First, I hope you don't name the file directory and the DBM files the
> same... that's just an initial guess.

i was under the impression that phpwiki would create the dbm files itself.
it creates the flat files itself?  if that's not what you mean then i
don't understand sorry ...  here's the relevant section of my config file:

   $WhichDatabase = 'dba'; // use one of "dbm", "dba", "mysql",
                           // "pgsql", "msql", or "file"

   // DBM and DBA settings (default)
   if ($WhichDatabase == 'dbm' or $WhichDatabase == 'dba' or
       $WhichDatabase == 'default') {
      $DBMdir = "/tmp";
      $WikiPageStore = "wiki";
      $ArchivePageStore = "archive";
      $WikiDB['wiki']      = "$DBMdir/wikipagesdb";
      $WikiDB['archive']   = "$DBMdir/wikiarchivedb";
      $WikiDB['wikilinks'] = "$DBMdir/wikilinksdb";
      $WikiDB['hottopics'] = "$DBMdir/wikihottopicsdb";
      $WikiDB['hitcount']  = "$DBMdir/wikihitcountdb";

> There was a post on the list recently about a special config option,
> and I think it was about Debian but I can't find it in the list
> archives... a module had to be loaded by PHP at runtime.

was there a solution?  i know debian pretty well but i can't find any
documentation exactly where the dba module is.  the docs say it's compiled
in and it looks like it is from running strings on the php binary but it's
more then possible that i have to enable something in a config file or
something.

> Also, did you compile the package yourself or use get-apt (or whatever
> Debian uses?) You might try setting it to 'dbm' instead of 'dba' and
> see if that works. I was wondering if dba_* support was compiled in or
> not.

i used apt-get.  when i try dbm i get a blank page in my browser with just
this when i view source:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<!-- $Id: index.php,v 1.5 2000/11/08 15:34:06 ahollosi Exp $ -->
<!-- $Id: config.php,v 1.24 2001/01/31 07:38:10 ahollosi Exp $ -->
<!-- $Id: dbmlib.php,v 1.7 2001/01/31 03:11:25 wainstead Exp $ -->
<!-- $Id: stdlib.php,v 1.21 2001/01/15 12:32:57 ahollosi Exp $ -->

adam.

Re: [Phpwiki-talk] how to enable html

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

Steve Wainstead schrieb:
> Hi Reini, sorry for the delay...

I've already implemented it now in my AcadWiki.

To support some multiline blocks (verbatim, code and nowiki) 
I've made a seperate loop to avoid looping all other transformer funcs.
This block is completely protected from further wiki transformations, only 
htmlchars are enforced to avoid HTML inline code. 
code is asis, verbatim and nowiki converts "<" to "&lt;" ...

But to overcome 
  <code><html><script><!-- do something bad --></script></html></code>

A special regex checks for </?[a-z]{1,6}> strings inside the code block 
and transforms < to &lt; then.

I want <code> to support arbitrary pasted code in every language. 
(lisp, c, perl, php, java, ...)
There the comparison characters "<" and ">" should not appear too close. 
  if (a < 2 || a > 4) is no html tag. but if (2<a>4) is one. 
is this valid code in some exotic language?
when pasting from the wiki you'll otherwise get the ugly &lt; and &gt; chars.

> After thinking for a bit about the problem, I always come back to the idea
> of "token substitution." 
...

thanks for your description.
this can be used to disable <script> and other malicious tags then. (as in
meatball)
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] transform.php

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

>I doubt that you will be able to ensure HTML4 compliance.

I'm not sure I understand this comment.  Why not?  Surely it's not impossible.
Whether it's worth the effort or not is (as always) open to debate.

>As far as I have tested out, "correct" markup will produce correct HTML.
>Why deal with stuff like double-intended lists without a single list first? 
>Wrong markup produces wrong HTML - simple enough.

';:' is often used to introduce a "block-indented paragraph", not a "list
item."    There's no reason ';;:' shouldn't produce
a block paragraph with more indentation --- and no reason it should have
to be nested within another list.  (Note that even though it produced
"invalid" HTML, this construct worked, at least with my browser.) Why
not fix things  (especially, since, in this case, the fix was easy) so that
this generates correct HTML?

And I see your point, that if given garbage, one shouldn't worry if one
outputs garbage.   On the other hand, if it's not too hard, why not
output valid garbage?  (Perhaps one could even try to flag the offending
garbage to help the user guess what he did wrong.)

>>(Paragraphs all on one line...)
>I think this is a frequent complaint. Maybe we should deal with this.
>I'm not sure if it's a good idea, but maybe (if modifications are small)
>we could add this as option?

Yes, I think it's simple to implement --- a minor modification to the
current transform code.  (Except maybe for tables  -- I have to think
about that a bit more.)

Just as an aside, I think proliferation of options (particularly one like this
which doesn't really change the functionality of PhpWiki at all) should be
avoided.  Having numerous options makes testing harder and also complicates
wiki-administrations and plug-and-playability.

Another idea (though I think it's more trouble than it's worth) is to
auto-convert the old pages when restoring (from a zip- or serialized- dump)
to a new version of PhpWiki.  Currently, the old-style tab-delimited lists,
and triple-quote bold are unsupported in the 1.3.x branch. This could be a
way to deal with that as well.

>> (I don't see any reason why italicization and boldizization shouldn't be
>> able to span these continuation lines as well.)
>
>Because, "errors" are then contained to one line? The thing I really like abou
> t 
>wiki markup is, that no matter what I (or others!!) do on line 3, line 4 will 
>always be shown as I have meant it to be displayed. Furthermore, currently if 
>there's only one '' in the line, italics won't even be opened. It needs an ope
> n 
>and close tag to be recognized by the regexp.

Yes, but it's a common wiki-idiom to italicize an entire paragraph.  Currently,
the paragraph is supposed to be on one line (though it may span many lines in 
the
textarea display).  I'm just suggesting that if we relax the restriction that
the paragraph must be on one line, we should similarly relax the restriction
for italics.  (The italics markup must still be contained within the paragraph,
but since the paragraph can be split across lines, so can the italicization.)


Just to reiterate a point from the my last message, since I think I've found
a better way to say it:

I think the current transform code generally marks-up the inline and 
block-level
elements in the wrong order.   The block-level markup should be processed 
first,
then the in-line markup should be processed on a block-by-block basis.
 
Jeff

Re: [Phpwiki-talk] transform.php

[<ho...@sb...>]

Jeff,

my net connection is down and maybe will remain so for another week (aaarrggh). 
I cannot send emails from my regular address, so I can't post to phpwiki-talk. 
Could you please forward this email?

[turning transform.php into a bona fide parser]
> 1. It would help guarantee correctness of generated HTML.

I doubt that you will be able to ensure HTML4 compliance. As far as I have 
tested out, "correct" markup will produce correct HTML. Why deal with stuff 
like double-intended lists without a single list first? Wrong markup produces 
wrong HTML - simple enough.

> 2. It would make extensions to the markup such as Reini's
> <code></code> blocks cleaner to implement.

Block stuff could easily be fitted into the current transform.php with some 
minor modifications. I have already thought about that. (About block markup 
itself: I guess you know where I stand ;o)

> 3. I've starting thinking about how to colorize (or otherwise) mark
> the transformed text to highlight diffs.  It's not easy to fit a
> colorizing scheme into the current transform code

Hm, if you think of the one diff-mode where you have the two versions side by 
side, it should be fairly easy to implement. Using some variation of the 
current diff-mode might be hard to implement, I agree.

> all the ways I've thought of to do this would surely not
> receive the Arno seal of code simplicity.

:o) Well, I'd also argue that the diff stuff is not fundamental to wiki, and 
that the current diff is good enough for 95% of all cases. But I'm also 
interested to learn about the different ideas you had!

> To change topics slightly, a personal peeve I have with the current
> markup, is this thing about having to put entire paragraphs (& list items,
> etc...) on one line.

I think this is a frequent complaint. Maybe we should deal with this. Your 
simple solution (everything keeps current mode until a newline or another mode-
markup is encountered) seems straightforward and easy to implement. I'm not 
sure if it's a good idea, but maybe (if modifications are small) we could add 
this as option?

> (I don't see any reason why italicization and boldizization shouldn't be
> able to span these continuation lines as well.)

Because, "errors" are then contained to one line? The thing I really like about 
wiki markup is, that no matter what I (or others!!) do on line 3, line 4 will 
always be shown as I have meant it to be displayed. Furthermore, currently if 
there's only one '' in the line, italics won't even be opened. It needs an open 
and close tag to be recognized by the regexp.

/Arno

Re: [Phpwiki-talk] how to enable html

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

On Mon, 5 Mar 2001, Steve Wainstead wrote:

>
>
> Hi Reini, sorry for the delay...
>
> After thinking for a bit about the problem, I always come back to the idea
> of "token substitution."
>
> We use the $FieldSeparator variable to pull things out of the text of the
> page when parsing, which you've probably seen in the code. We do this for
> links:

What I should have written is "We use the $FieldSeparator variable to
*replace* things in the text..."

~swain

---
                  http://wcsb.org/~swain/
"Without music to decorate it, time is just a bunch of boring
production deadlines or dates by which bills must be paid."
                     -- Frank Zappa

Re: [Phpwiki-talk] problem with phpwiki using dba.

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

On Mon, 5 Mar 2001, Adam Shand wrote:

> phpwiki works great when i set it like this in lib/conifig.php:
>
> $WhichDatabase = 'file';
>
> but as soon as i try to set it to 'dba' i get this error:
>
> Warning: Variable passed to reset() is not an array or object in /var/www/devel.spack.org/phpwiki/lib/dbalib.php on line 52
> Warning: Variable passed to each() is not an array or object in /var/www/devel.spack.org/phpwiki/lib/dbalib.php on line 53
> WikiFatalError
> Cannot open database 'wiki' : '/tmp/wikipagesdb', giving up.

First, I hope you don't name the file directory and the DBM files the
same... that's just an initial guess.

>
> the web server does have permissions to write there because it works just
> fine in file mode so i'm not sure what to do.  i'm wondering if debian has
> done something a little weird, it breaks all the php extensions into
> seperate packages so i only have the core, imap and gd ones installed.
> does dba need to be listed in an "extension=xxx" line in my php.ini file?

There was a post on the list recently about a special config option, and I
think it was about Debian but I can't find it in the list archives... a
module had to be loaded by PHP at runtime.

Also, did you compile the package yourself or use get-apt (or whatever
Debian uses?) You might try setting it to 'dbm' instead of 'dba' and see
if that works. I was wondering if dba_* support was compiled in or not.

Let me know if any of that helps and we'll try again if not.

~swain

---
                  http://wcsb.org/~swain/
"Without music to decorate it, time is just a bunch of boring
production deadlines or dates by which bills must be paid."
                     -- Frank Zappa

Re: [Phpwiki-talk] how to enable html

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

Hi Reini, sorry for the delay...

After thinking for a bit about the problem, I always come back to the idea
of "token substitution."

We use the $FieldSeparator variable to pull things out of the text of the
page when parsing, which you've probably seen in the code. We do this for
links:

    see this great site: http://www.foo.com/

is transformed into:

    see this great site: tokenNumbertoken

Actually the token in 1.2 and earlier is the "power of three" symbol (i.e.
10^3 == 1000). But you should see what I mean.

To avoid the changing of any HTML in the page source, you could just use
the same technique to pull out all HTML tags before processing and then
put them back when it's done. You could even do this on a line-by-line
basis; you wouldn't need to work on the page as a whole. So for each line
you would use a regexp matching whatever HTML you want to allow, replace
all matches with tokens, and after all the Wiki transformations are done
you would just put the HTML back in.

If that doesn't make sense let me know and I'll try to explain further.
However you should be able to just copy the code that pulls out links and
later puts them back, but instead of matching for links you can match for
HTML tags.

cheers
~swain

> I've experimented a bit with supporting html code.
> But I need another feature not supported with this:
>
> ...<code> ...
> verbatim multiline code, no wikilinks.
> ..</code>
>
> the problem is the disabling of all further wiki transformations in such a
> code block, which is multiline.
>
> I've tried this bad hack, with combining some flags (for the special
> do_transform loop),
> and setting other global vars for the loop. but it is very dirty, and doesn't
> even work yet.
> any ideas?
>
> $transform->register(WT_SIMPLE_MARKUP & WT_MODE_MARKUP, 'wtm_code', '<code>');
>
> function wtm_code($line, &$trfrm) {
>    global $transform;
>    $line = $trfrm->SetHTMLMode('code', ZERO_LEVEL, 0) . "\n" . $line;
>    $transform->mode_set = 1; // hack to allow mult. lines
>    return $line;
> }
>
>
> another unclean idea I tried, was to process all lines in the <code> block
> seperately.
> something like this:
>
> // protected text within a <code> block. no markups at all.
> // not line orientated! (like <nowiki> or <verbatim>)
> /*
> function wtm_code($line, &$trfrm) {
>    global $transform;
>    $i = strpos($line, '<code>');
>    $prefix = substr($line,0,$i);
>    $line = substr($line,$i);
>    // echo "<code>: $line<br>"; // debug
>    $c = $transform->linenumber;
>    $count = count($transform->content);
>    // this might fail on missing closing tag
>    while (!$i and ($c < $count))
>    {
>       $actline = $transform->content[$c];
>       $i = strpos($actline, '</code>');
>       $line .= $actline;
>       $c++;
>    }
>    $transform->linenumber = $c;
>    // echo "</code>: ",substr($actline,$i),"<br>";  // debug
>    return $prefix . $line . substr($actline,$i);
> }
> */
>
>
>
> Steve Wainstead schrieb:
> >
> > On Thu, 22 Feb 2001, Didier Bretin wrote:
> >
> > > Hello,
> > >
> > >   I'm with the 1.1.9 version, and I can't find where I can allow the use
> > > of html. Can you help me ? :o)
> >
> > To enable HTML, you only have to uncomment one block of code in
> > lib/transform.php. It looks like this:
> >
> > /* 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;
> >       }
> > */
> >
> > Just strip out all the comments and you can then insert HTML this way:
> >
> > | <table>
> > | <tr><td>blah</td></tr>
> > | </table>
> >
> > by putting a bar  | at the start of every line.
> >
> > If you want to go much further than that you can change the rules in
> > transform.php (not for the light hearted!) to use HTML instead of Wiki
> > markup.
> >
> > cheers
> > ~swain
> >
> > ...............................ooo0000ooo.................................
> >    Hear FM quality freeform radio through the Internet: http://wcsb.org/
> >                      home page: www.wcsb.org/~swain
> >
> > _______________________________________________
> > Phpwiki-talk mailing list
> > Php...@li...
> > http://lists.sourceforge.net/lists/listinfo/phpwiki-talk
>
> --
> Reini Urban
> http://xarch.tu-graz.ac.at/home/rurban/
>
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> http://lists.sourceforge.net/lists/listinfo/phpwiki-talk
>

---
                  http://wcsb.org/~swain/
"Without music to decorate it, time is just a bunch of boring
production deadlines or dates by which bills must be paid."
                     -- Frank Zappa

Re: [Phpwiki-talk] transform.php

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

>Had anybody already thought about coding transform.php completely=20
>in object oriented style ?

Here's a bunch of random thoughts I've been having regarding the
transform code:

Jeffs_hacks-branch has an OO transform.php.  Nobody really liked
it completely (not even myself).

The "new" transform code in 1.3.x is not really very different from
the "old" code.  This is both good and bad.

I think that the transform code could be improved.  Turning it into
a bona fide parser, as Thomas suggests, would really help in several areas:

1. It would help guarantee correctness of generated HTML.

2. It would make extensions to the markup such as Reini's <code></code>
   blocks cleaner to implement.  (I'll refrain from commenting on whether
   <code> blocks are a good idea.)

3. I've starting thinking about how to colorize (or otherwise) mark the
   transformed text to highlight diffs.  It's not easy to fit a colorizing
   scheme into the current transform code --- all the ways I've thought of
   to do this would surely not receive the Arno seal of code simplicity.

   If done correctly a two stage transformation --- parsing then output would
   allow this to be done in a much cleaner way.

I think that any such new parser should probably operate in two steps.  First
it should parse the "in-line" markup elements (bold, italic, links) --- then
the "block-level" elements (paragraphs, lists, tables, <code> blocks).
Perhaps this can all be handled in one parse step; but the distinction between
the two types of mark-up needs to be made pretty clear for the sake of
correct HTML generation, among other things.

(I'm thinking perhaps that the inline markup should be handled by adding
the ability to mark regions of text as having specific "flavors".  Flavors
would include bold, italic, link (I think), as well as things like 'deleted',
'added', 'modified-add', 'modified-del'.)

(This is all brain-storming, don't take it too seriously.)

----

I'm not sure that the ability to generate other mark-up (TeX or whatever)
is of great importance, but turning transform into a proper parser would
certainly make that easier as well.

----

To change topics slightly, a personal peeve I have with the current markup,
is this thing about having to put entire paragraphs (& list items, etc...)
on one line.  Having been raised on troff and then TeX, those really-long
lines just drive me batty.

Looking at the textarea in the edit page on my browser, it's impossible to 
tell whether there's a real \n or not between lines.  I often find myself 
manually
deleting all spaces from the ends of lines to make sure there is no \n 
in there.

To confuse matters more , for plain paragraphs, the requirement that the
paragraph be on one line is silently waived --- currently, it is still
enforced for list items (& tables).

I think it would be a good idea to make it so that all lines which do
not begin with some sort of block type mark-up (e.g. a '*', '#', ';', '|',
or space) are interpreted as continuations of the preceding line.
(The only reason I see for not making this change is that it will break
existing pages.) 

Ie.

A sentence.
Another.
* Item.
More item.

Should be interpreted as

<p>A sentence. Another.</p>
<ul>
<li>Item. More item.
</ul>

instead of

<p>A sentence. Another.</p>
<ul><li>Item.</ul>
<p>More item.</p>

(I don't see any reason why italicization and boldizization shouldn't be able 
to
span these continuation lines as well.)  E.g.:

;:''Here are some followup comments.
I really don't like this at all. --Jeff''

should work.

-------
Comments?

Jeff

Re: [Phpwiki-talk] transform.php

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

On Fri, 2 Mar 2001, Thomas Kalka wrote:

> Had anybody already thought about coding transform.php completely
> in object oriented style ?

The new one Arno wrote, or are you using 1.2?

> I`m thinking about reimplementing it in this manor:
>
> a) First parse the WikiPage into a Structure of Objects
>     (this part is totaly independent of html)
>
> b) these objects have the ability to transform into different
>     outputs (for example html, plain-text, TeX, ...)
>    They get this ability mostly by inheritance from simple
>    TransformationPrototypeClasses

What would the page objects be? For example, WikiSentence, WikiParagraph,
WikiLink, etc?

~swain

---
                  http://wcsb.org/~swain/
"Without music to decorate it, time is just a bunch of boring
production deadlines or dates by which bills must be paid."
                     -- Frank Zappa

[Phpwiki-talk] problem with phpwiki using dba.

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

hey.

hopefully i'm just being stupid and it's an obvious problem because i
really want this to work.  i'm a relative newbie with php but haven't had
many problems with other programs i want to work.  i'm using debian linux,
php4.0.4pl1 and apache 1.3.14.

phpwiki works great when i set it like this in lib/conifig.php:

$WhichDatabase = 'file';

but as soon as i try to set it to 'dba' i get this error:

Warning: Variable passed to reset() is not an array or object in /var/www/devel.spack.org/phpwiki/lib/dbalib.php on line 52
Warning: Variable passed to each() is not an array or object in /var/www/devel.spack.org/phpwiki/lib/dbalib.php on line 53
WikiFatalError
Cannot open database 'wiki' : '/tmp/wikipagesdb', giving up.

the web server does have permissions to write there because it works just
fine in file mode so i'm not sure what to do.  i'm wondering if debian has
done something a little weird, it breaks all the php extensions into
seperate packages so i only have the core, imap and gd ones installed.
does dba need to be listed in an "extension=xxx" line in my php.ini file?

regardless any help would be much appreciated.

thanks,
adam.

Re: [Phpwiki-talk] how to enable html

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

I've experimented a bit with supporting html code.
But I need another feature not supported with this:

...<code> ...
verbatim multiline code, no wikilinks.
..</code>

the problem is the disabling of all further wiki transformations in such a 
code block, which is multiline.

I've tried this bad hack, with combining some flags (for the special
do_transform loop), 
and setting other global vars for the loop. but it is very dirty, and doesn't
even work yet. 
any ideas?

$transform->register(WT_SIMPLE_MARKUP & WT_MODE_MARKUP, 'wtm_code', '<code>');

function wtm_code($line, &$trfrm) {
   global $transform;
   $line = $trfrm->SetHTMLMode('code', ZERO_LEVEL, 0) . "\n" . $line;
   $transform->mode_set = 1; // hack to allow mult. lines
   return $line;
}


another unclean idea I tried, was to process all lines in the <code> block
seperately.
something like this:

// protected text within a <code> block. no markups at all.
// not line orientated! (like <nowiki> or <verbatim>)
/*
function wtm_code($line, &$trfrm) {
   global $transform;
   $i = strpos($line, '<code>');
   $prefix = substr($line,0,$i);
   $line = substr($line,$i);
   // echo "<code>: $line<br>"; // debug
   $c = $transform->linenumber;
   $count = count($transform->content);
   // this might fail on missing closing tag
   while (!$i and ($c < $count))
   {
      $actline = $transform->content[$c];
      $i = strpos($actline, '</code>');
      $line .= $actline;
      $c++;
   }
   $transform->linenumber = $c;
   // echo "</code>: ",substr($actline,$i),"<br>";  // debug
   return $prefix . $line . substr($actline,$i);  
}
*/



Steve Wainstead schrieb:
> 
> On Thu, 22 Feb 2001, Didier Bretin wrote:
> 
> > Hello,
> >
> >   I'm with the 1.1.9 version, and I can't find where I can allow the use
> > of html. Can you help me ? :o)
> 
> To enable HTML, you only have to uncomment one block of code in
> lib/transform.php. It looks like this:
> 
> /* 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;
>       }
> */
> 
> Just strip out all the comments and you can then insert HTML this way:
> 
> | <table>
> | <tr><td>blah</td></tr>
> | </table>
> 
> by putting a bar  | at the start of every line.
> 
> If you want to go much further than that you can change the rules in
> transform.php (not for the light hearted!) to use HTML instead of Wiki
> markup.
> 
> cheers
> ~swain
> 
> ...............................ooo0000ooo.................................
>    Hear FM quality freeform radio through the Internet: http://wcsb.org/
>                      home page: www.wcsb.org/~swain
> 
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> http://lists.sourceforge.net/lists/listinfo/phpwiki-talk

-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] object orientiation

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

On Fri, 2 Mar 2001, Malcolm Ryan wrote:

> I already find that the InterWiki link scheme is distracting enough. Trying
> to Wiki:ReadASentence with PhpWiki:InterWikiLinks in it is
> NomicWiki:HardEnoughAlready.

> I think non-computer-types are really going to baulk at this sort of
> thing. I know people who think WikiWords are distracting enough as it is.

I think InterWiki linking is really of interest to Wiki enthusiasts,
mostly. It does get some use on Advogato when referring to the definition
of a term.

~swain


http://wcsb.org/~swain/
=============================================================
"Without music to decorate it, time is just a bunch of boring
production deadlines or dates by which bills must be paid."
   -- Frank Zappa