phpwiki-talk

[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

[Phpwiki-talk] storing diffs in the archive

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

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?

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.

sw

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

Re: [Phpwiki-talk] Change in embedded image procedure

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

On Wed, 19 Jul 2000, Jeff Dairiki wrote:

> On a related note: what about trying to phase out the page references
> altogether?  As far as I can see (except for the case of inlined
> images) [1] with the appropriate entry in the page references is
> identical in function to [1|http://www.foo.bar/wazoo.html].

Good point. Again, references were something we inhereted from classic
Wiki. Arno made a good case to drop them when we started out on 1.1, but I
was stubborn because some people use and like them (that is, people that
emailed me, not my imaginary friends ;-)

I am intrigued however by a change Ari made in the NBTSC PhpWiki where
references are no more, they are instead "footnotes" in the classic sense:
http://www.nbtsc.org/wiki/MarkupTest

I haven't read the code for this yet. Whether it has value or not, I don't
know, but it looks cool at least :-)

Another reason I had was that references are the way to embed images... so
in the end the compomise we made was to jam the references in one column
and get a D- in database design. I guess I was also enamored with
backwards compatibility.

> If you're going to invent new syntax, how about something that doesn't
> create any more special characters.  Maybe something like
> 
>   [ INLINE | alt text | http://foo.com/img.png ]
> 
> Yeah, it's ugly.  There's probably something better.
> 
> A couple of things to think about:
> 
> To by lynx friendly, it would be nice to be able to specify ALT text 
> for an inlined image.
> 
> One of the reasons I personally don't use the wiki inlined images very
> much is that there's currently no way to specify the image size.
> With my browser, that means I don't get to see any of the page until
> the image loads.  I hate that.
> 
> One could create syntax for specifying image size:
> 
>   [ INLINE 20x60 | alt text | http://foo.com/img.png ]
> 
> Or to get fancy, one might be able to have PhpWiki fetch the image
> once (in a while) and cache the size.

Ugh. I should start a WikiPage on ReinventingHtml. How about no embedded
images? :-)

sw 

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

Re: [Phpwiki-talk] New transform code.

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

Just catching up on the week's posts...

On Tue, 18 Jul 2000, Jeff Dairiki wrote:

>   1. Transform "''"s
>   2. Transform "'''"s
>   3. Transform "__"s
>   4. Transform "''"s again
>   5. Transform "'''"s again
> 
> This, I think, handles everything that your method does (while eliminating
> the possibility of invalid HTML output.)

Hmm. Don't forget ''''' :-)

sw

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

[Phpwiki-talk] auth problems (fwd)

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

Michael wrote me with problems using the admin/ tools... he was just
getting a server error. It looks like some weirdness with his server
configuration, and he ultimately did away with wiki_auth.php3 and
installed his own .htaccess file.

sw

> > >2. If I try to start /admin/index.php3 I get an "error 500: intern
> > >server error".
> >
> > No solution.
>
> Hmm. It will try to do basic HTTP authentication, promting you for a
> login/password. I wonder if your version of Apache has auth enabled?
>
> You could try commenting out the block that tries to authenticate you
> and see if you can access the forms... that would be a big help if we
> knew to look for this.

Now it works.

1. My ISP has only .php3, not .php included for running PHP. I have
altered the file names etc.
2. If I insert a blank line before the first line in admin/index.php3 I
don't get the error 500 (strange???)
3. I don't get a prompt for the password, so I think my ISP don't has
auth enabled.
4. I have wiki_auth..php3 commented out and a .htaccess included in the
admin directory - no sloppy systems administration ;)
5. The directories in wiki_config.php3 don't work for admin/php3. I have
included a $AdminArchiveDataBase with a "../" before the path from
$ArchiveDataBase.

Thank you for the hints. It was a big help!

best regards

Michael d. Eschner




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

Re: [Phpwiki-talk] New transform code.

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

I've cleaned up the new wiki_transform code somewhat.  I'm still
tokenizing the __bold__ and ''italic''s, but I think I've found a
cleaner way around the "recursable" problem.

I've also added support for pagenames in $PATH_INFO
(configurable in wiki_config with the WIKI_PAGENAME_IN_PATHINFO
constant.)

I've created a new branch ("jeffs_hacks-branch") in the CVS repository
which contains both of these hacks.  (To get it, you need
to add the '-rjeffs_hacks-branch' option to the 'cvs checkout' command.)

Comments are hereby solicited.

Jeff

[Phpwiki-talk] off the net mostly

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

I'll be off the net most of Thursday-Monday, while I'm in Cleveland for a
wedding. Just so you know if I'm not at all responsive :-)

sw

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

Re: [Phpwiki-talk] Change in embedded image procedure

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

On a related note: what about trying to phase out the page references
altogether?  As far as I can see (except for the case of inlined
images) [1] with the appropriate entry in the page references is
identical in function to [1|http://www.foo.bar/wazoo.html].

Now...

In message <Pin...@bo...>,Steve Wai
nstead writes:
>But unnamed, bracketed image links do:
>
>[http://phpwiki.sourceforge.net/phpwiki/png.png]
>
>Does anyone see any obvious flaws to this?

Nothing terrible.  But it sort of breaks my intuitive feeling that
[http://foo/bar.png] should be equivalent to http://foo/bar.png in
the same way that [WikiWord] is equivalent to WikiWord.


> Would you rather introduce a
> new construct, which might be more intuitive, like:
>
>{http://phpwiki.sourceforge.net/phpwiki/png.png}

If you're going to invent new syntax, how about something that doesn't
create any more special characters.  Maybe something like

  [ INLINE | alt text | http://foo.com/img.png ]

Yeah, it's ugly.  There's probably something better.

A couple of things to think about:

To by lynx friendly, it would be nice to be able to specify ALT text 
for an inlined image.

One of the reasons I personally don't use the wiki inlined images very
much is that there's currently no way to specify the image size.
With my browser, that means I don't get to see any of the page until
the image loads.  I hate that.

One could create syntax for specifying image size:

  [ INLINE 20x60 | alt text | http://foo.com/img.png ]

Or to get fancy, one might be able to have PhpWiki fetch the image
once (in a while) and cache the size.



In other news.  The CVS problem appears to be fixed.  You can now
check out (or otherwise use) named revisions.

I've mostly finished hacking in PATH_INFO support (switchable in
wiki_config.)  Soon (probably tomorrow) I'll check it into a branch
("jeffs_pathinfo_hacks-branch") in the CVS so y'all can inspect it.

Jeff

[Phpwiki-talk] Change in embedded image procedure

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

I helped a PhpWiki user/operator with the hairy process of embedding an
image file (which requires the use of "references"). This reminded me of a
small change I was thinking of some time ago and I want everyone's
feedback before I put it in place: 

Raw URLs do not get embedded:

http://phpwiki.sourceforge.net/phpwiki/png.png

Named URLs do not get embedded:

[Check out this great art|http://phpwiki.sourceforge.net/phpwiki/png.png]

But unnamed, bracketed image links do:

[http://phpwiki.sourceforge.net/phpwiki/png.png]

Does anyone see any obvious flaws to this? Would you rather introduce a
new construct, which might be more intuitive, like:

{http://phpwiki.sourceforge.net/phpwiki/png.png}

?

The latter approach means that the use of [] is consistent.

sw

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