phpwiki-talk

Re: [Phpwiki-talk] RFC: 1.1.6b doesn't add pages

[<Mar...@t-...>]

Hi,

> Are you trying to use the same database? The schema changed from 1.1.5 to
> 1.1.6. Page data is now written to columns instead of storing everything
> in one serialzed hash.
This is just fixed, thanks Arno.

> I am working on a new script that might help you move your pages from
> 1.1.5 to 1.1.6, if you are concerned about saving them.
Yes, I really appreciate the idea. Otherwise I have to load and copy all of the 1.1.5 Wiki pages on the next 
weekend :-)

	- Markus


---
BITPlan GmbH smart solutions - Meerbuscher Str. 58-60 - 40670 Meerbusch-Osterath 
Tel +49 2159 5236-0 - Fax +49 2159 5236-10 - mg...@bi... - http://www.bitplan.de

Home Office: Markus Guske - Erftstrasse 17 - D-41564 Kaarst
Tel +49 173 946 1880 - Fax +49 2131 769-195 - mg...@gu...

Re: AW: [Phpwiki-talk] RFC: 1.1.6b doesn't add pages

[<Mar...@t-...>]

Hi,

[...]
> 1.1.6 was released without serious testing.
It doesn't matter. Hope I will find most of them :-)

> The fix for your problem is most likely the following:
> 
> Add the following in wiki_savepage.php3 around line 39 
Thanks it works!!!

> for other known errors and their cure see:
> http://phpwiki.sourceforge.net/1.1.6/index.php3?Known%20bugs%20in%201.1.6
That's a good point :-) I just bookmarked these pages.

Sorry for the delay, but I found no time to check it out (the work).

Again thank you for the support,

	- Markus

P.S.: I love this tool it helps me and my friends to save a lot of time!!! I stay tuned.


---
BITPlan GmbH smart solutions - Meerbuscher Str. 58-60 - 40670 Meerbusch-Osterath 
Tel +49 2159 5236-0 - Fax +49 2159 5236-10 - mg...@bi... - http://www.bitplan.de

Home Office: Markus Guske - Erftstrasse 17 - D-41564 Kaarst
Tel +49 173 946 1880 - Fax +49 2131 769-195 - mg...@gu...

Re: [Phpwiki-talk] New PhpWiki on Sourceforge

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

On Mon, 3 Jul 2000, Jeff Dairiki wrote:

> I just checked a new wiki_diff.php3 into the CVS repo.  It's faster
> than the previous one (which did turn out to be an issue.)  Also I've
> added the compose() (and reverse()) method to class WikiDiff, so it's all
> ready to be used in a full versioning system.

Great work! :-)
 
> "All" that needs to be done now is to fix the db access API and schema so
> that multiple backup versions can be saved.  I can work on that (particularly
> for the MySQL and DBM drivers) if I'm not stepping on any toes.

Not at all. I think that when a project stops refactoring code because the
developer whose code gets changed throws tantrums is the day that project
dies. Always feel free to question design choices; I do :-)

For the record I also want total versioning down to the first version.
However the point I differ on (my personal opinion) is that storage space
is cheap, Wikis are just text, so why not save the whole thing? Not every
little edit change though. Let me explain.

Right now we have a store of live pages and a store of their last version. 
When a new author saves the page the new version goes live, the current
live page goes into the archive, and the last version is lost forever.

What if the last version is not lost, but stays in the archive? We have
all the previous versions by the previous authors; little edits the
current author makes don't get archived (I know when I edit a Wiki page I
make at least two saves and usually more). How much room does this take
up?

A fairly long page on c2.com is http://c2.com/cgi-bin/wiki?LordOfTheFlies.
It's 14234 according to Netscape. Let's say the page is very active, and
there are 100 edits over its lifetime... that's over a meg of data. That's
probably a worst case senario; most pages don't see that much activity.

Another good yard stick is Ari's Wiki. It's using 23 megs right now, and
because DBM files keep every copy they ever had, and Ari's wiki is
*really* active, I think that's pretty good in terms of space (sadly, all
previous versions are lost in the DBM file).

Now, how much work is it to:

* Store only the diffs of the pages
* Recombine them when someone wants to see the differences between version
1.1 and version 1.99?

If it's not much work at all (on the programmer (Jeff :-) and the server) 
then I think only storing diffs is a Good Thing. If 50-100 megs for a Wiki
sounds accessive, storing only diffs is a Good Thing. If the problem is
also one that simply interests you and you don't care what benefit it has
for PhpWiki it's also probably a Good Thing (for you :-) 

I think we can stick with the "archive" table for this and the user will
see no changes in behavior, other than being able to retrieve any
previos version of the page.

I am going to go into this more in a separate post, but first I have to
check with my friends to see if we are still going to see the fireworks. I
had jury duty last week and took one of my favorite Wiki idea books along,
Jon Udell's "Practical Internet Groupware." (See my review at
http://www.amazon.com/exec/obidos/ASIN/1565925378/qid%3D962757399/104-0556265-3752700) 
. It gave me an epiphany regarding saving versions...

sw

p.s. my other favorite idea book is Philip and Alex's Guide to Web
Publishing, which is more of an opinion book than a technical book:
http://www.amazon.com/exec/obidos/ASIN/1558605347/qid%3D962757580/104-0556265-3752700

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

Re: [Phpwiki-talk] lock pages & co

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

On Wed, 5 Jul 2000, Arno Hollosi wrote:

> I just committed the following changes:
> 
> - some bug fixes
> - added GetAllWikiPageNames($dbi) for mySQL
> - dumpserial & loadserial now rawurlen/decode() the filename
> - added support for locked pages

All now live on http://phpwiki.sourceforge.net/phpwiki/ too

 
> Editing locked pages doesn't work yet.
> This is because $ScriptURL points to admin/index.php3 instead of
> the main index.php3. I ugly hack would be to str_replace /admin/ with ""
> But we aim for better solutions, don't we?
> Note: if ServerAddress is set manually and not by the if/else clause,
> then editing works. Comment out the part from wiki_lockpage and try it out.

Hrm. I was reading Ari's code over the weekend (Ari simply emailed me a
login/passwd to the server, very generous!) and he (she?) uses $PHP_SELF
now... dunno if that will be any help here. Ari also uses $PATH_INFO for
the page name instead of the CGI variables, so right off when we want to
change from using CGI srings to pathinfo we have a conversion function we
can borrow.

> Also, ###LOGO### doesn't work from inside admin/ when using templates.
> This is because there's no absolute path used in the default config.

Oh, did you add templating to the admin forms? (looks...) Oh, you must
mean when you edit a locked page... that won't herald the end of the earth
fortunately ;-)

> So, lock pages works more or less.
> It's not 100% secure though -- to make it water-proof one would have
> to test in save_page as well. But I didn't bother right now. I mean,
> what are the odds, that someone is going to do some URL hacking?

Famous last words ;-)

And besides I don't know how much louder I can scream "it's BETA!"

sw


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

[Phpwiki-talk] lock pages & co

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

I just committed the following changes:

- some bug fixes
- added GetAllWikiPageNames($dbi) for mySQL
- dumpserial & loadserial now rawurlen/decode() the filename
- added support for locked pages

Editing locked pages doesn't work yet.
This is because $ScriptURL points to admin/index.php3 instead of
the main index.php3. I ugly hack would be to str_replace /admin/ with ""
But we aim for better solutions, don't we?
Note: if ServerAddress is set manually and not by the if/else clause,
then editing works. Comment out the part from wiki_lockpage and try it out.

Also, ###LOGO### doesn't work from inside admin/ when using templates.
This is because there's no absolute path used in the default config.

So, lock pages works more or less.
It's not 100% secure though -- to make it water-proof one would have
to test in save_page as well. But I didn't bother right now. I mean,
what are the odds, that someone is going to do some URL hacking?

/Arno

Re: [Phpwiki-talk] New PhpWiki on Sourceforge

[J C L. <cl...@ka...>]

On Tue,  4 Jul 2000 22:10:17 +0200 (MEST) 
Arno Hollosi <aho...@in...> wrote:

>> Perhaps I should restate my original post.  What I listed are
>> some of the things I'll be doing.  I'm starting from a base of
>> PHPWiki.

> Understood - I thought commenting from our standpoint makes sense
> in order to help you see differences and common ground.

Oh, absolutely, and I agree.  That was the intent of my original
post -- to see if there was some basis of cooperation between the
two projects given that they share a common root.

<bow>

> I now better understand the intent of your changes. Quite
> intersting.  Actually, I'm all in favour of wiki taking over the
> web :o)

<dissemble>  
Well, umm, golly gosh.
</dissemble>

Actually the intent of this project from my end is to act as the
foundation for what in essence becomes a human-centric knowledgebase
where the concentration is on individual evaluation and
discrimination among items without distinction between original
items and meta-items.

>> Agreed.  When viewed a particular way what I'm really doing is
>> adding the ability for the author of a WikiItem to define an
>> explicit context for his WikiItem (as versus being a purely
>> abstracted node)

> I'm sure you have looked at the node typing of everything2?  Some
> good ideas in there too.

Actually, until you mentioned it, no.  Yes, some very good ideas in
there.  That's going to take some study.  Thanks!

-- 
"Finally coming home"                       Home: cl...@ka...
J C Lawrence                               Other: co...@ka...
----------(*)                     Keys etc: finger cl...@ka...
--=| A man is as sane as he is dangerous to his environment |=--

[Phpwiki-talk] some thoughts on structure

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

Hi all,

ever since Steve forwarded Ari's email to the list I've been thinking
about restructuring phpwiki.

Here are some thoughts/questions:

- the db interface will become very large. I realized that when I
  added functions for MostPopular. For every such query we need
  two new functions. I don't like this.
  Possible solution: all search functions return a $pagehash array.
  For some searches the hash may only be sparsely populated, e.g.
  when doing a title or mostpopular search, it's unnecessary to
  set $pagehash['content'].
  There could be one general NextMatch function in this case.
  For the DBM interface that might be impossible - maybe that function
  has to have a switch() structure of some kind.

- template facility:
  wouldn't it be neat to be able to add new placeholders and their
  functions by simply including a program file with that additional
  functionality?
  this can either be done by having those placeholders and functions
  added to an array or by implementing them as objects:
  a base-class for placeholders, which contains
  the name of the placeholder and a function call. That function call
  is overloaded by actual implementations of placeholder-objects.
  A template class that does the translation from $content to $html.
  Placeholder objects register with that class, and then get called
  from there.

- the same could be used for wiki_transform.
  Maybe the array (class) also has to provide priorities, so that
  some functions are executed before others are.

The above would implicitly define APIs for phpwiki modules.
The actual core could be reduced in size, while modules could simply
extend the functionality by adding their functions to provided hooks.

This needs some discussion first, as it would be a major modification, 
but I think it's Very Nice (tm).

I think Ari came up with something similar (more or less), so we could 
learn (read: copy ;o) a lot from his code.

What do you think?

/Arno

Re: [Phpwiki-talk] New PhpWiki on Sourceforge

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

 > I just checked a new wiki_diff.php3 into the CVS repo.  It's faster
 > than the previous one (which did turn out to be an issue.)  Also I've
 > added the compose() (and reverse()) method to class WikiDiff, so it's all
 > ready to be used in a full versioning system.

Great.

 > "All" that needs to be done now is to fix the db access API and schema so
 > that multiple backup versions can be saved.
 > I can work on that (particularly for the MySQL and DBM drivers) if
 > I'm not stepping on any toes.

You won't be stepping on mine and I'm sure Steve doesn't ind either.
Go ahead :o)

 > > >   -- Inter-version colourised diff-style views available of edited pages
 > >
 > >Nice gimmick. Maybe Jeff is willing to implement this.
 > 
 > Unless I misunderstand, this is there now (in the CVS version.)

Your latest changes are indeed a step torwards that direction.
What I was thinking about is, e.g. diffs of version 5 against version 17
(not only version 16 against 17).

Also, I understood the above as a diff page, that looks like the original
wiki page (through wiki_transform), only with the diff changes highlighted
inside the wiki-page.
Currently wiki_diff shows diffs from the wiki source markup.

I'm ok with that. The other way would need some major
modifications to wiki_transform and some to wiki_stdlib and I don't
really think it's necessary. THere are more important things to be
implemented.

/Arno

Re: [Phpwiki-talk] New PhpWiki on Sourceforge

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

 > Perhaps I should restate my original post.  What I listed are some
 > of the things I'll be doing.  I'm starting from a base of PHPWiki.

Understood - I thought commenting from our standpoint makes sense in
order to help you see differences and common ground.

I now better understand the intent of your changes. Quite intersting.
Actually, I'm all in favour of wiki taking over the web :o)

 > Agreed.  When viewed a particular way what I'm really doing is
 > adding the ability for the author of a WikiItem to define an
 > explicit context for his WikiItem (as versus being a purely abstracted
 > node)

I'm sure you have looked at the node typing of everything2?
Some good ideas in there too.

/Arno

Re: [Phpwiki-talk] New PhpWiki on Sourceforge

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

Arno Hollosi writes:
> J C writes:
>
> >   -- Page histories with prior versions view available (encluding
> >      ownership changes).
>
>We already have a diff in 1.1.6 - only the prior version though.
>I assume that eventually this will develop into a full versioning system.

(Erratum: As of now diff is only in the CVS version, not 1.1.6(b).)

I just checked a new wiki_diff.php3 into the CVS repo.  It's faster
than the previous one (which did turn out to be an issue.)  Also I've
added the compose() (and reverse()) method to class WikiDiff, so it's all
ready to be used in a full versioning system.

"All" that needs to be done now is to fix the db access API and schema so
that multiple backup versions can be saved.  I can work on that (particularly
for the MySQL and DBM drivers) if I'm not stepping on any toes.

> >   -- Inter-version colourised diff-style views available of edited pages
>
>Nice gimmick. Maybe Jeff is willing to implement this.

Unless I misunderstand, this is there now (in the CVS version.)  You can
try it out on http://phpwiki.sourceforge.net/1.1.6/ (standard diff version)
or http://www.dairiki.org/HammondWiki/ (unified diff version).

Jeff

Re: [Phpwiki-talk] New PhpWiki on Sourceforge

[J C L. <cl...@ka...>]

<<Sorry, I accidentally screwed the addressing ont he first copy>>

On Mon, 03 Jul 2000 15:46:00 -0700 
J C Lawrence <cl...@ka...> wrote:

> Agreed.  When viewed a particular way what I'm really doing is
> adding the ability for the author of a WikiItem to define an
> explicit for his WikiItem (as versus being a purely abstracted
> node), and for others to then explicitly place that WikiItem and
> others in new contexts without invalidating or altering the
> original context, and to then allow those contexts to be
> manipulated as definitions in their own rights.

There's a missing word in the second sentence.  It should read:

  When viewed a particular way what I'm really doing is adding the
  ability for the author of a WikiItem to define an explicit
  __CONTEXT__ for his WikiItem (as versus being a purely abstracted
  node), and for others to then explicitly place that WikiItem and
  others in new contexts without invalidating or altering the original
  context, and to then allow those contexts to be manipulated as
  definitions in their own rights.

-- 
"Finally coming home"                       Home: cl...@ka...
J C Lawrence                               Other: co...@ka...
----------(*)                     Keys etc: finger cl...@ka...
--=| A man is as sane as he is dangerous to his environment |=--

Re: [Phpwiki-talk] New PhpWiki on Sourceforge

[J C L. <cl...@ka...>]

On Mon, 03 Jul 2000 15:46:00 -0700 
J C Lawrence <cl...@ka...> wrote:

> Agreed.  When viewed a particular way what I'm really doing is
> adding the ability for the author of a WikiItem to define an
> explicit for his WikiItem (as versus being a purely abstracted
> node), and for others to then explicitly place that WikiItem and
> others in new contexts without invalidating or altering the
> original context, and to then allow those contexts to be
> manipulated as definitions in their own rights.

There's a missing word in the second sentence.  It should read:

  When viewed a particular way what I'm really doing is adding the
  ability for the author of a WikiItem to define an explicit
  __CONTEXT__ for his WikiItem (as versus being a purely abstracted
  node), and for others to then explicitly place that WikiItem and
  others in new contexts without invalidating or altering the original
  context, and to then allow those contexts to be manipulated as
  definitions in their own rights.

-- 
"Finally coming home"                       Home: cl...@ka...
J C Lawrence                               Other: co...@ka...
----------(*)                     Keys etc: finger cl...@ka...
--=| A man is as sane as he is dangerous to his environment |=--

Re: [Phpwiki-talk] New PhpWiki on Sourceforge

[J C L. <cl...@ka...>]

On Mon,  3 Jul 2000 23:34:23 +0200 (MEST) 
Arno Hollosi <aho...@in...> wrote:

>> -- PHPLib based authentication.  -- Moving DB access under PHPLib

> I'm not too keen on using PHPLib.  

I need to integrate into an envionment which is PHPLib based.

> Authentication is easy to do oneself and the DB layer doesn't take
> dbm into account.

<nod>  I've noticed that I very rarely ever do pages any more that
don't involve an SQL backend somehow.  

> Also, with advanced stuff to come, it might even be that the SQL
> itself has to be different.

Easy to abstract and change.  There's been discussion of this lately
on the PHPLib list in regard to moving from MySQL to Oracle (which
I'll probably be doing eventually) and how to make that transition
easy with the various SQL differences.

>> -- Editing and page creation only by people with accounts.  --
>> Concept if "groups of users" ala Unix groups -- Concept of a page
>> "belonging" to a user.  -- Concept of that user granting edit
>> rights to a named group.  -- Ability for a user to transfer
>> ownership (and therefore rights) of a page from himself to
>> another user.  -- Ability to show an index of all the Wiki pages
>> belonging to a particular user or group ("Owner Indexes").

> These go all hand in hand. Although interesting, full support for
> accounts is not a major issue for 1.2. Maybe for later releases.
> I think the next big thing will be modularizing phpwiki. When this
> is done, it should be easy to add accounts without too much
> hassle.

Perhaps I should restate my original post.  What I listed are some
of the things I'll be doing.  I'm starting from a base of PHPWiki.
I'd like to not work against the PHPWiki developers in doing this,
but it is what I'm doing with a timetable on the order of a few
months.  

>> -- Ability for a Wiki page to be attached/associated with another
>> Wiki Page in the manner of a comment on the parent Wiki page.
>> Such Wiki Comment Pages, as they are not stand-alone pages in
>> their own right would be auto-named ala <UserID>.<Some_#> or
>> such.  -- Ability for such "comments" to be threaded and the
>> entire thread tree to be displayed on a single page with
>> indent-stlye threading.

> I don't see how this could be useful. Could you give an example?

Part of the intent is to use a Wiki as a) a corporate documentation
and research system, and b) as a meta-level evaluation system which
runs in parallel with a pre-established Wiki or non-Wiki site.  cf:
http://crit.org/

> If I want to have threaded discussions I'd use something like
> phorum.

Think of phorum constructed entirely of WikiItems.  Now think of
that both as the main site along with various other static pages,
and as a parallel meta layer commenting, evaluating, and referencing
the main site.

That's what I'm doing.

>> -- Ability for a Wiki page to be "attached" to a non-Wiki page
>> (eg local site URL).  Also, by extention, for Wiki threads to be
>> so rooted on URLs.

> This can already be done. wiki_transform.php3 places all its
> output into a variable, which can be processed further. The
> attaching functionality has to be implemented by the non-Wiki
> page.

<nod>  I'd like something a little more elegant (piping thru PHPLib
templates among other things), but yes.

>> -- Ability for a Wiki page to reference (special tag format)
>> other Wiki pages or Wiki Comments in a page such that the
>> contents of the referenced page are displayed in-line (perhaps
>> via TreeDoc (http://www.softky.com/TreeDoc/)).  ("In-place Wiki")

> Again, could you give an example why this is useful?

Consider a researcher mining a Wiki farm and constructing a Wiki
document of notes on what he found and evaluated, in-place quoting
the other WikiItems he referenced.

>> -- Careful use of indexes and Meta-robots such that such Wiki
>> networks are correctly search engine indexable.

> We are working on that. What are meta-robots (or do you mean
> simple web-bots indexing web pages?)

The Meta robots entry ala:

  <meta name="robots" content="index,follow">

Given that in the system I describe the content of a given WikiItem
may simultaneously appear in multiple contexts (as a stand-alone
item, as part of a threaded WikiDiscussion, abstracted as a quoted
WikiItem into another WikiPage, etc) providing suitable clues for
external search engines to make searching as useful as possible
takes a little thought.  I need Google and AltaVista to be able to
usefully index the resulting WikiWeb (you don't want 20 matches to
the same item in different contexts).

> Maybe you should read about WikiEssence, WikiNature, etc. on
> c2.com.  

Yes, I'm familiar with those documents and with Wikis in general.  I
realise that what I'm creating is not really a classical Wiki, and
in many ways deliberately sunders the basic design models and
assumptions of classical Wiki.  This is intentional.

> IMHO, if you overload wiki with functionality it ceases to be a
> wiki.  

Yup.  If I wanted a straight Wiki I'd be using any of the several
dozen already out there rather than building something new.

> But then, maybe that's your aim, i.e. creating something different
> based on a wiki.

Exactly.  My intent is to extend the benefits of Wiki on an
architectural scale to entire web sites.

> Especially, if you change the way topics are discussed within a
> wiki, the whole thing will take on a totally different nature.

Bingo.  Wiki has been done.  

> Note: I'm not saying that discussion within wiki is perfect. But
> it contributes to that wiki feeling that is part of wiki's
> attraction.

Agreed.  When viewed a particular way what I'm really doing is
adding the ability for the author of a WikiItem to define an
explicit for his WikiItem (as versus being a purely abstracted
node), and for others to then explicitly place that WikiItem and
others in new contexts without invalidating or altering the original
context, and to then allow those contexts to be manipulated as
definitions in their own rights.

-- 
"Finally coming home"                       Home: cl...@ka...
J C Lawrence                               Other: co...@ka...
----------(*)                     Keys etc: finger cl...@ka...
--=| A man is as sane as he is dangerous to his environment |=--

Re: [Phpwiki-talk] New PhpWiki on Sourceforge

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

Hi J C,

here are my two cents:

 >   -- PHPLib based authentication.
 >   -- Moving DB access under PHPLib

I'm not too keen on using PHPLib.
Authentication is easy to do oneself and the DB layer doesn't take dbm 
into account. Also, with advanced stuff to come, it might even be that 
the SQL itself has to be different.

 >   -- Editing and page creation only by people with accounts.
 >   -- Concept if "groups of users" ala Unix groups
 >   -- Concept of a page "belonging" to a user.
 >   -- Concept of that user granting edit rights to a named group.
 >   -- Ability for a user to transfer ownership (and therefore rights) 
 >      of a page from himself to another user.
 >   -- Ability to show an index of all the Wiki pages belonging to a
 >      particular user or group ("Owner Indexes").

These go all hand in hand. Although interesting, full support for
accounts is not a major issue for 1.2. Maybe for later releases.
I think the next big thing will be modularizing phpwiki. When this is
done, it should be easy to add accounts without too much hassle.

 >   -- Page histories with prior versions view available (encluding
 >      ownership changes).

We already have a diff in 1.1.6 - only the prior version though.
I assume that eventually this will develop into a full versioning system.

 >   -- Inter-version colourised diff-style views available of edited pages

Nice gimmick. Maybe Jeff is willing to implement this.

 >   -- Ability for a Wiki page to be attached/associated with another
 >      Wiki Page in the manner of a comment on the parent Wiki page.
 >      Such Wiki Comment Pages, as they are not stand-alone pages in
 >      their own right would be auto-named ala <UserID>.<Some_#> or such.
 >   -- Ability for such "comments" to be threaded and the entire
 >      thread tree to be displayed on a single page with indent-stlye
 >      threading.

I don't see how this could be useful. Could you give an example?
If I want to have threaded discussions I'd use something like phorum.

 >   -- Ability for a Wiki page to be "attached" to a non-Wiki page (eg
 >      local site URL).  Also, by extention, for Wiki threads to be so 
 >      rooted on URLs.

This can already be done. wiki_transform.php3 places all its output
into a variable, which can be processed further. The attaching
functionality has to be implemented by the non-Wiki page.

 >   -- Ability for a Wiki page to reference (special tag format) other
 >      Wiki pages or Wiki Comments in a page such that the contents of
 >      the referenced page are displayed in-line (perhaps via TreeDoc
 >      (http://www.softky.com/TreeDoc/)).  ("In-place Wiki")

Again, could you give an example why this is useful?

 >   -- Careful use of indexes and Meta-robots such that such Wiki
 >      networks are correctly search engine indexable.

We are working on that. What are meta-robots (or do you mean simple
web-bots indexing web pages?)


Maybe you should read about WikiEssence, WikiNature, etc. on c2.com.
IMHO, if you overload wiki with functionality it ceases to be a wiki.
But then, maybe that's your aim, i.e. creating something different
based on a wiki.

Especially, if you change the way topics are discussed within a wiki,
the whole thing will take on a totally different nature. Note: I'm not 
saying that discussion within wiki is perfect. But it contributes to
that wiki feeling that is part of wiki's attraction.

/Arno

Re: [Phpwiki-talk] page locking

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

Sure, we could do that. :-)

sw


On Mon, 3 Jul 2000, Arno Hollosi wrote:

> 
>  > Do we want to add page locking now? I want to. I think we should add one
>  > more column to the tables, "access" and it will just be Boolean for now. I
>  > have the administration forms largely fleshed out, and it should be simple
>  > and rudimentary for the first time it's released: if it's locked, noone
>  > can edit it, if it's not everyone can.
> 
> Cough.
> Ahm, how about using the flags column?
> That's what this column is all about - binary flags that can be tested 
> with bit-opertaions.
> 
> e.g. define("PAGE_LOCKED", 1);
> 
> if($pagehash['flags'] & PAGE_LOCKED)
>   dont_allow_edit();
> 
> /Arno
> 
> _______________________________________________
> 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] page locking

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

 > Do we want to add page locking now? I want to. I think we should add one
 > more column to the tables, "access" and it will just be Boolean for now. I
 > have the administration forms largely fleshed out, and it should be simple
 > and rudimentary for the first time it's released: if it's locked, noone
 > can edit it, if it's not everyone can.

Cough.
Ahm, how about using the flags column?
That's what this column is all about - binary flags that can be tested 
with bit-opertaions.

e.g. define("PAGE_LOCKED", 1);

if($pagehash['flags'] & PAGE_LOCKED)
  dont_allow_edit();

/Arno

[Phpwiki-talk] page locking

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

Do we want to add page locking now? I want to. I think we should add one
more column to the tables, "access" and it will just be Boolean for now. I
have the administration forms largely fleshed out, and it should be simple
and rudimentary for the first time it's released: if it's locked, noone
can edit it, if it's not everyone can.

0: noone can edit the page
1: everyone can edit the page

If there is a need in the future, we can broaden the levels of access by
using more integers.

If noone wants to go through the effort of updating all the schemas and
code, I understand.. we can also just use the "author" column and set it
to "root" or something similar, and that would serve as a means of locking
pages. This violates normalization though.

sw

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

Re: AW: [Phpwiki-talk] RFC: 1.1.6b doesn't add pages

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

Markus,

 > 	After the database creation I executed the SQL-commands from
 > schemas/schema.mysql within phpMyAdmin-Tool.

1.1.6 was released without serious testing.

The fix for your problem is most likely the following:

Add the following in wiki_savepage.php3 around line 39 

   if (! is_array($pagehash)) {
      $pagehash = array();
      $pagehash["version"] = 0;
      $pagehash["created"] = time();	# add this
      $pagehash["flags"] = 0;		# and add this
      $newpage = 1;
   } else {

for other known errors and their cure see:

http://phpwiki.sourceforge.net/1.1.6/index.php3?Known%20bugs%20in%201.1.6

/Arno

AW: [Phpwiki-talk] RFC: 1.1.6b doesn't add pages

[<Mar...@if...>]

Hello Steve,

thank you for your immediate reply.

> Hi Markus,
> 
> Are you trying to use the same database? 
	[Guske, Markus]  No, I created a new one.
	After the database creation I executed the SQL-commands from
schemas/schema.mysql within phpMyAdmin-Tool.

	Because of the new storing mechanism.

	That's what the install-scripts says. 

	Thanks in advance,

		- Markus Guske


> The schema changed from 1.1.5 to
> 1.1.6. Page data is now written to columns instead of storing everything
> in one serialzed hash.
> 
> I am working on a new script that might help you move your pages from
> 1.1.5 to 1.1.6, if you are concerned about saving them.
> 
> sw
> 
> 
> On Mon, 3 Jul 2000, Markus Guske wrote:
> 
> > Hello,
> > 
> > I use the phpwiki 1.1.5 successful under SuSE Linux and mysql
> > 
> > Today I started a switch to the latetest version 1.1.6b. 
> > 
> > But I couldn't get it run, because the Browser shows always "error
> writing page 'Adding Pages'
> > 
> > Is there something wrong with the mysql-schema or with the
> SQL-replace-Statement?
> > 
> > Any hints are appreciated.
> > 
> > Thanks in advance,
> > 
> > 	- Markus Guske
> > 
> > This is the output mysqladmin version:
> > mysqladmin  Ver 8.0 Distrib 3.22.32, for pc-linux-gnu on i686
> > TCX Datakonsult AB, by Monty    
> > 
> > ---
> > BITPlan GmbH smart solutions - Meerbuscher Str. 58-60 - 40670
> Meerbusch-Osterath 
> > Tel +49 2159 5236-0 - Fax +49 2159 5236-10 - mg...@bi... -
> http://www.bitplan.de
> > 
> > Home Office: Markus Guske - Erftstrasse 17 - D-41564 Kaarst
> > Tel +49 173 946 1880 - Fax +49 2131 769-195 - mg...@gu...
> > 
> > _______________________________________________
> > 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] New PhpWiki on Sourceforge

[J C L. <cl...@ka...>]

On Sun, 2 Jul 2000 18:21:11 -0400 (EDT) 
Steve Wainstead <sw...@wc...> wrote:

> I am particulary keen on getting page locking done, because I am
> tired of clearing out graffiti like
> http://phpwiki.sourceforge.net:80/wiki/index.php3?SteveWainsteadEatsWormsAndBlowsGoats.
> I mean, my personal life is nobody's business ;-)

I have some plans for a Wiki and was intending to worj off a base of
PHPWiki:

  -- PHPLib based authentication.
  -- Moving DB access under PHPLib
  -- Editing and page creation only by people with accounts.
  -- Concept if "groups of users" ala Unix groups
  -- Concept of a page "belonging" to a user.
  -- Concept of that user granting edit rights to a named group.
  -- Ability for a user to transfer ownership (and therefore rights) 
     of a page from himself to another user.
  -- Ability to show an index of all the Wiki pages belonging to a
     particular user or group ("Owner Indexes").
  -- Page histories with prior versions view available (encluding
     ownership changes).
  -- Inter-version colourised diff-style views available of edited pages
  -- Ability for a Wiki page to be attached/associated with another
     Wiki Page in the manner of a comment on the parent Wiki page.
     Such Wiki Comment Pages, as they are not stand-alone pages in
     their own right would be auto-named ala <UserID>.<Some_#> or such.
  -- Ability for such "comments" to be threaded and the entire
     thread tree to be displayed on a single page with indent-stlye
     threading.
  -- Ability for a Wiki page to be "attached" to a non-Wiki page (eg
     local site URL).  Also, by extention, for Wiki threads to be so 
     rooted on URLs.
  -- Ability for a Wiki page to reference (special tag format) other
     Wiki pages or Wiki Comments in a page such that the contents of
     the referenced page are displayed in-line (perhaps via TreeDoc
     (http://www.softky.com/TreeDoc/)).  ("In-place Wiki")
  -- Ability to link from a Wiki link in an In-place Wiki or Owner
     Index to the original context of that Wiki Page/Cpomment (eg the
     original comment-thread)
  -- Careful use of indexes and Meta-robots such that such Wiki
     networks are correctly search engine indexable.

I'd like to work with, or at least not against, the PHPWiki team in
this.  Does any of the above directly conflict with the PHPWiki
team's plans for PHPWiki?

-- 
"Show me the way to go home"                 Home: cl...@ka...
J C Lawrence                               Other: co...@ka...
----------(*)                     Keys etc: finger cl...@ka...
--=| A man is as sane as he is dangerous to his environment |=--

Re: [Phpwiki-talk] new admin/ directory

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

Don't forget you need to do a 

cvs update -d

to pick up the new directory.

sw

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

[Phpwiki-talk] new admin/ directory

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

OK, here's my first pass at an administrative module for PhpWiki.

I made a new subdirectory, admin/, which has three files in it. One is
index.php3, which will work much like the main index.php3: it opens the
database and goes through an if/elseif/elseif/else block to decide which
file to load.

The files it will choose from will be:

* serialize all pages
* dump all pages as HTML
* load a set of serialized pages
* lock/unlock pages
* rebuild the DB files (for DBM-based Wikis)
* load a set of admin forms (default if none of the above apply)

I wrote a page which did all the work of dumping the whole database out as
serialized hashes, and then accidentally deleted it and lost about 1hr's
work... being not entirely discouraged, I wrote these three files.

Besides index.php3 is wiki_adminforms.php (not .php3) which is an HTML
file mostly. (For now.) I wanted to write out everything I wanted to do
before starting to code, and anyone who wants to contribute can start
writing files based on the descriptions.

Third is a Perl script that reduces the size of a DBM file. I will write
all of it in PHP later but wanted to prove I was right about how DBM files
lose memory first, and I was... for the savvy sysadmin a Perl script will
be faster or more flexible a solution (and can be easily cron'd.)

The Perl script shrank the DBM file on wcsb.org from 2,464,640 bytes to 
117,574 (there are 91 pages in it).

sw


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

Re: [Phpwiki-talk] RFC: 1.1.6b doesn't add pages

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

Hi Markus,

Are you trying to use the same database? The schema changed from 1.1.5 to
1.1.6. Page data is now written to columns instead of storing everything
in one serialzed hash.

I am working on a new script that might help you move your pages from
1.1.5 to 1.1.6, if you are concerned about saving them.

sw


On Mon, 3 Jul 2000, Markus Guske wrote:

> Hello,
> 
> I use the phpwiki 1.1.5 successful under SuSE Linux and mysql
> 
> Today I started a switch to the latetest version 1.1.6b. 
> 
> But I couldn't get it run, because the Browser shows always "error writing page 'Adding Pages'
> 
> Is there something wrong with the mysql-schema or with the SQL-replace-Statement?
> 
> Any hints are appreciated.
> 
> Thanks in advance,
> 
> 	- Markus Guske
> 
> This is the output mysqladmin version:
> mysqladmin  Ver 8.0 Distrib 3.22.32, for pc-linux-gnu on i686
> TCX Datakonsult AB, by Monty    
> 
> ---
> BITPlan GmbH smart solutions - Meerbuscher Str. 58-60 - 40670 Meerbusch-Osterath 
> Tel +49 2159 5236-0 - Fax +49 2159 5236-10 - mg...@bi... - http://www.bitplan.de
> 
> Home Office: Markus Guske - Erftstrasse 17 - D-41564 Kaarst
> Tel +49 173 946 1880 - Fax +49 2131 769-195 - mg...@gu...
> 
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> http://lists.sourceforge.net/mailman/listinfo/phpwiki-talk
> 

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

[Phpwiki-talk] RFC: 1.1.6b doesn't add pages

[<Mar...@t-...>]

Hello,

I use the phpwiki 1.1.5 successful under SuSE Linux and mysql

Today I started a switch to the latetest version 1.1.6b. 

But I couldn't get it run, because the Browser shows always "error writing page 'Adding Pages'

Is there something wrong with the mysql-schema or with the SQL-replace-Statement?

Any hints are appreciated.

Thanks in advance,

	- Markus Guske

This is the output mysqladmin version:
mysqladmin  Ver 8.0 Distrib 3.22.32, for pc-linux-gnu on i686
TCX Datakonsult AB, by Monty    

---
BITPlan GmbH smart solutions - Meerbuscher Str. 58-60 - 40670 Meerbusch-Osterath 
Tel +49 2159 5236-0 - Fax +49 2159 5236-10 - mg...@bi... - http://www.bitplan.de

Home Office: Markus Guske - Erftstrasse 17 - D-41564 Kaarst
Tel +49 173 946 1880 - Fax +49 2131 769-195 - mg...@gu...

[Phpwiki-talk] New PhpWiki on Sourceforge

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

I have the PhpWiki+MySQL installation on SF working
(http://phpwiki.sourceforge.net/phpwiki/). This is going to be the main
PhpWiki site soon. I am going to write conversion routines to: 

* port from one DB to another (in this case it will be DBM -> MySQL but it
will work AnyDB -> AnyDB)

* port version 1.0 Wikis to 1.[12] Wikis.

This might be the beginning of 'auth' capabilities. That is, DB porting is
something the admin should only have access to, so I want to create a
general design soon for admin features (it will also include: exporting
pages as HTML, locking pages, and "rebuilding" DBM files.)

I am particulary keen on getting page locking done, because I am tired of
clearing out graffiti like
http://phpwiki.sourceforge.net:80/wiki/index.php3?SteveWainsteadEatsWormsAndBlowsGoats.
I mean, my personal life is nobody's business ;-)

sw

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