phpwiki-talk

Re: [Phpwiki-talk] Phpwiki producing junk

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

> If I then click on a link, I get a page full of junk characters.
> 
> Are you using Apache 2.0.x? I am, and I got the same results. The reason
> 
> apparently is that PhpWiki turns HTTP gzip compression on whether the 
> client supports it or not. To fix it, I commented out the guts of 
> compress_output() in lib/Request.pm.

Hrmph.  Yes this has come up before.   I suppose we should
make the compression a config option (and probably disable it
by default.)

It would be nice to figure out what the problem is.  AFAIK, PHP
should only be compressing the output if the browser sends
headers indicating that it can accept it.  
("Accept-Encoding: gzip" is the key header I think.)

Could it be that output is getting double compressed (once by PHP,
once by Apache) in your case?

Re: [Phpwiki-talk] Phpwiki producing junk

[Matti A. <ma...@ik...>]

On Saturday 09 November 2002 15:00, arthur.chereau wrote:

> After testing TWiki, I've just tried PHPwiki 1.3.3 because I found
> Twiki too complicated to use for my users. I've installed PHPwiki
> with MySQL but I can only get the first page right ("Loading up
> Virgin wiki"). If I then click on a link, I get a page full of junk
> characters.

Are you using Apache 2.0.x? I am, and I got the same results. The reason 
apparently is that PhpWiki turns HTTP gzip compression on whether the 
client supports it or not. To fix it, I commented out the guts of 
compress_output() in lib/Request.pm.

Cheers,

m.

[Phpwiki-talk] =?iso-8859-1?Q?Phpwiki_producing_junk?=

[<art...@vo...>]

Hi,

After testing TWiki, I've just tried PHPwiki 1.3.3 because I found Twiki too
complicated to use for my users. I've installed PHPwiki with MySQL but I can
only get the first page right ("Loading up Virgin wiki"). If I then click on a link,
I get a page full of junk characters.

Here's how I installed PHPwiki:

1) Extract

cd /home/http/phpwiki/
tar xzf ~/phpwiki-*.tar.gz
mkdir -p pages/
chown http http pages/
chmod 0755 pages/

2) Create the MySQL base

db_user=3D"wikiuser"
db_passwd=3D"wiki"
mysqladmin --user=3Droot --password=3D"sqlpwd" create phpwiki
cat <<EOF | mysql --user=3Droot --password=3D"sqlpwd"
  grant all privileges on *.* to $db_user@localhost \
  identified by "$db_passwd" with grant option;
  flush privileges;
EOF
mysql --user=3D"$db_user" --password=3D"$db_passwd" phpwiki \
      < /home/http/phpwiki/schemas/mysql.sql

3) Update httpd.conf

   Alias /wiki/ /home/http/phpwiki/
    <Directory /home/http/phpwiki>
        AllowOverride None
        Order allow,deny
        Allow from all
        SSLOptions +StdEnvVars
    </Directory>

4) Modify index.php

Here's the diff from the released index.php to my index.php:

@@ -93,7 +93,7 @@
 // This is used to generate a keywords meta tag in the HTML templates,
 // in bookmark titles for any bookmarks made to pages in your wiki,
 // and during RSS generation for the <title> of the RSS channel.
-//define('WIKI_NAME', 'PhpWiki');
+define('WIKI_NAME', 'PhpWiki');
 
 // If set, we will perform reverse dns lookups to try to convert the
 // users IP number to a host name, even if the http server didn't do
@@ -103,8 +103,8 @@
 // Username and password of administrator.
 // Set these to your preferences. For heaven's sake
 // pick a good password!
-define('ADMIN_USER', "");
-define('ADMIN_PASSWD', "");
+define('ADMIN_USER', "root");
+define('ADMIN_PASSWD', "rootpwd");
 
 // If true, only the admin user can make zip dumps, else zip dumps
 // require no authentication.
@@ -138,7 +138,7 @@
 
 // PhpWiki can generate an access_log (in "NCSA combined log" format)
 // for you. If you want one, define this to the name of the log file.
-//define('ACCESS_LOG', '/tmp/wiki_access_log');
+//define('ACCESS_LOG', '/var/log/phpwiki/access_log');
 
 
 // If ALLOW_BOGO_LOGIN is true, users are allowed to login (with
@@ -188,8 +188,8 @@
 //
 $DBParams =3D array(
    // Select the database type:
-   //'dbtype' =3D> 'SQL',
-   'dbtype'   =3D> 'dba',
+   'dbtype' =3D> 'SQL',
+   //'dbtype'   =3D> 'dba',
    
    // For SQL based backends, specify the database as a DSN
    // The most general form of a DSN looks like:
@@ -202,7 +202,7 @@
    //
    // FIXME: My version Pear::DB seems to be broken enough that there
    //        is no way to connect to a mysql server over a socket right now.
-   //'dsn' =3D> 'mysql://guest@:/var/lib/mysql/mysql.sock/test',
+   'dsn' =3D> 'mysql://wikiuser:wiki@localhost/phpwiki',
    //'dsn' =3D> 'mysql://guest@localhost/test',
    //'dsn' =3D> 'pgsql://localhost/test',
    
@@ -217,7 +217,7 @@
    //'prefix' =3D> 'phpwiki_',
    
    // Used by 'dba'
-   'directory'     =3D> "/tmp",
+   'directory'     =3D> "/home/http/phpwiki/pages",
    'dba_handler'   =3D> 'gdbm',   // Either of 'gdbm' or 'db2' work great for me.
    //'dba_handler' =3D> 'db2',
    //'dba_handler' =3D> 'db3',    // doesn't work at all for me....
@@ -314,7 +314,7 @@
 //define('THEME', 'Hawaiian');
 //define('THEME', 'MacOSX');
 //define('THEME', 'Portland');
-//define('THEME', 'Sidebar');
+define('THEME', 'Sidebar');
 //define('THEME', 'SpaceWiki');
 
 // Select a valid charset name to be inserted into the xml/html pages,


Did I miss something ?

------------------------------------------

Faites un voeu et puis Voila ! www.voila.fr 

[Phpwiki-talk] very urgent

[DRKABLANDUNCAN <drk...@eu...>]

MY NAME IS DR KABLANDUNCAN  A LEGAL PRACTITIONER AND A MEMBER=2C OF
NIGERIAN BAR ASSOCIATION AND INSTITUTION OF LEGAL STUDIES AND
INSTITUTE OF INTERNATIONAL AFFAIRS IN MY COUNTRY=2E

I AM FORWARDING THIS PROPOSAL TO YOU OT OF INTUITIVE CONFIDENCE I
HAVE
ABOUT YOU AND YOUR ABILITY TO ASSIST IN THE EXECUTION OF A CERTAIN
STRAIGHT FORWARD TRANSACTION=2E

THIS TRANSACTION INVOLVES A CASH INVESTMENT OF THE SUM OF
U=2ES$1=2E5MILLION =28TWENTY ONE MILLION FIVE HUNDRED THOUSAND UNITED
STATES
DOLLARS=29 IN REAL ESTATE BUSINESS OR BUYING SHARES IN A STRONG
RELIABLE
COMPANY IN YOUR COUNTRY=2E

THE INVESTMENT WILL BE UNDER YOUR SUPERVISION AND CONTROL ON BEHALF
OF
MY CLIENT=2C WHO IS THE CURRENT WORKS AND HOUSING MINISTER UNDER THIS
PRESENT PRESIDENT OLUSEGUN OBASANJO ADMINISTRATION=2E AS A MATTER OF
FACT=2C MY CLIENT IS VERY OPTIMISTIC TO INVEST IN YOUR COUNTRY DUE TO
HIS RECENT FINDING PERSONALLY BEST KNOWN TO HIM COUPLE WITH THE FACT
THAT THE CODE OF CONDUCT DOES NOT ALLOWS HIM TO RUN THE INVESTMENT
WITHOUT AN ASSISTANCE OF A FOREIGN PARTNER=2E MY CLIENT COMMEND YOUR
COUNTRY AS HE SAID THAT YOUR COUNTRTY IS FULL OF POTENTIAL IN THE
FIELD OF INVESTMENT AS A RESULT OF PRIVATE PERSONAL AND POLITICAL
REASONS=2E

HE DECIDED TO MAINTAIN ANONYMITY FOR NOW=2C PENDING A CONFIRMATION OF
YOUR WILLINGNESS TO ASSIST AND CORPORATE IN THE EXECUTIVE OF THIS
PROJECT=2E
=3EAS SOON AS I RECEIVE YOUR CONFIRMATION OF ASSISTANCE I WILL FORWARD
ALL RELEVANT DETAILS THAT WILL ENSURE THE SMOOTH AND OVER OF THE
MONEY
TO YOU=2C THESE DETAILS WOULD INCLUDES ALL RELEVANT INSTRUCTION OF
EXACTLY WHAT WE WANT=2C CONDITION OF INVESTMENT=2C OUR MEETING POINT TO
FAMILIAR THESE SERVICE RENDERED IN THIS RESPECT=2E
THIS ENQUIRY URGENT=2C AS IT DESERVES TO BE TREATED WITH URGENCY IN
ORDER NOT TO MAKE FURTHER CONTACT FOR SAME ABROAD YOU CAN HOWEVER
REACH ME THROUGH DIRECT EMAIL 
YOURS SINCERELY=2C
DR KABLANDUNCAN =28ESQ=29=2E

Re: [Phpwiki-talk] index.php to index-dist.php?

[Joby W. <joby@u.washington.edu>]

Ahh....

Sorry, I maintain seperate web and CVS/editing versions to avoid such 
problems.  I also only commit particular files rather than all modified. 
  But this is a worry.

jbw

Matti Airas wrote:
> On Friday 08 November 2002 22:02, Joby Walker wrote:
> 
> 
>>Since config-user.php is blank and should never need to be modified
>>in CVS we shouldn't need to worry.  Though, I agree that for
>>packaging it becomes a problem since we don't want to overwrite
>>someone's config-user.php with a blank file.
> 
> 
> But the first time a developer with CVS write access commits his code 
> changes to the repository and forgets to empty his config-user.php, his 
> local config is sent to the repository... Been there, done that. :-(
> 
> m.
> 

Re: [Phpwiki-talk] index.php to index-dist.php?

[Matti A. <ma...@ik...>]

On Friday 08 November 2002 22:02, Joby Walker wrote:

> Since config-user.php is blank and should never need to be modified
> in CVS we shouldn't need to worry.  Though, I agree that for
> packaging it becomes a problem since we don't want to overwrite
> someone's config-user.php with a blank file.

But the first time a developer with CVS write access commits his code 
changes to the repository and forgets to empty his config-user.php, his 
local config is sent to the repository... Been there, done that. :-(

m.

Re: [Phpwiki-talk] NewTextFormattingRules, DynamicTextFormattingHelp

[Matti A. <ma...@ik...>]

[Manual Cc to mailing list... Damn mail clients!]

On Friday 08 November 2002 18:46, Jeff Dairiki wrote:
> > I'm still wondering about the anchor generation, however...
>
> Either of those suggestions is certainly doable, but my concerns are:
>   1. They can lead to very unnecessarily long anchor names.
>   2. Duplicate anchor names are possible.
>   3. It might be too much magic.
>
> Example:
>
> !! #[References]
>
> is explicit.  Everyone can see that there's something special
> about "References" (even if they're not sure what it is.)

Yes, but the problem is, that without automatic anchoring you'd have to
edit the page to be able to link to it. That'd be a problem if you
didn't have permissions to do so...

However, I agree with your points 1 and 2, although duplicate anchor
names might not be that dangerous. Shit happens, as they say...

> Upon second thought, maybe the old-style ''emphasis'' __isn't__
> deprecated.
>
:-)

Technical side-note: the implementation regexps would probably be much
more robust if the tag characters were doubled: **bold**, __italic__,
==monospace==. But I really don't have strong feelings about those.

> Other concerns are: lynx, links, emacs-w3, etc...
> Not a big deal

True, but all of them are used by advanced users, who probably can deal
with both help texts being displayed at the same time. The real problem
are casual users. There still might be some IE 4 and NN 4 users in
corporate environments, and poor support for them might be a problem
for PhpWiki adoption. Sigh, maybe I should implement support for
them... Or what do you say? (Please, tell me they're not necessary.)

m.

-------------------------------------------------------

Re: [Phpwiki-talk] index.php to index-dist.php?

[Joby W. <joby@u.washington.edu>]

Since config-user.php is blank and should never need to be modified in 
CVS we shouldn't need to worry.  Though, I agree that for packaging it 
becomes a problem since we don't want to overwrite someone's 
config-user.php with a blank file.

Other views?

jbw

Matti Airas wrote:
> On Friday 08 November 2002 17:35, Joby Walker wrote:
> 
> 
>>index.php will be replaced with:
>>
>>index.php -- just contains includes (in CVS as index2.php)
>>config/config-dist.php -- default distribution settings
>>config/config-user.php -- localized config settings
>>
>>This has been in CVS for a few weeks, but I have received no comment
>>on implementation.  It should be good to go.
> 
> 
> OK, good. It'd be nice, though, if there were no config-user.php at all 
> in CVS, so that it's safe to do cvs updates (and maybe commits) without 
> risk of hosing current configuration (or the default configuration in 
> CVS). Then, config-user.php could be included (instead of currently 
> being required), and if it's missing, a nag message with instructions 
> to create an empty configuration file could be included in the header 
> of each and every displayed page. Or alternatively, the user could be 
> instructed to use the configurator in the works... :-)
> 
> m.
> 

Re: [Phpwiki-talk] index.php to index-dist.php?

[Matti A. <ma...@ik...>]

On Friday 08 November 2002 17:35, Joby Walker wrote:

> index.php will be replaced with:
>
> index.php -- just contains includes (in CVS as index2.php)
> config/config-dist.php -- default distribution settings
> config/config-user.php -- localized config settings
>
> This has been in CVS for a few weeks, but I have received no comment
> on implementation.  It should be good to go.

OK, good. It'd be nice, though, if there were no config-user.php at all 
in CVS, so that it's safe to do cvs updates (and maybe commits) without 
risk of hosing current configuration (or the default configuration in 
CVS). Then, config-user.php could be included (instead of currently 
being required), and if it's missing, a nag message with instructions 
to create an empty configuration file could be included in the header 
of each and every displayed page. Or alternatively, the user could be 
instructed to use the configurator in the works... :-)

m.

Re: [Phpwiki-talk] NewTextFormattingRules, DynamicTextFormattingHelp

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

On Fri, 8 Nov 2002 12:46:23 +0200
Matti Airas <ma...@ik...> wrote:

> >   Named anchors:
> >      #[foo]       An anchor around the text "foo" with id "foo".
> >      #[|foo]      An empty anchor with id "foo".
> >      #[howdy|foo] An anchor around the text "howdy" with id "foo".
> >   References to name anchors are made thusly:
> >      [#foo], [OtherPage#foo], [named|OtherPage#foo] ...
> 
> OK, added. I actually tried to get them work already while writing the 
> documentation in the first place, but couldn't figure out how they 
> work. :-)
> 
> I'm still wondering about the anchor generation, however. Shouldn't it 
> be automatic, so that headings and maybe some other special markup (or 
> maybe three first words of each paragraph) would be automatically 
> anchored? That would make it easier to refer to some arbitrary text 
> passages such as 
> http://mairas.net/wiki/NewTextFormattingRules#References (doesn't work 
> yet).

Either of those suggestions is certainly doable, but my concerns are:
  1. They can lead to very unnecessarily long anchor names.
  2. Duplicate anchor names are possible.
  3. It might be too much magic.

Example:

!! #[References]

is explicit.  Everyone can see that there's something special
about "References" (even if they're not sure what it is.)

> >   The new "nestled" emphasis:  *bold*, _italic_, and =monospace=.
> >   (I think ''emph'' and __strong__ are quasi-deprecated.)
> >
> >   The old-style list markup works (more or less) as before.
> >   I'm not sure whether this is worth mentioning on the page or not...
> 
> OK, I removed traces of old-style markup and made the page use new 
> markup only. At the moment the page is quite badly broken, but it can 
> be thought of as a test case. :-)

Upon second thought, maybe the old-style ''emphasis'' __isn't__
deprecated.

> > Currently, in older browsers, I think your [DynamicTextFormattingHelp]
> > 
> > patch shows both old and new help messages.  I'm not sure whether 
> > that's the best thing to do in this case...  (pros: all the info is 
> > there; cons: cluttered, confusing...) Comments?
> 
> This was my intention, although I agree it might not be ideal behaviour.
> 
> However, at least for some time the majority of existing pages are 
> written using OldMarkup, and it would be very confusing to edit them 
> without any kind of reference. Maybe it would be safe to assume that 
> people using browsers with Javascript disabled or without proper DHTML 
> support would be advanced enough to be able to handle the UI 
> degradation? Or is there still a significant amount of corporate 
> Netscape 4 users to worry about?

Other concerns are: lynx, links, emacs-w3, etc...
Not a big deal
> Given an unlimited amount of headache pills, I could try to implement 
> support for IE 4 and Netscape 4, but I'd rather not (those proprietary 
> DOM implementation deserve to die).

I agree completely.  It's not worth the effort or code clutter to fix
those cases.

Re: [Phpwiki-talk] index.php to index-dist.php?

[Joby W. <joby@u.washington.edu>]

We are looking to change configuration settings.

index.php will be replaced with:

index.php -- just contains includes (in CVS as index2.php)
config/config-dist.php -- default distribution settings
config/config-user.php -- localized config settings

This has been in CVS for a few weeks, but I have received no comment on 
implementation.  It should be good to go.

jbw

Matti Airas wrote:
> Would it make sense to rename index.php to index-dist.php in CVS (and 
> maybe in further releases as well)? Furthermore, DirectoryIndex in 
> .htaccess could be "index.php index-dist.php". That way, you could 
> safely update your local Wiki without overwriting the configuration.
> 
> ... or how do you prefer to handle configuration files with CVS?
> 
> Cheers,
> 
> m.
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: See the NEW Palm 
> Tungsten T handheld. Power & Color in a compact size!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwiki-talk

[Phpwiki-talk] index.php to index-dist.php?

[Matti A. <ma...@ik...>]

Would it make sense to rename index.php to index-dist.php in CVS (and 
maybe in further releases as well)? Furthermore, DirectoryIndex in 
.htaccess could be "index.php index-dist.php". That way, you could 
safely update your local Wiki without overwriting the configuration.

... or how do you prefer to handle configuration files with CVS?

Cheers,

m.

Re: [Phpwiki-talk] NewTextFormattingRules, DynamicTextFormattingHelp

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

Jeff Dairiki schrieb:
>>http://mairas.net/wiki/DynamicTextFormattingHelp.
> 
> Also very cool!  I see no problem with DHTML (we already use javascript
> other places as well) as long as it degrades reasonably for people with
> older browsers (or with javascript disabled).
> 
> Currently, in older browsers, I think your patch shows both old and new
> help messages.  I'm not sure whether that's the best thing to do in this
> case...  (pros: all the info is there; cons: cluttered, confusing...)
> Comments?

Add it to CVS.
-- 
Reini Urban

Re: [Phpwiki-talk] Bug#168137: phpwiki: HTTP_HOST should be used instead of SERVER_NAME in config.php (fwd)

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

Jeff Dairiki schrieb:
>>Which is kinda the reason for my question above - can ServerName be set
>>on a per-VHost basis?  If not, you'd need to use HTTP_HOST or manually
>>set SERVER_NAME in PHPWiki for each VHost you wanted to have Wikiing.
> 
> 
> Yup.  You can (and probably should) put a ServerName directive in each
> <VirtualHost> section of an Apache config file.

I'm also against this patch.
There's only HTTP_HOST but multiple SERVER_NAME's.
I use name-based vhosts extensively. This will break most of my wiki's.

It broke the debian user's wiki because of his special server 
configuration. If he wants to be hidden from outside, well so.
If not he has to define a vhost.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] A PhpHighlight plugin

[Martin G. <gim...@gi...>]

Carsten Klapp <car...@us...> writes:

Hi again

> I checked it into CVS with a modification to make it compatible with
> PHP < 4.2.0 and the ability to specify colors. (Time for me to think
> about upgrading my PHP).

I've just tried the version you put in CVS, and since I have a recent
version of PHP, the variable $has_old_php doesn't exist when we arrive
at the 'if ($has_old_php)' statement.

Changing it to 'if (!empty($has_old_php))' fixes this tiny problem...

-- 
Martin Geisler                       My GnuPG Key: 0xF7F6B57B

See http://gimpster.com/ and http://phpweather.net/ for:
PHP Weather => Shows the current weather on your webpage and
PHP Shell   => A telnet-connection (almost :-) in a PHP page.

Re: [Phpwiki-talk] Bug#168137: phpwiki: HTTP_HOST should be used instead of SERVER_NAME in config.php (fwd)

[Matthew P. <mj...@ie...>]

On Thu, 7 Nov 2002, Jeff Dairiki wrote:

> > Which is kinda the reason for my question above - can ServerName be set
> > on a per-VHost basis?  If not, you'd need to use HTTP_HOST or manually
> > set SERVER_NAME in PHPWiki for each VHost you wanted to have Wikiing.
> 
> Yup.  You can (and probably should) put a ServerName directive in each
> <VirtualHost> section of an Apache config file.

That makes it even easier, then.  Thanks.

- Matt

Re: [Phpwiki-talk] Bug#168137: phpwiki: HTTP_HOST should be used instead of SERVER_NAME in config.php (fwd)

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

> Which is kinda the reason for my question above - can ServerName be set
> on a per-VHost basis?  If not, you'd need to use HTTP_HOST or manually
> set SERVER_NAME in PHPWiki for each VHost you wanted to have Wikiing.

Yup.  You can (and probably should) put a ServerName directive in each
<VirtualHost> section of an Apache config file.

Re: [Phpwiki-talk] Bug#168137: phpwiki: HTTP_HOST should be used instead of SERVER_NAME in config.php (fwd)

[Matthew P. <mj...@ie...>]

On Thu, 7 Nov 2002, Jeff Dairiki wrote:

> According to the CGI spec (http://hoohoo.ncsa.uiuc.edu/cgi/env.html)
> SERVER_NAME should be "The server's hostname, DNS alias, or IP address
> as it would appear in self-referencing URLs."

Well, that certainly puts the tin hat on it.  If that's what we're supposed
to be using in self-referential links according to the spec, that kind of
answers the question permanently.

> SERVER_NAME can be explicitly set in the apache config file
> using the ServerName directive.   See:
>   http://httpd.apache.org/docs/mod/core.html#servername

Just a question off the topic since it just popped into my head - can you
set SERVER_NAME on a per-VHost basis?  I should probably just try it, I
guess.

> If he doesn't want to muck with the Apache config, the PhpWiki admin
> can also explicitly define PhpWiki's SERVER_NAME in the PhpWiki config
> file (index.php).   $HTTP_SERVER_VARS['SERVER_NAME']
> is only used as the default when the admin hasn't specified a
> value for SERVER_NAME in the config file.

Which is a reasonable alternative.

> (The PhpWiki admin is, of course also allowed to put something like
>   define('SERVER_NAME', $_SERVER['HTTP_HOST']);
> into index.php if that's really what s/he wants.)

Heh, quite a reasonable way to do it if that's the desired functionality.

> As far as what to use for the default, auto-detected case,
> it's not clear to me that $HTTP_SERVER_VARS['HTTP_HOST'] would
> work better than $HTTP_SERVER_VARS['SERVER_NAME'] in the majority
> of cases. 

It would work, to my way of thinking, from the point of view that if the
client has used that name to get to the server in the first place, it would
be reasonable to expect it to work for the next request...

> Another concern is that, 'HTTP_HOST' comes from the browser 
> (client), passed in one of the Host: header of the HTTP request ---
> so there may be some security issues involved as well.

Mmmm... not a security expert, but nothing comes to mind off the top of my
head.  But trusting anything from the client-side is never recommended...
<g>

> The real intended use of HTTP_HOST is for use in virtual hosting
> situations where multiple virtual hosts share the same IP address.
> Generally, it's used by the server (apache) to determine which 
> virtual host to direct the request to...

Which is kinda the reason for my question above - can ServerName be set on a
per-VHost basis?  If not, you'd need to use HTTP_HOST or manually set
SERVER_NAME in PHPWiki for each VHost you wanted to have Wikiing.  Of
course, you're going to have to have some sort of separate config for each
independent Wiki, but I thought it might save a bit of work to have one less
config item to set for each VHost.

At the end of the day, though, the CGI spec says "Thou shalt use SERVER_NAME
for self-referencing URLs" so, in the absence of anything really
show-stopping to the contrary, I'll take the spec's word for it.

- Matt

Re: [Phpwiki-talk] Bug#168137: phpwiki: HTTP_HOST should be used instead of SERVER_NAME in config.php (fwd)

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

Thanks for passing on the report, Matthew.

> Is this a problem which the PHPWiki authors feel is a real problem?

I think this is a non-bug.

According to the CGI spec (http://hoohoo.ncsa.uiuc.edu/cgi/env.html)
SERVER_NAME should be "The server's hostname, DNS alias, or IP address
as it would appear in self-referencing URLs."

So if SERVER_NAME is not what you want in self-referencing URLs, I
say it's an Apache configuration problem.

SERVER_NAME can be explicitly set in the apache config file
using the ServerName directive.   See:
  http://httpd.apache.org/docs/mod/core.html#servername


If he doesn't want to muck with the Apache config, the PhpWiki admin
can also explicitly define PhpWiki's SERVER_NAME in the PhpWiki config
file (index.php).   $HTTP_SERVER_VARS['SERVER_NAME']
is only used as the default when the admin hasn't specified a
value for SERVER_NAME in the config file.

(The PhpWiki admin is, of course also allowed to put something like
  define('SERVER_NAME', $_SERVER['HTTP_HOST']);
into index.php if that's really what s/he wants.)


 
I'm reluctant to make changes in PhpWiki's auto-config defaults
based on problems dealing with cases where the hosts IP does not
map to a resolable host-name --- it seems that's what manual
configuration is for.

As far as what to use for the default, auto-detected case,
it's not clear to me that $HTTP_SERVER_VARS['HTTP_HOST'] would
work better than $HTTP_SERVER_VARS['SERVER_NAME'] in the majority
of cases. 

Another concern is that, 'HTTP_HOST' comes from the browser 
(client), passed in one of the Host: header of the HTTP request ---
so there may be some security issues involved as well.



The real intended use of HTTP_HOST is for use in virtual hosting
situations where multiple virtual hosts share the same IP address.
Generally, it's used by the server (apache) to determine which 
virtual host to direct the request to...

[Phpwiki-talk] Author not posting properly

[Brian R. <raz...@vm...>]

I just installed version 1.3.3 on RedHat Linux 7.3 using mySQL as the
backend and am having a problem whereby after I login it will show me as
being logged in--but when I make a change the only thing it records is the
IP address.  Can someone point me in the right direction as to where I might
look to fix this?  We are trying to use the app for documentation and it is
important for us to know who made modifications.

Thank you,
Brian Razzaque

[Phpwiki-talk] Bug#168137: phpwiki: HTTP_HOST should be used instead of SERVER_NAME in config.php (fwd)

[Matthew P. <mj...@ie...>]

I've just gotten this bug report from a user of the Debian package of
PHPWiki (reproduced in part below; the complete bug report and all
subsequent discussion can be found at http://bugs.debian.org/168137).  As
all good users do, he's even produced a patch (attached) to correct the
problem as he sees it.

Is this a problem which the PHPWiki authors feel is a real problem?  The
patch should apply cleanly, and I'm going to apply and test it when I've got
a bit more free time, but I thought it best to get this out to the upstream
developers ASAP.

-- 
-----------------------------------------------------------------------
#include <disclaimer.h>
Matthew Palmer, Geek In Residence
http://ieee.uow.edu.au/~mjp16

---------- Forwarded message ----------
Date: Thu, 07 Nov 2002 10:02:06 +0100
From: Ulf Rompe <deb...@ro...>

phpwiki uses $HTTP_SERVER_VARS['SERVER_NAME'] to build URLs. I believe that
$HTTP_SERVER_VARS['HTTP_HOST'] should be used instead. Many systems have more
than one name, and often the primary configured name is not resolvable from
outside. In my case, the server is normally named "server.internal-nis-domain",
but to be accessible via WWW it has an additional DNS entry calles like
"server.official-domain.de". SERVER_NAME resolves to the first, unreachable
name, whereas HTTP_HOST gives the right one (which has to be correct because
it is the name we called to reach the PHP script).

Maybe it would be possible to work around the problem by defining a VirtualHost
(untested), but I think changing the variable would be the right way because
HTTP_HOST is meant for this purpose.

Re: [Phpwiki-talk] NewTextFormattingRules, DynamicTextFormattingHelp

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

On Thu, 07 Nov 2002 21:30:45 +0100
Martin Geisler <gim...@gi...> wrote:

> There's a problem with this markup: it only works when there's a space
> after the closing *, _ or =. So your example doesn't work as you typed
> it - you have to type it like this:
> 
>   *bold* , _italic_ , and =monospace= .

Okay, that's a bug.  I'll look at it.  As you point out, the regexps
are hairy.
 
> Also, why is the underscore used for italic? I've always thought that
> one used /slashes/ for italic and _underscore_ for underlining. At
> least that's how Gnus pretty-prints my mails, and it also seams more
> logical to me.

This was discussed at length awhile ago.  It seems everyone has their
own ideas on the precise meaning of the the possible emphasis characters.

A problem with slashes as delimeters is that slashes commonly occur
as parts of filenames.  (E.g. on unix systems, config files are kept
in /etc/.)

When used in ascii email, it's easy for all to agree that all these
things are some form of emphasis --- exactly what sort of emphasis 
each corresponds to is subject to disagreement...

I think it's fairly non-controversial to assert that *this* and _this_
are (by far) the most commonly used forms of emphasis in e-mail.
Therefore, my feeling is that these should correspond to bold and italic
emphasis, or vice versa...

> The changed class is this:
> 
> class Markup_nestled_emphasis extends BalancedMarkup
> {
>     var $_start_regexp = '[*_=\/]';
> 
>     function getEndRegexp ($match) {
>         return "\\" . $match;
>     }
> }

The "nestled" in nestled emphasis means that the delimiters have
to be properly nestled at (some sort of) word boundaries.
The opening delimiter must have no space between it and the
beginning of the first delimited word, and correspondingly
there must be no space between the last delimited word
and the trailing delimiter.

Re: [Phpwiki-talk] NewTextFormattingRules, DynamicTextFormattingHelp

[Martin G. <gim...@gi...>]

Jeff Dairiki <da...@da...> writes:

>   The new "nestled" emphasis: *bold*, _italic_, and =monospace=. (I
>   think ''emph'' and __strong__ are quasi-deprecated.)

There's a problem with this markup: it only works when there's a space
after the closing *, _ or =. So your example doesn't work as you typed
it - you have to type it like this:

  *bold* , _italic_ , and =monospace= .

Which, of course, looks awful because of the spaces before ','...

Also, why is the underscore used for italic? I've always thought that
one used /slashes/ for italic and _underscore_ for underlining. At
least that's how Gnus pretty-prints my mails, and it also seams more
logical to me.

I changed the Markup_nestled_emphasis class so do the markup like
this, but I'm afraid that it will change something else, because I
changed the huge regular expressions (which I didn't understand fully)
to much simpler versions... Perhaps someone could explain, what all
the look-ahead and look-behind does?

The changed class is this:

class Markup_nestled_emphasis extends BalancedMarkup
{
    var $_start_regexp = '[*_=\/]';

    function getEndRegexp ($match) {
        return "\\" . $match;
    }
    
    function markup ($match, $body) {
        switch ($match) {
        case '*': return new HtmlElement('b', $body);
        case '_': return new HtmlElement('u', $body);
        case '=': return new HtmlElement('tt', $body);
        default:  return new HtmlElement('i', $body);
        }
    }
}


-- 
Martin Geisler                       My GnuPG Key: 0xF7F6B57B

See http://gimpster.com/ and http://phpweather.net/ for:
PHP Weather => Shows the current weather on your webpage and
PHP Shell   => A telnet-connection (almost :-) in a PHP page.

Re: [Phpwiki-talk] NewTextFormattingRules, DynamicTextFormattingHelp

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

> http://mairas.net/wiki/NewTextFormattingRules.

Very good.

Some things which might be worth adding:
  
  Named anchors:
     #[foo]       An anchor around the text "foo" with id "foo".
     #[|foo]      An empty anchor with id "foo". 
     #[howdy|foo] An anchor around the text "howdy" with id "foo".
  References to name anchors are made thusly:
     [#foo], [OtherPage#foo], [named|OtherPage#foo] ...

  The new "nestled" emphasis:  *bold*, _italic_, and =monospace=.
  (I think ''emph'' and __strong__ are quasi-deprecated.)

  The old-style list markup works (more or less) as before.
  I'm not sure whether this is worth mentioning on the page or not...

 
> http://mairas.net/wiki/DynamicTextFormattingHelp.

Also very cool!  I see no problem with DHTML (we already use javascript
other places as well) as long as it degrades reasonably for people with
older browsers (or with javascript disabled).

Currently, in older browsers, I think your patch shows both old and new
help messages.  I'm not sure whether that's the best thing to do in this
case...  (pros: all the info is there; cons: cluttered, confusing...)
Comments?

Re: [Phpwiki-talk] Bug reports?

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

> Where do you prefer to get bug reports? In Sourceforge BTS, in PhpWiki 
> WikiWeb or on this mailing list? Or some combination of them all?

Any of the above are officially okay, I think...  Maybe that should
change.

We (I, at least) have gotten so far behind in the SF tracker, that I'm
afraid to look over there these days.   (Out of curiosity, does anyone
else check regularly over there?)

Here's my general preferences (but these are not laws):

 1. If it's a concise bug report (problem well defined, probably with
included
    patch).  It's probably best posted here.  (Or post on the SF bug
tracker,
    along with a note here.)  This is the sort of thing that should be 
    (simply) and quickly fixed in CVS by someone...

 2. If it's really, really important, make sure to post something here.
    That's where it's most likely to be noticed in some sort of timely
manner.

 3. Everything else should probably go on the tracker --- that being the
    best place to _track_ those issues which may take some time to
resolve.

 4. Except of course things which aren't really bugs but more along
    the "feature request" and "how do I?" sorts of things --- those should
    probably go on the wiki (or here, if they're interesting...)