phpwiki-talk

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 

Re: [Phpwiki-talk] path_info vs. query_args

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

 > If changing to PATH_INFO means a Wiki cannot be indexed by a search
 > engine, I would question its worth.  

The other way around: using PATH_INFO allows URLs without "?" - and
they can be indexed then.

 > Arno, if I read the mails right, some spiders ignore everything after the
 > ? in a URL. That would mean a PhpWiki cannot be indexed since everything
 > after the index page has a question mark...

Correct.
Search for WikiEssence on google, altavista, excite.
No engine will list: http://www.c2.com/cgi/wiki?WikiEssence
(another nice side-effect of those simple wiki pagenames: they form
excellent search terms for search engines :o)
And c2's wiki is not that unknown, is it?

[just to prove me wrong I just saw that raging.com lists a hit with
"?" when searching for recentvisitors]
So, let's say: not all major search engines support "?" links, or if
they do they don't rate such pages high.

 > therefore, switching to
 > PATH_INFO would mean a Wiki could be indexed, and that would be a Good
 > Thing since someone doing a search on "hammond organs" would find a lot of
 > the pages in Jeff's Wiki. Sound correct?

Correct.

So it seems to be a worthwile change. I suggest that we put it off,
until we had a look at Ari's code and agreed on the impending
refactoring of phpwiki.

/Arno

Re: [Phpwiki-talk] Re: PhpWiki (fwd)

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

 > Ari runs the NBTS Wiki (http://www.nbtsc.org/wiki/); I emailed Ari today
 > ... it appears a tarball will be available to us soon.

 > In addition to that, I've
 > been hyper-modularizing things, so you can just comment out an include
 > file to turn on and off features;

That sounds *very* interesting.
I guess we should adopt a similar structure for our distribution.

I don't know which naming convention Ari uses for the files, and if
it would be better to turn on/off those features in wiki_config, but
I definitely look forward to getting my hands on his code.

At some point I was worrying we might pack too many features into
phpwiki. But by adopting such a flexible scheme and keeping the
number of core files small admins can decide for themselves.

/Arno

[Phpwiki-talk] Re: PhpWiki (fwd)

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

Ari runs the NBTS Wiki (http://www.nbtsc.org/wiki/); I emailed Ari today
asking about the interesting changes and things, and it appears a tarball
will be available to us soon. Thought you might be interested.

sw

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

---------- Forwarded message ----------
Date: Fri, 30 Jun 2000 13:19:51 -0700 (PDT)
From: Aredridel <are...@nb...>
To: Steve Wainstead <sw...@wc...>
Subject: Re: PhpWiki

: Hi Ari!
: 
: I love surfing the NBTS Wiki. I was looking today to see how it was doing,
: and I noticed on HeyYouGuysInCharge that the Wiki is taking about 23M now.
: I am guessing that you are running a DBM-based Wiki, and was wondering if
: you periodically rebuild the DBM file? They have a built in memory leak
: and you might be able to save a lot of space.

Mmm, I've not rebuilt it yet; Not an issue, really, and since I'm going to
merge in your PostgreSQL code and use that, I'll just ignore it since
there's plenty of space.

: Also, I don't know if you've followed the development of PhpWiki but it's
: moved to Sourceforge and has come a long way
: (http://phpwiki.sourceforge.net/). You have a lot of neat improvements
: that I wouldn't mind seeing in PhpWiki's main distribution.

Mmm, yeah. I've made a lot of changes to the rendering engine; I've been
trying to clean the code up for release now. In addition to that, I've
been hyper-modularizing things, so you can just comment out an include
file to turn on and off features; Those features can be anything from Full
HTML rendering, Login functions, ability to have private pages, Limited
subset-of-HTML rendering, standard PhpWiki markup, my modified markup, and
separate images for the logo on each page with a fallback. 

: The soon-to-be 1.2 release will run on your choice of DBM, mSQL,
: MySQL, and Postgresql (it's aleady ported to all of them).

Excellent. I saw the MySQL stuff already (in the 1.14 release, I
think) and was considering switching, but got lazy. 

Thanks for the email, and after I clean up my code, I'll upload a tarfile
for you to pick at and merge into the main release as you like.

Ari

[Phpwiki-talk] mysql on sourceforge

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

I've gotten a login and database created on sourceforge, and I'll set up
the current version soon, running off mysql.

sw

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

Re: [Phpwiki-talk] path_info vs. query_args

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

On Fri, 30 Jun 2000, Arno Hollosi wrote:

>  > I envision URLs like 
>  > 
>  >   http://phpwiki.sourceforge.net/1.1.6/index.php3/PhpWikiBrainstorm
>  >   http://phpwiki.sourceforge.net/1.1.6/index.php3/PhpWikiBrainstorm?edit
>  > 
>  > I think these will work anywhere without server reconfiguration.
> 
> Interesting. I didn't know that these URLs work without server tweaking.
> Does this only work on Apache or on other servers as well?

Yes, PATH_INFO is always populated by whatever follows the / after a CGI
file. We'd find it in that array... what's it called...
http_request_vars[] or something... or else in $PATH_INFO.

>  > Also (I think) it would make it easy to create static 'snapshots' of a
>  > Wiki using a web mirroring tool like wget.
> 
> Do we really want to encourage mirroring through wget or other utils?
> (btw, wget is able to handle "?" stuff).

I think there might be some other, more Wiki-specific way of doing
mirroring and file sharing. More on this some other time.


If changing to PATH_INFO means a Wiki cannot be indexed by a search
engine, I would question its worth.  

Arno, if I read the mails right, some spiders ignore everything after the
? in a URL. That would mean a PhpWiki cannot be indexed since everything
after the index page has a question mark... therefore, switching to
PATH_INFO would mean a Wiki could be indexed, and that would be a Good
Thing since someone doing a search on "hammond organs" would find a lot of
the pages in Jeff's Wiki. Sound correct?

sw

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

Re: [Phpwiki-talk] diffs on the live site

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

On Fri, 30 Jun 2000, Arno Hollosi wrote:

> 
>  > This reminds me... someone requested that I generate a patch set for each
>  > release, which is a reasonable request... does CVS support that directly?
> 
> cvs has a diff & rdiff option.
> Unfortunately, they do not support tags as identifier, only revisions
> and dates. So you need to find the exact date of the release (probably 
> including time of day).

ja, I should have read the docs first... cvs rdiff -r x.x -r y.y will
generate patch sets (diffs). Next time I'll be less impulsive about
mailing the list :-)

sw


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

Re: [Phpwiki-talk] path_info vs. query_args

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

 > I envision URLs like 
 > 
 >   http://phpwiki.sourceforge.net/1.1.6/index.php3/PhpWikiBrainstorm
 >   http://phpwiki.sourceforge.net/1.1.6/index.php3/PhpWikiBrainstorm?edit
 > 
 > I think these will work anywhere without server reconfiguration.

Interesting. I didn't know that these URLs work without server tweaking.
Does this only work on Apache or on other servers as well?


 > Which brings to mind another point: we should probably emit
 > the Last-Modified: and Cache-Control: HTTP headers (and possibly check the
 > If-Modified-Since: and If-None-Match: request headers).

Yes, I was thinking about this too.
Cache-control headers are especially useful when editing pages.
There's some good information about caching on:
http://www.mnot.net/cache_docs/
and a nice tool at
http://www.ircache.net/cgi-bin/cacheability.py


 > Also (I think) it would make it easy to create static 'snapshots' of a
 > Wiki using a web mirroring tool like wget.

Do we really want to encourage mirroring through wget or other utils?
(btw, wget is able to handle "?" stuff).

I recall reading a page on c2.com, how spiders or mirror-attempts
"brought down" c2.com, because they were also mirroring the results from 
the fulltext search on page titles. These searches are quite expensive 
and those dumb bots flooded c2.com with such requests.

One of my most popular sites (http://gtl.jeudego.org/) is mirrored
about two/three times a month. Usually this creates up to 3 requests
per second - which effectively makes the site unusuable for an hour.

/Arno

Re: [Phpwiki-talk] path_info vs. query_args

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

>Jeff wrote:
> > o Pagenames moved to PATH_INFO rather than in QUERY_ARGS.
>
>just to be sure I understand what you're talking about:

Yes, I think you've got the idea.

>It is a reasonable suggestion, but it means that
>phpwiki would no longer run "out of the box". This kind of setup
>requires changes to the web server's config. This is not possible
>everywhere.

I envision URLs like 

  http://phpwiki.sourceforge.net/1.1.6/index.php3/PhpWikiBrainstorm
  http://phpwiki.sourceforge.net/1.1.6/index.php3/PhpWikiBrainstorm?edit

I think these will work anywhere without server reconfiguration.

Getting

  http://phpwiki.sourceforge.net/1.1.6/PhpWikiBrainstorm

to work would be slick, but does take hacking on the server configuration.
Easy enough for individual users to do if they want.

>The only difference might be for spiders scanning the web (e.g.
>search engines). Some of them ignore anything after "?" and would only 
>index the main page and nothing else.

Yes. 

Which brings to mind another point: we should probably emit
the Last-Modified: and Cache-Control: HTTP headers (and possibly check the
If-Modified-Since: and If-None-Match: request headers).

(i.e. for cache control purposes, browsed pages should appear to be
static pages.)

I once figured out the correct way to handle these (for
http://www.dairiki.org/tides/) , and could probably sort it out again pretty
quickly.

>Any other reason?

It makes more logical sense: the URL for each page looks like a URL for a page.
URLs for operations on a page look like URLs for operations on a page.

Also (I think) it would make it easy to create static 'snapshots' of a
Wiki using a web mirroring tool like wget.

Jeff