phpwiki-talk

Re: [Phpwiki-talk] phpwiki behind a proxy

[Benjamin T. <th...@cc...>]

Great! I added "define('SERVER_PORT', 443);" and that's it!

Thank you very, very much!!

Benjamin


Reini Urban wrote:
> Benjamin Thelen schrieb:
> 
>> This is the code snipped I added:
>>
>>
>> if($_SERVER["HTTP_HOST"]== "wiki-Server.intern"){
>>         define('SERVER_NAME', 'extern.dns-name.de');
>> }
>> else{
>>         define('SERVER_NAME', 'wiki-Server');
> 
> 
> Just do the same for SERVER_PROTOCOL:
> 
> if($_SERVER["HTTP_HOST"]== "wiki-Server.intern"){
>         define('SERVER_NAME', 'extern.dns-name.de');
>         define('SERVER_PROTOCOL', 'https');
> }
> else{
>         define('SERVER_NAME', 'wiki-Server');
>         define('SERVER_PROTOCOL', 'http');
> }
> 
>>
>>
>> This would run fine, but we use https to access the "phpwiki-server" 
>> from outside. If I now call 
>> https://extern.dns-name.de/phpwiki-1.3.9/index.php every link on this 
>> page refers to http://extern.dns-name.de/.... The difference is the 
>> "s". So, somehow phpwiki replaces https to http, doesn' it? Do you 
>> have an idea how to fix this?
> 
> 

Re: [Phpwiki-talk] phpwiki behind a proxy

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

Benjamin Thelen schrieb:
> This is the code snipped I added:
> 
> 
> if($_SERVER["HTTP_HOST"]== "wiki-Server.intern"){
>         define('SERVER_NAME', 'extern.dns-name.de');
> }
> else{
>         define('SERVER_NAME', 'wiki-Server');

Just do the same for SERVER_PROTOCOL:

if($_SERVER["HTTP_HOST"]== "wiki-Server.intern"){
         define('SERVER_NAME', 'extern.dns-name.de');
         define('SERVER_PROTOCOL', 'https');
}
else{
         define('SERVER_NAME', 'wiki-Server');
         define('SERVER_PROTOCOL', 'http');
}

> 
> 
> This would run fine, but we use https to access the "phpwiki-server" 
> from outside. If I now call 
> https://extern.dns-name.de/phpwiki-1.3.9/index.php every link on this 
> page refers to http://extern.dns-name.de/.... The difference is the "s". 
> So, somehow phpwiki replaces https to http, doesn' it? Do you have an 
> idea how to fix this?

-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] phpwiki bug report and fix...

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

kevin lyda schrieb:
> i'm not subscribed, just passing this info on:
> 
> in lib/WikiUserNew.php on line 1957 of version 1.39 there is a line that
> reads:
> 
>     fputs($fp, "user $user\n");
> 
> it needs to read:
> 
>     fputs($fp, "user $userid\n");
> 
> it is for the pop3 auth method.
> 
> thanks for all your work, hope this helps.

Thanks, that was already reported before and already fixed in current CVS.
But I will add this patch to the upcoming 1.3.9 bugfix-patch also.

-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] allow_anon_edit false doesn't seem to work?

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

Russ Miller schrieb:
> Is the permissions problem ironed out? 

Yes

 > Is it back in the stable 1.3.8 branch?

No, sorry.
1.3.9 is the last stable developers release.
We are working on 1.3.10, with many changes and fixes. And as you can 
see at the demo site, it is not yet stable.

I will produce a patch against 1.3.9 which will fix the permission 
problem and some more minor fixes, and put it to the sf.net patches site 
today.
   https://sourceforge.net/tracker/?group_id=6121&atid=306121
But this version will not work with php-4.0.6!

I just released a new phpwiki-1.2.4 package (from the 2001 stable 
branch) which fixes some dba problems.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] phpwiki behind a proxy

[Benjamin T. <th...@cc...>]

Hi Joby,

Thanks again for your help!! But I'm afraid, that is still not the 
solution.

I think I found the origin of the problem, which I just wrote in my 
answer to Reini. I think, this is why defining *one* server name does 
not help. If you could be so kind to read my answer to Reini?

Thank you very much to you as well,
Benjamin



Joby Walker wrote:
> In Part 6 of the index.php there is:
> 
> ---------------------------------------------------------------
> /*
>  * Canonical name and httpd port of the server on which this PhpWiki
>  * resides.
>  */
> //if (!defined('SERVER_NAME')) define('SERVER_NAME', 'some.host.com');
> ---------------------------------------------------------------
> 
> change to:
> 
> ---------------------------------------------------------------
> /*
>  * Canonical name and httpd port of the server on which this PhpWiki
>  * resides.
>  */
> if (!defined('SERVER_NAME')) define('SERVER_NAME', $_SERVER['HTTP_HOST']);
> ---------------------------------------------------------------
> 
> 
> $_SERVER['SERVER_NAME'] is the cannonical name set via apache.conf
> $_SERVER['HTTP_HOST'] is the hostname requested by the browser
> 
> $_SERVER['SERVER_NAME'] is the default because most administrators would 
> prefer to force the use of cannonical names to ensure that a standard is 
> set.  For example, to force the display of www.domainname.com rather 
> than hostname.domainname.com.  Doing so is desireable because it 
> prevents broken links/bookmarks/etc if the website is moved to a 
> different host.
> 
> Joby Walker
> 
> 
> Benjamin Thelen wrote:
> 
>> Hello,
>>
>>
>> I found out, that phpwiki builds up the urls from a static "http" and 
>> from "ServerName" given in apache-httpd.conf, which is in fact given 
>> as our external dns-name. So if I change this to the internal name or 
>> add the internal name to phpwikis SERVER_NAME-section in index.php, 
>> access from intranet is working fine.
>> This is why HTTP_HOST does not solve the problem, because the hostname 
>> is always the internal name of the machine and http is used instead of 
>> https. Using "define SERVER_NAME as $_SERVER['HTTP_HOST']" just shows 
>> up an empty browser.
>>
>>
>> Why does phpwiki not add a relative path to the request, coming from 
>> the browser?
>>
>>
>>
>> Kind Regards,
>> Benjamin
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Joby Walker wrote:
>>
>>> In index.php define SERVER_NAME as $_SERVER['HTTP_HOST'].  This will 
>>> grab the hostname used by the browser.
>>>
>>> Joby Walker
>>> C&C Computer Operations Software Support Group
>>>
>>>
>>>
>>> Benjamin Thelen wrote:
>>>
>>>> Hi,
>>>>
>>>> I have a debian/squid server which forwards http request to another 
>>>> debian-machine on which apache 1.3.26, phpwiki-1.3.7 and some other 
>>>> php-based applications (phprojekt/phpMyAdmin/squirrelmail) are running.
>>>>
>>>> Using phpwiki from the intranet everything works fine. If I access 
>>>> the main-page from outside the intranet, for example from home, the 
>>>> first page isn't displayed properly and every link and the pics on 
>>>> this page refers to the internal name of the server, instead of the 
>>>> public domain name.
>>>>
>>>> All the other php-based applications work fine.
>>>>
>>>> Example:
>>>>
>>>> Intranet
>>>> http://host/phpwiki/index.php
>>>>
>>>> Internt:
>>>> http://www.dns-name.de/phpwiki/index.php
>>>>
>>>>
>>>> So, it seems that phpwiki asks its host for the hostname and 
>>>> prepends the hostname to the path, where phpwiki is located, instead 
>>>> of using relative paths.
>>>>
>>>>
>>>> Sorry, it's a little bit difficult to explain, but I hope you got 
>>>> the problem somehow.
>>>>
>>>>
>>>> Is there a missconfiguration of phpwiki? I tried 
>>>> define('SERVER_NAME' and define('SCRIPT_NAME' and the 
>>>> configurator.php, but all that did not solve the problem!
>>>>
>>>>
>>>> Thanks,
>>>> Benjamin
>>>>
>>>>
>>>>
>>>>
>>>> -------------------------------------------------------
>>>> This SF.Net email is sponsored by: Oracle 10g
>>>> Get certified on the hottest thing ever to hit the market... Oracle 
>>>> 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
>>>> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
>>>> _______________________________________________
>>>> Phpwiki-talk mailing list
>>>> Php...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/phpwiki-talk
>>>
>>>
>>>
>>>
>>
> 

Re: [Phpwiki-talk] phpwiki behind a proxy

[Benjamin T. <bt...@cc...>]

Reini Urban wrote:
> Benjamin Thelen schrieb:
> 
>> I found out, that phpwiki builds up the urls from a static "http" and 
>> from "ServerName" given in apache-httpd.conf, which is in fact given 
>> as our external dns-name. So if I change this to the internal name or 
>> add the internal name to phpwikis SERVER_NAME-section in index.php, 
>> access from intranet is working fine.
>> This is why HTTP_HOST does not solve the problem, because the hostname 
>> is always the internal name of the machine and http is used instead of 
>> https. Using "define SERVER_NAME as $_SERVER['HTTP_HOST']" just shows 
>> up an empty browser.
>>
>> Why does phpwiki not add a relative path to the request, coming from 
>> the browser?
> 
> 
> It does use relative paths where appropriate.
> Only if the 3rd parameter for WikiURL is true, absolute paths are used.
> 
> Why don't you put your logic between the config loader and the main loader?
> Or fix config.php for your special case?



Hello Reini,

thanks for your help!
I am afraid I don't understand, what you mean with "3rd parameter for 
WikiURL is true". And I'm afraid I also don't know what config loader 
and the main loader are?


I could fix the first step in config.php. I would like to explain the 
case in detail. Maybe you have a better solution.

The server on which phpwiki resides has a hostname, which differs if 
the "phpwiki-server" is accessed from outside (through a firewall and 
a proxy-server) or inside. That comes from the proxy-server 
configuration. The proxy-server knows the "phpwiki-server" as 
'wiki-server.intern' and the "phpwiki-server" knows itself as 
'wiki-server'. That is kind of a missconfiguration of the 
proxy-server, but in our case the first step to a solution. There is a 
third name for the "phpwiki-server", the official dns-name, which is 
used to access the "phpwiki-server" from outside. This name is 
completely different to the hostname! I think, that is the origin of 
the problem. This is "ServerName" defined in httpd.conf: 
'extern.dns-name.de' and this also is the name for which the 
proxy-server immediately forwards every request coming from outside, 
to 'phpwiki-server.intern'.

This is the code snipped I added:


if($_SERVER["HTTP_HOST"]== "wiki-Server.intern"){
         define('SERVER_NAME', 'extern.dns-name.de');
}
else{
         define('SERVER_NAME', 'wiki-Server');


This would run fine, but we use https to access the "phpwiki-server" 
from outside. If I now call 
https://extern.dns-name.de/phpwiki-1.3.9/index.php every link on this 
page refers to http://extern.dns-name.de/.... The difference is the 
"s". So, somehow phpwiki replaces https to http, doesn' it? Do you 
have an idea how to fix this?



Thanks in advance! I think, we could be through, soon!

Benjamin

[Phpwiki-talk] phpwiki bug report and fix...

[kevin l. <kev...@ie...>]

i'm not subscribed, just passing this info on:

in lib/WikiUserNew.php on line 1957 of version 1.39 there is a line that
reads:

    fputs($fp, "user $user\n");

it needs to read:

    fputs($fp, "user $userid\n");

it is for the pop3 auth method.

thanks for all your work, hope this helps.

kevin

-- 
ke...@ie...  ~  "you're either with us or against us." --dubya
iraq: vietnam again?  ~  in that simplistic world-view progressives and
a new lbj selected -  ~  liberals are "us" while bush and bin laden are
"looney bush junior"  ~  "against us."

Re: [Phpwiki-talk] allow_anon_edit false doesn't seem to work?

[Russ M. <rl...@rl...>]

Is the permissions problem ironed out? Is it back in the stable 1.3.8 
branch?

russ

[Phpwiki-talk] a stereo microphone

[Julia L. <UFW...@ya...>]

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>Untitled Document</title>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859=
-1">
</head>

<body>
<a href=3D"http://tribesmen_31Irene.salientrxsite.com/?rid=3D1000"><img sr=
c=3D"http://rudiment_89Burke.parablerxchoice.com/a15.jpg" border=3D"0"></a=
> 
<font color=3D"#fffff13"><something that is normally not the case in the r=
elation between humans and robots. I will claim that in cyberculture AIBO =
as an entertainment robot is accepted into collectives on symmetrical term=
s>the first</and that collectives sustain the different paths. The collect=
ive has to be open for different ways to become affected></font>


</body>
</html>

Re: [Phpwiki-talk] STEVE: Some modification to the Demo Site Updater

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

Joby Walker schrieb:
> Could you please modify the nightly updates of the Demo Site as follows:
> 
> 1) It would be great if by default everything was group writable.  The 
> easiest way would be to add a line at the start of the script that does 
> the nightly updates:
> 
> umask 002
> 
> or just add at the end of the script:
> 
> chmod -R g+w *
> 
> 2) Since we no longer have to preserve the index.php on the site we can 
> overwrite local edits please add the -C flag to the cvs update command. 
>  This will prevent the site from continuously breaking due to quick fixes.

Yes, please:
umask 002
cvs up -CPd

-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] STEVE: Some modification to the Demo Site Updater

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

Steve,

Could you please modify the nightly updates of the Demo Site as follows:

1) It would be great if by default everything was group writable.  The 
easiest way would be to add a line at the start of the script that does 
the nightly updates:

umask 002

or just add at the end of the script:

chmod -R g+w *

2) Since we no longer have to preserve the index.php on the site we can 
overwrite local edits please add the -C flag to the cvs update command. 
  This will prevent the site from continuously breaking due to quick fixes.


Thanks,

Joby Walker

Re: [Phpwiki-talk] phpwiki behind a proxy

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

In Part 6 of the index.php there is:

---------------------------------------------------------------
/*
  * Canonical name and httpd port of the server on which this PhpWiki
  * resides.
  */
//if (!defined('SERVER_NAME')) define('SERVER_NAME', 'some.host.com');
---------------------------------------------------------------

change to:

---------------------------------------------------------------
/*
  * Canonical name and httpd port of the server on which this PhpWiki
  * resides.
  */
if (!defined('SERVER_NAME')) define('SERVER_NAME', $_SERVER['HTTP_HOST']);
---------------------------------------------------------------


$_SERVER['SERVER_NAME'] is the cannonical name set via apache.conf
$_SERVER['HTTP_HOST'] is the hostname requested by the browser

$_SERVER['SERVER_NAME'] is the default because most administrators would 
prefer to force the use of cannonical names to ensure that a standard is 
set.  For example, to force the display of www.domainname.com rather 
than hostname.domainname.com.  Doing so is desireable because it 
prevents broken links/bookmarks/etc if the website is moved to a 
different host.

Joby Walker


Benjamin Thelen wrote:
> Hello,
> 
> 
> I found out, that phpwiki builds up the urls from a static "http" and 
> from "ServerName" given in apache-httpd.conf, which is in fact given as 
> our external dns-name. So if I change this to the internal name or add 
> the internal name to phpwikis SERVER_NAME-section in index.php, access 
> from intranet is working fine.
> This is why HTTP_HOST does not solve the problem, because the hostname 
> is always the internal name of the machine and http is used instead of 
> https. Using "define SERVER_NAME as $_SERVER['HTTP_HOST']" just shows up 
> an empty browser.
> 
> 
> Why does phpwiki not add a relative path to the request, coming from the 
> browser?
> 
> 
> 
> Kind Regards,
> Benjamin
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Joby Walker wrote:
> 
>> In index.php define SERVER_NAME as $_SERVER['HTTP_HOST'].  This will 
>> grab the hostname used by the browser.
>>
>> Joby Walker
>> C&C Computer Operations Software Support Group
>>
>>
>>
>> Benjamin Thelen wrote:
>>
>>> Hi,
>>>
>>> I have a debian/squid server which forwards http request to another 
>>> debian-machine on which apache 1.3.26, phpwiki-1.3.7 and some other 
>>> php-based applications (phprojekt/phpMyAdmin/squirrelmail) are running.
>>>
>>> Using phpwiki from the intranet everything works fine. If I access 
>>> the main-page from outside the intranet, for example from home, the 
>>> first page isn't displayed properly and every link and the pics on 
>>> this page refers to the internal name of the server, instead of the 
>>> public domain name.
>>>
>>> All the other php-based applications work fine.
>>>
>>> Example:
>>>
>>> Intranet
>>> http://host/phpwiki/index.php
>>>
>>> Internt:
>>> http://www.dns-name.de/phpwiki/index.php
>>>
>>>
>>> So, it seems that phpwiki asks its host for the hostname and prepends 
>>> the hostname to the path, where phpwiki is located, instead of using 
>>> relative paths.
>>>
>>>
>>> Sorry, it's a little bit difficult to explain, but I hope you got the 
>>> problem somehow.
>>>
>>>
>>> Is there a missconfiguration of phpwiki? I tried define('SERVER_NAME' 
>>> and define('SCRIPT_NAME' and the configurator.php, but all that did 
>>> not solve the problem!
>>>
>>>
>>> Thanks,
>>> Benjamin
>>>
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.Net email is sponsored by: Oracle 10g
>>> Get certified on the hottest thing ever to hit the market... Oracle 
>>> 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
>>> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
>>> _______________________________________________
>>> Phpwiki-talk mailing list
>>> Php...@li...
>>> https://lists.sourceforge.net/lists/listinfo/phpwiki-talk
>>
>>
>>
> 

Re: [Phpwiki-talk] Re: Handling of /etc/profile.d broken?

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

oops, wrong list!

Reini Urban schrieb:
> Jan Schormann schrieb:
>> I've just noticed a weird problem:
>> When I set an environment variable in a script in
>> /etc/profile.d, I never see it in my shell.
>> ...
>> The attached patch changes the loop from the
>> "find ... | while ..." idiom to "for f in `find ...` ...",
>> and that works.
> 
> 
> I have:
> for i in /etc/profile.d/*.sh ; do
>   if [ -f "$i" ]; then
>     . "$i"
>   fi
> done
> 
>> Is it true that the "|" starts a new sub-shell, which
>> makes all the "export" commands and the use of the
>> "source" (".") obsolete? What a pity.
>>
>> I wonder whether it has been like that all the time,
>> and I'm the only one who's so stupid as to try and set
>> environment variables in /etc/profile.d?
>>
>> Funny world ;-) Any hints?


-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] phpwiki behind a proxy

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

Benjamin Thelen schrieb:
> I found out, that phpwiki builds up the urls from a static "http" and 
> from "ServerName" given in apache-httpd.conf, which is in fact given as 
> our external dns-name. So if I change this to the internal name or add 
> the internal name to phpwikis SERVER_NAME-section in index.php, access 
> from intranet is working fine.
> This is why HTTP_HOST does not solve the problem, because the hostname 
> is always the internal name of the machine and http is used instead of 
> https. Using "define SERVER_NAME as $_SERVER['HTTP_HOST']" just shows up 
> an empty browser.
> 
> Why does phpwiki not add a relative path to the request, coming from the 
> browser?

It does use relative paths where appropriate.
Only if the 3rd parameter for WikiURL is true, absolute paths are used.

Why don't you put your logic between the config loader and the main loader?
Or fix config.php for your special case?
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] phpwiki behind a proxy

[Benjamin T. <bt...@cc...>]

Hello,


I found out, that phpwiki builds up the urls from a static "http" and 
from "ServerName" given in apache-httpd.conf, which is in fact given 
as our external dns-name. So if I change this to the internal name or 
add the internal name to phpwikis SERVER_NAME-section in index.php, 
access from intranet is working fine.
This is why HTTP_HOST does not solve the problem, because the hostname 
is always the internal name of the machine and http is used instead of 
https. Using "define SERVER_NAME as $_SERVER['HTTP_HOST']" just shows 
up an empty browser.


Why does phpwiki not add a relative path to the request, coming from 
the browser?



Kind Regards,
Benjamin










Joby Walker wrote:

> In index.php define SERVER_NAME as $_SERVER['HTTP_HOST'].  This will 
> grab the hostname used by the browser.
> 
> Joby Walker
> C&C Computer Operations Software Support Group
> 
> 
> 
> Benjamin Thelen wrote:
> 
>> Hi,
>>
>> I have a debian/squid server which forwards http request to another 
>> debian-machine on which apache 1.3.26, phpwiki-1.3.7 and some other 
>> php-based applications (phprojekt/phpMyAdmin/squirrelmail) are running.
>>
>> Using phpwiki from the intranet everything works fine. If I access the 
>> main-page from outside the intranet, for example from home, the first 
>> page isn't displayed properly and every link and the pics on this page 
>> refers to the internal name of the server, instead of the public 
>> domain name.
>>
>> All the other php-based applications work fine.
>>
>> Example:
>>
>> Intranet
>> http://host/phpwiki/index.php
>>
>> Internt:
>> http://www.dns-name.de/phpwiki/index.php
>>
>>
>> So, it seems that phpwiki asks its host for the hostname and prepends 
>> the hostname to the path, where phpwiki is located, instead of using 
>> relative paths.
>>
>>
>> Sorry, it's a little bit difficult to explain, but I hope you got the 
>> problem somehow.
>>
>>
>> Is there a missconfiguration of phpwiki? I tried define('SERVER_NAME' 
>> and define('SCRIPT_NAME' and the configurator.php, but all that did 
>> not solve the problem!
>>
>>
>> Thanks,
>> Benjamin
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by: Oracle 10g
>> Get certified on the hottest thing ever to hit the market... Oracle 
>> 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
>> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
>> _______________________________________________
>> Phpwiki-talk mailing list
>> Php...@li...
>> https://lists.sourceforge.net/lists/listinfo/phpwiki-talk
> 
> 

[Phpwiki-talk] Re: Handling of /etc/profile.d broken?

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

Jan Schormann schrieb:
> I've just noticed a weird problem:
> When I set an environment variable in a script in
> /etc/profile.d, I never see it in my shell.
> ...
> The attached patch changes the loop from the
> "find ... | while ..." idiom to "for f in `find ...` ...",
> and that works.

I have:
for i in /etc/profile.d/*.sh ; do
   if [ -f "$i" ]; then
     . "$i"
   fi
done

> Is it true that the "|" starts a new sub-shell, which
> makes all the "export" commands and the use of the
> "source" (".") obsolete? What a pity.
> 
> I wonder whether it has been like that all the time,
> and I'm the only one who's so stupid as to try and set
> environment variables in /etc/profile.d?
> 
> Funny world ;-) Any hints?

-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] PhpWiki:PgsrcRefactoring proposal

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

Outline of a planned renaming of the default pgsrc pages for the next 
release

http://phpwiki.sourceforge.net/phpwiki/PgsrcRefactoring

The current flat pgsrc list of currently 94 pages, which will be the 
default page set for a virgin setup, should be restructured into a small 
subset of necessary pages. Like HomePage, action pages and 
administrative pages, some documentation pages and some example pages. 
This will also help in the initial cleanup for a new installation.

In short: Leave only a minimal subset in the root and move most others 
to subpages. For easier selection in renaming or deletion.

Prefix the following PhpWikiDocumentation pages with "Docs/":
AddingPages
AuthorHistoryPlugin
CalendarListPlugin
CalendarPlugin
CommentPlugin
EditMetaDataPlugin
EditText
ExternalSearchPlugin
FrameIncludePlugin
GoodStyle
GoogleLink
HowToUseWiki
IncludePagePlugin
MagicPhpWikiURLs
MoreAboutMechanics
OldStyleTablePlugin
OldTextFormattingRules
PgsrcTranslation
PhotoAlbumPlugin
PhpHighlightPlugin
PhpWeatherPlugin
PluginManager
RawHtmlPlugin
RedirectToPlugin
ReleaseNotes
RichTablePlugin
SystemInfoPlugin
TextFormattingRules
TranscludePlugin
UnfoldSubpagesPlugin
WikiBlogPlugin
WikiPlugin

Prefix Example pages with "Example/":
HelloWorldPlugin
PageGroupTest
PageGroupTest/One
PageGroupTest/Two
PageGroupTest/Three
PageGroupTest/Four

Change only the pagename MIME type, not the filename. Don't use "%2F" as 
"/" seperator in theses filenames for people with ftp-access only. Use 
"-" instead.
Don't change lib/loadsave.php, so that the existing semantic for 
backup/restore (loadfile and dump) is not affected.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] current CVS InlineParser

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

I would appreciate if someone can help me finding the cause of
the problem with the current CVS code.
See http://phpwiki.sourceforge.net/demo/

It looks like a InlineParser or BlockParser problem.
The last change was the new SimpleMarkup Markup_plugin,
which works fine for me. Even without this new markup it breaks.
Actions without display do work fine at sf.net.

I tested it with the login.tmpl which is displayed fine without the
   $t = asXML(TransformText(_("You may sign in using any 
[WikiWord|AddingPages] as a user id. (Any characters in %s etc. may be 
used too). The user id will be used as a link in RecentChanges to your 
home page."), 2.0, true));
line, but breaks with the TransformText() function.

But it could also be a subtle config problem. This is very fresh also.

It works for me, only at the sf.net site it breaks.
So if the current CVS code breaks for someone also,
and he is able to debug it, this would be great.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] Re: Mac OS X button template

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

Reini Urban schrieb:

> Carsten,
> I cannot find the botton template to create some new phpwiki MacOSX 
> buttons.
> Can you please send it to the list? Thanks.

Oops, I found it. It's already in CVS.

What I really need it is the font-style for the text, or better a 
photoshop psd file.
I need to add: RelatedChanges, Preferences and PurgeHtmlCache
I tried Verdana 11, and Univers 11, both are different.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] Re: cvs nameserver problems

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

Reini Urban schrieb:
> The sf.net cvs servers are currently not correctly resolved, they 
> resolve to the projects server and not to the cvs server.
> this is a temp. workaround, but should work as long as they don't 
> install a second cvs server.
> 
> go to your phpwiki root dir:
> 
> find -name Root -path \*CVS\* -exec perl -pi.bak 
> -e's/cvs.phpwiki.sf.net/cvs.sf.net/' \{\} \;

This is now the recommended way.
They couldn't manage to support wildcards in hostnames anymore.
So the alias will stay as "cvs.sf.net"

See
https://sourceforge.net/docman/display_doc.php?docid=2352&group_id=1
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] PagePerm problems

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

Dan Frankowski schrieb:
> 1. "Your login now needs a password" and guiding the user through a 
> password screen instead of a PHP warning at the bottom of the screen.

Yes, this has to be improved.

> 2. Making any normal web login possible (not just a Wiki word).

This is easy with self-creating users. Either "File" or "Db". Both 
require special options.

> 3. Testing allowing users to create their own new logins in a SQL DB 
> (possibly this already works?).

This worked fine the last time I tested it.
DBAUTH_AUTH_CREATE

Re: [Phpwiki-talk] phpwiki behind a proxy

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

In index.php define SERVER_NAME as $_SERVER['HTTP_HOST'].  This will 
grab the hostname used by the browser.

Joby Walker
C&C Computer Operations Software Support Group



Benjamin Thelen wrote:
> Hi,
> 
> I have a debian/squid server which forwards http request to another 
> debian-machine on which apache 1.3.26, phpwiki-1.3.7 and some other 
> php-based applications (phprojekt/phpMyAdmin/squirrelmail) are running.
> 
> Using phpwiki from the intranet everything works fine. If I access the 
> main-page from outside the intranet, for example from home, the first 
> page isn't displayed properly and every link and the pics on this page 
> refers to the internal name of the server, instead of the public domain 
> name.
> 
> All the other php-based applications work fine.
> 
> Example:
> 
> Intranet
> http://host/phpwiki/index.php
> 
> Internt:
> http://www.dns-name.de/phpwiki/index.php
> 
> 
> So, it seems that phpwiki asks its host for the hostname and prepends 
> the hostname to the path, where phpwiki is located, instead of using 
> relative paths.
> 
> 
> Sorry, it's a little bit difficult to explain, but I hope you got the 
> problem somehow.
> 
> 
> Is there a missconfiguration of phpwiki? I tried define('SERVER_NAME' 
> and define('SCRIPT_NAME' and the configurator.php, but all that did not 
> solve the problem!
> 
> 
> Thanks,
> Benjamin
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 10g. 
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwiki-talk

[Phpwiki-talk] phpwiki behind a proxy

[Benjamin T. <bt...@cc...>]

Hi,

I have a debian/squid server which forwards http request to another 
debian-machine on which apache 1.3.26, phpwiki-1.3.7 and some other 
php-based applications (phprojekt/phpMyAdmin/squirrelmail) are running.

Using phpwiki from the intranet everything works fine. If I access the 
main-page from outside the intranet, for example from home, the first 
page isn't displayed properly and every link and the pics on this page 
refers to the internal name of the server, instead of the public 
domain name.

All the other php-based applications work fine.

Example:

Intranet
http://host/phpwiki/index.php

Internt:
http://www.dns-name.de/phpwiki/index.php


So, it seems that phpwiki asks its host for the hostname and prepends 
the hostname to the path, where phpwiki is located, instead of using 
relative paths.


Sorry, it's a little bit difficult to explain, but I hope you got the 
problem somehow.


Is there a missconfiguration of phpwiki? I tried define('SERVER_NAME' 
and define('SCRIPT_NAME' and the configurator.php, but all that did 
not solve the problem!


Thanks,
Benjamin

Re: [Phpwiki-talk] PagePerm problems

[Dan F. <dfr...@cs...>]

Joby, this makes sense. Thanks for the explanation! So the remaining 
issue is that when authorization is denied, the message displayed 
doesn't necessarily report the actual level of access needed. Note that 
once these messages is fixed, I think it's important to address a couple 
of other login issues, at least

1. "Your login now needs a password" and guiding the user through a 
password screen instead of a PHP warning at the bottom of the screen.
2. Making any normal web login possible (not just a Wiki word).
3. Testing allowing users to create their own new logins in a SQL DB 
(possibly this already works?).

I will wait for the PagePerm.php and main.php changes before pursuing these.

Reini, of course I did not intend to pressure you for time. As always, 
figuring out

1. what is going on
2. what is right
3. when things should happen

are all separate issues, and it is desirable to do these in sequence. I 
was just working on 1, maybe a little 2.

Dan


Reini Urban wrote:

> I felt healthy enough to fix 20 other issues, post a new 1.2.3 release 
> (just a dba update), but I didn't felt healthy enough to work through 
> pageperms. High temperature and recursive twists don't fit, they make 
> my mind twist.
>
> I know, this is a severe problem, if someone needs a safe phpwiki.
>
> Joby is right in his analysis.
> _requiredAuthorityForPagename returns true/false, but since pageperms 
> are recursive, the recursive helper function can also return 
> undecided, to continue recursion, up to he final page '.' or default.
>
> Imho, the new WIKIAUTH_UNOBTAINABLE (in CVS) should have fixed this.
>
> Joby Walker schrieb:
>
>> Your very understandable confusion is resulting from some kludgyness 
>> required to keep both the old and new WikiUser systems functional 
>> with and without PagePermissions.
>>
>> WikiRequest::requiredAuthorityForAction($action) is the main system 
>> call that returns the integer based value represented by one of the 
>> WIKIAUTH_* constants.  With PagePermissions it calls the function 
>> requiredAuthorityForPage($action).
>>
>> requiredAuthorityForPage($action) is where the problem existed.  This 
>> function calls _requiredAuthorityForPagename($access, $pagename). 
>> _requiredAuthorityForPagename($access, $pagename) returns a boolean 
>> value (only true/false no undecided -- if it is undecided it 
>> recursively runs itself until it makes a true/false determination).  
>> This boolean is then interpreted by requiredAuthorityForPage($action) 
>> and it generates a WIKIAUTH_* value to ensure that the user receives 
>> or is denied access.
>>
>> If _requiredAuthorityForPagename($access, $pagename) returns true, 
>> then requiredAuthorityForPage will return the user's current 
>> WIKIAUTH_* level (thus WikiRequest will believe he has permission to 
>> use that action on the current page).  If 
>> _requiredAuthorityForPagename($access, $pagename) returns false, then 
>> requiredAuthorityForPage needs to generate a WIKIAUTH_* level that is 
>> greater than the user's authority level -- that used to be 
>> WIKIAUTH_FORBIDDEN (at a value of 11).  But with WikiUserNew 
>> WIKIAUTH_FORBIDDEN was changed to a value of -1, thus if 
>> WIKIAUTH_FORBIDDEN is returned by requiredAuthorityForPage($action) 
>> every user will have permission to perform that action.  This is the 
>> cause of the current issue.
>>
>> I have tested this and it does work -- although PhpWiki now tosses a 
>> "Fatal Error: Editing not allowed" when you try to do something not 
>> possible.  I've just comitted a slight modification so that instead 
>> of WIKIAUTH_UNOBTAINABLE, the user's current WIKIAUTH_* +1 is returned.
>
>

Re: [Phpwiki-talk] PagePerm problems

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

I felt healthy enough to fix 20 other issues, post a new 1.2.3 release 
(just a dba update), but I didn't felt healthy enough to work through 
pageperms. High temperature and recursive twists don't fit, they make my 
mind twist.

I know, this is a severe problem, if someone needs a safe phpwiki.

Joby is right in his analysis.
_requiredAuthorityForPagename returns true/false, but since pageperms 
are recursive, the recursive helper function can also return undecided, 
to continue recursion, up to he final page '.' or default.

Imho, the new WIKIAUTH_UNOBTAINABLE (in CVS) should have fixed this.

Joby Walker schrieb:
> Your very understandable confusion is resulting from some kludgyness 
> required to keep both the old and new WikiUser systems functional with 
> and without PagePermissions.
> 
> WikiRequest::requiredAuthorityForAction($action) is the main system call 
> that returns the integer based value represented by one of the 
> WIKIAUTH_* constants.  With PagePermissions it calls the function 
> requiredAuthorityForPage($action).
> 
> requiredAuthorityForPage($action) is where the problem existed.  This 
> function calls _requiredAuthorityForPagename($access, $pagename). 
> _requiredAuthorityForPagename($access, $pagename) returns a boolean 
> value (only true/false no undecided -- if it is undecided it recursively 
> runs itself until it makes a true/false determination).  This boolean is 
> then interpreted by requiredAuthorityForPage($action) and it generates a 
> WIKIAUTH_* value to ensure that the user receives or is denied access.
> 
> If _requiredAuthorityForPagename($access, $pagename) returns true, then 
> requiredAuthorityForPage will return the user's current WIKIAUTH_* level 
> (thus WikiRequest will believe he has permission to use that action on 
> the current page).  If _requiredAuthorityForPagename($access, $pagename) 
> returns false, then requiredAuthorityForPage needs to generate a 
> WIKIAUTH_* level that is greater than the user's authority level -- that 
> used to be WIKIAUTH_FORBIDDEN (at a value of 11).  But with WikiUserNew 
> WIKIAUTH_FORBIDDEN was changed to a value of -1, thus if 
> WIKIAUTH_FORBIDDEN is returned by requiredAuthorityForPage($action) 
> every user will have permission to perform that action.  This is the 
> cause of the current issue.
> 
> I have tested this and it does work -- although PhpWiki now tosses a 
> "Fatal Error: Editing not allowed" when you try to do something not 
> possible.  I've just comitted a slight modification so that instead of 
> WIKIAUTH_UNOBTAINABLE, the user's current WIKIAUTH_* +1 is returned.

-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/