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