phpwiki-talk

[Phpwiki-talk] Server Power

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

I am currently renting a dedicated server in Virginia, that I have full
access to..
http://websystems.com.au

we can use that if necessary, I am unsure how much server access/config we
are allowed at SourceForge

-N

Re: [Phpwiki-talk] Re: FindPage on Win32

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

Hi,

answers/thoughts on Nicholas' recent emails:

 > > For some reason the FindPage ie
 > > http://phpwiki.sourceforge.net/wiki/index.php3?FindPage
 > > does not present the text-boxes

Search boxes are broken in 1.1.4. A fix is in the CVS.

 > > also the FindPage link at the bottom of the pages doesnt work correctly

Same as above - fix is already in CVS.
[ Newnames must have been a very quick&dirty hack, Steve ;o) ]


> this seems to be a great solution, it would be nice if wiki_config.php3 and
> say wiki_template.php3 where the only pages one needed to alter to customise
> ones wiki.

That is the general idea. Maybe it gets a little bit more complicated
than that. E.g. I'm sure someone would like to customize the
appearance of the editpage as well - I don't mean the general layout
but changes "within" the page like e.g. changing the size of the text field.


> will we have to re-enter our pages manually? could we make a sript that
> migrates our data into the new schema?

I'm sure we will come up with an export script. That way the whole
wiki can be exported into files just like those in "/pgsrc" and
inserted into a new empty wiki without problems. Of course, new pagenames
have this pesky problem of allowing chars which shouldn't appear in filenames.


> I am looking at getting PhpWiki to work with the following;
> PhpHoo2, PHPSlash, TWIG, Listman, Webmin

This touches upon the extension of wiki. Some of these features are
needed within wiki too, although in a watered-down version. E.g. a
better category concept (phphoo) or better focus on current
topics (phpslash), notification of users (listman), ...

What we really want is of course that phpwiki develops into this massive
portal system and that we never need to care about the Web again :o)

Good ideas can be drawn from a bunch of sources like Everything2 or ACS.

My main concern is navigation within wiki. My private wiki (which is
used to discuss a forthcoming wiki for Go) holds about 100 pages but
I've already lost track of what's in it and where. To that end, my
priorities are categories, paths, plus some magic based on back-links.
Also, I intend to add a fulltext search engine to my wiki.
UDMSearch (http://mysearch.udm.net/) looks promising - it is able to
index mySQL columns, just what is needed for phpwiki (phpwiki itself
will remain ignorant/independent of the search engine)


/Arno

Re: [Phpwiki-talk] wikinames, layout, db, and more

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

What are you using on
> NT, by the way?)

MySQL 3.22.34, PHP4 (I think, I am having some installations weirdness with
PHP)


> This will be the easy part... creating the user auth system and
> integrating it will be the hard part. Security always makes things more
> difficult.

could we source script from somewhere?
http://directory.google.com/Top/Computers/Programming/Languages/PHP/


> In particular, we have to be careful of trying to reinvent HTML. Before
> long people will be asking for tables and frames and Javascript, and
> that's when I go into retirement :-)
>

lets not recreate HTML, it would be good to have shortcuts to web objects
though (WOM:)
http://www.objs.com/OSA/wom.htm

also have you seen the Superdocs concept at Everything2.com?
http://everything2.com/index.pl?node=XP


>
> My desire is to push this architecture in new and interesting ways, and
> eventually when the 1.2 series matures, write a new one from scratch,
> because it will probably reach a point where we will have to anyway.
>

ok, sounds good, I'll help, its a bit of a learning curve for me


> > see http://synarchy.net/usyd/ped/task0.html
> Ah, to be in college again :-)

partime, nights, I am in a masters stream (no undergrad degree though) I
work in the days too, http://www.worldmedicus.com

>
> I'm also interested in a Slashdot front end to PhpWiki, and right now my
> thinking is that it will be a seperate file, a.k.a. wiki_weblog.php3
> (which can optionally be made index.php3).

hmmm, thats very interesting, right now I have 2 projects (contract and uni)
to finish this week, after that I'll be diving manically into PHPdom

>
> After reading through this and looking at your drawings I understand why
> you want a more component-based approach... your drawings remind me an
> awful lot of Ted Neson's :-)

hopefully I am a bit more grounded, not so utopian, I'll take that as a
compliment

btw have you seen http://synarchy.net/CRV

Re: [Phpwiki-talk] wikinames, layout, db, and more

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

On Tue, 6 Jun 2000, Nicholas Roberts wrote:

> I assume that we are not bound by
> > backwards-compatibility?
> 
> will we have to re-enter our pages manually? could we make a sript that
> migrates our data into the new schema?

Only if you launched on the old MySQL code base, and even then it would be
possible to write a conversion script. I don't see any backwards
compatibility issues with the DBM storage approach. (What are you using on
NT, by the way?)

> > If we need some kind of authentication I would suggest that we
> > basically just have two users: anonymous and admin. This allows
> > e.g. to have "frozen" pages which only admin people can edit or unfreeze.
> > (Might be useful for system documentation or other sensitive stuff.)
> 
> I envision 3 states for a page
> 
> 1. Frozen: only admin can alter
> 2. Comment-On: main text frozen for anonymous (admin full access), time and
> author-stamped comments allowable at the bottom of the page
> 3. Open: free-form classic wiki editing

This will be the easy part... creating the user auth system and
integrating it will be the hard part. Security always makes things more
difficult.

> 
> 
> References & Footnotes
> 
> I think that is is useful to have these. I would like to see Footnotes &
> References to be more structured. I think it makes great sense to have each
> Reference unique, so they can be re-used, maybe something like
> PhpWikii:NSTBCWiki:WelcomeVistors:1.
> 
> Maybe if you wanted to use it in another page it could be [r |
> WelcomeVistors.1]
> 
> The other alternative (the way EditThisPage handles it) is to have site-wide
> references, thereby guarneteeing uniqueness
> 
> 
> ie
> Editing Form
> Number/shortcut [1]
> URL [http:/some.url.com]
> Title [This URL is about PHPWiki] - optional
> Author [Swain & Hollosi]  - optional
> 
> if a template was used it would be easy to turn-off/on and re-position
> footnotes, perhaps making them a seperate page, or allwing them to be
> expanded into the page etc?
> 

Yes, and this could be related to another idea I've had about storing page
names in a persistent data structure; does PHP support global variables
the way mod_perl does? If it did we could maintain a list of defined and
undefined pages, though at the moment my head is congested and I can't
remember why I wanted to do this :-)

All in all, we'll probably wind up doing the simplest/most important
things first. I don't see references changing much in the near future.

> 
> Images
> 
> I am a big fan of images/photos/visual metaphors, so I'd like to see a more
> elegant image system
> 

In my experience with Wikis, images are rarely utilized; beyond making
them easier to embed I think it would be time wasted to do any more.

In particular, we have to be careful of trying to reinvent HTML. Before
long people will be asking for tables and frames and Javascript, and
that's when I go into retirement :-)

> Editing Form
> Name/shortcut [Fern]
> Source URL [http://some.url.com/images/fern.gif ]
> Hyperlink [http://some.url.com/fern.html]
> Alt [This photo is a fern] - optional
> Author [Swain & Hollosi]  - optional
> 
> then maybe everytime an author writes [i | fern] the Fern image is embedded.
> Perhaps again it would be good to have site-wide image registration.
> 

I think these are both good ideas. They shouldn't be hard to implement,
but they hinge on the new database schemas and whatever performance
impact. i.e. let's wait and see when we have the new DB interface worked
out.

> 
> It seems that we are getting away from the original classic Wiki, but I
> noticed TheTcler Wiki has a lot of great enchancements. I am using PhpWiki
> for a Uni project and so will be doing a lot of work along these lines
> anyway and it would be great if they where integrated in the 'official'
> PhpWiki, even if they are options to be activated.

I am leaving the 1.03 release as is, which is very very close to the
original Wiki. (Change the logo and you probably could fool Ward
Cunningham ;-) 

My desire is to push this architecture in new and interesting ways, and
eventually when the 1.2 series matures, write a new one from scratch,
because it will probably reach a point where we will have to anyway.


> 
> I am looking at getting PhpWiki to work with the following;
> 
> PhpHoo2
> PHPSlash (with PHPLib for support)
> TWIG
> Listman
> Webmin
> 
> At first I am going for a SyncreticHack, then after a few iterations I might
> get somekind of SourceForge style seemlessness
> 
> see http://synarchy.net/usyd/ped/task0.html


Ah, to be in college again :-)

I'm also interested in a Slashdot front end to PhpWiki, and right now my
thinking is that it will be a seperate file, a.k.a. wiki_weblog.php3
(which can optionally be made index.php3).

After reading through this and looking at your drawings I understand why
you want a more component-based approach... your drawings remind me an
awful lot of Ted Neson's :-)

sw

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

Re: [Phpwiki-talk] wikinames, layout, db, and more

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

On Tue, 6 Jun 2000, Nicholas Roberts wrote:

> > I was thinking about creating one file which contains the layout with
> > some placeholders like ##TITLE##, ##PAGE##, etc. which get replaced
> > by the page content. This keeps the actual wiki content isolated from
> > the HTML layout.
> >
> 
> this seems to be a great solution, it would be nice if wiki_config.php3 and
> say wiki_template.php3 where the only pages one needed to alter to customise
> ones wiki.

That is certainly the goal here... even better if you only have to edit
one file, but I don't think combining layout and config info is a good
idea :-)

> at present the codebase is evolving so much that it is difficult to follow
> and implement all the changes for a newbie, especially with customised
> HTML/layout spread through the php.

In fact, you are invaluable because it's all too easy for me to think,
"oh, I'll just write an ex script to mod all the files," and not bother
with a solution that works for everybody. Hang in there.

sw


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

Re: [Phpwiki-talk] wikinames, layout, db, and more

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

I assume that we are not bound by
> backwards-compatibility?

will we have to re-enter our pages manually? could we make a sript that
migrates our data into the new schema?

> If we need some kind of authentication I would suggest that we
> basically just have two users: anonymous and admin. This allows
> e.g. to have "frozen" pages which only admin people can edit or unfreeze.
> (Might be useful for system documentation or other sensitive stuff.)

I envision 3 states for a page

1. Frozen: only admin can alter
2. Comment-On: main text frozen for anonymous (admin full access), time and
author-stamped comments allowable at the bottom of the page
3. Open: free-form classic wiki editing


References & Footnotes

I think that is is useful to have these. I would like to see Footnotes &
References to be more structured. I think it makes great sense to have each
Reference unique, so they can be re-used, maybe something like
PhpWikii:NSTBCWiki:WelcomeVistors:1.

Maybe if you wanted to use it in another page it could be [r |
WelcomeVistors.1]

The other alternative (the way EditThisPage handles it) is to have site-wide
references, thereby guarneteeing uniqueness


ie
Editing Form
Number/shortcut [1]
URL [http:/some.url.com]
Title [This URL is about PHPWiki] - optional
Author [Swain & Hollosi]  - optional

if a template was used it would be easy to turn-off/on and re-position
footnotes, perhaps making them a seperate page, or allwing them to be
expanded into the page etc?


Images

I am a big fan of images/photos/visual metaphors, so I'd like to see a more
elegant image system

Editing Form
Name/shortcut [Fern]
Source URL [http://some.url.com/images/fern.gif ]
Hyperlink [http://some.url.com/fern.html]
Alt [This photo is a fern] - optional
Author [Swain & Hollosi]  - optional

then maybe everytime an author writes [i | fern] the Fern image is embedded.
Perhaps again it would be good to have site-wide image registration.


It seems that we are getting away from the original classic Wiki, but I
noticed TheTcler Wiki has a lot of great enchancements. I am using PhpWiki
for a Uni project and so will be doing a lot of work along these lines
anyway and it would be great if they where integrated in the 'official'
PhpWiki, even if they are options to be activated.


I am looking at getting PhpWiki to work with the following;

PhpHoo2
PHPSlash (with PHPLib for support)
TWIG
Listman
Webmin

At first I am going for a SyncreticHack, then after a few iterations I might
get somekind of SourceForge style seemlessness

see http://synarchy.net/usyd/ped/task0.html

cheers

-N

Re: [Phpwiki-talk] wikinames, layout, db, and more

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

>
> I was thinking about creating one file which contains the layout with
> some placeholders like ##TITLE##, ##PAGE##, etc. which get replaced
> by the page content. This keeps the actual wiki content isolated from
> the HTML layout.
>

this seems to be a great solution, it would be nice if wiki_config.php3 and
say wiki_template.php3 where the only pages one needed to alter to customise
ones wiki.

at present the codebase is evolving so much that it is difficult to follow
and implement all the changes for a newbie, especially with customised
HTML/layout spread through the php.

cheers

-N

Re: [Phpwiki-talk] Re: FindPage on Win32

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

I'm definetely the greenwood in this group, I guess its purely a MS
screw-up, I am going to upgrade to Linux on my development machine real-soon
now, I have a Linux dedicated server and I can see a continual conversion
overhead...

----- Original Message -----
From: Steve Wainstead <sw...@pa...>
To: Nicholas Roberts <nic...@sy...>;
<php...@li...>
Sent: Tuesday, June 06, 2000 8:51 AM
Subject: [Phpwiki-talk] Re: FindPage on Win32


> Hi Nicholas!
>
> The links you sent are incomplete (http://dragon) so I couldn't surf the
> site to see myself. I looked at the source you sent but all I see are
> the words Search and FullSearch showing up. I wonder if this isn't a
> regular expression problem on the MS platform?
>
> Well, send the links again and I'd be happy to take another look at it!
>
> sw
>
> Nicholas Roberts wrote:
> >
> > hi folks
> >
> > I am developing a PhpWikiClone on Win32 (Win98+Apache 1.3.9+Php3.0.16).
> >
> > For some reason the FindPage ie
> > http://phpwiki.sourceforge.net/wiki/index.php3?FindPage
> >
> > does not present the text-boxes, see attachment (findpage.html) my url
> > http://dragon/index.php3?FindPage
> >
> > also the FindPage link at the bottom of the pages doesnt work correctly,
see
> > atachment (findpage-findpage.html) ie my url
> > http://dragon/index.php3?FindPage&value=FindPage
> >
> > how the full search does work?!  ie my url
> > http://dragon/index.php3?full=FindPage
> >
> > thanks in advance
> >
> > -N
> >
>
  ------------------------------------------------------------------------
> >                     Name: findpage.html
> >    findpage.html    Type: Hypertext Markup Language (text/html)
> >                 Encoding: quoted-printable
> >
> >                              Name: findpage-findpage.html
> >    findpage-findpage.html    Type: Hypertext Markup Language (text/html)
> >                          Encoding: quoted-printable
>
> --
> http://wcsb.org/~swain/ | "In a calendar year, America's entire
>   *   *   *   *   *   * | recorded music industry has revenues
> *   *   *   *   *   *   | roughly equal to one month's sales by
>   *   *   *   *   *   * | IBM." --Philip Greenspun
>
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> http://lists.sourceforge.net/mailman/listinfo/phpwiki-talk
>

[Phpwiki-talk] Re: FindPage on Win32

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

Hi Nicholas!

The links you sent are incomplete (http://dragon) so I couldn't surf the
site to see myself. I looked at the source you sent but all I see are
the words Search and FullSearch showing up. I wonder if this isn't a
regular expression problem on the MS platform?

Well, send the links again and I'd be happy to take another look at it!

sw

Nicholas Roberts wrote:
> 
> hi folks
> 
> I am developing a PhpWikiClone on Win32 (Win98+Apache 1.3.9+Php3.0.16).
> 
> For some reason the FindPage ie
> http://phpwiki.sourceforge.net/wiki/index.php3?FindPage
> 
> does not present the text-boxes, see attachment (findpage.html) my url
> http://dragon/index.php3?FindPage
> 
> also the FindPage link at the bottom of the pages doesnt work correctly, see
> atachment (findpage-findpage.html) ie my url
> http://dragon/index.php3?FindPage&value=FindPage
> 
> how the full search does work?!  ie my url
> http://dragon/index.php3?full=FindPage
> 
> thanks in advance
> 
> -N
> 
>   ------------------------------------------------------------------------
>                     Name: findpage.html
>    findpage.html    Type: Hypertext Markup Language (text/html)
>                 Encoding: quoted-printable
> 
>                              Name: findpage-findpage.html
>    findpage-findpage.html    Type: Hypertext Markup Language (text/html)
>                          Encoding: quoted-printable

-- 
http://wcsb.org/~swain/ | "In a calendar year, America's entire
  *   *   *   *   *   * | recorded music industry has revenues
*   *   *   *   *   *   | roughly equal to one month's sales by
  *   *   *   *   *   * | IBM." --Philip Greenspun

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

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

Arno,
Here's your reply to my initial suggestion. I wanted to forward it so it
goes in the mail archive.

sw

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

---------- Forwarded message ----------
Date: Wed, 26 Apr 2000 00:01:32 +0200 (MEST)
From: Arno Hollosi <aho...@in...>
To: Steve Wainstead <sw...@wc...>
Subject: Re: MySQL schema


Hi Steve,

about your mySQL schema:
(quoting the whole thing for easier reading)

 > CREATE TABLE wiki (
 >    pagename VARCHAR(100) PRIMARY KEY,
 >    version INT,
 >    stamp VARCHAR(40),
 >    author VARCHAR(100),
 >    content MEDIUMTEXT,
 >    refs TINYINT
 > );
 > 
 > CREATE TABLE archive (
 >    pagename VARCHAR(100) PRIMARY KEY,
 >    version INT,
 >    stamp VARCHAR(40),
 >    author VARCHAR(100),
 >    content MEDIUMTEXT,
 >    refs TINYINT
 > );
 > 
 > CREATE TABLE wiki_refs (
 >    refnum INT NOT NULL,
 >    pagename VARCHAR(100) NOT NULL,
 >    ref VARCHAR(255) NOT NULL,
 >    UNIQUE INDEX wiki_refs_indx (refnum, pagename)
 > );

You need a "version INT" in wiki_refs too.
E.g. "FrontPage" version 4 (in wiki) has references and
"FrontPage" version 3 (in archive) has refs too. There's no way to
distinguish the two in your schema.

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

On a side note, I don't think that "refs TINYINT" in wiki/archive is
necessary. Strictly speaking your schema won't be normalized (in a higher 
normal form - 3NF or 4NF) if you add this column. But it's not much to
worry about. Advantages: it safes a little time when displaying the page.

But speaking of references: I don't like them. Editing them takes many 
steps: "edit page" -> "save" -> "ok" -> "edit page" -> "edit links" -> "save"
Instead I would suggest a markup of the kind "[1:http://host.com/page.html]"
or something similar. I know this is not part of the original Wiki.
I don't know how important being a 100% clone of the original is to
you. I would change this without hesitation - but that is me.


 > Regarding the timestamp, you're right about Unix timestamps being better.
 > I think that we could even use some database dependent way, like using
 > native MySQL date types.

I wouldn't use a database dependent way. This makes it a hassle to
create advanced features based on the date stamp. Unix timestamps are
fine, because basically they are integers (easy calculations and
comparisons) and can be converted easily using PHP functions.
Changing this in the current Wiki would only require some minor
updates. Of course, unix timestamps have this pesky year 2037 problem ;o)


 > it's now got me thinking about normalized
 > schemas and a more flexible architecture, which is a bit further than I
 > wanted, but as long as it's fun I will persist :-)

great :o)

Actually, I have a lot of nifty ideas on how to improve navigation
within wiki. It requires additional database magic and is resource
intensive (execution time) to duplicate with gdbm. If you are
interested anyway I write a short summary of features I would like to
see (and which I will implement in one of my future Wikis).


 > I rewrote UpdateRecentChanges completely yesterday. 
 > I also updated the documentation; your new INSTALL.mysql is included. I
 > pages that come with PhpWiki are in the correct format with \r

is the changed version already online?

/Arno

Re: [Phpwiki-talk] wikinames, layout, db, and more

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

Hey :o)

 > * Using the scheme you mention above as the default
 > * Leaving the code for [] links in, but anyone installing PhpWiki will
 > have to manually enable it?

I would suggest that we keep '[]' and don't add my own convention '__'.
Instead we add a regexp to wiki_config.php3 which limits characters
inside '[]' - thereby creating the same effect as my '__' proposal.
If someone doesn't like the restrictions then they can be removed by
changing the regexp - all the code remains in place. How about that?

 > Yes, definitely. Someone told me recently (was it you?) that they got rid
 > of the page "Thanks for your edits" and instead take you directly back to 
 > the page you edited. I think that's a reasonable thing to do; I understand
 > that page is there to solve a caching problem with browsers of 4-5 years
 > ago.

Well, if it's only the cache that is the problem, then we can just add 
various http headers like "Last-Modified:", "Expires:",
"Cache-Control:", ...
I don't mind the page being there. It can be a useful place to provide 
some additional information to authors. Or to print errors while
inserting the page. But it's not a hot topic for me.

 > At first it should be easy to isolate the top and bottom, which are already
 > in functions:

I was thinking about creating one file which contains the layout with
some placeholders like ##TITLE##, ##PAGE##, etc. which get replaced
by the page content. This keeps the actual wiki content isolated from
the HTML layout.

 > Yes, to get to the point I mentioned above, there's database work to do.

Your proposed schema looked ok. I assume that we are not bound by
backwards-compatibility? In that case I'll have a look at that schema
again and prepare a more detailed comment on it.

 > For example, you also talked about better navigation in the Wiki, and 
 > * MostActivePages
 > * MostViewedPages
 > * MostLinkedToPages
 > * OrderOfCreation

Nice one :o) I like this one.


 > Also if we add user authentication ...

This is a chapter on its own. I mean right now there is no such thing.
We can add some simple user authentication, only to rewrite it
with a real authentication in a year. Creating a complete
authentication system is not easy and requires some work. I guess we
should keep this option open right now.

If we need some kind of authentication I would suggest that we
basically just have two users: anonymous and admin. This allows
e.g. to have "frozen" pages which only admin people can edit or unfreeze.
(Might be useful for system documentation or other sensitive stuff.)

 > I will take responsibility for DBM support;

Ok - I will take care of mySQL. Once we have agreed on a schema and
interfacing functions it should be quite easy to do.

 > [DBM support]
 > I know it's slow and has other problems, but I want to retain the goal 
 > of "just untar and use it!" so people can try it out easily.

I like this feature as well. I guess this plus the clear design made
phpwiki the php wiki of my choice.

 > a few more functions, plus the rewrite for the normalized schema. I want
 > to add Postgresql and mSQL support too since 

PHP already has some kind of db abstraction layer. I will look into it. 
Maybe we can combine PGSQL, mSQL, mySQL all in one file.

 > > [rant about references]
 > I know you don't like them, but I am going to be stubborn about this :-)

Seesh! ;o)
Maybe we can make them optional and enable them by default?

 > [...] a mechanism to embed any image in a page 
 > Something like 
 > [http://www.someurl.com/graphics/image.png]
 > would suffice.

My words :o)

 > Also, the NBTS Wiki changed the code to make references actual footnotes:
 > http://www.nbtsc.org:80/wiki/index.php3?FootNotes

I don't like footnotes all that much. I don't have strong objections
though. Is it used much?


 > It seems they've overcome the problem with using tabs for lists by 
 > * first level
 > ** second level
 > *** third level etc.

Interesting. I guess we have to find a better solution for the 'tab'
issue anyway, because 95% of all users are on Windows machines
which don't support tab in text fields. Although I don't like Windows
at all I guess it would be arrogant to burden 95% of users with that issue.

 > In fact there are a lot of nice things about the markup there. 
 > http://www.nbtsc.org:80/wiki/index.php3?TextFormattingRules

The only other thing I can see (apart from *,**,*** lists and
footnotes) is allowing some HTML tags. I think including
HTML tags inside wiki is like opening Pandora's box.
Sure, they can be useful and people might recognize them, but where
are you going to stop? People will keep nagging - wiki administrators
will have to have a very thick skin.

 > [dbmlib interface]
 > For that matter, should it be rewritten 
 > as a class instead of a function library?

Good question. I don't know. In a way, a function library is almost
a class anyways.
What would be the benefit of a class?

/Arno

Re: [Phpwiki-talk] html templates & layout

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

Nicholas,

you wrote:
 > could I suggest
 > 
 > top
 > -----------------
 > left | middle | right
 > -----------------
 > bottom

If you prefer this way you can easily incorporate this within the
top | bottom - schema. Assume we create one template where ##TEXT##
gets replaced by the wiki page.

Your file could look like this:

--- template file ----
include "top-template"
include "left-template"
##TEXT##
include "right-template"
include "bottom-template"
----------------------

Voila :o) Each section in its own file.


Or did I misunderstand your question?

/Arno

Re: [Phpwiki-talk] new wikinames and javascript vulnerability

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

could I suggest

top
-----------------
left | middle | right
-----------------
bottom

ie http://synarchy.net/phpwiki

I've found that its more flexible and less confusing this way, than having
top and left and right and bottom in the same places

also, http://www.editthispage.com is a great example of where PhpWiki might
go

for instance image shortcuts ie you register images urls and a shortcut,
then you can embed them in pages, kind of like the references feature

-N

>
> _______________
> header of page
>
> _______________
> body of page
>
>
>
>
>
> _______________
> footer of page
>

Re: [Phpwiki-talk] new wikinames and javascript vulnerability

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

Hey Arno! :-)

On Sun, 4 Jun 2000, Arno Hollosi wrote:

> All in all I don't like this fancy linking stuff at all. I think wiki
> benefits from the simple names. If I want to link to a page, I can
> make educated guesses. It's easier to link to old style names - I mean 
> what are the chances that I remember

I agree. In the course of composing a page at c2.com, I can make a guess
that there's a page called StanfordUniversity, but it's less certain that
there's a [Stanford University] or [StanfordUniversity] or just [Stanford
University|http://www.stanford.edu]. Or worse, all those and more.

> I can see some shortcomings in the old-style convention, this why I
> added the following patch to a private version of phpwiki:
> 	- allow digits instead of lowercase letters too (not uppercase!)
> 	  e.g. My2Cents, E13375P34k (eleetspeak ;o)
> 	- plus a version similar too '[]' I used '__' to mark it:
> 	  has to start with uppercase letter, afterwards any combination
> 	  of A-Za-z0-9 is allowed, e.g. __Singleword__, __FAQ__
> 
> I assume that the later extension gets rid of almost all cases where
> the simple wikinames don't seem enough. Yet it is restrictive enough
> to avoid chaos. What do you think about this scheme?

Probably better. What do you think about:

* Using the scheme you mention above as the default
* Leaving the code for [] links in, but anyone installing PhpWiki will
have to manually enable it?

I think we have 90% of the bugs worked out at this point anyhow, and I
think there are more interesting things to work on (more in a moment)...

 
> Btw, how about a better theming possibility of phpwiki?
> I changed the layout of phpwiki (see gtl.jeudego.org/wiki/),
> but it's not easy to do at all.
> Introducing an HTML template possibility should be easy to do.
> About three templates are needed: regular browsing,
> search results, editing. (Well editing is actually three files:
> edit text, edit links, and save ok.)

Yes, definitely. Someone told me recently (was it you?) that they got rid
of the page "Thanks for your edits" and instead take you directly back to 
the page you edited. I think that's a reasonable thing to do; I understand
that page is there to solve a caching problem with browsers of 4-5 years
ago.

At first it should be easy to isolate the top and bottom, which are already
in functions:

_______________
header of page

_______________
body of page





_______________
footer of page

All we need to do is keep the body of the wiki page isolated (like it is
I think, all the page text comes out of wiki_transform.php3, but I think 
it's prepending/appending the header and footer). How about having the header
and footer in a single file, and wiki_transform.php3 is inserted in the 
middle of the file?
 
> Another change I would like to see included before 1.2 is released
> are that references (backlinks) get their own database. Plus some nice 
> features that take advantage of this concept.

Yes, to get to the point I mentioned above, there's database work to do. 
You rightly pointed out some time ago we could do a lot more with a more
normalized schema. I'm all in favor of that.

For example, you also talked about better navigation in the Wiki, and 
I think there are a few "hard coded pages" like RecentChanges that would
make a Wiki more useful:

* MostActivePages would be the pages that get edited the most
* MostViewedPages would rank according to popularity (this means 
  the Wiki does its own logging, which in itself would be useful)
* MostLinkedToPages for the most frequently referenced
* OrderOfCreation would list pages according to their creation date. This 
  would be useful when a lot of new pages are added at once on a particular
  subject, and you could see how they were added
* more sophisticated searches

Also if we add user authentication, or some means of identity through
cookies, we can add: pages a person has edited, pages a person created,
and so on. Adding user auth is a wide open field, worth a long discussion
on its own.

To that end, we can start with the schema I suggested to you a while
ago, and implement that. I will take responsibility for DBM support; I 
know it's slow and has other problems, but I want to retain the goal 
of "just untar and use it!" so people can try it out easily. Anything
that we do with RDBMS's can be done with DBM files, but it won't scale.
Which is fine since Wikis don't scale either ;-)

Anyhow, to do the above, we just need to extend the db interface with
a few more functions, plus the rewrite for the normalized schema. I want
to add Postgresql and mSQL support too since a) both are popular and b) 
both are installed on my home box :-)


> I still think that EditLinks is awkward. Just had a look at tcl'ers:
> [http://....] produces [1] - nice.
> Inline images can be done the same way, e.g.
> [http://host.com/inline_me.png] vs. http://host.com/dont_inline.png
> 
> The only drawback I can see is that one can't reuse the link,
> i.e. using [1] more than once in the page. Shouldn't be a big problem -
> I have never seen a page that reused links.

I know you don't like them, but I am going to be stubborn about this :-)
There are other options to explore. In the six or so months I ran two 
Wikis at the New York Times, noone ever used references. Not even for 
embedding images. So I am thinking about a mechanism to embed any image 
in a page (in any format even). It's too clumsy to add a reference, then
save the page, edit it again just to get the EditLinks page and add the 
URL. It probably discourages image use. Something like 

[http://www.someurl.com/graphics/image.png]

would suffice.

Also, the NBTS Wiki changed the code to make references actual footnotes:
http://www.nbtsc.org:80/wiki/index.php3?FootNotes
The cool thing is the footnote links back to the line it's referenced 
from.

I'm sure they would contribute the code; I can tell you that references are
used by some PhpWiki users as well. (At least two people use PhpWiki 
on their home boxes for personal use, that I've heard from via email).

NBTS also has made a few interesting changes to the markup language.
It seems they've overcome the problem with using tabs for lists by 
using the Emacs convention of:

* first level
** second level
*** third level etc.

In fact there are a lot of nice things about the markup there. 
http://www.nbtsc.org:80/wiki/index.php3?TextFormattingRules

I know I've had a few other ideas floating around in my head the last few
days but I'm coming down with a cold and they are hiding somewhere. Let me
know what you think; I'd like to settle on the database schema soon, followed
by additions to the dbmlib interface. For that matter, should it be rewritten 
as a class instead of a function library?

cheers
sw

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

Re: [Phpwiki-talk] new wikinames and javascript vulnerability

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

You wrote:

 > Yes, the list can be configured so hitting "reply" sends to the list
 > instead of the author, but the Sourceforge documentation strongly
 > recommends against this (they don't say why though). I'm used to this with
 > other lists I'm on so I assumed it was for a good reason.

I assume it's because most lists in open source projects are set up
this way. But this is a small project & a small list so we can make
our own rules, no? Anyway, I think I can get used to this setting too.
This is not a big issue.


 > Anyway, I was thinking how to solve this; and it hits the deeper issue of,
 > "What is the best linking scheme?" It's one that best serves the users, of
 > course.

I take it as read that my "latest updates" email didn't reach you
before you wrote this. Seems the mailing list had some delay yesterday.

 > One thing I don't like about it is having to use url-encoded page names:
 > http://www.somewiki.com/wiki/index.php3?this%20is%20a%20page%20name
 > It's ugly and unreadable.

I guess this plus reasons of database design made the tcl'er wiki
replace the name by a number. It's readable, but not easy to memorize.
All in all I don't like this fancy linking stuff at all. I think wiki
benefits from the simple names. If I want to link to a page, I can
make educated guesses. It's easier to link to old style names - I mean 
what are the chances that I remember
[In the beginning - first stop for someone new to Tcl and Tk]
if not coming directly from that page?

I can see some shortcomings in the old-style convention, this why I
added the following patch to a private version of phpwiki:
	- allow digits instead of lowercase letters too (not uppercase!)
	  e.g. My2Cents, E13375P34k (eleetspeak ;o)
	- plus a version similar too '[]' I used '__' to mark it:
	  has to start with uppercase letter, afterwards any combination
	  of A-Za-z0-9 is allowed, e.g. __Singleword__, __FAQ__

I assume that the later extension gets rid of almost all cases where
the simple wikinames don't seem enough. Yet it is restrictive enough
to avoid chaos. What do you think about this scheme?

 > I also have reservations about allowing named URL's (i.e. 
 > [some link name| http://www.foo.com/] ) because Wiki pages and external
 > pages look the same... I like the fact that they are clearly
 > distinguished under the old linking scheme.

Naming might be ok. If we keep it then it should be possible to
name internal pages as well. Distinguishing between internal/external
links could be done by color or using some kind of emphasis suitable
for the current wiki theme.


 > Anyways, I think a simple approach is to write out all the kinds of links
 > we want to allow and then only allow those that fit the pattern.

I already have done something like this. Try to create a bad URL or
see the EditLinks page in the latest CVS version.


 > > While poking around I discovered that the $magic_quotes_gpc=1 bug
 > > seems to be back (this time for page names)
 >
 > That's odd. Maybe Sourceforge has it enabled? Or is the bug on your local
 > machine?

I don't know about sourceforge. I use my own machine. And here magic quotes
are on. The problem is not odd at all. Under the old scheme there were 
only letters in the pagename. Now everything can be in the name
including _\'"_ and these characters get quoted.


Btw, how about a better theming possibility of phpwiki?
I changed the layout of phpwiki (see gtl.jeudego.org/wiki/),
but it's not easy to do at all.
Introducing an HTML template possibility should be easy to do.
About three templates are needed: regular browsing,
search results, editing. (Well editing is actually three files:
edit text, edit links, and save ok.)

Another change I would like to see included before 1.2 is released
are that references (backlinks) get their own database. Plus some nice 
features that take advantage of this concept.

I still think that EditLinks is awkward. Just had a look at tcl'ers:
[http://....] produces [1] - nice.
Inline images can be done the same way, e.g.
[http://host.com/inline_me.png] vs. http://host.com/dont_inline.png

The only drawback I can see is that one can't reuse the link,
i.e. using [1] more than once in the page. Shouldn't be a big problem -
I have never seen a page that reused links.

/Arno

Re: [Phpwiki-talk] new wikinames and javascript vulnerability

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

On Sat, 3 Jun 2000, Arno Hollosi wrote:

> the new name linking scheme is vulnerable to attack.
> The exploit goes something like this:
> 
> external links:
> [external | javascript:alert('you are hacked')]
> 
> internal links:
> [internal: <script language=javascript>alert('bad stuff happens');</script>]
> 
> The javascript is executed both times.
> This opens the doors to Javascript exploits never ending.
> (Actually internal links allow to include arbitrary HTML)

Great catch, Arno. I tried out a couple other Wiki clones to see how they
behave and this attack did not work. I'm not at all ashamed that I
introduced such a wide hole, since it was a half-day's hacking to add the
new linking scheme :-)

Anyway, I was thinking how to solve this; and it hits the deeper issue of,
"What is the best linking scheme?" It's one that best serves the users, of
course.

One thing I don't like about it is having to use url-encoded page names:

http://www.somewiki.com/wiki/index.php3?this%20is%20a%20page%20name

It's ugly and unreadable. It's also unmemorable, which might even be
worse. A great thing about the old linking scheme is that it's so easy to
remember them:

http://c2.com/cgi-bin/wiki?LordOfTheFlies

Very effective.

I also have reservations about allowing named URL's (i.e. 
[some link name| http://www.foo.com/] ) because Wiki pages and external
pages look the same... I like the fact that they are clearly
distinguished under the old linking scheme.

Anyways, I think a simple approach is to write out all the kinds of links
we want to allow and then only allow those that fit the pattern. For
example,

[A PhpWiki page]

[an ftp link | ftp://ftp.redhat.com/pub/]

[a news link | news://secnews.netscape.com/]

[a web link | http://www.nytimes.com/]

[a mailto | mailto:sw...@pa...]

The Wiki does this already under the old linking scheme. It shouldn't be
hard to make sure it's universal.
 
> While I favour the approach to limit the charset allowed within '[]',
> I guess we can get by with the following fix:
> left of '|': encode text with htmlspecialchars()
> (same goes for names in RecentChanges)
> right of '|': forbid links starting with 'script' or 'java'

Right, in fact there are only six or so allowable patterns on the right
side (http, ftp, news, mailto, gopher, telnet, etc.)

> While poking around I discovered that the $magic_quotes_gpc=1 bug
> seems to be back (this time for page names) - not sure if this is
> also true when using mySQL.

That's odd. Maybe Sourceforge has it enabled? Or is the bug on your local
machine?

sw


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

Re: [Phpwiki-talk] new wikinames and javascript vulnerability

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

Yes, the list can be configured so hitting "reply" sends to the list
instead of the author, but the Sourceforge documentation strongly
recommends against this (they don't say why though). I'm used to this with
other lists I'm on so I assumed it was for a good reason.

Wikic and the Tcl'ers Wiki both use the [] linking scheme. I wonder if
they are vulnerable too?


sw

On Sat, 3 Jun 2000, Arno Hollosi wrote:

> 
> Hi there,
> 
> the new name linking scheme is vulnerable to attack.
> The exploit goes something like this:
> 
> external links:
> [external | javascript:alert('you are hacked')]
> 
> internal links:
> [internal: <script language=javascript>alert('bad stuff happens');</script>]
> 
> The javascript is executed both times.
> This opens the doors to Javascript exploits never ending.
> (Actually internal links allow to include arbitrary HTML)
> 
> While I favour the approach to limit the charset allowed within '[]',
> I guess we can get by with the following fix:
> left of '|': encode text with htmlspecialchars()
> (same goes for names in RecentChanges)
> right of '|': forbid links starting with 'script' or 'java'
> 
> I will look further into the issue and tell you with
> what I can come up.
> 
> While poking around I discovered that the $magic_quotes_gpc=1 bug
> seems to be back (this time for page names) - not sure if this is
> also true when using mySQL.
> 
> 
> /Arno
> 
> P.S: be careful when replying to the list.
> Apparently the "Reply-To:" header is not set, so a simple
> reply just goes to the author and not to the list.
> 
> Steve, can this be changed in the list settings?
> 
> _______________________________________________
> 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] latest updates

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

Hi again,

I guess this is enough for the weekend.
I fixed the following:

- fixed raw HTML & javascript exploits in pagenames and links
  added $AllowedProtocols to wiki_config while doing so.

- fixed mySQL support (new names were not supported!)

- fixed FindPage and search boxes (was broken)
  note: search terms are now preg_quote()'ed instead of chars removed

- fixed various magic_quotes_gpc=1 bugs (can appear in pagename now)

- fixed linking of new pagenames in RecentChanges
  and fix followup bug: deleting old entries works again


There is still a weird error when using wiki_dbm.php3 but *not*
when using wiki_mysql.php3.

Create a link containing a '\', like [bad '\ name].
Now edit [bad '\ name] -> save -> no page stored!
Instead a page title like [bad ' name] appears, but with no content.

Now the weird part: edit [bad '\ name] again -> save -> page is created!
What's going on here?


cheerio
/Arno

[Phpwiki-talk] new wikinames and javascript vulnerability

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

Hi there,

the new name linking scheme is vulnerable to attack.
The exploit goes something like this:

external links:
[external | javascript:alert('you are hacked')]

internal links:
[internal: <script language=javascript>alert('bad stuff happens');</script>]

The javascript is executed both times.
This opens the doors to Javascript exploits never ending.
(Actually internal links allow to include arbitrary HTML)

While I favour the approach to limit the charset allowed within '[]',
I guess we can get by with the following fix:
left of '|': encode text with htmlspecialchars()
(same goes for names in RecentChanges)
right of '|': forbid links starting with 'script' or 'java'

I will look further into the issue and tell you with
what I can come up.

While poking around I discovered that the $magic_quotes_gpc=1 bug
seems to be back (this time for page names) - not sure if this is
also true when using mySQL.


/Arno

P.S: be careful when replying to the list.
Apparently the "Reply-To:" header is not set, so a simple
reply just goes to the author and not to the list.

Steve, can this be changed in the list settings?

[Phpwiki-talk] initial cvs import/commit

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

Hi,

I've uploaded versions 1.0.3 and 1.1.4 to the CVS.
1.0.3 is tagged "release-1_0_3" and 1.1.4 is named
(you guessed it) "release-1_1_4"


Also, I have two patches I could add:

- headings: "!" in first column of line
	! makes a h3
	!! makes a h2
	!!! makes a h1

- enforce no hyperlinking with !WikiName


Should I add those patches?
Let me know.

/Arno

[Phpwiki-talk] test

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

Hello. Test post.

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