phpwiki-talk

Re: [Phpwiki-talk] one more feature...

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

Hi Steve,

 > ... I'd like to add is the ability to link ISBN numbers. I think the
 > regexp for this might be on c2.com; I was browsing there today looking for
 > something and saw mention of a page with regular expressions for common
 > Wiki patterns.

Where would ISBN numbers link to?
Or are they just pagenames as well?

 > I am thinking next of compiling Apache/PHP4/mSQL and writing a
 > wiki_msql.php3 for that (maybe it's time to rename all the files to just
 > wiki_something.php).

I guess we can postpone this renaming until 1.2
(ok, I'm a lazy bastard who doesn't want to change his apache config
just yet)


Btw, I've just renamed pageviewer.php3 as wiki_pageinfo.php3.
It now is called from index.php3 and uses template 'MESSAGE'.
See [more info] link at the bottom of each page :o)

I'm going to have a look at mySQL now.

/Arno

[Phpwiki-talk] one more feature...

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

... I'd like to add is the ability to link ISBN numbers. I think the
regexp for this might be on c2.com; I was browsing there today looking for
something and saw mention of a page with regular expressions for common
Wiki patterns.

This is not high priority obviously but I think it's a Good Thing.

sw

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

[Phpwiki-talk] postgresql support

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

Basic Postgresql support is now complete, except for one little bug:
searches are all case sensitive. Anyone know a way around this?

I've ported all the functions (OpenDataBase, InsertPage, InitTitleSearch
and so on) and have a Wiki running quite nicely here on my home box.

The schema I'm using is in phpwiki/schemas/schema.psql, and it looks good
so far. I am thinking next of compiling Apache/PHP4/mSQL and writing a
wiki_msql.php3 for that (maybe it's time to rename all the files to just
wiki_something.php).

sw

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

Re: [Phpwiki-talk] rollout of 1.1.6

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

On Wed, 21 Jun 2000, Arno Hollosi wrote:

>  > * in a DBM-based Wiki, call dump.php3.
> 
> can be in a mysql or pgsql wiki as well - I don't see any problems

Yes, this was just an example. It would port any database to any database.

I think in the long run it would be used the most for DBM -> RDBMS though
(as people upgrade their installations);  DBM files are a great way to
start off, and for small Wikis they are sufficient, but as traffic rises
you really want the stability and efficiency of a SQL database. 

> How about having the page source in files like /pgsrc and one additional file
> that contains serialized data structures (in the 1.1.6 format)?

That would be even simpler... I'll only have to write one dump.php3 file
:-)

> On a side note: the file names have to be escaped in some way.
> The new naming scheme allows arbitrary characters and some
> filesystems don't allow that. Know of any good escaping scheme,
> short of naming the files 1,2,3,4,5,6, ....

Would rawurlencode() work?

> (I thought of something like using a special character, say ','
> and escape any odd characters with their decimal value, e.g.
> the name "you \\don't// hear, do you?" would be saved as
> "you ,92,,92,don,39,t,47,,47, hear,44, do you,63,"
> I guess you can see why this might not be a good solution)

There's probably no clean solution to this. Anyways people should
StickWithTheNamingConvention :-)

sw

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

Re: [Phpwiki-talk] rollout of 1.1.6

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

 > > - add the ability to dump the contents of a wiki into files like in /pgsrc
 > > - add the ability to dump from 1.0.x and 1.1.y wikis to 1.1.6 format.

 > * in a DBM-based Wiki, call dump.php3.

can be in a mysql or pgsql wiki as well - I don't see any problems
here. Just call RetreivePage and store it in a file.

 > * Choose between saving the page source only (like the files in pgsrc/),
 > or as serialized data structures (preserving all page information).

How about having the page source in files like /pgsrc and one additional file
that contains serialized data structures (in the 1.1.6 format)?

 > * call load.php3 to load pages; choose whether they are page source or
 > serialized hashes in files

No need to create a new file - just instruct wiki_setupwiki.php3 to
look for that additonal file and read in the serialized data and fill
the newly created structures not with defaults but with values from
that file.

 > * load the database, checking for each file whether it has all 8
 > attributes (lastmodified, refs, created, version, etc) and add defaults if
 > they are not there

 > * go have coffee and relax

Nice idea - we should add this to the README :o)

On a side note: the file names have to be escaped in some way.
The new naming scheme allows arbitrary characters and some
filesystems don't allow that. Know of any good escaping scheme,
short of naming the files 1,2,3,4,5,6, ....
(I thought of something like using a special character, say ','
and escape any odd characters with their decimal value, e.g.
the name "you \\don't// hear, do you?" would be saved as
"you ,92,,92,don,39,t,47,,47, hear,44, do you,63,"
I guess you can see why this might not be a good solution)

 > what do you think about
 > making the schema for the ARCHIVE table the same as for WIKI?

No problem. As you say: it saves code. It's always better to
have easy manageable code.

/Arno

Re: [Phpwiki-talk] rollout of 1.1.6

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

On Tue, 20 Jun 2000, Arno Hollosi wrote:

> - incorporate pageviewer.php3 into the regular wiki setup (via placeholder)
>   e.g. at the bottom of the page: (last updated 1 Mar 2000 [more info])
>   the "more info" link leads to the pageviewer of that particular page
>   (placeholder e.g. ###INFOURL###?###PAGEURL###)
>   (note: pageviewer itself should use the MESSAGE template)

Interesting; when I started writing pageviewer.php3 I only wanted a
debugging tool for developers... I didn't think about making it available
to end users.

It should be renamed then to wiki_pagestructure.php3 or something similar
for consistency.

> 
> - add the ability to dump the contents of a wiki into files like in /pgsrc
> - add the ability to dump from 1.0.x and 1.1.y wikis to 1.1.6 format.
>   (in both cases the reload could be done by simply putting the result 
>   into /pgsrc and starting over again. In 1.1.6, we may or may not
>   lose additional information like version number, last modified, ...

Yes, was thinking about this last night. The algorithm would be:

* in a DBM-based Wiki, call dump.php3.
* Choose between saving the page source only (like the files in pgsrc/),
or as serialized data structures (preserving all page information).
* Dump the pages
* Edit wiki_config.php3, switching databases
* call load.php3 to load pages; choose whether they are page source or
serialized hashes in files
* load the database, checking for each file whether it has all 8
attributes (lastmodified, refs, created, version, etc) and add defaults if
they are not there
* go have coffee and relax


> - resolve the LostUpdate-bug when editing a copy of the page where
>   (version_wiki - version_copy) != 1

ok

> - resolve the EditCopy link appearance -- maybe we don't need the
>   ###IFCOPY### placeholder at all - I don't like that placeholder.

ok, this is in TODO

> - implement the new db schema in mySQL (only tables wiki & archive).
>   (my task)

Question: (I think I already emailed you on this) what do you think about
making the schema for the ARCHIVE table the same as for WIKI? I think this
might save us some code writing since InsertPage and RetrievePage can work
on both tables.

> 
> 1.1.5 was announced on freshmeat 10 days ago.
> I guess it doesn't hurt if 1.1.6 takes some more days.

Seems longer ago than that! :-)

sw


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

Re: [Phpwiki-talk] rollout of 1.1.6

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

Hi,

 > I'd like to roll out 1.1.6 soon, and put it up live on Sourceforge. Any
 > comments? I think the theme-ability is a big thing and worthy of a
 > freshmeat posting alone.

I'd like to see the following going into 1.1.6
(this shouldn't be too much work and can be done within two, three days):

- incorporate pageviewer.php3 into the regular wiki setup (via placeholder)
  e.g. at the bottom of the page: (last updated 1 Mar 2000 [more info])
  the "more info" link leads to the pageviewer of that particular page
  (placeholder e.g. ###INFOURL###?###PAGEURL###)
  (note: pageviewer itself should use the MESSAGE template)

- add the ability to dump the contents of a wiki into files like in /pgsrc
- add the ability to dump from 1.0.x and 1.1.y wikis to 1.1.6 format.
  (in both cases the reload could be done by simply putting the result 
  into /pgsrc and starting over again. In 1.1.6, we may or may not
  lose additional information like version number, last modified, ...

- resolve the LostUpdate-bug when editing a copy of the page where
  (version_wiki - version_copy) != 1

- resolve the EditCopy link appearance -- maybe we don't need the
  ###IFCOPY### placeholder at all - I don't like that placeholder.

- implement the new db schema in mySQL (only tables wiki & archive).
  (my task)


1.1.5 was announced on freshmeat 10 days ago.
I guess it doesn't hurt if 1.1.6 takes some more days.

/Arno

[Phpwiki-talk] rollout of 1.1.6

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

I'd like to roll out 1.1.6 soon, and put it up live on Sourceforge. Any
comments? I think the theme-ability is a big thing and worthy of a
freshmeat posting alone.

People keep trying to use new features on sourceforge (that's a 1.03 wiki)
and I'd like to give them the ability to try things like the new linking
scheme and such.

sw

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

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