phpwiki-talk

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

[Phpwiki-talk] SubWikiTags readability

[Thomas K. <th...@co...>]

> How would this affect the readability of links? The current =
LinkingScheme
   using WikiWords is nice because it PreservesReadability of the text.

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

Yes. Therefore I'm using an output in the form of ~ToDo for the=20
Link ThomasKalka.ToDo in the page ThomasKalka. You will know this
kind of linking from encyclopedias.

For InterWikiLinks i would  like to have (optianally) an output in the
form of ->ReadASentence (where -> might be a nice picture). If you=20
hoover over it, you would get the InterWikiSite displayed.


Thomas

[Phpwiki-talk] transform.php

[Thomas K. <th...@co...>]

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

I`m thinking about reimplementing it in this manor:

a) First parse the WikiPage into a Structure of Objects=20
    (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=20
   TransformationPrototypeClasses

Thomas

[Phpwiki-talk] object orientiation

[Thomas K. <th...@co...>]

I`m thinking about using
..WikiName
for the following reasons

a) In my logic the .WikiName is an operator , something like "part of". Then
..SomeThing would
    be interpretetd as >>SomeThing is "part of" "."<< and the first "." is
the pointer to the actual object.

b) It is more error-save then just .WikiTag , which you could produce more
easily by  mistake.
    If one allows also NonWikiWords to be used for namig  Objects this
becomes even more important.

c) .something is not as easily recognized by humans as ..something, this is
more uncommon.


Thomas

Re: [Phpwiki-talk] object orientiation

[Malcolm R. <mal...@cs...>]

On Thu, Mar 01, 2001 at 04:47:03PM -0800, Jeff Dairiki wrote:
> >> I my thougths a first step towards a object-oriented wiki could be to
> >> allow for nested wiki-tags like in the following examples: 
> >> 
> >> WikiTag.SubWikiTag.SubSubWikiTag is interpreted as a whole
> >> 
> >> ..SubWikiTag  in a page is prepended with the page-name in links 
> >> 
> >> for example in the the page ThomasKalka
> >> ..ToDo would link to ThomasKalka.ToDo
> >> 
> >> 
> >> What do you think ??
> 
> Yes, I was going to comment on this before, but forgot.
> (First, I'm not sure I would call this object-oriented!)
> 
> I did start a wiki-page with similar ideas at:
>   http://phpwiki.sourceforge.net/phpwiki/index.php?NewWikiPageNameSemantics

How would this affect the readability of links? The current LinkingScheme
using WikiWords is nice because it PreservesReadability of the text.

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

Nevermind having Usemod:PathNames/ComplexPathNamesLikeThis.

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.

Malcolm

-- 
Malcolm Ryan - mal...@cs... - http://www.cse.unsw.edu.au/~malcolmr/
  AI Dept, CSE, UNSW, Australia, Phone: +61 2 9385-6906 Fax: +61 2 9385-1814

           "He causes his sun to rise on the evil and the good,
           and sends rain on the righteous and the unrighteous." - Matt 5:45

Re: [Phpwiki-talk] object orientiation

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

>> I my thougths a first step towards a object-oriented wiki could be to
>> allow for nested wiki-tags like in the following examples: 
>> 
>> WikiTag.SubWikiTag.SubSubWikiTag is interpreted as a whole
>> 
>> ..SubWikiTag  in a page is prepended with the page-name in links 
>> 
>> for example in the the page ThomasKalka
>> ..ToDo would link to ThomasKalka.ToDo
>> 
>> 
>> What do you think ??

Yes, I was going to comment on this before, but forgot.
(First, I'm not sure I would call this object-oriented!)

I did start a wiki-page with similar ideas at:
  http://phpwiki.sourceforge.net/phpwiki/index.php?NewWikiPageNameSemantics


UseMod has a SubPage feature which is very similar to what you suggest
  see http://www.usemod.com/cgi-bin/wiki.pl?action=browse&id=SubPage

UseMod uses '/' as the separator between page and subpage.  I think '.'
makes a much better separator.  Perhaps this is because of my Unix
background '/ToDo'  doesn't look like a sub-page to me --- the leading
slash to me indicates a top-level file.  

Why two leading dots and not just one?  Why couldn't .ToDo be enough?

Jeff

Re: [Phpwiki-talk] object orientiation

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

On Fri, 16 Feb 2001, Thomas Kalka wrote:

> I my thougths a first step towards a object-oriented wiki could be to
> allow for nested wiki-tags like in the following examples: 
> 
> WikiTag.SubWikiTag.SubSubWikiTag is interpreted as a whole
> 
> ..SubWikiTag  in a page is prepended with the page-name in links 
> 
> for example in the the page ThomasKalka
> ..ToDo would link to ThomasKalka.ToDo
> 
> 
> What do you think ??
> 
> Thomas
> 
> 
> 
> 
> 
> 

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

[Phpwiki-talk] change of address

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

I've switched to my sw...@pa... email address for all things PhpWiki.
This really a test message disguised as an announcement.

~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] Displaying diffs

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

On Thu, 1 Mar 2001, Jeff Dairiki wrote:

> >Yes and yes, and it's an idea I've played with (in my head at least).
> >Doing it by diffs is somewhat awkward though... what would be cool is to
> >store the pages in a format that preserves the change information somehow.
> >Outside of XML though, I haven't had any ideas how to preserve this info.
> 
> A very interesting idea!  In the database, tag each line with which version
> number in which it originally appeared.  Then a display similar to (but
> hopefully far less cluttered than) the 'annotated' source view produced by
> the SF CVS  browser could then be produced.  (I.e. "recent" additions or 
> changes could be highlighted, and perhaps annotated with the author's name.)
> (My guess is that deleted text would not be shown in this display.)
> 
> An example of SF CVS 'annotated' source can be found at:
>   http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/phpwiki/lib/editpage.php?annota
> te=1.15&cvsroot=phpwiki
> 
> Another, simpler, option which has been in the back of my head for a while
> now, is just to fix things so that the diff output gets transform.php'ed.
> Then one can create a "unified diff" (with infinite context) which will be
> the transformed page with changes since the last version highlit.
> (One VersionHistory is added, changes since any particular archived version,
> could be highlit.)

To further this discussion... here's another approach. The idea came from
two places: reading about Xanadu, and looking at the diffs on Sourceforge
this way:

http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/phpwiki/lib/config.php.diff?cvsroot=phpwiki&r1=text&tr1=1.20&r2=text&tr2=1.21&f=h

Rather than trying to cram all the information in a single page, display
the two versions side by side. Highlight the differences. Also, the Unix
tool sdiff does this and can be very userful at times. (I think Emacs'
"Emerge" mode does this too). This has been one of the clearest ways I've
seen to view page differences.


> Also, I'm happy to report that Sandra (my wife), Lucy (my dog) and I (along
> with most of the rest of Seattle) seem to have survived yesterday's rather
> large earthquake in fine shape.

Good to hear! For some reason I thought you lived in CA. All I really knew
though was that you lived in PST somewhere :-)

~swain


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