phpwiki-talk

Re: [Phpwiki-talk] Misc. comments

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

On Thu, 22 Feb 2001, Arno Hollosi wrote:
> 
> P.S: why doesn't http://phpwiki.sourceforge.net/alpha/ give the FrontPage?
> 

Hmm. Could it be... a bug? ;-)

Hmm. Ran the cron script and that brought it back to life.

~swain

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

Re: [Phpwiki-talk] Misc. comments

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

> >- ...I don't like messing with the include path. Instead I suggest
> > ... including all other files with "$phpwikidir/lib/filename.php".
> >Much easier to understand, less things to mess around. ...
>
> Hmm. I respectfully disagree.  ini_set("include_path", "/some/where")
> seems pretty clear to me.

Because of the usage of include_path you need FindFile & FindLocalizedFil=
e.
Otherwise all you needed doing would be testing for $phpwikidir/locale/..=
=2E.
Next point: people like Pablo combine phpwiki with other applications. Th=
ey=20
might make use of include_path as well. How big are the chances that ther=
e=20
is another lib/config.php, lib/main.php, ... To avoid collision we would=20
have to rename either the files to wiki_* or the directory to wiki_lib/*
Both look not attractive to me. Why mess with this stuff? include_path is=
=20
not as straight forward as $phpwikidir. What are the benefits?
I don't see any. As for cons, see above.

> The idea was to make clear distinctions between PHP code (located
> via include_path), language-independent data files (FindFile), and
> localizable data fiels (FindLocalizedFile).

Is the distinction by using different subdirectories not enough?

> >- about the templates: some are proposing to make them more
> > sophisticated. I argue against this. The end result is (after adding
> > loops etc.) reinventing PHP or other HTML-embedded languages.
>
> True, but we are inventing a (hopefully) simple HTML-embedded language.

The problem is: in the beginning it's simple. Soon you can think of more=20
and more fancy things and sooner or later you add them all until to the=20
point where your template language is as powerful as PHP. I'd like to=20
stress that again: I'm not totally opposed to your template stuff at=20
jeffshack_branch, but for wiki admins phpwiki it just gets more complicat=
ed=20
again: instead of 3 simple templates suddenly they are confronted with 14=
=20
templates. Sure it's more powerful, but does it need to be that powerful?
I argue that this is unnecessary bloat like in M$ programs. 99% of these=20
functionality will never be used. For those 1% of users who'd like to=20
modify e.g. the way search results look it is reasonable to force them to=
=20
edit the php files.


> What do the current templates provide now that couldn't be just as easi=
ly
> provided by straight PHP files consisting [...]
> one can not (I think) capture the output of an include("template.php") =
---
> it always gets spewed straight to the client.)

You could modify the template in a way so that
$x =3D file("template.php") - $html =3D eval($x) works.


> >- object orientation: I know Jeff likes OO, I don't.
> I guess that "easier/harder to understand" is very much a matter of
> personal opinion.

Ok, maybe I have to be more precise. I don't like your style of OO.
Don't take this as personal offense. I think you are a great programmer,=20
but you are clearly overdoing things. Take for example your transform.php=
=20
from jeffshack_branch and my one (the current transform.php). Yours is mo=
re=20
powerful, I'm sure. But mine __gets the job done__ too (maybe there will =
be=20
some minor modifications to it, but all in all it's ok). As for code=20
complextity, ease of understanding, ... I think that my version wins hand=
s=20
down (please correct me).


> The $dbi is a thing with a well defined set of methods which can be
> applied to it (DBLIB.txt).  Why not use the tools provided by the
> language to make this explicit.

I guess my objections are not so much in turning $dbi into a class.
I fail to see however, why we need classes like WikiLink.


> The $pagehash can, I think, truly benefit from becoming a bona fide
> object.

This is the one I strongly argue against. Currently $pagehash is a set of=
=20
variables which can be modified easily *throughout* the code. Once you tu=
rn=20
$pagehash into an object phpwiki becomes a completely different applicati=
on.


> There are many properties of a page which must be determined in a
> backend-dependent manner.  In some backends certain properties (e.g.
> backlinks) may be expensive to determine.  Different types of pagehash
> objects could be generated by the different backends.  They would all
> inherit basic and default methods from an underlying base class.

I fail to see why we need objects for this.=20


> 2. The SF task list has been growing at a seemingly exponential rate.=20

Only because it's on the task list doesn't mean we have to implement it.
Steve uses it as kind of wishlist - not as a definite TODO list.


> (For the most part, not my doing.)  All kinds of fancy features have be=
en
> discussed: page types, user authentication, version history.  If or whe=
n
> all these features are added, phpwiki is not going to be a small progra=
m.

I don't necessarily argue for a small program, but for a simple program.


> PS: Hey!  What's wrong with emacs?  What do you use/suggest?

I don't know of any good php development platforms. It's even worse if yo=
u=20
have lots of classes and stuff.


> PPS: The wiki (http://phpwiki.sourceforge.net/phpwiki.) might be a bett=
er
> place in which to carry out much of this discussion.

That may be true for the db api, but not for general discussions. I don't=
=20
like having to check many places for information - a mailing list is easy=
,=20
everything is in one place and it's pushed at me (instead of pulling it=20
from webpages). I think there's a reason why 99.9% of all open source=20
projects have mailing lists as their primary communication medium.


And yes, I think it would be healthy to establish some development goals=20
and guidlines for phpwiki. Implementing new features is fun. But without=20
clear goals we end up writing a big, bloated app capable of doing just=20
about everything, but so complex that not anyone is really going to like =
it=20
(and so far away from WikiPhilospohy that noone will recognize it as a wi=
ki=20
anymore). And maybe some coding guidelines should be discussed as well.

Compare pwiki and phpwiki - I think the reason why people choose phpwiki =
is=20
that it's so simple to install, customize, and extend. Once you take thes=
e=20
properties away phpwiki has lost it's appeal. Interestingly enough people=
=20
who are attracted to phpwiki because it's so simple are the first ones to=
=20
propose extensions to the functionality.


/Arno

P.S: why doesn't http://phpwiki.sourceforge.net/alpha/ give the FrontPage=
?

Re: [Phpwiki-talk] Misc. comments

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

Welcome back, Arno!

>- the new layout looks nice, but packing the whole page into a table just 
>to make it look nice is not really browser friendly.

Point taken.

- the rush for new wiki markup (tables, picture floats, ...) -- I don't 
like that at all.

I'll stay out of this one, except to say: I wanted simple tables, so I added 
them.
(And you're the one who added footnotes! :-) )

>- ...I don't like messing with the include path. Instead I suggest 
> ... including all other files with "$phpwikidir/lib/filename.php".
>Much easier to understand, less things to mess around. ...

Hmm. I respectfully disagree.  ini_set("include_path", "/some/where") seems
pretty clear to me.

>- the phpwiki code gets more and more complicated. That's against one of 
>our primary design goals (at least we had this goal some months ago).

More later. But, just in the way of explanation:

> * prepend.php -- why do we need this fancy error postponing?

I put that in because error/warning messages were making
for corrupt zip-dumps.  I suppose I hide it in libzip.php.

> * config.php -- why do we need FindFile(), FindLocalizedFile() etc.
> we didn't need these functions before. What makes them necessary now?

The idea was to make clear distinctions between PHP code (located
via include_path), language-independent data files (FindFile), and
localizable data fiels (FindLocalizedFile).  I'll admit that FindFile
and FindLocalizedFile should bear comments to that effect.

>There are other places as well. Keep the code simple. Fancy stuff should be 
>removed and the code kept clear and easy.
>
>- about the templates: some are proposing to make them more sophisticated.
>I argue against this. The end result is (after adding loops etc.) 
>reinventing PHP or other HTML-embedded languages. 

True, but we are inventing a (hopefully) simple HTML-embedded language.

I would argue that if one is to have templates at all, they should be there
to provide a clear separation between the design and programming of the page.
As it stands some things (like ###RELATEDPAGES###) have their layout set 
in PHP code, while others are layed out in the template files.  Adding
a new "theme" to a current PhpWiki more than likely requires editing some
PHP code.

What do the current templates provide now that couldn't be just as easily
provided by straight PHP files consisting of mostly HTML interspersed
with things like "<?php echo $RELATEDPAGES; ?>"?  At least this would
provide the opportunity to intersperse larger chunks of PHP code
to generate tables and such.  (Answer in part to this question: one
can not (I think) capture the output of an include("template.php") ---
it always gets spewed straight to the client.)

>We had some discussion about this some months ago - dig it up in 
>the list archive.

I tried, but haven't found anything particularly deep yet.  Geocrawler
keeps periodically crashing my Netscape, which makes it difficult.

>- object orientation: I know Jeff likes OO, I don't.

I guess that "easier/harder to understand" is very much a matter of personal
opinion.  I view the database backend as a thing.  A thing upon which
one can perform certain actions, some of which produce other things
(of a different sort).  It really just _screams_ "please implement me
as an object".  Maybe, in this case "object" is not the right word.
Perhaps "concrete class" and "class oriented" would be better terms.
The current code is already written pretty much in this manner.  The 
$dbi is a thing with a well defined set of methods which can be applied
to it (DBLIB.txt).  Why not use the tools provided by the language to
make this explicit.

The $pagehash can, I think, truly benefit from becoming a bona fide object.
There are many properties of a page which must be determined in a
backend-dependent manner.  In some backends certain properties (e.g.
backlinks) may be expensive to determine.  Different types of pagehash
objects could be generated by the different backends.  They would all
inherit basic and default methods from an underlying base class.

>In short: keep it simply. phpwiki is getting too fancy for my taste.

This is a point on which a policy decision should definitely be made.
(Or restated, if it's already been made.)

Some things to think about:

1. "Simple is in the eye of the beholder."  (See above.)

2. The SF task list has been growing at a seemingly exponential rate.  (For the
most part, not my doing.)  All kinds of fancy features have been discussed:
page types, user authentication, version history.  If or when all these
features are added, phpwiki is not going to be a small program.
   No matter what your definition of "simplicity" is, maintaining it
with all these features thrown in is not going to be easy.

Jeff

PS: Hey!  What's wrong with emacs?  What do you use/suggest?

PPS: The wiki (http://phpwiki.sourceforge.net/phpwiki.) might be a better
place in which to carry out much of this discussion.

[Phpwiki-talk] Misc. comments

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

Hi all,

I'm back. Some comments on recent developments:

- using stylesheets is a good idea - I'm a fan of stylesheets myself.

- the new layout looks nice, but packing the whole page into a table just=
=20
to make it look nice is not really browser friendly. I suggest using=20
stylesheets and <divs> for this layout trick. Thus older browsers are not=
=20
inconvinienced by a page table.

- the rush for new wiki markup (tables, picture floats, ...) -- I don't=20
like that at all. You are just reinventing HTML all over again. That is=20
*not* the purpose of wiki markup. Sure, the proposed markup is easy and=20
looks efficient, but for a newcomer it gets more and more complicated to=20
learn all these rules - heck, even I won't remember all markup and specia=
l=20
rules in a month if you continue at the current pace.

- the "exchange" of index.php and config.php is good. However, I don't li=
ke=20
messing with the include path. Instead I suggest setting a $phpwikidir in=
=20
index.php and including all other files with "$phpwikidir/lib/filename.ph=
p".
Much easier to understand, less things to mess around. See also next poin=
t.

- the phpwiki code gets more and more complicated. That's against one of=20
our primary design goals (at least we had this goal some months ago). It=20
will become harder to understand phpwiki and new users will feel=20
intimitated by the code. Examples:
   * prepend.php -- why do we need this fancy error postponing?
   Usually (in production), no errors should be displayed at all.
   Only for debugging one may wish to set error_reporting to E_ALL. And
   then I want those messages to appear whenever they actually happen - I
   don't care about the layout then.
   * config.php -- why do we need FindFile(), FindLocalizedFile() etc.
   we didn't need these functions before. What makes them necessary now?
   (see also $phpwikidir above).
There are other places as well. Keep the code simple. Fancy stuff should =
be=20
removed and the code kept clear and easy.

- about the templates: some are proposing to make them more sophisticated=
=2E
I argue against this. The end result is (after adding loops etc.)=20
reinventing PHP or other HTML-embedded languages. When I added ###IF### I=
=20
was very unhappy, but that was that. We had some discussion about this so=
me=20
months ago - dig it up in the list archive.

- object orientation: I know Jeff likes OO, I don't. Could someone please=
=20
explain me the advantages of using classes, when we use exactly *one*=20
instance of this class throughout the whole program? We don't even do=20
inheriting or other stuff. Just makes things harder to understand -- Also=
,=20
I don't consider emacs or other text editors a good development tool for =
OO=20
programs) -- these are also my *prime* argument against Jeff's db API. Th=
e=20
only thing I like about Jeff's API is the PageIterator - that one makes=20
sense.


That'll should do for now. In short: keep it simply. phpwiki is getting t=
oo=20
fancy for my taste.

/Arno

[Phpwiki-talk] Database schema redesign

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

Thanks to Jeff for all his work refactoring the site. There is a lot of
good stuff going on right now; see
http://phpwiki.sourceforge.net/phpwiki/index.php?CategoryNextWiki for
more.

Arno should be back now (and I'm sure he has lots of free time ;-) so we
need to reach a consensus on the next database API and schema.

I've been going crazy with the task manager at sourceforge, as you may
have noticed, and I've linked all tasks dependent on this thread. These
look like the most urgent issues, followed by what tables they affect (or
might affect, if we add tables):

* Unique IDs for Wiki pages (wiki, archive)

* Logging (new tables?)

* Version history/longer archive (archive)

* Link table + dangling references (wikilinks?)

* Email notification of page changes (subscribe to a page) (user prefs?)

* Authentication and user preferences (auth table? user prefs table?)

* Support multiple Wikis off the same installation (wiki, archive)


Things which might relate to this thread:

Page types (low priority for now)
InterWiki linking (add a new table or page?)
Revamped search (indexing pages for faster search?)

Rather than start a monster thread, we can discuss this on the Wiki
itself, or else we'll wind up with massinve quoting and replies. I've
repeatedly lost things in the past because the list was too active to
track them.

Do go there now and add your comments. 

http://phpwiki.sourceforge.net/phpwiki/index.php?NewDatabaseApi

Feel free to send notice to the list when you update NewDatabaseApi. (Be
nice and send the link.)

~swain

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

Re: [Phpwiki-talk] CategoryNextWiki

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

Oops, that's at
http://phpwiki.sourceforge.net/phpwiki/index.php?full=CategoryNextWiki

~swain

On Sun, 18 Feb 2001, Steve Wainstead wrote:

> 
> I started to organize a page linking to all the pages related to the
> development effort, when I found Jeff had already created a
> CategoryNextWiki. I'm marking a couple extra pages now. It all cries out
> for refactoring though.
> 
> ~swain
> 
> ...............................ooo0000ooo.................................
>    Hear FM quality freeform radio through the Internet: http://wcsb.org/
>                      home page: www.wcsb.org/~swain 
> 
> 
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> http://lists.sourceforge.net/lists/listinfo/phpwiki-talk
> 

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

[Phpwiki-talk] CategoryNextWiki

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

I started to organize a page linking to all the pages related to the
development effort, when I found Jeff had already created a
CategoryNextWiki. I'm marking a couple extra pages now. It all cries out
for refactoring though.

~swain

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

[Phpwiki-talk] alpha site updated

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

Sourceforge recently fell back to the backup development server, for
reasons I don't know. This caused the loss of the new crontab I wrote and
the alpha site did not update yesterday and today.

I updated it by hand today and reinstalled the crontab.

~swain

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

[Phpwiki-talk] Apache Rewrite

[Reini U. <ru...@x-...>]

Offtopic question, but for phpwiki:

This
RewriteEngine On
RewriteRule	^/wiki$	        /home/rurban/acadwiki-1.3.1pre/index.php
RewriteRule	^/wiki/(.+)$	/home/rurban/acadwiki-1.3.1pre/index.php/$1

for example converts /wiki/FrontPage to <path>/frontpage on Apache 3.14,
Win32.
Is this only on Win32?
I hate lowercased pages.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] tables again

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

On Thu, 15 Feb 2001, Aredridel wrote:

> I'd say that tables should always have a small, tasteful border: reason
> being to avoid people using them as layout controls, and instead, use 'em as
> tabular data only.

I agree with Ari here. Tables are for tabular data. A Wiki is for
hypertext.

~swain

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

Re: [Phpwiki-talk] images

[Reini U. <ru...@x-...>]

> Thomas Kalka schrieb:
> How about taking the fancy table formatting ( i mean < ^ > ) to pictures ?
> [<pic.png] text floates at right i.e. picture is going to the left side
> [>pic.png] text floates at left i.e picture is going to the right side
> [^pic.png] no text arround picture i.e picture is going in the middle
> The picture [pic.png] where it is

good, simple and easy to implement. 

I only have to think of possible clashes with the wanted feature imagelinks.
  [<pic.png|LinkedPage] should display the png not the text as "<pic.png".
  but it seems to be okay.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] tables again ,css

[Thomas K. <th...@co...>]

> I'd say that tables should always have a small, tasteful border: reason
> being to avoid people using them as layout controls, and instead, use 'em
as
> tabular data only.
>
> I'd say the same for joined cells-- why bother? It's not simple markup,
and
> rather against the spirit of Wiki.

Regarding all this comments to tables i would suggest:

leave tables as they are, ommit any customization of table layout and do it
all in the stylesheet.

If one could add a [style.css] to set the stylesheet and/or something to
change the actual class
(maybe [class:aclass]) then the whole things would be higly configurable.

Thomas

Re: [Phpwiki-talk] images

[<d9...@na...>]

On Thu, Feb 15, 2001 at 10:51:24PM -0800, Aredridel wrote:
> > How about taking the fancy table formatting ( i mean < ^ > ) to pictu=
res =3D
> > ?
> >=20
> > [<pic.png] text floates at right i.e. picture is going to the left si=
de
> > [>pic.png] text floates at left i.e picture is going to the right sid=
e
> > [^pic.png] no text arround picture i.e picture is going in the middle
> > The picture [pic.png] where it is
>=20
> Oooh, not a bad syntax.... hmm!
>=20
> I like it -- clean, simple to implement, more or less understandable...=
 Wow.

Yes, very nice! If you can vote on new features, I give this high points.
And if you have > in a picture file name, you are stupid.

--=20
___\ Jon =C5slund

Re: [Phpwiki-talk] tables again

[Aredridel <are...@nb...>]

> Does anybody have an idea how to markup tables in wiki, so that they
> appear without a border ?
> 
> Maybee we should change to=20
> 
> | this | is | a | table without border
> 
> || this on || is with border
> 
> 
> || another || with || border
> ||+ first two cells joined  || third cell=20

I'd say that tables should always have a small, tasteful border: reason
being to avoid people using them as layout controls, and instead, use 'em as
tabular data only.

I'd say the same for joined cells-- why bother? It's not simple markup, and
rather against the spirit of Wiki.

Ari

Re: [Phpwiki-talk] images

[Aredridel <are...@nb...>]

> How about taking the fancy table formatting ( i mean < ^ > ) to pictures =
> ?
> 
> [<pic.png] text floates at right i.e. picture is going to the left side
> [>pic.png] text floates at left i.e picture is going to the right side
> [^pic.png] no text arround picture i.e picture is going in the middle
> The picture [pic.png] where it is

Oooh, not a bad syntax.... hmm!

I like it -- clean, simple to implement, more or less understandable... Wow.

Ari

[Phpwiki-talk] images

[Thomas K. <th...@co...>]

How about taking the fancy table formatting ( i mean < ^ > ) to pictures =
?

[<pic.png] text floates at right i.e. picture is going to the left side
[>pic.png] text floates at left i.e picture is going to the right side
[^pic.png] no text arround picture i.e picture is going in the middle
The picture [pic.png] where it is




What do you think ?

Thomas

Re: [Phpwiki-talk] tables again

[Thomas K. <th...@co...>]

> My take on it is that tables are to allow one to present data which wants
> to be tabular in a tabular form.  They're not in the wiki to allow
> for fancy diddling and customization of the layout.

I agree completely.

My requests on a wiki are
*make input as easy as possible
*make output as helpfull as possible
*find a structure, where any helpfull text fits in

helpfull texts could be
*instructions (demands: images, tables)
*theoretical papers (footnotes, chapters, references,annotations )
*collections (tables wiht guides for the eye)


But think of these two examples

a) you like to have a instruction how to cook something,
then you would like to have a table with text and pictures, without any
borders

| text describing procedure | [picture.png] %%% title

b) you have a long list of data (for example train arrivals or something
like that)
its not so nice to read without help, but this might be also different
colouring from line to line


> What about just one thin border around the whole table (no lines between
> cells.)  Just so that it's obvious that it's a table?


>
> (I'm open to suggestions regarding whether the tables should be centered
> or not as well.)

In my oppinion not centered.


>
> Note also, that in the CVS I've changed the default justification from
> centered to left-justified.   (That's the HTML default anyway,) and
> it seems like that's the most common choice.

agreed

Thomas

Re: [Phpwiki-talk] tables again

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

>Does anybody have an idea how to markup tables in wiki, so that they
>appear without a border ?

Yeah, I've been noticing that mostly I've been wanting border-less tables
as well.  Perhaps tables should always be border-less?

What about just one thin border around the whole table (no lines between
cells.)  Just so that it's obvious that it's a table?

(I'm open to suggestions regarding whether the tables should be centered
or not as well.)

> | this | is | a | table without border

> || this on || is with border

That's non-intuitive for me.  And seems a bit complicated.

My take on it is that tables are to allow one to present data which wants
to be tabular in a tabular form.  They're not in the wiki to allow 
for fancy diddling and customization of the layout.


Note also, that in the CVS I've changed the default justification from 
centered to left-justified.   (That's the HTML default anyway,) and
it seems like that's the most common choice.

Jeff

[Phpwiki-talk] object orientiation

[Thomas K. <th...@co...>]

I my thougths a first step towards a object-oriented wiki could be to =
allow for nested
wiki-tags like in the following examples:

WikiTag.SubWikiTag.SubSubWikiTag is interpreted as a whole

..SubWikiTag  in a page is prepended with the page-name in links=20

for example in the the page ThomasKalka
..ToDo would link to ThomasKalka.ToDo


What do you think ??

Thomas

[Phpwiki-talk] tables again

[Thomas K. <th...@co...>]

Does anybody have an idea how to markup tables in wiki, so that they
appear without a border ?

Maybee we should change to=20

| this | is | a | table without border

|| this on || is with border


|| another || with || border
||+ first two cells joined  || third cell=20


??? Thomas
=20

[Phpwiki-talk] alpha site updating

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

The alpha site updated correctly last night. You can play with it at:

http://phpwiki.sourceforge.net/alpha/

Thanks to Jeff for a new logo!

~swain

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

[Phpwiki-talk] more on the alpha site

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

I've added a cron job to update the alpha site nightly at 5:50 am PST. One
problem is the index.php; for now, I have a backup copy that I overwrite
the version coming out of CVS with (to preserve the database info).

This means if there are important changes to index.php it will have to be
corrected by hand.

The good thing about this is it's a sort of nightly test. It would be
better if the alpha site were wiped and installed from scratch every
night, but that would be quite a trick. I could write ex scripts to make
the edits to index.php as needed, but then when the file changes it might
break the script. There's probably a way around this.

The mysql install was a little trickier than in the past; the definition
of the database name should be closer to the other database info, b/c at
first I thought there just wasn't a field for it.

Also, from the point where I installed it (nice install page Jeff!) there
were Incoming and Outgoing links with numbers and I don't know where they
came from, nor do they seem to be updating. At least, the numbers on
MostPopular don't match. They definitely don't match the current site, so
there can't be some database mixup.

~swain

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

[Phpwiki-talk] alpha site up

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

You can see the alpha site at 

http://phpwiki.sourceforge.net/alpha/

However you will need to rewrite the links to:

http://phpwiki.sourceforge.net/alpha/index.php/WikiWikiWeb

for example. I've filed a bug report about this.


I'll have a cron job written shortly to update the the alpha site every
night.

~swain

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

Re: [Phpwiki-talk] test-wiki

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

In message <3A8...@x-...>,Reini Urban writes:
>What about removing %%Search%% and %%Fullsearch%% sooner or later?
>The new MacigPhpWikiURLs are functionally equivalent and even better.
>
>  [ Title Search | phpwiki:?action=search&searchterm=() ] 
>  [ Full Search | phpwiki:?action=search&searchtype=full&searchterm=() ] 

Yes, I think that's a good plan eventually.

Note that while I like the idea of the magic phpwiki:, I don't
really like the grammar I implemented, and would appreciate
suggestions for improvements.

Pros:
  Very flexible.   Can embed all sort of links/forms for
  administrative actions without having a special token
  (like %%Search%%) for everything one might want to do.

Cons:
  The syntax is a bit confusing.  (Not a huge con,
  since the average user, or even average admin never has to 
  write any of these links.)

  Not flexible enough.
  As an example: on the UserPreferences page,
  it would be nice to have a form with two input fields
  (edit area height and width).  It would also be nice to
  set the default values for these inputs to the users
  current settings.  Can't do that with the current syntax.
  (Now there's two seperate forms --- one for height, one
  for width --- and no (or constant) default values.)
  Tokens like %%EDIT_WIDTH%% would solve this (the default value)
  problem, but then, we wanted to get away from tokens.
  Or did we?

  Another example: how to exand/modify the syntax to allow
  for image buttons, etc... as Reini has requested?

Another consideration is that it would be nice to be able to
(easily) generate these sorts of links in the template files.

For example, one might like to put a search form somewhere in
the browse template --- it would be convenient not to have to enter
the entire form by hand.

Also, it would eliminate a lot of the template tokens we have now.
E.g. it would be nice to be able to say someting like
  %%%[Edit this page|phpwiki:?action=edit]%%% 
rather than
  <a class="wikiaction" href="###ACTION###edit">Edit this page</a>
Or 
  See %%%[phpwiki:UserPreferences]%%% .
rather than
  See <a class="wikilink" href="###BROWSE###UserPreferences"><span 
class="wikiword">UserPreferences</span></a>.

Perhaps we could introduce a way to delimit text in the templates
which should be run through transform.php?  e.g:
  {{{See UserPreferences.}}}


(The option to use PATH_INFO or not has made the task of
generating URLs in the templates much more complicated than
it used to be.   This is compounded by all the class= args
added for CSS support.)


While we're on the subject of templates, I think it would
be nice to implement some sort of "loop" construct in
the templates.

In the not too distant future (once we move to multiple saved 
versions) were going to have to generate more tables (and
more complicated tables) than we are now.

I think that it would be nice to get the table layout
into the template files, rather than being hard-coded into the
php code.
 

Jeff

[Phpwiki-talk] ChangeLog in nightly builds

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

A full ChangeLog will appear in all nightly builds, once SourceForge
decides to restart crond. It's been down a few days but they must have
forgotten the root password. >:-P

Of course, one should not look a gift horse in the mouth, as the old
saying goes.

~swain

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