phpwiki-talk

[Phpwiki-talk] 1.1.8

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

I'd like to release 1.1.8 this week. I've gotten the DBM lib up to date,
Ari has contributed a flat file database which works for the important
things (search, load, browse), and who knows what else in the last six
weeks.

Check in anything you want included, and I'll ship a tarball in the middle
of the week.

sw

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

[Phpwiki-talk] weird wiki_diff error on SourceForge

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

In the last two days I keep getting:

Fatal error: Unsupported operand types in
/home/groups/phpwiki/htdocs/phpwiki/wiki_diff.php3 on line 869

on SourceForge whenever I try to use the diff utility. I suspect that it's
some problem on their end, since I haven't done a "cvs update -d" in three
or four weeks.

The line in question is:

            $x += $ncopy;
            $y += $ncopy;

Both these lines cause an error, and if I comment them out diff compiles
again... but $x, $y, and $ncopy all are used in numeric contexts at all
times based on my grepping the code.

Jeff, any ideas? I think they might have either upgraded recently (they're
using 4.02 now, see http://phpwiki.sourceforge.net/phpinfo.php3) or else
their server is in some unstable state, which has happened a couple of
times before and they need a reboot. I'm using 4.00 at home so I can't
test this out yet.

sw

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

Re: [Phpwiki-talk] some good news...

[Michael D. E. <md...@md...>]

> It's always nice to hear someone is happy with PhpWiki...

> you have written a very groovy php app.
>
> thanks a lot..

Hi,

phpwiki IS a very groovy application and really: thanks a lot  :-)))))

I have it running in an intranet, so I can't give you an URL.
I'm waiting for the possibility to delete pages, because we have many
newbies which are experimenting a lot. If they are experienced phpwiki
users they don't need their experiments and they have to be deleted.

Have a great day

Michael D. Eschner

[Phpwiki-talk] some good news...

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

It's always nice to hear someone is happy with PhpWiki...

Subject: not a bug
Date: Thu, 31 Aug 2000 13:55:58 -0400
From: ron phelps <ron...@ce...>
To: sw...@pa...

well Steve..
you have written a very groovy php app.

thanks a lot..
I will be using this on the Nursesportal somewhere
as a free form converstation area for nurses who want to
discuss Nursing Issues..


right now it resides at http://ezpresentations.com/phpwiki/index.php3
because i only have two domains moved over to my new server..
and ezpresentations is not being used yet..

so when i get it on its own domain
I;ll send you the address to the working copy..

thanks again
ron

ps
it was extremely easy to setup in mysql
wow..

ron
webmaster
http://nursesportal.com



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

[Phpwiki-talk] new Wiki clone

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

http://moin.sourceforge.net/

Python based... just thought I'd point it out...

sw

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

Re: [Phpwiki-talk] Modularization ideas

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

Hi All,

Sorry I dropped off the face of the earth.  I suddenly became very busy
(combination of work and last-ditch-end-of-summer-looms recreation).

(I will probably remain busy for at least another couple of weeks...)

I am still here though, and will try to find time soon to add the
PATH_INFO and admin browse stuff to the main branch.

>I think this was Jeff's goal as well, but I don't know if he realized it
>(Jeff?). I think we'd all like to see rendering modularized, so go ahead
>with it, but don't bother forking the code base.

Yes it was my main goal, and I think I accomplished it --- though I admit
that my rendering code less than transparent in clarity.  (In fact, off all the
hacks in the jeffs_hacks-branch, I'm least happy with the rendering code.)
If you've got something better, go for it!


>I've just finished Jakob Nielsen's "Designing Web Usability" and have some
>ideas about the page layout, and as time permits I'll be checking in those
>changes this week (at work, we are now in the "death march" to reach a
>deadline, so time is precious).
>
>I want to shrink the logo, add a nav bar across the top and maybe the
>bottom too (to reduce the amount of scrolling needed), and add Ari's Wiki
>feature of how many times a page was edited (not necessary but I like it).

Note that in the jeffs_hacks branch, the addition of nav bars are can
be accomplished by a simple editing of templates files (probably just one:
template/wrapper.html).

>Arno drafted the "wikilinks" table which hasn't been implemented yet, but
>I want to add a right-hand rail listing all the pages that link to the
>current one. I got this idea from Nielsen's book; having "related pages"
>in a right hand rail is a Web convention apparently, and I have long been
>bothered by how this feature is hidden away in the page title link (i.e.
>click the page title 'FrontPage' and see all the pages that link to
>FrontPage).

A great idea.  Also note that the links table is implemented in jeffs_hacks.
Again (toot, toot) I think adding your right hand rail to jeffs_hacks
is a simple matter of editing templates (it might take a little php hacking,
too --- I'm not sure without looking.)



I think you should take a look at the database interface in jeffs_hacks again,
and consider it for inclusion into the main branch.  While some of the code
in jeffs_hacks admitedly fairly obtuse, I think the database code is
pretty straightforward.   I really don't see much room for (other than
incremental) improvement in it.  (Other than that the minisql and psql
backends still don't exist.)

Your ghost,
Jeff

Re: [Phpwiki-talk] Modularization ideas

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

I think this was Jeff's goal as well, but I don't know if he realized it
(Jeff?). I think we'd all like to see rendering modularized, so go ahead
with it, but don't bother forking the code base.

I've just finished Jakob Nielsen's "Designing Web Usability" and have some
ideas about the page layout, and as time permits I'll be checking in those
changes this week (at work, we are now in the "death march" to reach a
deadline, so time is precious).

I want to shrink the logo, add a nav bar across the top and maybe the
bottom too (to reduce the amount of scrolling needed), and add Ari's Wiki
feature of how many times a page was edited (not necessary but I like it).

Arno drafted the "wikilinks" table which hasn't been implemented yet, but
I want to add a right-hand rail listing all the pages that link to the
current one. I got this idea from Nielsen's book; having "related pages"
in a right hand rail is a Web convention apparently, and I have long been
bothered by how this feature is hidden away in the page title link (i.e.
click the page title 'FrontPage' and see all the pages that link to
FrontPage).

Ideally it should be configurable; if the Wiki admin doesn't want the
performance penalty of listing all related pages (a mere SELECT statement
though it is) or the page clutter of a list of titles, they can leave it
out. 

I think the nav bar I drafted last night was:

EditText | Changes | PageInfo | Help | MostPopular | RecentChanges |
FindPage

and it will just be a set of plain text links, to satisfy Lynx and Emacs
w3 mode (which I test PhpWiki in periodically. There could also be a
WhatLinksToThisPage link of some kind rather than list the pages on the
right side. Users can add an imagemap if they want.

A long term goal I have is to revamp FindPage entirely... there are many
things a search can do that are totally feasible in PhpWiki, like all
pages returned by the search have the search term highlighted when the
user clicks on them.

sw

On Tue, 29 Aug 2000, Aredridel Niothke wrote:

> Jeff's OO work aside, I was wondering if it would be appropriate to make 
> the rendering engine modular? I've taken this approach to some extent on the 
> Wiki I've been hacking on, and I was thinking it would be rather nice to be 
> able to change which wiki markup language is used on a wiki upon unpacking the 
> tarball: Specifically, one could have an HTML parser, so HTML could be used 
> safely, or a "standard PHPWiki" language, or the language I've used on the 
> NBTSWikiWiki (http://www.nbtsc.org/wiki), which has the goal of being almost 
> as readable unrendered as in HTML.
> 
> It's quite possible to modularize the renderer and let the user simply
> uncomment a few include lines in their wiki_config.php3 to select the wiki
> language.
> 
> Does anyone have any objection to my checking in such changes? Should I
> branch the code?
> 
> 	Aredridel
> _______________________________________________
> 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] Modularization ideas

[Aredridel N. <are...@er...>]

Jeff's OO work aside, I was wondering if it would be appropriate to make 
the rendering engine modular? I've taken this approach to some extent on the 
Wiki I've been hacking on, and I was thinking it would be rather nice to be 
able to change which wiki markup language is used on a wiki upon unpacking the 
tarball: Specifically, one could have an HTML parser, so HTML could be used 
safely, or a "standard PHPWiki" language, or the language I've used on the 
NBTSWikiWiki (http://www.nbtsc.org/wiki), which has the goal of being almost 
as readable unrendered as in HTML.

It's quite possible to modularize the renderer and let the user simply
uncomment a few include lines in their wiki_config.php3 to select the wiki
language.

Does anyone have any objection to my checking in such changes? Should I
branch the code?

	Aredridel

[Phpwiki-talk] db refactoring

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

OK, after a lot of hair pulling I've done some (imperfect) refactoring of
the database interface:

SaveCopyToArchive is now in the database libraries (out of stdlib) because
it will be implementation dependent.

I've added IsInArchive() which works the same as IsWikiPage().

RetrievePage() now takes a third argument, the table name (or page store
if you prefer). This is kind of unfortunate but can be remedied, because
SaveCopyToArchive is really just a copy now of InsertPage, and I should
have written a RetrieveCopy() instead. That is, 

InsertPage is to SaveCopyToArchive
IsWikiPage is to IsInArchive
RetrievePage stands alone

But after a day of dead ends and testing, testing, testing it will have to
wait.

index.php3 just makes one call to open the database. It doesn't matter if
the user is editing a live page or a copy. Several other pages no longer
make calls to open the database.

I've tested this new version on the DBM and Postgresql bases over and
over, and it looks good. I can load pages, edit copies, do diffs, info,
title and fulltext searches, and RecentChanges works.

Now, another thing that has really troubled me over the weekend:

On Thu, 10 Aug 2000, Jeff Dairiki wrote:

> If we are going to move to a new OO database API, it seems to me that there's
> no point in putting too much effort into implementing features in the
> old API.

I looked through the code base Jeff wrote, and it's so amazing... but it
defines 57 classes, and is quite inpenetrable! It works so well though
that it really deserves its own release.

Jeff, would you like to release this as a special verion of PhpWiki?
Perhaps a 1.3 branch? It's so far removed from the 1.1 branch that I don't
think they can be merged (which was never your goal anyway). I've really
anguished over what to do about the differences between the code bases; I
think they both deserve release. 1.1 is so close to being finished, and we
have so many ideas it's tempting to keep racing ahead, but I think that's
what happened to Project Xanadu, and they never released anything. I'm
anxious myself to start on a 2.0 code base. After today's hacking I see
the kruft creeping in everywhere in the 1.1 code.

sw


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

[Phpwiki-talk] embedded images

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

I've added a new function (a clone of LinkURL called LinkImage) to embed
images that appear as [http://foo.com/image.png]. I updated HowToUseWiki
as well.

sw

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

Re: [Phpwiki-talk] pgsql update, unifying db interface

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

Look at my new database code in the jeffs_hacks-branch.  It fully implements
MostPopular (& the link tables) both for DBM and MySQL backends.

Maybe now's the time to switch to that?  (If we don't want to deal with 
multiple
archived pages yet, we could implement a MAX_ARCHIVED_PAGES constant
to limit the number of old pages which get kept in the database (to one).)

If we are going to move to a new OO database API, it seems to me that there's
no point in putting too much effort into implementing features in the
old API.

Jeff
In message <Pin...@bo...>,Steve Wai
nstead writes:
>I'm having trouble with the DBM version because it would mean some very
>messy code; I'd have to open a file in one function and close it in
>another.
>
>It would also mean reworking index.php3 since it wouldn't have to decide
>on which db to open (there's only one). It might be simple, or there might
>be control flow problems... I'm too sleepy to think it through tonight.
>
>I have tomorrow off though and will look into it, as well as bring more
>stuff up to date for the project.

[Phpwiki-talk] pgsql update, unifying db interface

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

I've written the code for MostPopular for the Postgresql library, and it
now works/is checked in.

I'm having trouble with the DBM version because it would mean some very
messy code; I'd have to open a file in one function and close it in
another.

This is all because of SavePageToArchive, which has a call to open the
database to access the archive. We need to get rid of this; for the RDBMSs
this means a second unneeded connection to the DB.

It would also mean reworking index.php3 since it wouldn't have to decide
on which db to open (there's only one). It might be simple, or there might
be control flow problems... I'm too sleepy to think it through tonight.

I have tomorrow off though and will look into it, as well as bring more
stuff up to date for the project.

sw

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

[Phpwiki-talk] problem upgrading the live site

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

Tonight I tried to update the live site on Sourceforge, but for some
reason PhpWiki didn't see the pages in the database anymore... it tried to
reload the database and broke on a SQL error. I haven't done any more
testing yet, but thought I'd bring it up. 

sw

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

Re: [Phpwiki-talk] php mode?

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

>Jeff, can you send a URL for the php-mode extension for emacs?

Sure!

   http://www.ontosys.com/reports/PHP.html

(I think there are other implementations of php-mode out there, as well,
but don't have any first hand knowledge of them.)

Jeff

[Phpwiki-talk] php mode?

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

Jeff, can you send a URL for the php-mode extension for emacs?

thx
sw

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

Re: [Phpwiki-talk] back again

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

>Yeah, PHP has the same weakness with globals as Perl and Tcl. They are
>bothersome.

At least Perl's got modules.  Don't know about Tcl.

>>   3. Dump/load serialized (or MIME encoded) pages.  Do we need this too?
>>      My vote is no.
>
>Hmm. Iffy. Overall, I'd rather not focus too much effort on the admin
>tools.

Good, I'll ignore that.

>>   4. Dump HTML pages.  Do we need this?   I think this is a low demand item,
>>      and that it's better done with some external tool (script).
>
>Imagine a group of
>programmers, if you can, who are documenting a system. They won't want to
>ship a Wiki to the customer (sadly).

Okay, I understand the point now.  I think it should wait until after 1.2.

>OK... I'd keep the prefixes though. I think there's something about the
>way PHP does searches along the include path that any duplicate file names
>clobber each other even if they are in different directories.

I was actually thinking of not relying on a search path. Just replace
"include('wiki_stdlib.php3')" by "include('wiki/stdlib.php3')".
(Or perhaps "require('wiki/stdlib.php3')" -- any reason not to?)
(Or maybe "require('wiki/stdlib.inc')" which seems to be a more standard
naming convention --- not that it matters.)

The include path stuff, while slick, is, I think, a portability headache.
AFAIK, the path has to be set either in system config files (bad); or in 
.htaccess files, which can only be done under Apache, and then only if
things are configured correctly.

>>   PATH_INFO?  I personally don't really care if this goes into 1.2 or not
>>   (as long as it makes it in at some point.)
>
>PATH_INFO is a Good Thing because: it will make URLs a little easier to
>read, indexing by search engines a little more likely, and ... well that's
>about it. Easier for users to remember/type.

Okay I'll probably hack that in then.  Hacking in the admin browsing
is going to requires messing around with the URLs anyway.

>>   (Related to admin issue 2, above:) are we going to keep page refs in 1.2?
>
>Can't we just leave them where they are, and ignore them when exported?
>This sounds like a case of Worse Is Better. Refs work now, require no more
>thought on our part, and if they are lost when exporting to file, fine.
>Not perfect but who wants to put the effort into it?

It loses page content, seems bad.  At the very least I'd want to add the
references as "footnotes" to the bottom of the page content, so they're still
there, and can be fixed manually if desired.

I'll work on this stuff next week.

Jeff

Re: [Phpwiki-talk] back again

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

On Thu, 3 Aug 2000, Jeff Dairiki wrote:

> Sorry.  When I write new code it tends to come out that way.
> I think that some things, like the pagehashes and dbis really are 
> (already were) objects, and are best expressed explicitly that way.

Oh yes, we've gone over that previously. We're totally behind you on the
$pagehash and $dbi issues; they are objects and will benefit from OOD.

You also made it plain you were hacking experimentally, so I never
expected readable/production ready code either. No apologies needed,
because no offense was given.

> (My motivation in these cases stems mostly from my deep --- at times,
> irrational --- loathing of global namespace pollution.)

Yeah, PHP has the same weakness with globals as Perl and Tcl. They are
bothersome.

> As always, feel free to make criticisms --- and to make or suggest changes 
> --- I'm pretty thick skinned.

We'll use blunt instruments ;-)

> BTW, do you all use any auto-indentation tools?  I've been using php-mode
> in emacs, and can't get it to duplicate your style.

I use the space bar :-) But I'll check out the php-mode for Emacs since
I've been using it lately (Emacs that is).

> >of things to do is not very long. Jeff, would it be hard to hack the
> >admin design you came up with into the 1.1.7 tree?
> 
> No problem.  Tell me though: how much of the admin functionality that's
> currently in 1.1.7 do we really want?
> 
>   1. Admin browse mode: lock/unlock pages and edit locked pages.

yes...
 
>   2. Zip export.  Do you like the current zip file (MIME) format?

yep...

>   3. Dump/load serialized (or MIME encoded) pages.  Do we need this too?
>      My vote is no.

Hmm. Iffy. Overall, I'd rather not focus too much effort on the admin
tools.


>   4. Dump HTML pages.  Do we need this?   I think this is a low demand item,
>      and that it's better done with some external tool (script).

low demand; we can wait for someone to contribute it :-) But I do think
people will want static HTML snapshots someday. Imagine a group of
programmers, if you can, who are documenting a system. They won't want to
ship a Wiki to the customer (sadly).

>   5. Convert 1.0 DBMs.  Currently the code in wiki_setupwiki can load pages
>      from either a directory ("pgsrc/") or a zip file.  The source used is
>      specified by the setting of WIKI_PGSRC in wiki_config.
> 
>      My inclination is to allow WIKI_PGSRC to be set to a version 1.0 DBM as 
> well.
> 
>      I guess the question is whether there should, in addition, be some
>      method other than WIKI_PGSRC to load pages from zips/dirs/1.0DBMs.
>      I guess so.

Yeah, I can continue responsibility for 1.0 loading; backwards
compatibility is a millstone around one's neck though. (It's such a
trouble, that is).

>      Should there be a web-admin option to blow away the current database
>      contents completely?  Or should the new pages always just load over
>      the old ones, leaving the old contents in the archive?

Ouch.. never erase, would be me philosophy. We can't do the admin's job
for them, just make it easier. Loading pages should follow the same
procedure as any Wiki page insert/update. (InsertPage())

> Other issues for 1.2 (other than whats already in the TODO.)
> 
>   Move the lib files to a wiki/ subdirectory (and drop the wiki_ prefix?)
>   I think this is a win/win proposition, and we should just do it.

OK... I'd keep the prefixes though. I think there's something about the
way PHP does searches along the include path that any duplicate file names
clobber each other even if they are in different directories.
 
>   PATH_INFO?  I personally don't really care if this goes into 1.2 or not
>   (as long as it makes it in at some point.)

PATH_INFO is a Good Thing because: it will make URLs a little easier to
read, indexing by search engines a little more likely, and ... well that's
about it. Easier for users to remember/type.


>   (Related to admin issue 2, above:) are we going to keep page refs in 1.2?
>   Leave them in the database but hide them from the user?  Drop them 
> completely?
>   (My vote is leave them in the database, but hide them from the user:
>   convert them to inline links both when the page is edited, and when
>   the page is exported to a zip file.  This would ease the total abandonment
>   of page refs in 1.3 and beyond.)

Can't we just leave them where they are, and ignore them when exported?
This sounds like a case of Worse Is Better. Refs work now, require no more
thought on our part, and if they are lost when exporting to file, fine.
Not perfect but who wants to put the effort into it? Not us. We are
evolving away from Ward Cunningham's classic WikiWikiWeb.

>   I.e. I'd rather not make page refs part of the "PhpWikiZip standard" if
>   they're going to be dropped in the next version of PhpWiki.

They are going to be dropped, and you have your papal dispensation :-)

> I'm going to be on a road trip from tomorrow morning through Monday, so don't
> worry if I'm strangely silent.

Have fun! Wear your seat belt! :-)

sw

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

Re: [Phpwiki-talk] back again

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

>It is excellent work... and you're not alone when you say OOP designs are
>harder to understand. They are. 

Sorry.  When I write new code it tends to come out that way.
I think that some things, like the pagehashes and dbis really are 
(already were) objects, and are best expressed explicitly that way.
However, some of the other things which are expressed as classes in
my code could be just as clearly expressed without classes. 
(My motivation in these cases stems mostly from my deep --- at times,
irrational --- loathing of global namespace pollution.)

As always, feel free to make criticisms --- and to make or suggest changes 
--- I'm pretty thick skinned.

>When I think about PhpWiki's "usability" I think of it in three terms: 
>* And, how easy is it to understand the program design and modify it?
>(hacker usability)

I'll be the first to admit that my new code could use some documentation.
I'll work on it.  Also, I'm still uncomfortable with my new
wiki_transform/wiki_renderlib code.  I'm happy with it's functionality,
but the code is admittedly less than transparent...


Some coding standards would be good.

BTW, do you all use any auto-indentation tools?  I've been using php-mode
in emacs, and can't get it to duplicate your style.

>We will not abandon 1.1.7 (to be 1.2). I want to finish it up and the list
>of things to do is not very long. Jeff, would it be hard to hack the
>admin design you came up with into the 1.1.7 tree?

No problem.  Tell me though: how much of the admin functionality that's
currently in 1.1.7 do we really want?

  1. Admin browse mode: lock/unlock pages and edit locked pages.

  2. Zip export.  Do you like the current zip file (MIME) format?

  3. Dump/load serialized (or MIME encoded) pages.  Do we need this too?
     My vote is no.

  4. Dump HTML pages.  Do we need this?   I think this is a low demand item,
     and that it's better done with some external tool (script).

  5. Convert 1.0 DBMs.  Currently the code in wiki_setupwiki can load pages
     from either a directory ("pgsrc/") or a zip file.  The source used is
     specified by the setting of WIKI_PGSRC in wiki_config.

     My inclination is to allow WIKI_PGSRC to be set to a version 1.0 DBM as 
well.

     I guess the question is whether there should, in addition, be some
     method other than WIKI_PGSRC to load pages from zips/dirs/1.0DBMs.
     I guess so.
     Should there be a web-admin option to blow away the current database
     contents completely?  Or should the new pages always just load over
     the old ones, leaving the old contents in the archive?

Other issues for 1.2 (other than whats already in the TODO.)

  Move the lib files to a wiki/ subdirectory (and drop the wiki_ prefix?)
  I think this is a win/win proposition, and we should just do it.

  PATH_INFO?  I personally don't really care if this goes into 1.2 or not
  (as long as it makes it in at some point.)

  (Related to admin issue 2, above:) are we going to keep page refs in 1.2?
  Leave them in the database but hide them from the user?  Drop them 
completely?
  (My vote is leave them in the database, but hide them from the user:
  convert them to inline links both when the page is edited, and when
  the page is exported to a zip file.  This would ease the total abandonment
  of page refs in 1.3 and beyond.)

  I.e. I'd rather not make page refs part of the "PhpWikiZip standard" if
  they're going to be dropped in the next version of PhpWiki.


I'm going to be on a road trip from tomorrow morning through Monday, so don't
worry if I'm strangely silent.

Jeff

Re: [Phpwiki-talk] back again

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

On Thu, 3 Aug 2000, Arno Hollosi wrote:

> I'm back from my vacation.

Rested or exhausted? ;-)


> Jeff's "takeover":  :)
> Overall I agree with Steve: I've no problem with someone contributing
> much more than me or replacing my code and going into a new direction.
> Although I'm not too happy about the 100% OOP approach I think I can
> live with it once I am familiar with the code. Call me old-fashioned
> but I find OOP harder to understand than conventional code.
> I had only a brief look at the code so far. Very good work, Jeff.

It is excellent work... and you're not alone when you say OOP designs are
harder to understand. They are. Even great OOP designs; I think Netscape's
approach to the DOM via Javascript is pretty good, but it takes a long
time to understand. Perl's CGI.pm was a bad one circa 1996, but I haven't
used it since. All of the OOP code I saw at the New York Times on the Web
was pretty bad. I think procedural design can be more obvious and
intuitive, but don't get me wrong, OOP has long term benefits. LambdaMOO
programming also benefits from a really good design.

When I think about PhpWiki's "usability" I think of it in three terms: 
* How easy is it to install and start using? (admin usability)
* How easy is it to use the browser interface and navigate/add/edit? (user
usability)
* And, how easy is it to understand the program design and modify it?
(hacker usability)

> Tables, and all that fancy stuff: I don't care if this code is
> included or not, but I want an easy option to turn that fancy stuff
> off (or have it off by default). I think recreating HTML is no
> good. It's part of WikiNature to have an easy markup, which newbies
> can understand and use without reading any docs. If you want the
> HTML-like features then use HTML.

Agreed. We'll add tables I suppose. Simple tables. I vow that we will
never do nested tables; they can enable HTML in the Wiki if they want
that. 

As long as users can: write paragraphs and LinkToPages they have 90%
of what they need, and everything else in the markup language is mostly
fluff.

> Inline images:
> Please leave the markup simple. I opt for
> [http://host/inline.jpg] and http://host/as_link.jpg.
> I think it's a clear, nice, and above all easy solution.
> And no, I don't think the inconsistency with
> [http://host/is_a_link.html] hurts. ALT tag? How about just giving
> one generic ALT tag to all images? Otherwise allow HTML (see above).

Agreed. Images are a low priority, and they can enable HTML if they want.
 
> References:
> Well, I guess you know my opinion on these. I see them as burden.
> Maybe an option in wiki_config to turn them off?

Once I've hacked in [http://inlined.png] and http://linked.png, we can
either abandon them or ignore them. We'll drop them in 2.0.

> Admin as WikiPages:
> Good idea.

Yes, it's so simple and perfect I can't believe I didn't think of it!

> If I interpret the situation right, then we will abandon 1.1.7 and
> switch to Jeff's code instead, right? If that is so, is 1.1.7 in a
> state that is suitable to be left as is? Maybe someone else wants
> to take this as a base instead of Jeff's code. If we need to do some
> cleanup, then we should do it now.

We will not abandon 1.1.7 (to be 1.2). I want to finish it up and the list
of things to do is not very long. Jeff, would it be hard to hack the
admin design you came up with into the 1.1.7 tree?

I think Jeff's work may form the basis of 2.0... I want to discuss a few
coding guidelines soon, because the "code usability" is important to the
hackers out there so they can understand/extend/hack PhpWiki.

sw

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

[Phpwiki-talk] back again

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

Hi folks,

I'm back from my vacation.
Wow :o) Quite some news since I left.

Jeff's "takeover":  :)
Overall I agree with Steve: I've no problem with someone contributing
much more than me or replacing my code and going into a new direction.
Although I'm not too happy about the 100% OOP approach I think I can
live with it once I am familiar with the code. Call me old-fashioned
but I find OOP harder to understand than conventional code.
I had only a brief look at the code so far. Very good work, Jeff.
I will write another email once I've dived deeper into it.

Tables, and all that fancy stuff: I don't care if this code is
included or not, but I want an easy option to turn that fancy stuff
off (or have it off by default). I think recreating HTML is no
good. It's part of WikiNature to have an easy markup, which newbies
can understand and use without reading any docs. If you want the
HTML-like features then use HTML.

Inline images:
Please leave the markup simple. I opt for
[http://host/inline.jpg] and http://host/as_link.jpg.
I think it's a clear, nice, and above all easy solution.
And no, I don't think the inconsistency with
[http://host/is_a_link.html] hurts. ALT tag? How about just giving
one generic ALT tag to all images? Otherwise allow HTML (see above).

References:
Well, I guess you know my opinion on these. I see them as burden.
Maybe an option in wiki_config to turn them off?

Admin as WikiPages:
Good idea.

That's about it for the nitty, gritty details.
Steve said: I want PhpWiki to be the best designed, easiest to install
and most featureful Wiki out there.
Let's keep the big picture in mind. Good design means modularity, easy 
to configure, easy to administer, easy to extend. It also means good
documentation, so that other hackers out there can easily create
new modules for their needs. Eventually some of these modules will
flow back into the main distribution of phpwiki.
I'm not sure the current phpwiki rates high in all these categories.
So I suggest to focus our attention more on these issues than fancy
new features. Features will creep in without us even noticing :o)

If I interpret the situation right, then we will abandon 1.1.7 and
switch to Jeff's code instead, right? If that is so, is 1.1.7 in a
state that is suitable to be left as is? Maybe someone else wants
to take this as a base instead of Jeff's code. If we need to do some
cleanup, then we should do it now.


/Arno

p.s: Jeff wrote (about bold & italics):

> Actually, my original intent was to handle this via regexps.
> Ie. the regexp for the __Bold__ expressions should have been:
>  "__[^_'](?:[^_']+|_(?!_)|'(?!'))+(?<!_)__"
> There! Haha. Make sense?

It does. Although it saddens me to see that I can't do this:
 "__'cool'__ he said."

;-P

[Phpwiki-talk] New version on jeff_hacks-branch in CVS

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

I've checked in my latest (extensive) hacks into the jeffs_hacks-branch
of the CVS repository.

Take a look.  I'm sure there are bugs.

Jeff

Re: [Phpwiki-talk] storing diffs in the archive

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

On Fri, 28 Jul 2000, Jeff Dairiki wrote:

> Once (if) the code is working, I see reason to let paranoia be the motivation
> for saving whole pages.  I think some criteria like:
> 
>   if ( ( [number of lines in diff] < [number of lines in page] / FACTOR )
>                                          || ( version % INTERVAL != 0 ) )
>       [Save diff]
>   else
>       [Save whole page]
> 
> would work fine.

Simple solution. Hard to read though ;-)
 
> >Sure, check it into your hacks branch... I checked it out a couple of days
> >ago but was unable to make it work. I like the new switch:case in
> >index.php3.
> 
> Why wouldn't it work?  Any ideas?

Yes: Syntax error on line 286 of wiki_renderlib.php3. I tried to figure
out why it thought so but in the 5 minutes I spent it just didn't want to
instantiate any objects for some reason. (Line 286 has a call to new for
some class and the method has a comment in the param list).

> I could take them or leave them personally.  I added it is an example
> extension module.  The idea is that table support (or whatever) can be
> added by including a extension module in wiki_config.  (Same thing for
> inline HTML.)  Inline images could be done the same way.

I see. Sounds neat!
 
> Speaking of which, another way to handle the inline image idea
> is to allow <IMG> tags within the page.  (They would have to be parsed
> enough to make sure the URL's in them were sane.)

Hrmm. In the direction you are going, would it be possible to let the Wiki
admin:

* choose classic Wiki markup
* choose extended Wiki markup
* choose basic HTML
* or create their own markup

as the markup language, when the Wiki is first set up? I wouldn't want to
allow them to choose all of them necessarily, if it means conflicts and
parsing headaches.

> Yes this would require both account and session information to be stored in
> the database, but would be straightforward enough.   Then one would have the
> hooks for other fancy features like "mail me a note whenever this page 
> changes".

People have asked for that, and I think they will be less than happy if
the Wiki is really active and they get flooded... for low activity Wikis I
think that's fine, and I'd email the whole page plus the diff and a link
to edit the page, drawing them back into the Wiki.
 
> And when and if you (all) give the word I'm happy to be the one to merge my
> hacks back into the main branch.  (Either all of them or some of them.)

I'll buy you a beer someday :-)

sw

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

Re: [Phpwiki-talk] storing diffs in the archive

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

On Thu, 27 Jul 2000, Jeff Dairiki wrote:

> My guess is that you definitely don't want to apply 100 patches to go back 
> 100 versions --- I'm sure that would take a while.  Applying 10 patches is
> probably fine as long as they're reasonable size.
> 
> Now that I've thought about it awhile I don't think you'd want to store
> exclusively diffs.  I think small diffs should be stored as diffs. For bigger
> diffs (the storage gains are smaller compared the speed loss) and one might
> as well just store the whole page.   Probably there should be some limit on
> the diff chain length as well.

I've thought along similar lines; there must be a reasonable scheme where
every 10th page is whole and the rest are diffs, or author "commits" are
diffs but changes between authors are stored as whole pages.
 
> I'm a bit embarrassed to admit it but I've continued hacking here off and
> on for the past week, and have gotten PhpWiki to a totally unrecognizable 
> state.
> 
> Now, in my home version I've:
> 
>   Redone the database interface comepletely.  I've added support for
> multiple archived versions.  The links table (MySQL) is now used for
> proper and quick backlinks searches.  Of course it's object oriented.
> The schema are all changed.  MySQL and DBM backends are both working.
 
>   Then I started worrying about the user interface too. (What I've done so
> far is add a history page --- much like the info page, but more compact ---
> which lists versions, dates, authors, and has links to views and diffs of
> each version.)

too cool!

 
>   Writing all these pages and links was giving me template headaches so
> I started working on a new template scheme.  First I tried PHPlib's templates
> --- which I think have some good ideas --- but wasn't happy.  I'm pretty
> happy with what I've got now.  Almost all of the HTML and I think all
> of the output text is in the templates now.  The templates support
> conditional chunks of output and loops.
> 
> So I'm not sure any of the original (meaning 1.1.7!) code remains in
> my version.  As I said, I'm a bit embarrassed.  I certainly don't want to
> take over your project.   However, you're more than welcome to my code.

Nah, don't be embarassed! It sounds like you've added some great things.
I'd love to see it all in action.

> Let me know your level of interest.  I can either check it into the CVS,
> either in the jeffs_hacks branch, or some other new branch.   Or I get
> a tar file to you.

Sure, check it into your hacks branch... I checked it out a couple of days
ago but was unable to make it work. I like the new switch:case in
index.php3.

> Note that tables are in the jeffs_hacks-branch of the CVS already.
> The syntax (copied from some Wiki --- I can't remember which at the moment
> is
> 
> || column 1 text || column 2 text || column 3 text
> |{ left aligned text || centered text |} right aligned text
 
I guess one cannot hold back the tide ;-)

> Another interesting idea I've put into my home hacks is to do away with the
> admin page.  Instead one can browse the Wiki in admin mode (through admin.php3
> instead of index.php3).  It's identical to normal mode, except there is
> a button on each page to lock/unlock it, (and you can edit locked pages).

This is the best idea yet. It makes great sense and it would greatly
reduce the amount of code we have! I wish I'd thought of it. What I want
to add eventually is something on the level of a mailing list's
authentication: user fills out registration (just a name and email
address), a password is mailed to the account, and the user can optionally
change it down the road. This simple access allows them to edit pages. A
lot of people are sqeamish about using Wikis because they think the pages
will be erased and filled with uuencoded warez and pr0n. With version
control and auth, they have some peace of mind.

I can't speak for Arno but if all of my code is replaced, I could care
less (I will just contribute more) because I want PhpWiki to be the best
designed, easiest to install and most featureful Wiki out there, and I
want you and Arno to get all the credit for your work!

I only wish you would have made more stingent demands to objectify
pagehash and the database, and I would have listened (or should have?) 
because I want my codevelopers to be happy... instead of forking the
code... but it's never too late :-) 

sw

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

Re: [Phpwiki-talk] storing diffs in the archive

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

In message <Pin...@bo...>,Steve Wai
nstead writes:
>
>Jeff, I'm adding things to PhpWikiBrainstorm and I'm wondering.. is it
>easy to store the diffs instead of the whole pages? And would it be hard
>to iterate through the diffs and reconstitute version 5 of a page that's
>up to version 7? 10? 30?

My guess is that you definitely don't want to apply 100 patches to go back 
100 versions --- I'm sure that would take a while.  Applying 10 patches is
probably fine as long as they're reasonable size.

Now that I've thought about it awhile I don't think you'd want to store
exclusively diffs.  I think small diffs should be stored as diffs. For bigger
diffs (the storage gains are smaller compared the speed loss) and one might
as well just store the whole page.   Probably there should be some limit on
the diff chain length as well.

>I know we want to store all versions of a page for safety reasons, and I'm
>wrangling with what the user interface should look like.

I'm a bit embarrassed to admit it but I've continued hacking here off and
on for the past week, and have gotten PhpWiki to a totally unrecognizable 
state.

Now, in my home version I've:

  Redone the database interface comepletely.  I've added support for
multiple archived versions.  The links table (MySQL) is now used for
proper and quick backlinks searches.  Of course it's object oriented.
The schema are all changed.  MySQL and DBM backends are both working.

  Then I started worrying about the user interface too. (What I've done so
far is add a history page --- much like the info page, but more compact ---
which lists versions, dates, authors, and has links to views and diffs of
each version.)

  Writing all these pages and links was giving me template headaches so
I started working on a new template scheme.  First I tried PHPlib's templates
--- which I think have some good ideas --- but wasn't happy.  I'm pretty
happy with what I've got now.  Almost all of the HTML and I think all
of the output text is in the templates now.  The templates support
conditional chunks of output and loops.

So I'm not sure any of the original (meaning 1.1.7!) code remains in
my version.  As I said, I'm a bit embarrassed.  I certainly don't want to
take over your project.   However, you're more than welcome to my code.

Let me know your level of interest.  I can either check it into the CVS,
either in the jeffs_hacks branch, or some other new branch.   Or I get
a tar file to you.



Note that tables are in the jeffs_hacks-branch of the CVS already.
The syntax (copied from some Wiki --- I can't remember which at the moment
is

|| column 1 text || column 2 text || column 3 text
|{ left aligned text || centered text |} right aligned text

Jeff

Another interesting idea I've put into my home hacks is to do away with the
admin page.  Instead one can browse the Wiki in admin mode (through admin.php3
instead of index.php3).  It's identical to normal mode, except there is
a button on each page to lock/unlock it, (and you can edit locked pages).

The admin page is replaced by a regular Wiki page.  There are special
tokens like %%WikiZip%% (analagous to %%Search%%) which produce a button
which will get you a zip archive.  (There's a %%Login%% button which will
switch you to browsing through admin.php3, or you could do it by just
manually entering the url.)

[Phpwiki-talk] phpwiki patch (fwd)

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

Here is a user-contributed patch for tables... and a MySQL bug. What do
you guys think of adding tables?

sw

----

Okay, this patch includes a fix for MySQL.  it calles
set_magic_quotes_runtime(0), which was on by default in my php install,
and it broke everything.

The other few things are just feature enhancements added by me.  I added a
history to the top (check http://crunchydog.adhesive.com/wiki), and I
also added a way to make tables too, this may be a little too complicated
for the tidy stripped-down mark-up language you've created, but here's an
example:

^^
^Cell 1|Cell 2|Cell 3$
^Cell 1|Cell 2|Cell 3$
$$

Anyway, you're free to use any or all of this stuff if you'd like.


                -- Hawk Newton

--
Hawk Newton RHCE                           ha...@ad...
Adhesive R&D                               512-647-1200
Adhesive Software                          http://www.adhesive.com