phpwiki-talk

Re: [Phpwiki-talk] http authentication weirdness

[Carsten K. <car...@ma...>]

There is something wacky with OmniWeb's cookies then, I tried IE and it's 
keeping me logged in Ok.

Thanks,
Carsten

On Saturday, December 8, 2001, at 01:51  am, Jeff Dairiki wrote:

> On Fri, 7 Dec 2001 21:32:48 -0500
> "Carsten Klapp" <car...@ma...> wrote:
>
>> It's a problem on the http://phpwiki.sourceforge.net/phpwiki/ server.
>
> Hmm.  It seems to be working for me now.  (And has been for the past
> several days.)
>
> I don't think PhpWiki's authentication will work correctly (currently) if
> your browser doesn't do cookies.  Could that be part of the problem in
> this case?
>

Re: [Phpwiki-talk] http authentication weirdness

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

On Fri, 7 Dec 2001 21:32:48 -0500
"Carsten Klapp" <car...@ma...> wrote:

> It's a problem on the http://phpwiki.sourceforge.net/phpwiki/ server.

Hmm.  It seems to be working for me now.  (And has been for the past
several days.)

I don't think PhpWiki's authentication will work correctly (currently) if
your browser doesn't do cookies.  Could that be part of the problem in
this case?

Re: [Phpwiki-talk] http authentication weirdness

[Carsten K. <car...@ma...>]

It's a problem on the http://phpwiki.sourceforge.net/phpwiki/ server.

It used to happen on my own server before today, but is fine now. I had 
been playing with /tmp permissions so that's probably what it was.

Carsten

On Friday, December 7, 2001, at 08:42  pm, Jeff Dairiki wrote:

> On Fri, 7 Dec 2001 19:46:40 -0500
> "Carsten Klapp" <car...@ma...> wrote:
>
>> For some reason I can't ever seem to stay logged in as the
> administrator,
>> or even as a regular "bogus" user. After editing one page, the next page
> I
>> edit says I will be logged as [my ip address]. I have to click back and
>> Sign in, then edit all over again.
>
> Where (what wiki) is this?
>
> The authentication mechanism relies on PHP4's session support.
> Data for each session gets saved in its own file somewhere on the httpd
> server.
> By default the session state files get put in /tmp.
> The SourceForge project web server is load-shared accross multiple http
> servers,
> each with their own /tmp --- so saving session data in /tmp is no good ---
> you
> must configure php so that it saves session is some place that's
> accessible by
> all the servers.
>
> There's some notes in index.php about this.  Look for session.save_path.
>
> Guests for dinner.  Gotta go.  Let me know if this doesn't help.

Re: [Phpwiki-talk] New formatting engine (was <code></code>)

[Sergio A. K. <ser...@ho...>]

[snip]

in my wiki I use:

**bold text**
//italic text//
__underlined text__

I think is the more intuitive way, and the more known
to those people who use text/plain email...

/sergio

Re: [Phpwiki-talk] http authentication weirdness

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

On Fri, 7 Dec 2001 19:46:40 -0500
"Carsten Klapp" <car...@ma...> wrote:

> For some reason I can't ever seem to stay logged in as the
administrator, 
> or even as a regular "bogus" user. After editing one page, the next page
I 
> edit says I will be logged as [my ip address]. I have to click back and 
> Sign in, then edit all over again.

Where (what wiki) is this?

The authentication mechanism relies on PHP4's session support.
Data for each session gets saved in its own file somewhere on the httpd
server.
By default the session state files get put in /tmp.
The SourceForge project web server is load-shared accross multiple http
servers,
each with their own /tmp --- so saving session data in /tmp is no good ---
you
must configure php so that it saves session is some place that's
accessible by
all the servers.

There's some notes in index.php about this.  Look for session.save_path.

Guests for dinner.  Gotta go.  Let me know if this doesn't help.

[Phpwiki-talk] http authentication weirdness

[Carsten K. <car...@ma...>]

For some reason I can't ever seem to stay logged in as the administrator, 
or even as a regular "bogus" user. After editing one page, the next page I 
edit says I will be logged as [my ip address]. I have to click back and 
Sign in, then edit all over again.

The http authentication screen also shows something strange, domain 
"phpwiki000". Each time I am asked to sign in the digits increment by one,
  this defeats any saved passwords in my browser.

Is the authentication code still in flux, or do you think it's a problem 
with my browser? (OmniWeb 4.1sp11)

Carsten

[Phpwiki-talk] New formatting engine (was <code></code>)

[Lawrence A. <Law...@th...>]

I am slowly being swamped trying to keep up with everyone's ideas.

I have started a page at

 http://phpwiki.sourceforge.net/phpwiki/NewWikiMarkup

in an attempt to keep track of everything.  The idea is to summarise 
what we have got at the moment, and to summarise proposals for new 
markup in a (semi-)ordered fashion

Please help out if you have time. 

Lawrence--------------------------------------------------------
Confidentiality Notice

The information contained in this e-mail is confidential.  It is for the
use of the named recipient only.  If you are not the named recipient, 
please destroy and do not disclose the contents of this e-mail
to any other person, or copy it.  Thank you for your co-operation.

Re: [Phpwiki-talk] About languages

[Carsten K. <car...@ma...>]

I found a code snippet demonstrating how to automatically determine the 
default language selected in a user's browser. May be useful for offering 
a default language choice in the user preferences.

Carsten

<?php
// language codes are comma delimited
$lang = strtok ( $HTTP_ACCEPT_LANGUAGE, "," );
while ( $lang ) {
     //if there is "en" in it
     if ( strstr ( $lang, "en" ) ) {
         header ( "Location: http://localhost/english/" );
         exit;
     }
     if ( strstr ( $lang, "es" ) ) {
         header ( "Location: http://localhost/castellano/" );
         exit;
     }
     if ( strstr ( $lang, "nl" ) ) {
         header ( "Location: http://localhost/nederlands/" );
         exit;
     }
     if ( strstr ( $lang, "de" ) ) {
         header ( "Location: http://localhost/deutsch/" );
         exit;
     }
     $lang = strtok( "," );
} //next token and end of while
// default relocation in case nothing got detected
header ("Location: http://localhost/english/");
exit;
?>


On Wednesday, November 28, 2001, at 11:40  am, Jeff Dairiki wrote:

> On Wed, 28 Nov 2001 10:08:36 +0000
> "Lawrence Akka" <la...@20...> wrote:
>
>> A few thoughts -
>>
>> 1)  The language of the interface should be user-selectable.  Just
> because
>> the [web|wiki]master has decided to set the locale as Italian, doesn't
> mean
>> that everyone wants to see Italian links/instructions.
>
> Yes, once we have real users and user preferences, that's probably a fine
> idea.
>

[Phpwiki-talk] New formatting engine (was <code></code>)

[Carsten K. <car...@ma...>]

I don't see a need to bring back tabs or the quotes, I just noticed that 
some text copied from c2 didn't format correctly when I pasted it into my 
own Wiki. Besides it's too difficult to figure out what combination of 
multiple nested quotes will give the formatting I want.

There are some notes somewhere that imply PhpWiki syntax is fully 
compatible with other Wiki syntax, either in the docs or somewhere on the 
web site. I'll look for it again and see if it needs rewording. The 
TextFormattingRules page and TestPage should be updated too. It does say 
the quotes are buggy but if they're not going to be reimplemented it might 
as well say that all of the old quote syntax isn't supported anymore.


I like the *bold text* and _italic text_ email tags.
  - Underscores have also long been used to represent italicized text in 
traditional type-written text for book manuscripts and movie scripts, they 
are later converted to italics when typeset and published.
  - I've seen emails using slashes for italics but not many (maybe 2), and 
then there is also ~italics~.
  - Slashes are too common in filename paths and URLs nowadays.
  - Now that we've moved away from typewriters, bold and italic text are 
readily available to everyone. So underlined text is used mainly to 
indicate link-text and sometimes for headings.

I agree with Jeff on the %%%. Personally I think it was a bad choice, even 
if it was arbitrarily chosen for lack of something better which didn't 
conflict with existing code. I don't have a better suggestion, and I'm 
reluctant to use or encourage use of too many html <tags> in WikiMarkup. 
HTML is very anglo-centric, and too distracting to read and edit when 
there is a lot of it.

Another bad choice I think is the use of !, both for headings and for 
!DontLink. One limitation I've run into is only 3 levels of headings. 
While heading levels 4, 5 and 6 are not frequently used outside of 
documentation or other published material, they are supported by html. Is 
anyone else here interested in seeing 4 (or more) heading levels?


Setext uses a very similar and intuitive text-only markup. Many mailing 
lists and faqs use(d) the setext format, mostly prior to the advent of 
html, and there are still digest viewing software available for parsing 
this format.

I do really like the setext format, and I'm not necessarily proposing to 
fully implement setext markup in PhpWiki. A lot of thought has been put 
into the format and there might be some ideas or markup rules we can take 
from it.


If you want to read more about setext send a blank email to setext@tidbits.
com for an automated reply. It's a bit dated but still interesting.

Some excerpts from the document you'll get:

   Setext, on the other hand, has been _optimized_
   for reading directly by human eyes on what probably is still the
   lowest common denominator of today's computer hardware, an 80-
   character by 24-line terminal screen.

   the setext format relies
   solely on the presence of _implicit_ typotags, carefully chosen
   to be as visually unobtrusive as possible.  The underlined word
   above is one such instance of the defacto "invisible" coding.
   Inserted typotags will at worst appear as mere "typos" in the text.

Some markup examples:
**bold words**
_underlined words_
hotword_ (sparingly used, can be indicated by shadow text, colored etc.)
some_hot_words_
~italic words~
(C) copyright
(R) registered trademark
(TM) trademark
' -- ' emdash (no quotes)

   Heading
=========

   Heading
---------

<urls and emails>

..comment lines are suppressed by
..lines starting with twodot tags
..

Unix setext viewer (source code, with a **man page in setext format 
showing some tables**)
http://www.etext.org/Zines/ASCII/InterText/ascii/setext-
viewers/setext-viewer-05-unix.uu

Other setext software and examples: <http://hospex.org.pl/setext-
clients.html> (some links here are broken)
Another setext example: <http://hospex.icm.edu.pl/which-spec.html>

Carsten


On Friday, December 7, 2001, at 10:37  am, Jeff Dairiki wrote:

> On Fri, 7 Dec 2001 00:17:57 -0500 (EST)
> "Steve Wainstead" <sw...@pa...> wrote:
>
>> I'd like to move (again) to a syntax like the NBTSC Wiki, which is in
> line
>> with suggestions by many users over the last two years. Ali went for
>> syntax that is a lot like how people do things in plain text elsewhere:
>>
>> *bold*
>> /italic/
>
> I'm becoming convinced, too.  That this syntax should be supported.  It
> certainly makes more sense than ''this'' (or '''''this''''').
>
> I'm a bit leary of the /italic/ syntax.  For one, I think the fact that
> slashes are common in file names and URLs might lead to more syntactic
> miscombooboos and ambiguities.  Also, I've never noticed that particular
> convention to be commonly used (in e-mails).  I always thought _this was
> italic_.
>
> An inline markup for monospace would be nice, too, I think.
>
> My vote goes with: *bold*, _italic_, =monospace=.
>
> To avoid many problems, I think these delimiters need to be snuggled up to
> words which they delimit.  This completely eliminates the ambiguity
> between opening and closing delimiters.  Opening delimiters are preceded
> by a space (or beginning-of-line, or certain punctuation), and followed by
> a word character.  Closing delimiters are preceded by a word characters,
> and followed by space, end-of-line, or punctuation.
>
> On the other hand, I also really like sticking with the standard HTML tags
> <b>bold</b>, <i>italic</i>, <tt>monospace</tt>.  (Even <em>, <strong>,
> <code>, etc... might be nice.)  I see no reason not to support (at least
> the first three of) these as well.  Many/most people already know them, so
> they're easy to remember.  They're easy to parse.
>
> (In addition, we could support the current ''italic'' and __bold__ (at
> least for awhile), since none of these syntaxes clash.)
>
>
>
> Block-level markup is more of a problem, especially with our current
> line-oriented parser.  On the other hand lots of good ideas have been
> proposed:
>   o This should be recognized as a list.
>      o And this should be a nested list item.
>        This should be part of the same item.
>     And this should be part of the same level-one item.
>
> A definition list should looks like:
>    Term:
>        Definition.
>
> The problem with these: parsing is tricky (but certainly doable).  They
> clash with the current leading space means monospace, non-flowed markup.
>
>
> Speaking of which: who was it who recently said they were working on a new
> transform engine?  Is that still in progress?  I keep meaning to write a
> new transform engine myself, but whenever I start thinking about it, I get
> stuck when I can't find a PHP-ized version of yacc.
>
>
>> Now, the one thing that has troubled me about both the plugin syntax and
>> the proposed plain text tags is they are not consistent with the markup
> to
>> date... and inconsistency is not good for the user. As PhpWiki grows in
>> features, though, I understand it gets harder to maintain consistency.
>
> I'm not entirely happy with the plugin syntax, but haven't yet thought of
> a better alternative.
>
> Introducing new block-level constructs without using the eqivalent of
> <pre></pre> is really tricky.  (As demonstrated above, our current
> leading-space-means-non-flowed-monospace conflicts with pretty much any
> intuitive list markup.)
>
> In general (and I think you yourself may have said this some time ago)
> there's no point in reinventing HTML.  SGML/HTML/XML-like syntax is a bit
> verbose, but it's cleanly extensible, and it mixes fairly well with plain
> text.  As you say, the more features we add, the harder a clean syntax
> becomes.  I think there's nothing wrong with supporting some clean
> "e-mail-like" markup, as well as some HTML-like alternatives.  The fancier
> features, perhaps only need to be HTML-style.
>
> For example, I would say the introduction of '%%%' to mean '<br>' was a
> bad choice.  What's wrong with using '<br>'?  It seems much less likely to
> cause confusion.

Re: [Phpwiki-talk] was <code></code>

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

On Fri, 7 Dec 2001, Jeff Dairiki wrote:

> > *bold*
> > /italic/
>
> I'm becoming convinced, too.  That this syntax should be supported.  It
> certainly makes more sense than ''this'' (or '''''this''''').
>
> I'm a bit leary of the /italic/ syntax.  For one, I think the fact that
> slashes are common in file names and URLs might lead to more syntactic
> miscombooboos and ambiguities.  Also, I've never noticed that particular
> convention to be commonly used (in e-mails).  I always thought _this was
> italic_.

It has the unfortunate plus that it kinda /looks/ like italics right off
the bat. I just checked Ari's site and they use -bold- and /italic/.

> An inline markup for monospace would be nice, too, I think.

Hmm. Didn't we used to have this? Maybe I'm thinking of hacks I did at the
NYT.

> My vote goes with: *bold*, _italic_, =monospace=.

I like =monospace=, but I really like /italic/ and I know that means a lot
of trouble. When I was making PhpWikiSites two days ago, I found that
putting __ at the end of a URI caused a bug, since __ is valid in a URI.n

> To avoid many problems, I think these delimiters need to be snuggled up to
> words which they delimit.  This completely eliminates the ambiguity
> between opening and closing delimiters.  Opening delimiters are preceded
> by a space (or beginning-of-line, or certain punctuation), and followed by
> a word character.  Closing delimiters are preceded by a word characters,
> and followed by space, end-of-line, or punctuation.

Agreed, and that's how we've always done it, afaik..

> On the other hand, I also really like sticking with the standard HTML tags
> <b>bold</b>, <i>italic</i>, <tt>monospace</tt>.  (Even <em>, <strong>,
> <code>, etc... might be nice.)  I see no reason not to support (at least
> the first three of) these as well.  Many/most people already know them, so
> they're easy to remember.  They're easy to parse.

<b>it's</b> <i>not</i> <tt>quite</tt> <b><i>as</i></b> easy on the eyes,
but we do get the benefit of a large user base who already know html. (Oh,
if you have an HTML-reading mail client you might not see that. Sorry).

> Block-level markup is more of a problem, especially with our current
> line-oriented parser.  On the other hand lots of good ideas have been
> proposed:
>   o This should be recognized as a list.
>      o And this should be a nested list item.
>        This should be part of the same item.
>     And this should be part of the same level-one item.
>
> A definition list should looks like:
>    Term:
>        Definition.
>
> The problem with these: parsing is tricky (but certainly doable).  They
> clash with the current leading space means monospace, non-flowed markup.

In a sense the list syntax is block oriented. Couldn't <pre> use the stack
in the same fashion? i.e. it would need to see <pre> and then </pre> to
clear the stack.

> Speaking of which: who was it who recently said they were working on a new
> transform engine?  Is that still in progress?  I keep meaning to write a
> new transform engine myself, but whenever I start thinking about it, I get
> stuck when I can't find a PHP-ized version of yacc.

I don't recall anyone working on this... but line-oriented parsing is a
pain. It would make life easier if we did recursive descent parsing; it
would be even better if we stored the pages as xhtml, with only the links
dynamically added at serve time, which would reduce a lot of overhead.

> I'm not entirely happy with the plugin syntax, but haven't yet thought of
> a better alternative.

[plugin:foo param1 param2 param3... paramN] maybe? This would be a lot
like the other link schemes.

> Introducing new block-level constructs without using the eqivalent of
> <pre></pre> is really tricky.  (As demonstrated above, our current
> leading-space-means-non-flowed-monospace conflicts with pretty much any
> intuitive list markup.)
>
> In general (and I think you yourself may have said this some time ago)
> there's no point in reinventing HTML.  SGML/HTML/XML-like syntax is a bit
> verbose, but it's cleanly extensible, and it mixes fairly well with plain
> text.  As you say, the more features we add, the harder a clean syntax
> becomes.  I think there's nothing wrong with supporting some clean
> "e-mail-like" markup, as well as some HTML-like alternatives.  The fancier
> features, perhaps only need to be HTML-style.
>
> For example, I would say the introduction of '%%%' to mean '<br>' was a
> bad choice.  What's wrong with using '<br>'?  It seems much less likely to
> cause confusion.

At this point, where I am interested in evolving and extending PhpWiki, I
have no trouble with adding HTML tags. To this I will say: we need utterly
simple markup to make the Wiki super easy to use:

[snip]
I am making a *bold* link to my name: *SteveWainstead*. You can see my
project page [here | http://phpwiki.sf.net/]. Send me some email:
mailto:sw...@pa....
[snip]

I think that's about as basic as it gets: write plain text, make some
links, and a little emphasis. This will cover 99% of what users will do.
I'm bothered by /* this */ becoming italic bold though...

~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] was <code></code>

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

warning: lots of opinions from someone that doesn't program follow ...

> I'm a bit leary of the /italic/ syntax.  For one, I think the fact that
> slashes are common in file names and URLs might lead to more syntactic
> miscombooboos and ambiguities.  Also, I've never noticed that particular
> convention to be commonly used (in e-mails).

for files so long as it's <whitespace>/italic text/<whitespace> it should
be okay shouldn't it?  files/directories might have a space in them but
they shouldn't start or end with a space.

> I always thought _this was italic_.

i always thought that was underline ;)

> An inline markup for monospace would be nice, too, I think.

yes please, though i still think monospace should turn off wiki words (but
i can use <pre> for that now.

> My vote goes with: *bold*, _italic_, =monospace=.

that'll work well i think, i think /italic/ is clearor to someone that
hasn't seen it before but i don't think it really matters that much.

> To avoid many problems, I think these delimiters need to be snuggled
> up to words which they delimit.  This completely eliminates the
> ambiguity between opening and closing delimiters.  Opening delimiters
> are preceded by a space (or beginning-of-line, or certain
> punctuation), and followed by a word character.  Closing delimiters
> are preceded by a word characters, and followed by space, end-of-line,
> or punctuation.

i'm not sure allowing the opening tag should allow anything but whitespace
or a new line immediately before it.  i think this sorta thing is asking
for trouble.  or am i misunderstanding?

blah.*bold* text.
/*fake comment*/

but i do think the closing one needs to allow end of line or punctuation
)]!?.,"'`} is all i can think o f that might be valid.  this allows:

*bold text*!
test (stuff *in bold*)
stuff "*in bold*".

> On the other hand, I also really like sticking with the standard HTML
> tags <b>bold</b>, <i>italic</i>, <tt>monospace</tt>.  (Even <em>,
> <strong>, <code>, etc... might be nice.)  I see no reason not to
> support (at least the first three of) these as well.  Many/most people
> already know them, so they're easy to remember.  They're easy to
> parse.

i would like it if this was configurable, i'd enable it on my personal
wiki cause it makes cut'n'paste easy, but on public/community wiki's i
think it would be a bad thing cause now you have mixed syntax and the
"wiki way" is simpler and faster for everyone but you're always gonna have
someone that uses html tags cause they know them.

> (In addition, we could support the current ''italic'' and __bold__ (at
> least for awhile), since none of these syntaxes clash.)

yah, again it would be nice if eventually this was a legacy option which
was disabled by default but could be enabled if needed.

> Block-level markup is more of a problem, especially with our current
> line-oriented parser.  On the other hand lots of good ideas have been
> proposed:
>   o This should be recognized as a list.
>      o And this should be a nested list item.
>        This should be part of the same item.
>     And this should be part of the same level-one item.

this is how moin does it.  lists must start with a leading space, and
instead of multiple *'s for nested list item's you use multiple spaces.

it works great but it's very confusing to new comers.

* this
** seems to make
*** more sense to people.

> The problem with these: parsing is tricky (but certainly doable).
> They clash with the current leading space means monospace, non-flowed
> markup.

i would love to see the leading space meaning monospace die.  lets use
<pre> instead.  the leading space meaning monospace makes cut'n'paste
hell.  i also think it's really unintuitive to newbies.

> I'm not entirely happy with the plugin syntax, but haven't yet thought
> of a better alternative.

fwiw, moin's syntax for plugins (macros) is [[plugin(options]] and twiki
uses %PLUGIN{options}%.

which reminds me, i'd really like it if [this is a link] went a way.  i
use that all the time in text.  maybe have a link be [[this is a link]] or
["this is a link"].

> The fancier features, perhaps only need to be HTML-style.

i think that probably makes sense so long as we can avoid security issues
like cross site scripting.

> For example, I would say the introduction of '%%%' to mean '<br>' was
> a bad choice.  What's wrong with using '<br>'?  It seems much less
> likely to cause confusion.

that makes sense, when i started using moin they used [[BR]] and it took
me forever to figure out that was they way to put in a line break.  where
there isn't a good wiki alternative, why re-invent html?

adam.

[Phpwiki-talk] Small patch concerning auth. (fwd)

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

This got lost in my ever-expanding inbox... sorry...

~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
---------- Forwarded message ----------
Date: Fri, 16 Nov 2001 01:59:45 -0800
From: Yaacov Akiba Slama <sl...@ya...>
To: sw...@pa...
Subject: Small patch concerning auth.

Hi,
I installed phpwiki-1.3.1 and I put it in a directory with
an  .htaccess file because its a private wiki (even if it is
on a public webserver).
In such a configuration, the webserver (apache in my config)
handles all the auth, including the password. So the
password need not - in theory, and also with my patch - to
be in index.php.
So I modified the file lib/WikiUser.php (patch follow) so if
the ADMIN_PASSWD is NOT DEFINED, there is no verification of
the passwrd since it's already done by the webserver.
In this config, one has only to define the ADMIN_USER in
index.php and use the auth by the webserver.
Perhaps it's better to add a new boolean variable
USE_SERVER_AUTH ? I don't know.
Here the patch :
--- WikiUser.php.old	Fri Nov 16 03:51:07 2001
+++ WikiUser.php	Fri Nov 16 04:16:04 2001
@@ -145,7 +145,7 @@
         $passwd = $this->_request->get('PHP_AUTH_PW');

         if (!empty($userid) && $userid == ADMIN_USER) {
-            if (!empty($passwd) && $passwd == ADMIN_PASSWD)
+            if (!defined('ADMIN_PASSWD') ||
(!empty($passwd) && $passwd == ADMIN_PASSWD))
                 return $userid;
         }
         elseif (ALLOW_BOGO_LOGIN
@@ -157,8 +157,8 @@
     }

     function _demand_http_authentication () {
-        if (!defined('ADMIN_USER') || !defined('ADMIN_PASSWD')
-            || ADMIN_USER == '' || ADMIN_PASSWD =='') {
+        if (!defined('ADMIN_USER') || ADMIN_USER == ''
+            || (defined('ADMIN_PASSWD') && ADMIN_PASSWD
=='')) {
             return
                 "<p><b>"
                 . gettext("You must set the administrator
account and password before you can log in.")

Re: [Phpwiki-talk] Galeon

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

> Okay, I'm using galeon-0.12.7 with mozilla-0.9.5. When I try to look
> at, for instance, http://phpwiki.sourceforge.net/phpwiki/, I get a
> blank screen. View source shows "<html><body></body></html>".

just as a heads up i also use galeon and the above url works perfectly, so
unless something has been changed it's something specific to your setup.

$ dpkg -l mozilla-browser galeon
ii  mozilla-browse 0.9.5-5        Mozilla Web Browser - core and browser
ii  galeon         0.12.7-0.1     Mozilla based web browser with GNOME

adam.

Re: [Phpwiki-talk] Galeon

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

On Fri, 7 Dec 2001, Jeff Dairiki wrote:

> Gary Benson said:
> 
> > BTW, the new PhpWiki doesn't seem to work with Galeon (although Mozilla
> >  renders it just fine). I have no idea why...
> 
> Galeon is my regular browser these days.  It seems to work for me.
> 
> Can you be any more specific as to what the problem is?

Erk, didn't mean to send that last message just then :)

Okay, I'm using galeon-0.12.7 with mozilla-0.9.5. When I try to look at, 
for instance, http://phpwiki.sourceforge.net/phpwiki/, I get a blank 
screen. View source shows "<html><body></body></html>".

Actually, this sounds like it is a problem with Galeon rather than 
PhpWiki, so sorry to have troubled you all...

Cheers,
Gary

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

Re: [Phpwiki-talk] Galeon

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

Gary Benson said:
>
> BTW, the new PhpWiki doesn't seem to work with Galeon (although Mozilla
>  renders it just fine). I have no idea why...

Galeon is my regular browser these days.  It seems to work for me.

Can you be any more specific as to what the problem is?

[Phpwiki-talk] Galeon

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

BTW, the new PhpWiki doesn't seem to work with Galeon (although Mozilla 
renders it just fine). I have no idea why...

Re: [Phpwiki-talk] Editing area size

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

> CSS tip of the day:
> 
> If you add `style="width:100%"' to the attributes of the EditText
textarea
> then it expands to fill the width of the screen (no matter what `cols'
is 
> set to).
 
This is already in 1.3.  It's in phpwiki.css.   Should it be moved to
templates/editpage.html so that it's always there regardless of
which/whether style sheet is used?

PS: Only works in modern browsers.

Re: [Phpwiki-talk] was <code></code>

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

On Fri, 7 Dec 2001 00:17:57 -0500 (EST)
"Steve Wainstead" <sw...@pa...> wrote:

> I'd like to move (again) to a syntax like the NBTSC Wiki, which is in
line
> with suggestions by many users over the last two years. Ali went for
> syntax that is a lot like how people do things in plain text elsewhere:
> 
> *bold*
> /italic/

I'm becoming convinced, too.  That this syntax should be supported.  It
certainly makes more sense than ''this'' (or '''''this''''').

I'm a bit leary of the /italic/ syntax.  For one, I think the fact that
slashes are common in file names and URLs might lead to more syntactic
miscombooboos and ambiguities.  Also, I've never noticed that particular
convention to be commonly used (in e-mails).  I always thought _this was
italic_.

An inline markup for monospace would be nice, too, I think.

My vote goes with: *bold*, _italic_, =monospace=.

To avoid many problems, I think these delimiters need to be snuggled up to
words which they delimit.  This completely eliminates the ambiguity
between opening and closing delimiters.  Opening delimiters are preceded
by a space (or beginning-of-line, or certain punctuation), and followed by
a word character.  Closing delimiters are preceded by a word characters,
and followed by space, end-of-line, or punctuation.

On the other hand, I also really like sticking with the standard HTML tags
<b>bold</b>, <i>italic</i>, <tt>monospace</tt>.  (Even <em>, <strong>,
<code>, etc... might be nice.)  I see no reason not to support (at least
the first three of) these as well.  Many/most people already know them, so
they're easy to remember.  They're easy to parse.

(In addition, we could support the current ''italic'' and __bold__ (at
least for awhile), since none of these syntaxes clash.)



Block-level markup is more of a problem, especially with our current
line-oriented parser.  On the other hand lots of good ideas have been
proposed:
  o This should be recognized as a list.
     o And this should be a nested list item.
       This should be part of the same item.
    And this should be part of the same level-one item.

A definition list should looks like:
   Term:
       Definition.

The problem with these: parsing is tricky (but certainly doable).  They
clash with the current leading space means monospace, non-flowed markup.


Speaking of which: who was it who recently said they were working on a new
transform engine?  Is that still in progress?  I keep meaning to write a
new transform engine myself, but whenever I start thinking about it, I get
stuck when I can't find a PHP-ized version of yacc.


> Now, the one thing that has troubled me about both the plugin syntax and
> the proposed plain text tags is they are not consistent with the markup
to
> date... and inconsistency is not good for the user. As PhpWiki grows in
> features, though, I understand it gets harder to maintain consistency.

I'm not entirely happy with the plugin syntax, but haven't yet thought of
a better alternative.

Introducing new block-level constructs without using the eqivalent of
<pre></pre> is really tricky.  (As demonstrated above, our current
leading-space-means-non-flowed-monospace conflicts with pretty much any
intuitive list markup.)
 
In general (and I think you yourself may have said this some time ago)
there's no point in reinventing HTML.  SGML/HTML/XML-like syntax is a bit
verbose, but it's cleanly extensible, and it mixes fairly well with plain
text.  As you say, the more features we add, the harder a clean syntax
becomes.  I think there's nothing wrong with supporting some clean
"e-mail-like" markup, as well as some HTML-like alternatives.  The fancier
features, perhaps only need to be HTML-style.

For example, I would say the introduction of '%%%' to mean '<br>' was a
bad choice.  What's wrong with using '<br>'?  It seems much less likely to
cause confusion.

Re: [Phpwiki-talk] <code></code> tags [was <pre> tags]

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

Actually, Usemod uses <pre> for the feature in question:

  <pre></pre>
     Disables all WikiWord linking, as well as all text formatting.
     (This is an augmentation of the standard HTML interpretation of
<pre>.)

  <nowiki></nowiki>
     An in-line tag which disables WikiWord linking.  (Paragraph
formatting
     still works normally.)

  <code></code>
     (This is a standard HTML tag, too.)  It is roughly synonymous with
<tt></tt>.

So, I say we use <pre></pre>.


On Fri, 07 Dec 2001 10:02:13 +0000
"Lawrence Akka" <la...@us...> wrote:

> Meatball use <nowiki></nowiki>.  So lets use that. 

Re: [Phpwiki-talk] filenames with underscores: bleah

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

On Thu, 06 Dec 2001 22:23:04 -0800
"J C Lawrence" <cl...@ka...> wrote:

> Whitespace in filenames make automated processing of directory
> hierarchies and files unnecessarily difficult and careful.  Almost
> no value add, significant value loss.  

Yes.  This is my main complaint, too.  I also notice it confused the
SourceForge CVS checkin announcement mailer:

> Update of /cvsroot/phpwiki/phpwiki
> In directory usw-pr-cvs1:/tmp/cvs-serv11390/phpwiki
> 
> Modified Files:
>       Tag: release-1_2-branch
> 	INSTALL.Mac OS X 
> Log Message:
> typos & minor adj.
> 
> ***** Bogus filespec: INSTALL.Mac
> ***** Bogus filespec: OS


Carsten, if you want (or want me to) rename it to something else (without
spaces), that's fine.

PS: Just as a reminder: non US-ASCII in filenames also causes problems
with (at least) some CVS clients: best to avoid that as well.

Re: [Phpwiki-talk] Re: [Phpwiki-talk] 3-single quotes and 5-single quotes broken?

[Lawrence A. <la...@us...>]

At 05:14 07/12/2001, Steve Wainstead wrote:

>I'd like to move (again) to a syntax like the NBTSC Wiki, which is in line
>with suggestions by many users over the last two years. Ali went for
>syntax that is a lot like how people do things in plain text elsewhere:
>
>*bold*
>/italic/
>
>I think are two examples. Ali's reasoning was the marked up page language
>should be as easy to read/understand as the rendered page.


Yes, yes, yes.  People understand that.  I am often asked why *bold* 
doesn't work.  Another useful one from the email world is > as a prefix for 
a blockquote.

There are other motivations behind wiki markup - I have listed a few at

http://phpwiki.sourceforge.net/phpwiki/PurposesOfWikiMarkup

There is also an excellent discussion (imho) of how wiki rules can go bad 
(and suggestions for making them good) at

http://www.usemod.com/cgi-bin/mb.pl?SillyTextFormattingRules



>Now, the one thing that has troubled me about both the plugin syntax and
>the proposed plain text tags is they are not consistent with the markup to
>date... and inconsistency is not good for the user. As PhpWiki grows in
>features, though, I understand it gets harder to maintain consistency.
>
>I'd like to see some proposals that are consistent with our current
>syntax, or some way that would be compatible with NBTSC syntax.


It is hard to think of a "natural" way of indicating that you want to 
include a block of text without markup (eg code).  Zope structured text ( 
http://www.zope.org/Documentation/Articles/STX ) uses a paragraph followed 
by :: to indicate that the next indented block should have no markup at 
all.  You can also use text ending in "example:" to indicate the same 
thing.  That's a bit fancy for me.  The :: (or something like it), followed 
by indented text, might be OK though.  You don't need a closing tag in that 
case.  You just stop indenting to return to normal.

Also, its hard to think of a single character (which is what NBTSC's markup 
mostly uses) which can sensibly be used to indicate a block of 
code.  Whatever is chosen may well appear in the code itself, and would 
have to be escaped, which defeats the object.

I would like to implement a solution to the code problem.  It is a big 
difficulty for my users, you need to quote php code a lot without having to 
scan for and double up on square brackets all the time.  Hence my patch 
(see other thread!).  Ideally, I would like to do something that can be 
adopted in PhpWiki as a whole, rather than just patch my 
implementation.  That way, my site remains consistent with phpWiki 
generally, and I don't have to keep patching my code on every cvs release!

Steve, how about implementing my patch (or something like it) in the short 
term, and we can then discuss (perhpas on the wiki itself) moving towards 
NBTSC markup in the medium term.  I am wholeheartedly behind that move, and 
would be delighted to help implement it.

Lawrence

Re: [Phpwiki-talk] <pre> tags

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

Lawrence Akka schrieb:
> 
> I am keen to implement something like <pre></pre> tags for my own use, so that I can
> cut and paste php code into my wiki, between those tags, without all the array
> subscripts turning into links.  [Yes I know I can use [[, but its a bit of a 
> nuisance with long blocks of code].
> 
> Before I reinvent the wheel, has anyone else done this who is prepared to let me see
> their code?

yes, me.
see
http://xarch.tu-graz.ac.at/home/rurban/acadwiki-1.3.6pre/viewsrc.php?show=lib/transform.php#src

function wtm_code and wtm_verbatim, wtm_nowiki.
this needs several hacks in stdlib.php also.
I haven't had enough time yet to port it into the newer 1.3 branch.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] <code></code> tags [was <pre> tags]

[Lawrence A. <la...@us...>]

Meatball use <nowiki></nowiki>.  So lets use that.  Revised patch file at 
the bottom of this email

Lawrence

At 00:59 07/12/2001, Adam Shand wrote:

> > <code> and <pre> are fine by me too. Any thoughts on adding support
> > for all three synonyms? It might be useful to be compatible with other
> > Wikis, and <pre> might be useful for transferring existing html into a
> > Wiki.
>
>supporting <pre></pre> would be useful for cut'n'paste from html but given
>that none of the other tags would migrate cleanly i don't see that it's
>that big a deal.
>
>as for <nowiki> vs. <code> if we're copying meatball lets just copy them.
>what is their recommendation?  we may as well try and make this stuff as
>standard as possible between wikis.
>
>adam.


Context diff follows:


*** transform.old.php   Thu Dec  6 14:21:31 2001
--- transform.php       Thu Dec  6 14:29:43 2001
***************
*** 1,10 ****
! <?php rcs_id('$Id: transform.php,v 1.27 2001/11/16 22:59:02 dairiki Exp $');
   require_once('lib/WikiPlugin.php');

   define('WT_SIMPLE_MARKUP', 0);
   define('WT_TOKENIZER', 1);
   define('WT_MODE_MARKUP', 2);
!
   define("ZERO_LEVEL", 0);
   define("NESTED_LEVEL", 1);

--- 1,10 ----
! <?php rcs_id('$Id: transform.php,v 1.4 2001/11/27 10:44:32 lakka Exp $');
   require_once('lib/WikiPlugin.php');

   define('WT_SIMPLE_MARKUP', 0);
   define('WT_TOKENIZER', 1);
   define('WT_MODE_MARKUP', 2);
! define('WT_NO_MARKUP', 4);
   define("ZERO_LEVEL", 0);
   define("NESTED_LEVEL", 1);

***************
*** 15,20 ****
--- 15,21 ----
      var $replacements; // storage for tokenized strings of current line
      var $user_data;    // can be used by the transformer functions
                           // to store miscellaneous data.
+    var $MarkupEnabled;  // flag to determine whether markup shoud be 
transformed.  added by LA

      // private variables
      var $content;      // wiki markup, array of lines
***************
*** 27,32 ****
--- 28,34 ----
      {
         $this->trfrm_func = array();
         $this->stack = new Stack;
+       $this->MarkupEnabled = 1;  // Added by LA
      }

      /**
***************
*** 241,246 ****
--- 243,256 ----
               list($flags, $func, $regexp) = current($this->trfrm_func);
               next($this->trfrm_func)) {

+           // if MarkupEnabled is not set then ignore all further markup,
+           // except WT_NO_MARKUP functions (or we couldn't turn markup
+           // back on again (!), and wtm_specialchars (to remove html)
+           // Added by LA
+
+           if (!$this->MarkupEnabled && !($flags & WT_NO_MARKUP) && $func 
!= 'wtm_htmlchars')
+               continue;
+
             // if HTMLmode is already set then skip all following
             // WT_MODE_MARKUP functions
             if ($this->mode_set && ($flags & WT_MODE_MARKUP) != 0)
***************
*** 316,321 ****
--- 326,332 ----
   // register functions
   // functions are applied in order of registering

+ $transform->register(WT_NO_MARKUP, 'wtm_no_markup', 
'^<nowiki>|^<\/nowiki>'); //Added by LA
   $transform->register(WT_SIMPLE_MARKUP, 'wtm_plugin_link');
   $transform->register(WT_MODE_MARKUP, 'wtm_plugin');

***************
*** 643,648 ****
--- 654,673 ----
      function wtm_paragraph($line, &$trfrm) {
         $line = $trfrm->SetHTMLMode('p') . $line;
         return $line;
+    }
+
+    // No markup between <nowiki>, </nowiki>.  Added by LA
+    function wtm_no_markup($line, &$trfrm) {
+        if (preg_match('/^<nowiki>(.*)/', $line, $m)) {
+            $trfrm->MarkupEnabled = 0;
+            $line = $trfrm->SetHTMLMode('pre').$m[1];
+        echo 'on';
+        } elseif (preg_match('/^<\/nowiki>(.*)/', $line, $m)) {
+          $trfrm->MarkupEnabled = 1;
+          $line = $trfrm->SetHTMLMode('',0).$m[1];
+          echo 'off';
+        }
+        return $line;
      }

   // (c-file-style: "gnu")

Re: [Phpwiki-talk] <code></code> tags [was <pre> tags]

[Lawrence A. <la...@us...>]

I thought of that :-)

No - all html between <code> tags is escaped.  So you can cut and paste 
html without a problem.

Lawrence



At 22:35 06/12/2001, Steve Wainstead wrote:


>Can I do:
>
><code>
>
><script language="Javascript">
>alert("hello sailor!);
></script>
>
></code>
>
>If so, this is a security breach...
>
>~swain
>
>On Thu, 6 Dec 2001, Lawrence Akka wrote:
>
> > I have patched lib/transform.php (cvs as of today) to enable a new
> > formatting rule.
> >
> > A line beginning <code> will switch wiki formatting off, until a line
> > beginning </code>
> >
> > It is now easier to cut and paste large chunks of code into a wiki, without
> > all the ['s creating automatic links.
> >
> > In other words:
> >
> > test
> > <code>
> > This is a __wiki test__.  $array['index']
> > </code>
> > test
> >
> > will display as
> >
> > test
> >
> > This is a __wiki test__. $array['index']
> >
> > test
> >
> > I would appreciate feedback on this:
> >
> > *  Is it useful?
> > *  Does it work?
> > *  Should <code></code> be something else?
> > *  Should it go into the cvs?
> >
> > At the moment I am aware of one problem - an extra blank line seems to be
> > inserted after the end of the code
> >
> > Thanks
> >
> > Lawrence Akka
> >
> >
> > Context diff follows:
> >
> >
> > *** transform.old.php Thu Dec  6 14:21:31 2001
> > --- transform.php     Thu Dec  6 14:29:43 2001
> > ***************
> > *** 1,10 ****
> > ! <?php rcs_id('$Id: transform.php,v 1.27 2001/11/16 22:59:02 dairiki 
> Exp $');
> >    require_once('lib/WikiPlugin.php');
> >
> >    define('WT_SIMPLE_MARKUP', 0);
> >    define('WT_TOKENIZER', 1);
> >    define('WT_MODE_MARKUP', 2);
> > !
> >    define("ZERO_LEVEL", 0);
> >    define("NESTED_LEVEL", 1);
> >
> > --- 1,10 ----
> > ! <?php rcs_id('$Id: transform.php,v 1.4 2001/11/27 10:44:32 lakka Exp $');
> >    require_once('lib/WikiPlugin.php');
> >
> >    define('WT_SIMPLE_MARKUP', 0);
> >    define('WT_TOKENIZER', 1);
> >    define('WT_MODE_MARKUP', 2);
> > ! define('WT_NO_MARKUP', 4);
> >    define("ZERO_LEVEL", 0);
> >    define("NESTED_LEVEL", 1);
> >
> > ***************
> > *** 15,20 ****
> > --- 15,21 ----
> >       var $replacements;      // storage for tokenized strings of 
> current line
> >       var $user_data; // can be used by the transformer functions
> >                            // to store miscellaneous data.
> > +    var $MarkupEnabled;  // flag to determine whether markup shoud be
> > transformed.  added by LA
> >
> >       // private variables
> >       var $content;   // wiki markup, array of lines
> > ***************
> > *** 27,32 ****
> > --- 28,34 ----
> >       {
> >          $this->trfrm_func = array();
> >          $this->stack = new Stack;
> > +       $this->MarkupEnabled = 1;  // Added by LA
> >       }
> >
> >       /**
> > ***************
> > *** 241,246 ****
> > --- 243,256 ----
> >             list($flags, $func, $regexp) = current($this->trfrm_func);
> >             next($this->trfrm_func)) {
> >
> > +         // if MarkupEnabled is not set then ignore all further markup,
> > +         // except WT_NO_MARKUP functions (or we couldn't turn markup
> > +         // back on again (!), and wtm_specialchars (to remove html)
> > +         // Added by LA
> > +
> > +         if (!$this->MarkupEnabled && !($flags & WT_NO_MARKUP) && $func !=
> > 'wtm_htmlchars')
> > +             continue;
> > +
> >           // if HTMLmode is already set then skip all following
> >           // WT_MODE_MARKUP functions
> >           if ($this->mode_set && ($flags & WT_MODE_MARKUP) != 0)
> > ***************
> > *** 316,321 ****
> > --- 326,332 ----
> >    // register functions
> >    // functions are applied in order of registering
> >
> > + $transform->register(WT_NO_MARKUP, 'wtm_no_markup', '^<code>|^<\/code>');
> > //Added by LA
> >    $transform->register(WT_SIMPLE_MARKUP, 'wtm_plugin_link');
> >    $transform->register(WT_MODE_MARKUP, 'wtm_plugin');
> >
> > ***************
> > *** 643,648 ****
> > --- 654,673 ----
> >       function wtm_paragraph($line, &$trfrm) {
> >          $line = $trfrm->SetHTMLMode('p') . $line;
> >          return $line;
> > +    }
> > +
> > +    // No markup between <code>, </code>.  Added by LA
> > +    function wtm_no_markup($line, &$trfrm) {
> > +        if (preg_match('/^<code>(.*)/', $line, $m)) {
> > +            $trfrm->MarkupEnabled = 0;
> > +            $line = $trfrm->SetHTMLMode('pre').$m[1];
> > +        echo 'on';
> > +        } elseif (preg_match('/^<\/code>(.*)/', $line, $m)) {
> > +        $trfrm->MarkupEnabled = 1;
> > +        $line = $trfrm->SetHTMLMode('',0).$m[1];
> > +        echo 'off';
> > +        }
> > +        return $line;
> >       }
> >
> >    // (c-file-style: "gnu")
> >
> >
> > _______________________________________________
> > 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
>
>
>_______________________________________________
>Phpwiki-talk mailing list
>Php...@li...
>https://lists.sourceforge.net/lists/listinfo/phpwiki-talk

Re: [Phpwiki-talk] filenames with underscores: bleah

[J C L. <cl...@ka...>]

On Thu, 6 Dec 2001 18:54:03 -0500 
Carsten Klapp <car...@ma...> wrote:

> Bleah, those ugly underscores in filenames are my Pet-Peeve! Can
> we rename them to spaces or SmashThemTogether instead?

Whitespace in filenames make automated processing of directory
hierarchies and files unnecessarily difficult and careful.  Almost
no value add, significant value loss.  

-- 
J C Lawrence                
---------(*)                Satan, oscillate my metallic sonatas. 
cl...@ka...               He lived as a devil, eh?		  
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.