phpwiki-talk

Re: [Phpwiki-talk] forum posts -> phpwiki-talk

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

Later I reread Jeff's comments about setting up task lists to email
phpwiki-talk or some other notification list. Does anyone object if posts
to Open Discussion and Help are automatically posted to phpwiki-talk? It
seems to me the traffic here is managable and also the best place to get
help or discuss features.

~swain

On Fri, 16 Nov 2001, Steve Wainstead wrote:

>
> Hello,
>
> I've updated the preferences for two of the forums on Sourceforge, "Help"
> and "Open Discussion," so that posts to them will be forwarded to
> phpwiki-talk. This should not cause a significant increase in traffic.
>
> I've created a new mailing list, phpwiki-bugs, and I will have all bug
> reports in the bug tracker mailed to this list. If you subscribe to
> phpwiki-bugs you will get email as soon as a user posts.
>
> ~swain
>
> ---
>                   http://www.panix.com/~swain/
> "Without music to decorate it, time is just a bunch of boring
> production deadlines or dates by which bills must be paid."
>                      -- Frank Zappa
>
>
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwiki-talk
>

---
                  http://www.panix.com/~swain/
"Without music to decorate it, time is just a bunch of boring
production deadlines or dates by which bills must be paid."
                     -- Frank Zappa

Re: [Phpwiki-talk] [urls] stuck in mod_rewrite for prettifying urls

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

On Fri, 16 Nov 2001 10:42:50 +0100
"Tara Star" <te...@cl...> wrote:

> Adam Shand wrote:
> 
> >>I would like http://spirolattic.net/ to point to the wiki, and
> >>http://spirolattic.net/RecentChanges to point to RecentChanges... you
> >>get the idea.

Try:
(I'm assuming this is going in a .htaccess file, if it's going into
the server config file, you need to handle/expect leading /'s in the
URLs.  I'm also assuming you've copied index.php to 'wiki'.)


RewriteEngine On
RewriteRule ^wiki       -        [L]
RewriteRule ^wiki/.*    -        [L]
RewriteRule ^(.*)       wiki/$1  [L]


I think you'll also have to manually define VIRTUAL_PATH to the empty
string, in 'wiki' (assuming 'wiki' is your index.php.)

Re: [Phpwiki-talk] variable for page name?

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

On Fri, 16 Nov 2001 17:15:02 +0100
"Tara Star" <te...@cl...> wrote:

> I'm preparing a private wiki in which I'm going to allow certain pages 
> to be visible to the public. I'm doing it (rather clumsily, I'll admit) 
> by putting the whole page display into a control statement, like this:
> 
> if ($user->is_admin() || array_search($pagename, $public_pages))

I think you want:
 if ($user->is_authenticated() || in_array($PAGE, $public_pages))

(I'm assuming you want anyone who is "signed in" to be able to see all
pages.)

[Phpwiki-talk] variable for page name?

[Tara S. <te...@cl...>]

Is there a variable, that I can use in control statements in the=20
template pages, and whose value is the name of the current page?

I'm preparing a private wiki in which I'm going to allow certain pages=20
to be visible to the public. I'm doing it (rather clumsily, I'll admit)=20
by putting the whole page display into a control statement, like this:

if ($user->is_admin() || array_search($pagename, $public_pages))
{
show the page
} else
{
log in, please
}

I've gone through Template.php as well as I can, I've tried just using=20
"$pagename", but it's obviously not it.

Is there a variable somewhere I can use in the templates to check if the=20
name of the current page is in my $public_pages array?

Thanks :)

Tara

PS - btw, I've solved my not-so-mod_rewrite problems. See=20
http://spirolattic.net/ for the result :)

--=20
Je r=E9ponds au mieux de mes connaissances
Climb to the Stars! - http://climbtothestars.org/
SpiroLattic - http://climbtothestars.org/spiro/
Pompeurs Associ=E9s - http://pompage.net/

Re: [Phpwiki-talk] [urls] stuck in mod_rewrite for prettifying urls

[Tara S. <te...@cl...>]

Adam Shand wrote:

>>I would like http://spirolattic.net/ to point to the wiki, and
>>http://spirolattic.net/RecentChanges to point to RecentChanges... you
>>get the idea.
>>
>=20
> rather then mod_rewrite it why not just move all the wiki source files =
up
> one directory so they actually live at http://spirolattic.net/ ?


For complicated Tara-reasons, it's not possible (the wiki is accessible=20
through two domain names, so the mapping is a little delicate).


> if you want the rewritten rule to show up in the users browser you need=
 to
> have mod_proxy enabled as well and have these options at the end of rul=
e
> [P,L] for example here's a mod_rewrite rule i used to do to make a frie=
nds
> web site which he wanted to show up on my site to where it was actually
> hosted on uswest:
>=20
>   RewriteRule  ^/(.*)  http://www.users.uswest.net/~nift/$1    [P,L]


Tried this:

RewriteRule ^/(.*) http://climbtothestars.org/outside_wiki/$1 [P,L]

doesn't seem to work for me.

Actually, I don't want the re-written rule to show up in the browser. I=20
want http://spirolattic.net/RecentChanges to stay in the browser, even=20
if the "real" place of the thing is=20
http://spirolattic.net/wiki/RecentChanges.


>>RewriteRule ^([^wiki]+)$ wiki/$1
>>
>=20
> i think you want something more like this (assuming that there are not
> other non-wiki pages on spirolattic.net ... if there are then you're go=
nna
> have to figure out a way to tell what's a wiki page adn what isn't):
>=20
>   RewriteRule ^/(.*) http://spirolattic.net/wiki/$1	[P,L]


the problem with something like this is that it will rewrite the=20
rewritten uri -> hence ^/([^wiki]*) to prevent it from matching a uri=20
with "wiki" in it.


>>which of course fails miserably.
>>
>=20
> if i remember my regex's correctly what you're doing is creating a
> character class with the []'s so rather then matching "wiki" plus stuff
> you're matching one or more w's, i's or k's.


I'm actually trying to match "non-wiki-stuff". When you're matching=20
"positive", I think (well, that's what works in the other rewrite rules=20
I have running at the moment) that (india|logbook) will match either=20
"india" or "logbook". So I tried doing this: [^(wiki)] - but it doesn't=20
work either.

*sigh*

if anybody else has other ideas for this, I'll be glad to hear them -=20
but please don't lose any time on it.

:)

Tara



--=20
Je r=E9ponds au mieux de mes connaissances
Climb to the Stars! - http://climbtothestars.org/
SpiroLattic - http://climbtothestars.org/spiro/
Pompeurs Associ=E9s - http://pompage.net/

Re: [Phpwiki-talk] xhtml-compliant wiki

[Tara S. <te...@cl...>]

Steve Wainstead wrote:


> I want PhpWiki to support Lynx, Emacs' w3 mode, and all browsers of all
> versions. It's just text. I think it's more important to focus on featu=
res
> like version control, XML dumps, and features like that... the layout
> should be uncluttered and simple. A Wiki, any Wiki, is about ease of us=
e
> and writing hypertext.


the "new" table-less approach is much more lynx-etc-friendly than the=20
"old" table-ridden layouts.


> Out of the box, PhpWiki should support all browsers. I think that xhtml
> output won't pose much trouble: if you properly add spaces in tags like
> <br />, the 4.x browsers don't care. (However, is that all 4.x browsers=
?)


it's not just <br />. It's also a question of closing tags, nesting=20
elements properly, and avoiding the use of what I call "presentational"=20
html.

old browsers shouldn't choke on <br />: the "/" is treated as an unknown=20
attribute and ignored (that happens because we leave a space; without a=20
space, some browsers may choke).


> So, out of the box: no Javascript, no fancy CSS. Please. We can pack in
> all we want though, and make it easy to enable. By all means, styleshee=
ts
> and Javascript only supported in Mozilla would be most welcome by me! :=
-)


the great idea of css is that it is frighteningly easy to edit. If you=20
give a css-only version of php-wiki, and I decide I want to use fancy=20
css that isn't supported by old browsers, it's very easy for me to=20
change it - so no problem with that.

The problem is when the (x)html itself isn't "100% clean" - see what I me=
an?

:)


Tara


--=20
Je r=E9ponds au mieux de mes connaissances
Climb to the Stars! - http://climbtothestars.org/
SpiroLattic - http://climbtothestars.org/spiro/
Pompeurs Associ=E9s - http://pompage.net/

[Phpwiki-talk] forum posts -> phpwiki-talk

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

Hello,

I've updated the preferences for two of the forums on Sourceforge, "Help"
and "Open Discussion," so that posts to them will be forwarded to
phpwiki-talk. This should not cause a significant increase in traffic.

I've created a new mailing list, phpwiki-bugs, and I will have all bug
reports in the bug tracker mailed to this list. If you subscribe to
phpwiki-bugs you will get email as soon as a user posts.

~swain

---
                  http://www.panix.com/~swain/
"Without music to decorate it, time is just a bunch of boring
production deadlines or dates by which bills must be paid."
                     -- Frank Zappa

[Phpwiki-talk] about 1.2.2

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

I just want to note I ran many tests on version 1.2.2 today, from flat
file to Postgresql to MiniSQL to dba. There are still some bugs lurking
(backslashes in page titles are a problem) but otherwise I think the
project is better than ever. Now if only the PEAR DB.php people could step
on the gas!! :-)

I'm sure there are more bugs to be found but everyone who's contributed
has a lot to be proud of.

~swain

---
                  http://www.panix.com/~swain/
"Without music to decorate it, time is just a bunch of boring
production deadlines or dates by which bills must be paid."
                     -- Frank Zappa

[Phpwiki-talk] PhpWiki 1.2.2 out now

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

Release 1.2.2, which is the stable branch of PhpWiki, is out today. This
release has numerous user-contributed bug fixes (god bless users!) and now
has support for MSSQL thanks to Andrew Pearson.

ChangeLog is available here:

http://sourceforge.net/project/shownotes.php?release_id=61607

Download and have fun!

cheers
~swain

---
                  http://www.panix.com/~swain/
"Without music to decorate it, time is just a bunch of boring
production deadlines or dates by which bills must be paid."
                     -- Frank Zappa

Re: [Phpwiki-talk] xhtml-compliant wiki

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

On Thu, 15 Nov 2001, Adam Shand wrote:

>
> > (I like your SpiroLattic layout very much.  Though, personally, I
> > think it's too early to drop support for 4.0 browsers, I suppose I
> > could be convinced otherwise.)
>
> i think shipping in a form which doesn't support 4.0 browsers is okay so
> long as there's a fairly trivial option to revert back to something saner
> for people who need support for older clients.
>
> at somepoint we have to ditch 4.0 clients and focus effort on doing the
> right thing in the future and i think we're pretty close to that point.  i
> was the last person i knew that used netscape 4.77 on a regular basis and
> i swapped over to mozilla/galeon a few months ago and have been very
> happy.

I've read that IE is as much as 80% of the browser traffic today. I think
this is really unfortunate.

I want PhpWiki to support Lynx, Emacs' w3 mode, and all browsers of all
versions. It's just text. I think it's more important to focus on features
like version control, XML dumps, and features like that... the layout
should be uncluttered and simple. A Wiki, any Wiki, is about ease of use
and writing hypertext.

Out of the box, PhpWiki should support all browsers. I think that xhtml
output won't pose much trouble: if you properly add spaces in tags like
<br />, the 4.x browsers don't care. (However, is that all 4.x browsers?)

So, out of the box: no Javascript, no fancy CSS. Please. We can pack in
all we want though, and make it easy to enable. By all means, stylesheets
and Javascript only supported in Mozilla would be most welcome by me! :-)

~swain


---
                  http://www.panix.com/~swain/
"Without music to decorate it, time is just a bunch of boring
production deadlines or dates by which bills must be paid."
                     -- Frank Zappa

Re: [Phpwiki-talk] [urls] stuck in mod_rewrite for prettifying urls

[Adam S. <ad...@pe...>]

> I would like http://spirolattic.net/ to point to the wiki, and
> http://spirolattic.net/RecentChanges to point to RecentChanges... you
> get the idea.

rather then mod_rewrite it why not just move all the wiki source files up
one directory so they actually live at http://spirolattic.net/ ?

> So, armed with mod_rewrite and a lot of courage, I produced this:

if you want the rewritten rule to show up in the users browser you need to
have mod_proxy enabled as well and have these options at the end of rule
[P,L] for example here's a mod_rewrite rule i used to do to make a friends
web site which he wanted to show up on my site to where it was actually
hosted on uswest:

  RewriteRule  ^/(.*)  http://www.users.uswest.net/~nift/$1    [P,L]

> RewriteRule ^([^wiki]+)$ wiki/$1

i think you want something more like this (assuming that there are not
other non-wiki pages on spirolattic.net ... if there are then you're gonna
have to figure out a way to tell what's a wiki page adn what isn't):

  RewriteRule ^/(.*) http://spirolattic.net/wiki/$1	[P,L]

> which of course fails miserably.

if i remember my regex's correctly what you're doing is creating a
character class with the []'s so rather then matching "wiki" plus stuff
you're matching one or more w's, i's or k's.

adam.

[Phpwiki-talk] [urls] stuck in mod_rewrite for prettifying urls

[Tara S. <te...@cl...>]

I've successfully set up http://spirolattic.net/wiki/ to point to my=20
wiki (but as you've understood from my previous posts, I'm not satisfied=20
with that).

Sorry if I'm repeating myself, btw (I hope I'm not rambling too much, I=20
got a bit of a concussion this morning).

I would like http://spirolattic.net/ to point to the wiki, and=20
http://spirolattic.net/RecentChanges to point to RecentChanges... you=20
get the idea.

So, armed with mod_rewrite and a lot of courage, I produced this:

RewriteRule ^([^wiki]+)$ wiki/$1

which of course fails miserably.

http://spirolattic.net/ takes us nowhere, and=20
http://spirolattic.net/RecentChanges drops us on the HomePage.

Is anybody out there inspired?

Thanks if you can help :)

Tara

PS- tell me if I'm straying too far away from WikiThings
--=20
Je r=E9ponds au mieux de mes connaissances
Climb to the Stars! - http://climbtothestars.org/
SpiroLattic - http://climbtothestars.org/spiro/
Pompeurs Associ=E9s - http://pompage.net/

Re: [Phpwiki-talk] xhtml-compliant wiki

[Tara S. <te...@cl...>]

Jeff Dairiki wrote:


> (I like your SpiroLattic layout very much.  Though, personally, I
> think it's too early to drop support for 4.0 browsers, I suppose I coul=
d
> be convinced otherwise.)


Thanks!

seen http://alistapart.com/stories/tohell/ ? (re-chewed in a way on my=20
http://climbtothestars.org/coding/tableless/)

dropping support for old browsers doesn't necessarily mean you have to=20
go "all the way", like suggested here (and like I do), and remove ALL=20
formatting for them.

The main point is to try to stop using presentational HTML to work=20
around broken browser limitations.

you can also serve poor NN4.x a very light stylesheet, so that it is not=20
too "plain HTML" - a few font colors, margins if it doesn't choke on=20
them, etc.

I don't do it, because I believe there is a point in encouraging people=20
to use the more standards-compliant browsers, and serving old browsers a=20
bland (but perfectly accessible, mind you!) layout can help move in that=20
direction.

MHO

:)

Tara




--=20
Je r=E9ponds au mieux de mes connaissances
Climb to the Stars! - http://climbtothestars.org/
SpiroLattic - http://climbtothestars.org/spiro/
Pompeurs Associ=E9s - http://pompage.net/

Re: [Phpwiki-talk] xhtml-compliant wiki

[Adam S. <ad...@pe...>]

> (I like your SpiroLattic layout very much.  Though, personally, I
> think it's too early to drop support for 4.0 browsers, I suppose I
> could be convinced otherwise.)

i think shipping in a form which doesn't support 4.0 browsers is okay so
long as there's a fairly trivial option to revert back to something saner
for people who need support for older clients.

at somepoint we have to ditch 4.0 clients and focus effort on doing the
right thing in the future and i think we're pretty close to that point.  i
was the last person i knew that used netscape 4.77 on a regular basis and
i swapped over to mozilla/galeon a few months ago and have been very
happy.

adam.

Re: [Phpwiki-talk] xhtml-compliant wiki

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

On Sun, 11 Nov 2001 17:34:11 +0100
"Tara Star" <te...@cl...> wrote:

> the stylesheets which came with the script seemed pretty complex and had

> lots of useless classes for me, n
... 
> so let's say it would be possible to use templates similar to the 
> existing ones with xhtml-compliant code, but they are uselessly heavy
imho.
> 
> I guess it wouldn't take too long, based on the html templates I have, 
> to write a css sheet to give the wiki a look similar to the actual 1.3.1

>   one (give or take a few details).

I'm a programmer, not a designer, Jim!

I would just like to take this opportunity to say: I will in no way be
insulted if y'all decide to change the default look/layout of 1.3.x.  

(I like your SpiroLattic layout very much.  Though, personally, I
think it's too early to drop support for 4.0 browsers, I suppose I could
be convinced otherwise.)

Re: [Phpwiki-talk] wanting to do weird things again

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

On Thu, 15 Nov 2001 20:58:17 +0100
"Tara Star" <te...@cl...> wrote:

> See the idea? use the same engine for two different wikis.

Yes, that's exactly the reason we moved the config info from 
lib/config.php into index.php.

> Just one thing:
> 
> when I have to create tables in the db, with:
> 
> mysql -uuser -ppassword dbname <schemas/schema.mysql
> 
> what am I doing exactly?

The command 'mysql -uuser -ppassword dbname' connects to the
mysql server (on localhost) using the username 'user'
and password 'password'.  It then effectively does a 'use dbname;'.

The '< schemas/schema.mysql' feeds the contents of the file
schemas/schema.mysql into the standard input of the 'mysql ...'
command.  Essentially, it causes mysql to execute the SQL commands
in schema.mysql.  Those commands:
 1. Delete any pre-existing tables in the current database which
    are named: page, version, recent, nonempty, or link.
 2. Creates new tables with those names, with schema (columns)
    the way PhpWiki wants them to be.   
Roughly: it erases an PhpWiki data which might be in the selected
database,
and then re-initializes the tables (to any empty wiki).  (Then, the
first time you try to browse the HomePage of an empty wiki, PhpWiki will
load it up with the default pgsrc...)

Since this erases existing data in the selected database, you are
right to be wary of performing this command.

> because I see a file named schema.mysql in the 
> schemas directory... so I guess we're using that, right?

Right.  But only when you run the 'mysql < schema.mysql' command.

> And at the top 
> of this file is written "use DbForWiki1" - I think that was added at 
> some point earlier for trying to get the whole thing to work.

GET RID OF THAT LINE!  It's not necessary, if you leave it there,
then the command you propose above will erase all data in DbForWiki1.
(You must have added it.  There is no "use" line in the stock
version.)

> so, what should I do? try removing the "use DbForWiki1" line and see if 
> wiki1 still works? (do I run any risk of breaking something if I do
that?)

The contents of schema.mysql are only used when you initialize the
database.  You could delete schema.mysql, or edit it in any way you
want now, and it won't break your existing wiki.  (Unless of course
you feed it to mysql again.)

> or should I duplicate schema.mysql into wiki2schema.mysql, and change 
> the "use" line? would this break things later on for wiki2?

Just delete the "use" line.  The only time you should have to
edit schema.mysql is if you set $DBParams['prefix'] to a non-empty
value.  (You would want to do this if you wanted to run two independent
wikis in one mysql database.  Since you have the ability to create 
a second database for the second wiki, that is the better way to go.)

Once you delete the "use" line, then (as you proposed) just:

  mysql -uuser -ppasswd DbForNewWiki < schemas/schema.mysql

Before you do that, if you're paranoid --- it's probably a 
good idea even if you're not --- you might make a backup of
database for your first wiki by doing something like:

  mysqldump -uuser -ppasswd DbForWiki1 > wiki1-backup.mysql

[Phpwiki-talk] wanting to do weird things again

[Tara S. <te...@cl...>]

I want to set up a second wiki on my site.

I've used the <Files thingy> trick to get nice clean urls - wiki1=20
accessible through http://climbtothestars.org/spiro (you all know that=20
by now, I guess!)

The idea is this one:

I create a new database.

I create a new "index copy" file named "whatever" and do a <Files=20
whatever>... trick. In "whatever", I specify that I'm using the new db,=20
and point to different templates than the ones for wiki1.

See the idea? use the same engine for two different wikis.

Just one thing:

when I have to create tables in the db, with:

mysql -uuser -ppassword dbname <schemas/schema.mysql

what am I doing exactly? because I see a file named schema.mysql in the=20
schemas directory... so I guess we're using that, right? And at the top=20
of this file is written "use DbForWiki1" - I think that was added at=20
some point earlier for trying to get the whole thing to work.

so, what should I do? try removing the "use DbForWiki1" line and see if=20
wiki1 still works? (do I run any risk of breaking something if I do that?=
)

or should I duplicate schema.mysql into wiki2schema.mysql, and change=20
the "use" line? would this break things later on for wiki2?

there... hope you can make sense out of this.

thanks if you can help!

Tara
--=20
Je r=E9ponds au mieux de mes connaissances
Climb to the Stars! - http://climbtothestars.org/
SpiroLattic - http://climbtothestars.org/spiro/
Pompeurs Associ=E9s - http://pompage.net/

Re: [Phpwiki-talk] standards-compliant lists

[Tara S. <te...@cl...>]

Jeff Dairiki wrote:


> Just thinking out loud, mostly.  It's probably more trouble than
> it's worth.


what is - producing standards-compliant code, or supporting older=20
(broken!) browsers?

;)

T.



--=20
Je r=E9ponds au mieux de mes connaissances
Climb to the Stars! - http://climbtothestars.org/
SpiroLattic - http://climbtothestars.org/spiro/
Pompeurs Associ=E9s - http://pompage.net/

Re: [Phpwiki-talk] standards-compliant lists

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

On Thu, 15 Nov 2001 17:13:41 +0100
"Tara Star" <te...@cl...> wrote:

> no <font>, please! Use <ins> and <del>, and specify visual aspect in 
> css. Please please please!

Thanks for the hint.  :-)

These things would, of course, be "configurable" (even if that means
editing the source.)  Consider, though, that some of us still need to
support older browsers.  (AFAIK, Netscape 4.x doesn't support <ins>,
<del> at all.)

I suppose it would be possible to add an additional output layer
(only when needed) which would, e.g., translate <del> to <strike>,
etc...  (Of course XSLT is the real solution, but we're putting that
off for reasons specified elsewhere.)

I guess what I'm proposing is that we could write a cheesy/hacky
output translator which would allow us to move towards cleaner XHTML
output from the main PhpWiki code.  When it comes to pass that
PHP supports XSLT better, we'd drop the cheesy translator in favor
of real XSLT.

Just thinking out loud, mostly.  It's probably more trouble than
it's worth.

Re: [Phpwiki-talk] standards-compliant lists

[Tara S. <te...@cl...>]

Jeff Dairiki wrote:


>   1. Fancy diff output.  Before transforming, the diff engine
>      produces page text which includes all the deleted text (from
>      the previous revision) as well as the current page text.
>      Added and deleted spans of text would be so marked, somehow.
>=20
>      Then after transforming the added and deleted spans of text
>      would be marked up as <span>s (or maybe <strike>,
>      <font color=3D"...">).


no <font>, please! Use <ins> and <del>, and specify visual aspect in=20
css. Please please please!



--=20
Je r=E9ponds au mieux de mes connaissances
Climb to the Stars! - http://climbtothestars.org/
SpiroLattic - http://climbtothestars.org/spiro/
Pompeurs Associ=E9s - http://pompage.net/

Re: [Phpwiki-talk] standards-compliant lists

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

On Thu, 15 Nov 2001 12:01:30 +0000 (GMT)
"Gary Benson" <ga...@in...> wrote:

> I've come to the conclusion that the fact that wiki marks up line by
line
> means that:
>  - block-level markup is hard to code
>  - the WikiSyntax for block-level markup is contrived and ugly.
> 
> I'm working on a prototype two-pass markup scheme that will apply
> block-level markup (h[1-6], p, hr, ul, ol, dl, blockquote, pre and maybe
> table), leaving lines of text which will have line level markup (i, b,
a,
> etc), It will hopefully eliminate all the problems in
> MeatBall:SillyTextFormattingRules and, incidentally, produce well-formed
> XML/XHTML. It will also mean that stuff like ''italics'' will be able to
> span multiple lines.
> 
> When I turn it into code it will be a thing of beauty, I promise, but it
> is all in my head at the moment. I hope to get it done by sometime this
> weekend and then let you all have a look at it.

Most excellent.  As I've been saying, I've been thinking along similar
lines for awhile now.

One more point to think about: it would be nice to be able to mark
spans of (pre-transformed) wiki-text, then have those spans suitably
marked up in the post-transformed (X)HTML.  A couple uses for this
would be:

  1. Fancy diff output.  Before transforming, the diff engine
     produces page text which includes all the deleted text (from
     the previous revision) as well as the current page text.
     Added and deleted spans of text would be so marked, somehow.

     Then after transforming the added and deleted spans of text
     would be marked up as <span>s (or maybe <strike>,
     <font color="...">).

  2. Jump to match.  The full text search output now highlights
     matching words in the page text.  It would be nice if when
     you click on one of those, you're taken to the location of
     matching text within the target page.   I'm envisioning
     that if one browsed to a URL something like:
      http://a.b.c/wiki/HomePage?match=Wiki#match3
     in the transformed text, all occurences of the word 'Wiki'
     would be highlighted --- they would also all be marked
     up as named anchors: the first match named #match1, ...
     
     The best implementation of this would be, I think, (though
     I haven't though about this too hard) to mark the matching
     words in a separate step before transforming.  Again the
     transform code has to support some means of marking spans
     of pre-transformed text.
 
A complication to consider is that the pre-marked spans of text
may overlap with other markup in the transformed text.  (I.e.
in the diff case, an added section of text may span several
paragraphs.)  I think this means the transform code has to be
able to split the pre-marked spans into sub-spans, as necessary,
to maintain proper nesting of elements in the final XHTML.

No, it's not simple.  I'll keep thinking about it, too.

Re: [Phpwiki-talk] removing "index.php" from url

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

On Wed, 14 Nov 2001 11:58:38 -0700
"Aredridel" <are...@nb...> wrote:

> > You want e.g. the RecentChanges to be at
> > http://spirolattic.net/RecentChanges,
> > I think.
> > 
> > You can do this, I think, but not, I think (again), in quite the way
you
> > suggest.  You could do it, I'm sure, with mod_rewrite (since you can
do
> > just about anything with mod_rewrite).  It's also probably possible
> > to do this using Apache's 'Handler' directive.  There's some cryptic
> > notes I made on this at
http://phpwiki.sf.net/wiki/PageNamesInPathInfo.
> 
> I'm not sure how well Handler works -- I tried this a while ago with
less
> than success.  I'm not sure what's required.

Sorry.  Yes, the note to which you are replying was written in a
drunken stupor.  I meant to say "Apache's 'Action' directive". 
Along with 'SetHandler' this can be used to cause apache to pass
all requests for files in a particular directory to a CGI script.

I'm still, however, not comletely sure as to how one would go
about accomplishing the orignally proposed task, even armed with
this tool...

> > The reason most people would not want to do this is that if you do,
> > the wiki occupies the entire URL name space of your domain.  If you
ever
> > want to add something else (other than wiki) under that domain, you're
> > out of luck, since every URL points to a wiki page.
> 
> Unless you use mod_alias, which most people have compiled in, or
> mod_rewrite, or many oter modules, or you could write special support
for
> other URIs in the wiki php scripts.

My point, in case it wasn't clear, was that when USE_PATH_INFO is true,
and if the wiki were instaled as proposed:

   http://a.b.c/HomePage            is the home page of the wiki. 
   http://a.b.c/foo                 is another page in the wiki
   http://a.b.c/cgi-bin/script.cgi  is another (wierdly named) page in the
wiki.
   http://a.b.c/icons/rarrow.gif    ditto.

Sure, you could use mod_alias to make it so that /cgi-bin/script.cgi
and /icons/rarrow.gif are not treated as wiki pages, but then wiki
pages by those names are inaccessible (at least without further tricks.)

Functionally, this may not be a huge problem.  Who cares if you can't
make a wiki-page named icons/rarrow.gif?  But it's messy enough, that
it makes putting the wiki at http://a.b.c/wiki/HomePage look like
the better alternative to me.

Re: [Phpwiki-talk] standards-compliant lists

[Gary B. <ga...@in...>]

On Thu, 15 Nov 2001, Tara Star wrote:

> Gary Benson wrote:
>
>
> > I've come to the conclusion that the fact that wiki marks up line by line
> > means that:
> >  - block-level markup is hard to code
> >  - the WikiSyntax for block-level markup is contrived and ugly.
> >
> > I'm working on a prototype two-pass markup scheme that will apply
> > block-level markup (h[1-6], p, hr, ul, ol, dl, blockquote, pre and maybe
> > table), leaving lines of text which will have line level markup (i, b, a,
> > etc), It will hopefully eliminate all the problems in
> > MeatBall:SillyTextFormattingRules and, incidentally, produce well-formed
> > XML/XHTML. It will also mean that stuff like ''italics'' will be able to
> > span multiple lines.
>
> I assume you're talking about wiki-lines, and not html-<p>-lines!

For sure. The idea is that if you have something that looks like this:

    Hello I am a bit of a paragraph

    * ''hello I am a big rambly list
      item that splits across
      some lines''

    Hello I am a bit of another paragraph

then it will break that into:

 para: "Hello I am a bit of a paragraph"
 item: "''hello I am a big rambly list item that splits across some lines''
 para: "Hello I am a bit of another paragraph"

and then apply line-level markup to each, hence the ''italics'' will cross
line boundries automagically.

Gary

[ ga...@in... ][ GnuPG 85A8F78B ][ http://inauspicious.org/ ]

Re: [Phpwiki-talk] standards-compliant lists

[Tara S. <te...@cl...>]

Gary Benson wrote:


> I've come to the conclusion that the fact that wiki marks up line by li=
ne
> means that:
>  - block-level markup is hard to code
>  - the WikiSyntax for block-level markup is contrived and ugly.
>=20
> I'm working on a prototype two-pass markup scheme that will apply
> block-level markup (h[1-6], p, hr, ul, ol, dl, blockquote, pre and mayb=
e
> table), leaving lines of text which will have line level markup (i, b, =
a,
> etc), It will hopefully eliminate all the problems in
> MeatBall:SillyTextFormattingRules and, incidentally, produce well-forme=
d
> XML/XHTML. It will also mean that stuff like ''italics'' will be able t=
o
> span multiple lines.


I assume you're talking about wiki-lines, and not html-<p>-lines!


> When I turn it into code it will be a thing of beauty, I promise, but i=
t
> is all in my head at the moment. I hope to get it done by sometime this
> weekend and then let you all have a look at it.


Looking forward to that!

Tara





--=20
Je r=E9ponds au mieux de mes connaissances
Climb to the Stars! - http://climbtothestars.org/
SpiroLattic - http://climbtothestars.org/spiro/
Pompeurs Associ=E9s - http://pompage.net/

Re: [Phpwiki-talk] standards-compliant lists

[Gary B. <ga...@in...>]

On Thu, 15 Nov 2001, Tara Star wrote:

[snip]
> I'm sure I could hack out a little function or such to do this, but it
> would probably take me a VERY long time and be VERY ugly ;)
>
> waiting for feedback :)

I've come to the conclusion that the fact that wiki marks up line by line
means that:
 - block-level markup is hard to code
 - the WikiSyntax for block-level markup is contrived and ugly.

I'm working on a prototype two-pass markup scheme that will apply
block-level markup (h[1-6], p, hr, ul, ol, dl, blockquote, pre and maybe
table), leaving lines of text which will have line level markup (i, b, a,
etc), It will hopefully eliminate all the problems in
MeatBall:SillyTextFormattingRules and, incidentally, produce well-formed
XML/XHTML. It will also mean that stuff like ''italics'' will be able to
span multiple lines.

When I turn it into code it will be a thing of beauty, I promise, but it
is all in my head at the moment. I hope to get it done by sometime this
weekend and then let you all have a look at it.

Till later then,
Gary

[ ga...@in... ][ GnuPG 85A8F78B ][ http://inauspicious.org/ ]