phpwiki-talk

Re: [Phpwiki-talk] some bugs

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

Hi Arno!

Did you forget to cvs add the templating stuff? I can't check it out, and
I get:


[snip]
Warning: File("templates/browse.html") - No such file or directory in
wiki_stdlib.php3 on line 28

Warning: Bad arguments to join() in wiki_stdlib.php3 on line 28
[snip]


when I try to run my copy of PhpWiki. 

> full text search & dbm: try searching for "eat".
> All pages get listed. Reason: fieldname "cr_eat_ed"
> dbm search should limit its search to the actual content.

OK, not a show stopper but it needs fixing.

> edit copy: the logic when to show the EditCopy link is flawed.
> I think the link should always be shown.
> Example: I edit page PAGE, screw up, but save anyway
> Upon seeing the new PAGE I realize my error
> I would like to undo my error by using EditCopy
> ->currently not possible

Good point. Let's start a TODO list in the project to add these things,
and keep it in CVS as well.

> I.e. only because I'm the last one who has edited PAGE I'm not allowed 
> to access the archived version? Why?
> (note: the way pages get stored in the archive prevents any abuse)

Right... while it's important that the current editor of the page be
prevented from erasing the previous copy there's no reason why we can't
give her read-only access to retrieve it. 

 
> And my LostUpdate fix doesn't handle EditCopy cases correctly.
> It assumes that only one version has been created since the archived
> version. Which is of course an invalid assumption, as a single author
> might create multiple revisions (e.g. editing -> finding mistake ->
> editing again).
> 
> I was too lazy to fix this now.
> 
> See "FIXME" notes in wiki_savepage.php3

I have the current version from CVS but I don't find 'fixme' anywhere
(maybe you need to check in changes?). Then again I've been teaching
myself Emacs and maybe I don't use ^s properly. ;-)

I like the function you added to the pageviewer, but we should agree on a
place to put functions in pages instead of the middle (CVS merged its copy
with mine; I was playing with it last night trying to get the Postgres
version of InsertPage to work). Anyway, my preference is for function
definitions to go at the bottom of the source file (like having your
"main" at the top). I'll entertain arguments to the contrary... doesn't
PHP demand the function be defined before it's used?

sw


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

[Phpwiki-talk] some bugs

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

Steve,

while doing the template stuff I came across some bugs:

full text search & dbm: try searching for "eat".
All pages get listed. Reason: fieldname "cr_eat_ed"
dbm search should limit its search to the actual content.

edit copy: the logic when to show the EditCopy link is flawed.
I think the link should always be shown.
Example: I edit page PAGE, screw up, but save anyway
Upon seeing the new PAGE I realize my error
I would like to undo my error by using EditCopy
->currently not possible

I.e. only because I'm the last one who has edited PAGE I'm not allowed 
to access the archived version? Why?
(note: the way pages get stored in the archive prevents any abuse)

And my LostUpdate fix doesn't handle EditCopy cases correctly.
It assumes that only one version has been created since the archived
version. Which is of course an invalid assumption, as a single author
might create multiple revisions (e.g. editing -> finding mistake ->
editing again).

I was too lazy to fix this now.

See "FIXME" notes in wiki_savepage.php3

/Arno

Re: [Phpwiki-talk] Templates in phpWiki?

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

Hi there,

I just added support for HTML templates.
Check out the latest CVS version.
I will write up a short README for templates soon.


Niklas wrote:
 > 	- Use *this* form for writing bold text
 > 	- And _this_ form for writing italics
 > 	- Numerical references like this[1: http://www.test.com]

Currently we think about using "__markup like this__" for bold text
and " ''markup like this'' " for italics.

The reason is: italics is often used when quoting something, so
using '' makes sense. Emphasis like bold can either be done like "__"
or like "**" - we use "__" because "**" can conflict with bulleted lists.

Using single characters ("_", "*", "'") is not a good idea, as these
characters may appear in text too. Doubling them makes their function
clearer. Also, it makes the markup more visible during editing.

/Arno

[Phpwiki-talk] Templates in phpWiki?

[Niklas E. <el...@he...>]

Hi!

Thanks for a great WikiWikiClone, I'm just wondering whether you are
planning to support HTML templates for the pages in phpWiki? That would be
great and make it easy to customize your Wiki for a specific site.

Also, DolphinWiki has a few nice features that I think phpwiki could
benefit from:

	- Use *this* form for writing bold text
	- And _this_ form for writing italics
	- Numerical references like this[1: http://www.test.com]

Sorry if I've misunderstood anything.

best,
Nick

 ------[ Niklas Elmqvist <el...@he...> ]-------
        System Administrator, Chalmers Studenthem

[Phpwiki-talk] Recent changes in code

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

I thought I should forwarn everyone I changed all instances of the word
"text" to "content" to match the new database schema. This might break
your PhpWiki install if you run your Wiki off your CVS copy.

I did a clean install of phpwiki to ensure the changes worked, and they
did.

This might make backwards compatibility with existing PhpWikis moot... but
it can be remedied.

Also, I added two new php files for test purposes: pageviewer.php3 is for
viewing the details of a page, and test_dbmlib.php3, which should provide
a general diagnostic tool for database porters.

sw

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

[Phpwiki-talk] 1.1.5 released finally

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

Version 1.1.5 is out and should appear on Freshmeat by tomorrow.

sw

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

Re: [Phpwiki-talk] bugfix, db schema, thoughts on navigation

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

On Sat, 10 Jun 2000, Arno Hollosi wrote:

> Btw, the whole issue about "[" is pretty much a usability nightmare.

No surprise, again... from now on you can just describe them to me if you
wish, and I'll try to wrap my brain around them. We agree that freeform
links aren't necessarily good for a Wiki, but some people want them and I
was curious to experiment with it.

I have been planning on bracketing the code in if() {} statements, and
users can configure the Wiki to allow them. (It should ship with them
turned off by default). Also I want to use your regexps for a
Mor3F3x1bl3 l1nKing5tyl3. :-)

> I.e. "[[ some text \n more text]" renders as "[["  (\n = linebreak)

Too bad for the user, linebreaks aren't supported in any Wiki, are they?
;-)

> But getting to the point:
> I guess we should set us some achievable goals for the 1.2 release so
> that we don't wander around aimlessly. Also, we should consider not to 
> overdo it, as too much functionality is not a good thing.
> 
> The way I see things, the main goal for 1.2 is the new DB schema and
> the slew of functionality this entails.

Yes, that was my intention for the most part; in fact I want to make it
even easier and say that 1.2 is the release with the (almost) normalized
database schema, and even the new functionality can wait until we're sure
the old code base is stable on top of the new DB libraries. 1.2.1 could
have more features, if we wish; but I would make the short list to be:

1. New schema implemented
2. New linking optional, disabled by default
3. Old Wiki code base (the display) is stable
4. Old linking revisions: (I may need clarification on this)
  Images just need a URL in brackets []
  Arno's Wiki linking also in brackets [] (will this collide with 
  freeform linking?)
5. Some markup changes, like: ordered and unordered lists use *, **, ***
instead of tabs (blockquotes will have to be revised too), _bold_, etc.
(I'll have to go through the mail to see what we discussed.)

If we have the new pages (MostLinkedTo, MostEdited etc) then all the
better.


> 
> CREATE TABLE wiki (
> 	pagename VARCHAR(100) NOT NULL,
> 	version INT NOT NULL DEFAULT 1,
> 	flags INT NOT NULL DEFAULT 0,
> 	author VARCHAR(100),
> 	lastmodified INT NOT NULL,
> 	created INT NOT NULL,		# optional
> 	content MEDIUMTEXT NOT NULL,
> 	refs TEXT,			# refs are serialized
> 	PRIMARY KEY (pagename)
> 	);
> 
> CREATE TABLE archive (
> 	pagename VARCHAR(100) NOT NULL,
> 	content MEDIUMTEXT NOT NULL,
> 	refs TEXT,
> 	author VARCHAR(100),		# I guess those two columns
> 	lastmodified INT NOT NULL	# are nice to have
> 	PRIMARY KEY (pagename)
> 	);
> 
> CREATE TABLE wikilinks (
> 	frompage VARCHAR(100) NOT NULL,
> 	topage VARCHAR(100) NOT NULL,
> 	PRIMARY KEY (frompage, topage)
> 	);
> 
> CREATE TABLE hottopics (		# optional table
> 	pagename VARCHAR(100) NOT NULL,
> 	lastmodified INT NOT NULL
> 	PRIMARY KEY (pagename, lastmodified)
> 	);
> 
> CREATE TABLE hitcount (			# optional table
> 	pagename VARCHAR(100) NOT NULL,	# hits are in separate table in
> 	hits INT NOT NULL DEFAULT 0,	# order to avoid locking our
> 	PRIMARY KEY (pagename)		# main wiki table
> 	);
> 
> 

OK, let's consider this the signoff on the new schema. Nicholas suggests,
and I also had considered, allowing "appending" to a page instead of
edting it, which would absolve concurrency problems; so we might want to
add another table (version 1.4, say) where a page's appends go to, and
optionally they can be merged with the main page; but maybe that's overly
optimistic.

> What about categories and paths?

> While I'm still pretty fond of paths I'm not sure about
> categories anymore. The more I think about them, the more I dislike
> them. If people feel they really need them, they can create them
> easily by what is already provided through wiki. Adding a formal

True; in fact, you can do _anything_ in a Wiki if enough people agree to
that social convention. RoadMaps and StartingPoints are good examples of
this; after the pages and discussions mature, a human draws a map showing
people how to navigate it. We can get the machine to extract more meaning
from what's there, but ultimately a Wiki is a social space for humans and
it needs humans to give it meaning.

Categories are not on the list for 1.2, and I need to find out more about
how they are implemented and used anyway.

> I envision wiki more like a cloud, where several paths lead into it
> and the deeper you go, the more misty it becomes, and soon you wander
> off your path following hyperlinks. Sure, it's unstructured, it's
> chaotic. But to that end: use your browsers back button. Or
> alternatively, the wiki could give you a cookie and create a map of
> pages visited on the fly. Better yet, try to come up with a
> search not based on words, but on links (and the pagerank) that
> shows you related or important pages within reach.
> Navigation like this is far more useful than trying to press a highly 
> dynamic site into rigid categories.

Very poetic :-)

> p.s. I'm gone for the weekend - so don't be suprised if I don't
> answer emails until Wednesday.

Have a nice weekend! I'll roll out 1.1.5 if I can.

sw

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

[Phpwiki-talk] bugfix, db schema, thoughts on navigation

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

Hi,

just uploaded another fix for obscure "[[link] [link]" problem.

Btw, the whole issue about "[" is pretty much a usability nightmare.
I.e. "[[ some text \n more text]" renders as "[["  (\n = linebreak)
"[[ some text more text]" renders as "["
"] text [[" renders as "[",
"[[text] [[more here" renders as "["+"[[".
All this is pretty inconsistant. Also, it's impossible to have "]"
within "[[]" or "[]" for that matter. (I know the regexps, so need to
tell me why phpwiki behaves so weird :o)

But getting to the point:
I guess we should set us some achievable goals for the 1.2 release so
that we don't wander around aimlessly. Also, we should consider not to 
overdo it, as too much functionality is not a good thing.

The way I see things, the main goal for 1.2 is the new DB schema and
the slew of functionality this entails.
Templates are nice, but don't have high priority. Especially I think
that using something similar to free-energy is overkill. We don't need 
more than a simple replacement of placeholders, do we?

So here's again the current state of the db schema:

CREATE TABLE wiki (
	pagename VARCHAR(100) NOT NULL,
	version INT NOT NULL DEFAULT 1,
	flags INT NOT NULL DEFAULT 0,
	author VARCHAR(100),
	lastmodified INT NOT NULL,
	created INT NOT NULL,		# optional
	content MEDIUMTEXT NOT NULL,
	refs TEXT,			# refs are serialized
	PRIMARY KEY (pagename)
	);

CREATE TABLE archive (
	pagename VARCHAR(100) NOT NULL,
	content MEDIUMTEXT NOT NULL,
	refs TEXT,
	author VARCHAR(100),		# I guess those two columns
	lastmodified INT NOT NULL	# are nice to have
	PRIMARY KEY (pagename)
	);

CREATE TABLE wikilinks (
	frompage VARCHAR(100) NOT NULL,
	topage VARCHAR(100) NOT NULL,
	PRIMARY KEY (frompage, topage)
	);

CREATE TABLE hottopics (		# optional table
	pagename VARCHAR(100) NOT NULL,
	lastmodified INT NOT NULL
	PRIMARY KEY (pagename, lastmodified)
	);

CREATE TABLE hitcount (			# optional table
	pagename VARCHAR(100) NOT NULL,	# hits are in separate table in
	hits INT NOT NULL DEFAULT 0,	# order to avoid locking our
	PRIMARY KEY (pagename)		# main wiki table
	);



What about categories and paths?
There's a simplistic approach to both of them - similar to the way
c2-wiki currently realizes categories through backlinks.
While I'm still pretty fond of paths I'm not sure about
categories anymore. The more I think about them, the more I dislike
them. If people feel they really need them, they can create them
easily by what is already provided through wiki. Adding a formal
category mechanism creates more trouble than benefits. Just have a
look at c2.com: the most compelling "category" pages are not those lists 
of backlinks, but pages like e.g. ExtremeProgrammingRoadmap.
(Actually, the same might hold true for paths, I'm not sure yet)

I envision wiki more like a cloud, where several paths lead into it
and the deeper you go, the more misty it becomes, and soon you wander
off your path following hyperlinks. Sure, it's unstructured, it's
chaotic. But to that end: use your browsers back button. Or
alternatively, the wiki could give you a cookie and create a map of
pages visited on the fly. Better yet, try to come up with a
search not based on words, but on links (and the pagerank) that
shows you related or important pages within reach.
Navigation like this is far more useful than trying to press a highly 
dynamic site into rigid categories.

I guess I stop my rant here. I've rewritten the above paragraphs five
or six times - so you owe me to read them at least twice and spend
some time thinking about them ;o)


/Arno

p.s. I'm gone for the weekend - so don't be suprised if I don't
answer emails until Wednesday.

[Phpwiki-talk] sourceforge slowness

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

Well, I can't overwrite the older phpwiki-1.1.5.tar.gz I uploaded so it
may have to wait one more day until they clear out the incoming directory.
No big deal. I'll keep an eye on it.

sw

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

Re: [Phpwiki-talk] phpwiki-1.1

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

I deleted the v1_1_5 tag; I will adhere to the convention:

release-x_x_x

from now on...

sw

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

Re: [Phpwiki-talk] phpwiki-1.1

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

On Thu, 8 Jun 2000, Arno Hollosi wrote:

> I think we should agree on how to form tag names.
> You labeled it v_1_1_5 whereas I tagged previous releases as release-1_1_4

Yeah, I noticed this afterwards too :-/

> You tagged the whole thing BEFORE updating the HISTORY file, thus if
> you ship 1.1.5 it will be different from the 1.1.5 from CVS. I think
> you should redo the tag on HISTORY once you've updated it.

Doh! Well I never said I was perfect ;-)
 
> On a side note, I would have liked to get in a minor change before 1.1.5.
> (rename columns from data to hash -- data is a reserved word in mySQL
> and mySQL version 3.21 chokes on it.)

OK, I will hold off. Go to it.

> mySQL seems stable as well.

rock and roll
sw

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

Re: [Phpwiki-talk] phpwiki-1.1

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

Steve,

 > I've added a "phpwiki-1.1" "project" to the PhpWiki site.

ok.

 > I think I will now get a clean copy of the current CVS tree (if I can
 > figure out how to tag it 1.1.5)

I think we should agree on how to form tag names.
You labeled it v_1_1_5 whereas I tagged previous releases as release-1_1_4

 > and make sure the HISTORY file is close to
 > correct, and announce 1.1.5.

You tagged the whole thing BEFORE updating the HISTORY file, thus if
you ship 1.1.5 it will be different from the 1.1.5 from CVS. I think
you should redo the tag on HISTORY once you've updated it.

On a side note, I would have liked to get in a minor change before 1.1.5.
(rename columns from data to hash -- data is a reserved word in mySQL
and mySQL version 3.21 chokes on it.)

 > It seems stable for DBM, I don't have MySQL

mySQL seems stable as well.

/Arno

Re: [Phpwiki-talk] Re: MySQL schema (fwd)

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

Hi there,

Steve wrote:
 > > lastmodified is a unix time stamp (seconds since 1.1.1970)
 > I wonder, is this really better than using whatever DATE type 
 > there is that's native to the RDBMS? I do agree it's more portable.
 > (Will it work on NT? I never expected to support NT ;-)

It works on NT, because PHP's time() returns a unix time stamp.
Better than using DATE: I think yes. mySQL only recently supports date 
arithmetic, I don't know about mSQL. At least one server I deal with
has the slightly older mySQL version without date arithmetic.
Consider this example from HotTopics: pages are removed when
lastmodified < time() - 60*60*24*7  -- looks pretty, no?

 > > hits counts how many times this pages has been accessed (optional)
 > Interesting... I had thoughts about using a seperate table for logging --
 > Thoughts?

Might be actually better using a separate table, also I would do
something like this and use update instead of insert:

CREATE TABLE hottopics (
	pagename VARCHAR(100) NOT NULL,
	hits INT DEFAULT 0,
	PRIMARY KEY (pagename)
	);

We don't need to scale beyond 1 mio hits/month, so the performance
difference between update & insert is moot. I would use a different
table, as updating causes table locks. Don't know if this could be an
issue. If it is, I don't want to lock the main table.


 > Another feature I'd like to see, which I think you just thought of, is
 > "this page has been checked out" but does not necessarily prevent it from
 > being edited. If you decide to edit a page you might get a message like
 > "this page was checked out at Thu Jun 8 00:04:26 EDT 2000 by 127.0.0.1".
 > That would clue the user that their edits might be lost, or they might
 > erase someone else's edits. 

Edits are no longer lost - we already have a patch in place.
Notification would be possible. Although, what are the chances that
edits are lost? How often has this happend on your wikis?
Anyway, I guess this needs another table (or column in table wiki)
Time limit: 15min?

 > > CREATE TABLE archive (
 > > 	pagename VARCHAR(100) NOT NULL,
 > > 	content MEDIUMTEXT NOT NULL,
 > > 	PRIMARY KEY (pagename)
 > > 	);
 > > 
 > > Notes: archive can be either the bare minimum necessary (like above)
 > > or a complete copy of table wiki. A slightly extended version might
 > > include the following columns:
 > > 	author VARCHAR(100),
 > > 	lastmodified INT NOT NULL
 > 
 > I think we do need author, because the way pages go into the archive
 > is one of the defense mechanisms of the Wiki: 

You should have a look at your own code sometime :o)
This defence mechanism relies on the author in table wiki not in archive.
However, if archive stores more than one version I guess it would be
intersting to have the additonal information provided by author and
lastmodified.


 > I would like to see a Wiki where all previous
 > versions of the page are stored as diffs, but I have no desire to
 > reimplement "diff" in PHP. Perhaps the last ten versions? Five?

Yea, diff within PHP would be nifty. Of course, one could call the
shell tool, but that makes it less portable. I even had a look at
GNU diff's sources: ouch - much too complicated to do even an easy
version in PHP.


 > I like this, and I think it's a good first cut. A feature I've been asked
 > for is "Categories," which is a feature of another Wiki (Zwiki I think)
 > which somehow helps searches.

I assume that the EditText page would have a separate input field for
the category? I wouldn't make the category logic too complex. Basic
stuff is sufficient. I assume that part of wiki's appeal lies in its
chaotic nature - a too rigid structure wouldn't fit well.
Also, I would like to see 'Paths' or tracks/trails or whatever you call them.
Prev/next/up buttons should be dynamically created.


 > Also I think you mentioned somewhere about just throwing the references 
 > in one column, and I think that's satisfactory.

Fine.

/Arno

[Phpwiki-talk] phpwiki-1.1

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

I've added a "phpwiki-1.1" "project" to the PhpWiki site. This is just a
convenience for downloading the software. Since I wasn't 100% certain
about what I was doing, I uploaded the old 1.1.4 which still has the
broken search.

I know that sucks, but I was trying to figure out the difference between:
"project" as in the PhpWiki project versus "projects" within the PhpWiki
project versus "modules" which can be assigned "tasks." From what I
gather:

Overall, there is the PhpWiki "project" which can contain "projects" 
(which can be associated with "modules") which can have a set of "tasks"
defined for it (a "to-do" list in other words). 

I think I will now get a clean copy of the current CVS tree (if I can
figure out how to tag it 1.1.5) and make sure the HISTORY file is close to
correct, and announce 1.1.5. It seems stable for DBM, I don't have MySQL
installed and since neither of you has complained much I take it it works
fine with the old schema ;-)

sw

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

Re: [Phpwiki-talk] themes

[Nicholas R. <nic...@sy...>]

the source is here, the folks at http://Working-Dogs.com use it a lot it
seems

'My experience with FreeEnergy has resulted in a substantial increase in
productivity. If you wish to experiment with this model, I've provided a
minimal set of files with this article, fe.tar.gz. I can also recommend a
project I lead called FreeTrade, which uses FreeEnergy as the basis of an
ecomm toolkit. This project shows the difficulty we faced with PHP 3's
include functionality. In its next incarnation, we plan to move to a PHP
4-only code base that will take full advantage of the new include behavior.'

download GPL source here
http://www.leonatkinson.com/downloads/fe.tar.gz

Leon Atkinson seems to be something of a PHP Guru

----- Original Message -----
From: Steve Wainstead <sw...@wc...>
To: Nicholas Roberts <nic...@sy...>
Cc: Arno Hollosi <aho...@in...>; <php...@li...>
Sent: Thursday, June 08, 2000 2:32 PM
Subject: Re: [Phpwiki-talk] themes


>
> Yes, I think we can mine something from this. If there are drop-in PHP
> templating systems out there (must be GPL though) I'd like to consider it.
>
>
>
>
> On Wed, 7 Jun 2000, Nicholas Roberts wrote:
>
> > useful, will send a digest soon
> > http://www.zend.com/zend/art/free-energy.php
> >
> >
> > _______________________________________________
> > 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
>
>

Re: [Phpwiki-talk] themes

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

Yes, I think we can mine something from this. If there are drop-in PHP
templating systems out there (must be GPL though) I'd like to consider it.




On Wed, 7 Jun 2000, Nicholas Roberts wrote:

> useful, will send a digest soon
> http://www.zend.com/zend/art/free-energy.php
> 
> 
> _______________________________________________
> 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 

Re: [Phpwiki-talk] Re: MySQL schema (fwd)

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

looking good, Arno, a few questions...

On Wed, 7 Jun 2000, Arno Hollosi wrote:

> CREATE TABLE wiki (
> 	pagename VARCHAR(100) NOT NULL,
> 	version INT NOT NULL DEFAULT 1,
> 	flags INT NOT NULL DEFAULT 0,
> 	author VARCHAR(100),
> 	lastmodified INT NOT NULL,
> 	created INT NOT NULL,		# optional
> 	hits INT NOT NULL DEFAULT 0,	# optional
> 	content MEDIUMTEXT,
> 	PRIMARY KEY (pagename)
> 	);
> 
> Notes:
> lastmodified is a unix time stamp (seconds since 1.1.1972)

I wonder, is this really better than using whatever DATE type 
there is that's native to the RDBMS? I do agree it's more portable.
(Will it work on NT? I never expected to support NT ;-)

> hits counts how many times this pages has been accessed (optional)

Interesting... I had thoughts about using a seperate table for logging --
I've read about this somewhere, using MySQL for web server logging -- and
that means only doing inserts for the most part as opposed to updates,
which I think are more expensive (but that's probably implementation
dependent.)

Thoughts?

> flags contains a variety of indicators, possible flags are
> e.g. "locked page", "has references", ...

Another feature I'd like to see, which I think you just thought of, is
"this page has been checked out" but does not necessarily prevent it from
being edited. If you decide to edit a page you might get a message like
"this page was checked out at Thu Jun 8 00:04:26 EDT 2000 by 127.0.0.1".
That would clue the user that their edits might be lost, or they might
erase someone else's edits. 

> 
> CREATE TABLE wiki_refs (

more on this in a moment...

> 
> CREATE TABLE wiki_links (
> 	frompage VARCHAR(100) NOT NULL,
> 	topage VARCHAR(100) NOT NULL,
> 	PRIMARY KEY (frompage, topage)
> 	);

I see where this is going, and I'm down with it... (that is, 
I like it :-)

> CREATE TABLE archive (
> 	pagename VARCHAR(100) NOT NULL,
> 	content MEDIUMTEXT NOT NULL,
> 	PRIMARY KEY (pagename)
> 	);
> 
> Notes: archive can be either the bare minimum necessary (like above)
> or a complete copy of table wiki. A slightly extended version might
> include the following columns:
> 	author VARCHAR(100),
> 	lastmodified INT NOT NULL

I think we do need author, because the way pages go into the archive
is one of the defense mechanisms of the Wiki: 

User A saves, copy goes to archive
User B saves, copy goes to archive
User B erases page, laughs maniacally, but 
       since User B made the last save, it did not go into the archive
User A restores the page from archive

I have found this invaluable in restoring pages, although I have
encountered:

User A wipes page
User B wipes page
Steve tries to restore but only gets User A's wiped page

so it's not fullproof. I would like to see a Wiki where all previous
versions of the page are stored as diffs, but I have no desire to
reimplement "diff" in PHP. Perhaps the last ten versions? Five?
 
> I am not too happy about using pagename as foreign key in other
> tables. Indexing and looking up text is not fast. Instead a unique
> page id should be used. However, this creates problems with
> wiki_links, i.e. how do you store links to pages not yet created?

Well, how much traffic does a Wiki need to support? One of the appeals to
me of a Wiki is that it's a small thing, and to a degree we don't have to
worry much about performance. I still do though, I want it to be
efficient, but I'm not going to make it hard to code, maintain and extend
just to eek out more performance that might not be needed... if a Wiki
ever got the traffic Slashdot got it would probably be ruined in short
order as 20 people try to save changes to the FrontPage at the same time.
So I think using the page name is OK. 

 
> Optional feature: HotTopics
> 
> There are other ways to implement HotTopics as well. If you can come
> up with something better let me know.

I like this, and I think it's a good first cut. A feature I've been asked
for is "Categories," which is a feature of another Wiki (Zwiki I think)
which somehow helps searches.
 
> One way to have global persistent variables is to store them in the
> database as well. Something along the lines like:
> 
> CREATE TABLE globalvars (
> 	name varchar(100) NOT NULL,
> 	value varchar(255),
> 	PRIMARY KEY (name)
> 	);

If PHP cannot do this for us, then the database will do fine. I know 
mod_perl has some hook where you can load a module at server boot time
and it holds data structures that all processes can access (though I'd 
imagine there are concurrency problems with this arrangement.)

Also I think you mentioned somewhere about just throwing the references 
in one column, and I think that's satisfactory. It shouldn't take up
much of our coding time and if someone doesn't like it they can 
provide a patch :-)

We can just serialize/unserialize the refs as needed. Noone is going to
search them.

sw


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

[Phpwiki-talk] source software

[Nicholas R. <nic...@sy...>]

it might be useful to see how these folks are solving the category problem
etc
http://www.working-dogs.com/freeassociation/

[Phpwiki-talk] LostUpdateProblem fixed & some other stuff

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

Hi there,

I added a patch for the LostUpdateProblem just now.
It ignores EditLinks though.

Also, RecentChanges now indicates newly created pages with '(new)'.

On a side note:
Could we move some stuff out of wiki_stdlib.php3?
I would suggest to move the following:
	- UpdateRecentChanges() to wiki_savepage
	- SetHTMLOutputMode(), $stack, and ParseAndLink() to
	  wiki_display

Reason: functions are only used in those files and somehow belong
there. Also, wiki_stdlib is included for every hit and these changes
would make it smaller & less expensive.

Also, I would suggest that we redefine the directives for
the search boxes from [Search] and [Fullsearch] to something like
%%Search%% and %%Fullsearch%% - seems cleaner this way and frees
up those names as page names. Also, we can add new directives later on 
without having to worry about side effects.

On a related note: I don't like using ''' for bold. It may be the
"standard" way, but it's odd. For one thing you can't do things like:
''emphasis this '''bold text''' correctly'' easily. Plus you have to
type 6 chars. Actually, in textual conversation three ways to
emphasize text have gained popularity:
emphasis like *this* and like _this_ and like THIS.
Writing in caps is out of question, *this* may become a nightmare
because of using '*' for lists, but _this_ seems sensible. In order to 
be able to use '_' within text we just use '__' as markup.
The above problematic sentence thus would read:
''emphasis this __bold text__ correctly''
Looks natural to me and solves many regexp problems.
Comments?

Should I include a patch that limits chars within "[]"?
(option through wiki_config)


Footnote on the mySQL schema: while writing the patch for LostUpdate
I came accross those references again. Do we really perform such
sophisticated actions on those refs that the overhead of using a
separate table is justified? Thinking about it again I would suggest:
dropping the wiki_refs table and instead add a column refs to the wiki
table. Yes, it's not 100% normalized but I think it serves our purposes
well (and better than a separate table). This column would be included
in the archive table as well.


/Arno

P.S: Nicholas, I'm from Graz, Austria.

Re: [Phpwiki-talk] themes

[Nicholas R. <nic...@sy...>]

useful, will send a digest soon
http://www.zend.com/zend/art/free-energy.php

Re: [Phpwiki-talk] Re: MySQL schema (fwd)

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

'lo,

I've spent some time on the new database schema.
This is my first proposal.


CREATE TABLE wiki (
	pagename VARCHAR(100) NOT NULL,
	version INT NOT NULL DEFAULT 1,
	flags INT NOT NULL DEFAULT 0,
	author VARCHAR(100),
	lastmodified INT NOT NULL,
	created INT NOT NULL,		# optional
	hits INT NOT NULL DEFAULT 0,	# optional
	content MEDIUMTEXT,
	PRIMARY KEY (pagename)
	);

Notes:
lastmodified is a unix time stamp (seconds since 1.1.1972)
created is the creation date of the page (optional)
hits counts how many times this pages has been accessed (optional)
flags contains a variety of indicators, possible flags are
e.g. "locked page", "has references", ...


CREATE TABLE wiki_refs (
	pagename VARCHAR(100) NOT NULL,
	version INT NOT NULL,
	refnum INT NOT NULL,
	ref VARCHAR(255) NOT NULL,
	PRIMARY KEY (pagename, version, refnum)
	);

CREATE TABLE wiki_links (
	frompage VARCHAR(100) NOT NULL,
	topage VARCHAR(100) NOT NULL,
	PRIMARY KEY (frompage, topage)
	);

CREATE TABLE archive (
	pagename VARCHAR(100) NOT NULL,
	content MEDIUMTEXT NOT NULL,
	PRIMARY KEY (pagename)
	);

Notes: archive can be either the bare minimum necessary (like above)
or a complete copy of table wiki. A slightly extended version might
include the following columns:
	author VARCHAR(100),
	lastmodified INT NOT NULL


I am not too happy about using pagename as foreign key in other
tables. Indexing and looking up text is not fast. Instead a unique
page id should be used. However, this creates problems with
wiki_links, i.e. how do you store links to pages not yet created?


Optional feature: HotTopics
HotTopics are pages that were edited frequently over the past days.
Time span can be anything from one week to one month, depending on how 
active the wiki is.

CREATE TABLE hottopics (
	pagename VARCHAR(100) NOT NULL,
	lastmodified INT NOT NULL
	PRIMARY KEY (pagename, lastmodified)
	);

How this works: every time a page is edited an entry in hottopics is
created. The page HotTopics then makes the SQL query
"select pagename, count(*) as edits from hottopics group by pagename"
additionaly a limit can be added to the query e.g. "limit 25".
This table has to be pruned. As we don't want to use an outside
facility like a crontab entry, we use HotTopics as well. Everytime
the page is accessed we perform a
"delete from hottopics where lastmodified < $time"
$time being the unix time stamp that defines the time span.
If deleting is expensive and HotTopics is accessed a lot, then
some kind of global persistent variable holds the time hottopics was
last pruned and pruning is limited to once a day - the check for this
remains in HotTopics.

There are other ways to implement HotTopics as well. If you can come
up with something better let me know.

One way to have global persistent variables is to store them in the
database as well. Something along the lines like:

CREATE TABLE globalvars (
	name varchar(100) NOT NULL,
	value varchar(255),
	PRIMARY KEY (name)
	);


I guess this is enough food for thought.
Comments?

/Arno

[Phpwiki-talk] PHP4 new features

[Nicholas R. <nic...@sy...>]

we should look at the new features of PHP4, it may have some solutions to
our problems...
http://www.zend.com/zend/whats-new.php

Re: [Phpwiki-talk] themes

[Nicholas R. <nic...@sy...>]

PhpWiki is basically HTML embedded in PHP code, very often its the other way
around (especially in websites built by design-agencies ie ColdFusion, JSP
etc). As Arno has pointed-out the template should be HTML with PHP embedded
in it...

whats this a global flu? Steve's in NYC, Arno (?) I'm in Sydney and was
attacked last week...

I found half a doxen double vodkas and orange, a stupid movie like MI-2
(Sydney stupididty) and an early night killed my virus...

-N

----- Original Message -----
From: Arno Hollosi <aho...@in...>
To: <php...@li...>
Sent: Wednesday, June 07, 2000 6:25 PM
Subject: Re: [Phpwiki-talk] themes


>
> Steve,
>
> I guess you are too fixed on the functions themselves.
> Themes are usually done by using templates, i.e. files which
> have placeholders for the dynamic content.
>
> In the current version of phpwiki following templates are needed:
> browsing, edittext, editlinks, thanks-for-editing, search-results
>
> Placeholders needed are:
> %SCRIPT% ... URL of phpwiki script
> %TOPIC% ... page title
> %ENCTOPIC% ... URL-encoded page title
> %TEXT% ... page content (HTML, wiki markup, search results, ...)
> %LASTMODIFIED% ... 7 June, 2000 (or whatever)
> %REFERENCEx% ... for editlinks
>
> a simple template for e.g. browsing could look like:
>
> ----- browsing.html -----
>
> <html><head><title>phpwiki: %TOPIC%</title></head>
> <body><h1><A HREF="%SCRIPT%?full=%ENCTOPIC%">%TOPIC%</A></h1>
> %TEXT%
> <hr>
> <A HREF="%SCRIPT%?edit=%ENCTOPIC%">Edit this page</A>
> (last edited %LASTMODIFIED%)
> <A HREF="%SCRIPT%?FindPage">FindPage</A> by browsing or searching
> </body></html>
>
> ----- end of browsing.html -----
>
> You then have one function (the one that prints the final HTML)
> that reads in the template and replaces everything.
> If you are fancy, you can even provide a hook that allows
> knowledgeable admins to add their own placeholders. (Actually that
> should be quite easy.)
>
> How about that?
>
> I could cook up something like that in the next days, as I have some
> time due to illness too :(
>
>
>  > I don't feel like commiting this.
>
> That brings up a question I'd like to ask: is there a clean way to
> share "experimental" code through the CVS? The only way I can think of
> is creating branches, but I don't know if this is a good solution.
>
> On a side note: how about releasing a 1.1.5 version?
> (before the template stuff) 1.1.4 is just too buggy to keep around.
>
> /Arno
>
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> http://lists.sourceforge.net/mailman/listinfo/phpwiki-talk
>

Re: [Phpwiki-talk] themes

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

Steve,

I guess you are too fixed on the functions themselves.
Themes are usually done by using templates, i.e. files which
have placeholders for the dynamic content.

In the current version of phpwiki following templates are needed:
browsing, edittext, editlinks, thanks-for-editing, search-results

Placeholders needed are:
%SCRIPT% ... URL of phpwiki script
%TOPIC% ... page title
%ENCTOPIC% ... URL-encoded page title
%TEXT% ... page content (HTML, wiki markup, search results, ...)
%LASTMODIFIED% ... 7 June, 2000 (or whatever)
%REFERENCEx% ... for editlinks

a simple template for e.g. browsing could look like:

----- browsing.html -----

<html><head><title>phpwiki: %TOPIC%</title></head>
<body><h1><A HREF="%SCRIPT%?full=%ENCTOPIC%">%TOPIC%</A></h1>
%TEXT%
<hr>
<A HREF="%SCRIPT%?edit=%ENCTOPIC%">Edit this page</A>
(last edited %LASTMODIFIED%)
<A HREF="%SCRIPT%?FindPage">FindPage</A> by browsing or searching
</body></html>

----- end of browsing.html -----

You then have one function (the one that prints the final HTML)
that reads in the template and replaces everything.
If you are fancy, you can even provide a hook that allows
knowledgeable admins to add their own placeholders. (Actually that
should be quite easy.)

How about that?

I could cook up something like that in the next days, as I have some
time due to illness too :(


 > I don't feel like commiting this.

That brings up a question I'd like to ask: is there a clean way to
share "experimental" code through the CVS? The only way I can think of 
is creating branches, but I don't know if this is a good solution.

On a side note: how about releasing a 1.1.5 version?
(before the template stuff) 1.1.4 is just too buggy to keep around.

/Arno

[Phpwiki-talk] themes

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

I spent a little time tonight trying to think of a way to make theme
changes easier. A good starting place is the horrendous looking
WikiToolBar() (what was I thinking when I coded this? Probably that I
wouldn't have to be bothered with it again :-)

_________________________________________________________
   function WikiToolBar() {
      global $ScriptUrl, $pagename, $pagehash;
      $enc_name = rawurlencode($pagename);

      $retval  = "<hr>\n" .
		 "<a href=\"$ScriptUrl?edit=$enc_name\">EditText</a>\n" .
		 " of this page\n";
      if (is_array($pagehash)) {
         $retval .= " (last edited " . $pagehash["date"] . ")\n";
      }
      $retval .= "<br>\n" .
		 "<a href=\"$ScriptUrl?FindPage\">" .
		 "FindPage</a> by browsing or searching\n";
      return $retval;
   }
----------------------------------------------------------

PHP definitely has its limitations in this department. My solution
tonight, through the haze of NyQuil and aspirin and orange juice and tea,
was to move all this into a new file in a new directory,
"elements/wiki_toolbar.inc". After some cleanup I got this:

___________________________________________________________
<?
      // set up variables for display

      $enc_name = rawurlencode($pagename);
      if (is_array($pagehash)) {
         $last_edit = " (last edited " . $pagehash["date"] . ")\n";
      }

?>

<hr>
<a href="<? 
   echo "$ScriptUrl?edit=$enc_name"; 
?>">EditText</a> of this page

<? echo "$last_edit"; ?>

<br>
<a href="<? echo "$ScriptUrl"; ?>?FindPage">FindPage</a> by browsing 
or searching
------------------------------------------------------------

This isn't much better. When it comes to fine-grained mixing of PHP and
HTML, the end result is uglier than a modern strip mall.

I don't feel like commiting this. Any suggestions? If I go this route, the
three functions WikiHeader, WikiToolBar, and WikiFooter will be replaced
by .inc files. The other thing I don't like is having file names hardcoded
all over the place, so all three would have to be defined in
wiki_config.php3 as well.

sw


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