phpwiki-talk

Re: [Phpwiki-talk] Re: [phpwiki-checkins] CVS: phpwiki/lib PagePerm.php,1.8,1.9 WikiUser.php,1.53,1.54 WikiUserNew.php,1.60,1.61 main.php,1.135,1.136

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

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.

You are absolutely right that option (b) is where PhpWiki is currently 
going.

jbw



Joby Walker
C&C Computer Operations Software Support Group



Dan Frankowski wrote:
> Joby,
> 
> I thought about this, but it doesn't seem right. There is a more 
> fundamental problem with the definition and use of 
> PagePerm.php:requiredAuthorityForPagename(). Two possibilities:
> 
> 1) If you look at the code for 
> PagePerm.php:requiredAuthorityForPagename(), it seems focused upon 
> returning true/false/undecided. See also, for example, its usage in 
> PagePerm.php:mayAccessPage(), which is used in PageList, PagePerm, 
> RecentChanges, SOAP, Theme, etc.
> 
> 2) On the other hand, if you look at its usage in 
> main.php:requiredAuthorityForPage(), it looks as if it the client wished 
> it returned the appropriate authorization level necessary 
> (WIKIAUTH_ANON, WIKIAUTH_BOGO, WIKIAUTH_USER, ..). This level is used to 
> generate messages, so true/false/undecided is not enough.
> 
> Thus, there is fundamental confusion over what 
> requiredAuthorityForPage() is. Your fix presumes it is 2-style, but it 
> is not really right now-- only that one else clause looks anything like 
> 2-style.
> 
> Moreover, even if it were 2-style, that would be a mistake. The level 
> returned to main.php:requiredAuthorityForPage() is used to generate 
> error messages (e.g., "you must be logged in to edit this page"). 
> However, there are no error messages even defined for some of the new 
> ACL-style levels (e.g., ACL_CREATOR, ACL_OWNER, ACL_HASHOMEPAGE). Thus, 
> it is not even right to translate the ACL-style things to the old 
> level-style things.
> 
> The following choices remain:
> 
> a. Make PagePerm.php:requiredAuthorityForPagename() a 2-style thing for 
> real, and moreover somehow translate to old levels for purposes of error 
> messages in main.php.
> 
> b. Make main.php call into new PagePerm.php functions to check things 
> and get error messages. I think this is where Reini is headed, but it 
> needs more work.
> 
> c. Hidden option c.
> 
> Dan
> 
> Joby Walker wrote:
> 
>> This should resolve the ALLOW_ANON_EDIT = false problems.
>>
>> The issue was that requiredAuthorityForPage() was returning 
>> WIKIAUTH_FORBIDDEN on failure.  This used to be the correct value for 
>> failure (in the old WikiUser it equaled 11).  But in WikiUserNew, 
>> WIKIAUTH_FORBIDDEN has a value of -1 and signifies a user with no 
>> permissions.  Thus whenever requiredAuthorityForPage() wanted to 
>> return a value signalling that the user was not authorized it was 
>> returning a value that allowed anyone to perform that action.
>>
>> Joby Walker
>>
>>
>>
>>
>> Joseph (Joby) Walker wrote:
>>
>>> Update of /cvsroot/phpwiki/phpwiki/lib
>>> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv6194/lib
>>>
>>> Modified Files:
>>>     PagePerm.php WikiUser.php WikiUserNew.php main.php Log Message:
>>> Fixes permission failure issues.  With PagePermissions and Disabled 
>>> Actions when user did not have permission WIKIAUTH_FORBIDDEN was 
>>> returned.  In WikiUser this was ok because WIKIAUTH_FORBIDDEN had a 
>>> value of 11 -- thus no user could perform that action.  But 
>>> WikiUserNew has a WIKIAUTH_FORBIDDEN value of -1 -- thus a user 
>>> without sufficent permission to do anything.  The solution is a new 
>>> high value permission level (WIKIAUTH_UNOBTAINABLE) to be the default 
>>> level for access failure.
>>>
>>> Index: PagePerm.php
>>> ===================================================================
>>> RCS file: /cvsroot/phpwiki/phpwiki/lib/PagePerm.php,v
>>> retrieving revision 1.8
>>> retrieving revision 1.9
>>> diff -u -2 -b -p -d -r1.8 -r1.9
>>> --- PagePerm.php    14 Mar 2004 16:24:35 -0000    1.8
>>> +++ PagePerm.php    29 Apr 2004 17:18:19 -0000    1.9
>>> @@ -156,5 +156,5 @@ function requiredAuthorityForPage ($acti
>>>          return $GLOBALS['request']->_user->_level;
>>>      else
>>> -        return WIKIAUTH_FORBIDDEN;
>>> +        return WIKIAUTH_UNOBTAINABLE;
>>>  }
>>>  
>>> @@ -544,4 +544,7 @@ class PagePermission {
>>>  
>>>  // $Log$
>>> +// Revision 1.9  2004/04/29 17:18:19  zorloc
>>> +// Fixes permission failure issues.  With PagePermissions and 
>>> Disabled Actions when user did not have permission WIKIAUTH_FORBIDDEN 
>>> was returned.  In WikiUser this was ok because WIKIAUTH_FORBIDDEN had 
>>> a value of 11 -- thus no user could perform that action.  But 
>>> WikiUserNew has a WIKIAUTH_FORBIDDEN value of -1 -- thus a user 
>>> without sufficent permission to do anything.  The solution is a new 
>>> high value permission level (WIKIAUTH_UNOBTAINABLE) to be the default 
>>> level for access failure.
>>> +//
>>>  // Revision 1.8  2004/03/14 16:24:35  rurban
>>>  // authenti(fi)cation spelling
>>>
>>> Index: WikiUser.php
>>> ===================================================================
>>> RCS file: /cvsroot/phpwiki/phpwiki/lib/WikiUser.php,v
>>> retrieving revision 1.53
>>> retrieving revision 1.54
>>> diff -u -2 -b -p -d -r1.53 -r1.54
>>> --- WikiUser.php    10 Apr 2004 05:34:35 -0000    1.53
>>> +++ WikiUser.php    29 Apr 2004 17:18:19 -0000    1.54
>>> @@ -16,10 +16,11 @@ rcs_id('$Id$');
>>>  //       If no homepage, fallback to prefs in cookie as in 1.3.3.
>>>  
>>> +define('WIKIAUTH_FORBIDDEN', -1); // Completely not allowed.
>>>  define('WIKIAUTH_ANON', 0);
>>>  define('WIKIAUTH_BOGO', 1);     // any valid WikiWord is enough
>>>  define('WIKIAUTH_USER', 2);     // real auth from a 
>>> database/file/server.
>>>  
>>> -define('WIKIAUTH_ADMIN', 10);
>>> -define('WIKIAUTH_FORBIDDEN', 11); // Completely not allowed.
>>> +define('WIKIAUTH_ADMIN', 10);  // Wiki Admin
>>> +define('WIKIAUTH_UNOBTAINABLE', 100);  // Permissions that no user 
>>> can achieve
>>>  
>>>  $UserPreferences = array(
>>> @@ -722,4 +723,7 @@ class UserPreferences {
>>>  
>>>  // $Log$
>>> +// Revision 1.54  2004/04/29 17:18:19  zorloc
>>> +// Fixes permission failure issues.  With PagePermissions and 
>>> Disabled Actions when user did not have permission WIKIAUTH_FORBIDDEN 
>>> was returned.  In WikiUser this was ok because WIKIAUTH_FORBIDDEN had 
>>> a value of 11 -- thus no user could perform that action.  But 
>>> WikiUserNew has a WIKIAUTH_FORBIDDEN value of -1 -- thus a user 
>>> without sufficent permission to do anything.  The solution is a new 
>>> high value permission level (WIKIAUTH_UNOBTAINABLE) to be the default 
>>> level for access failure.
>>> +//
>>>  // Revision 1.53  2004/04/10 05:34:35  rurban
>>>  // sf bug#830912
>>>
>>> Index: WikiUserNew.php
>>> ===================================================================
>>> RCS file: /cvsroot/phpwiki/phpwiki/lib/WikiUserNew.php,v
>>> retrieving revision 1.60
>>> retrieving revision 1.61
>>> diff -u -2 -b -p -d -r1.60 -r1.61
>>> --- WikiUserNew.php    27 Apr 2004 18:20:54 -0000    1.60
>>> +++ WikiUserNew.php    29 Apr 2004 17:18:19 -0000    1.61
>>> @@ -97,4 +97,5 @@ define('WIKIAUTH_BOGO', 1);       // Any
>>>  define('WIKIAUTH_USER', 2);       // Bogo user with a password.
>>>  define('WIKIAUTH_ADMIN', 10);     // UserName == ADMIN_USER.
>>> +define('WIKIAUTH_UNOBTAINABLE', 100);  // Permissions that no user 
>>> can achieve
>>>  
>>>  if (!defined('COOKIE_EXPIRATION_DAYS')) 
>>> define('COOKIE_EXPIRATION_DAYS', 365);
>>> @@ -2803,4 +2804,7 @@ extends UserPreferences
>>>  
>>>  // $Log$
>>> +// Revision 1.61  2004/04/29 17:18:19  zorloc
>>> +// Fixes permission failure issues.  With PagePermissions and 
>>> Disabled Actions when user did not have permission WIKIAUTH_FORBIDDEN 
>>> was returned.  In WikiUser this was ok because WIKIAUTH_FORBIDDEN had 
>>> a value of 11 -- thus no user could perform that action.  But 
>>> WikiUserNew has a WIKIAUTH_FORBIDDEN value of -1 -- thus a user 
>>> without sufficent permission to do anything.  The solution is a new 
>>> high value permission level (WIKIAUTH_UNOBTAINABLE) to be the default 
>>> level for access failure.
>>> +//
>>>  // Revision 1.60  2004/04/27 18:20:54  rurban
>>>  // sf.net patch #940359 by rassie
>>>
>>> Index: main.php
>>> ===================================================================
>>> RCS file: /cvsroot/phpwiki/phpwiki/lib/main.php,v
>>> retrieving revision 1.135
>>> retrieving revision 1.136
>>> diff -u -2 -b -p -d -r1.135 -r1.136
>>> --- main.php    26 Apr 2004 12:15:01 -0000    1.135
>>> +++ main.php    29 Apr 2004 17:18:19 -0000    1.136
>>> @@ -289,5 +289,5 @@ class WikiRequest extends Request {
>>>          $what = $this->getActionDescription($this->getArg('action'));
>>>  
>>> -        if ($require_level == WIKIAUTH_FORBIDDEN) {
>>> +        if ($require_level == WIKIAUTH_UNOBTAINABLE) {
>>>              $this->finish(fmt("%s is disallowed on this wiki.",
>>>                                
>>> $this->getDisallowedActionDescription($this->getArg('action'))));
>>> @@ -886,4 +886,7 @@ main();
>>>  
>>>  // $Log$
>>> +// Revision 1.136  2004/04/29 17:18:19  zorloc
>>> +// Fixes permission failure issues.  With PagePermissions and 
>>> Disabled Actions when user did not have permission WIKIAUTH_FORBIDDEN 
>>> was returned.  In WikiUser this was ok because WIKIAUTH_FORBIDDEN had 
>>> a value of 11 -- thus no user could perform that action.  But 
>>> WikiUserNew has a WIKIAUTH_FORBIDDEN value of -1 -- thus a user 
>>> without sufficent permission to do anything.  The solution is a new 
>>> high value permission level (WIKIAUTH_UNOBTAINABLE) to be the default 
>>> level for access failure.
>>> +//
>>>  // Revision 1.135  2004/04/26 12:15:01  rurban
>>>  // check default config values
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> 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-checkins mailing list
>>> php...@li...
>>> https://lists.sourceforge.net/lists/listinfo/phpwiki-checkins
>>
>>
>>
>>
>> -------------------------------------------------------
>> 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: [phpwiki-checkins] CVS: phpwiki/lib PagePerm.php,1.8,1.9 WikiUser.php,1.53,1.54 WikiUserNew.php,1.60,1.61 main.php,1.135,1.136

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

Dan Frankowski wrote:

> Joby,
>
> I thought about this, but it doesn't seem right. There is a more 
> fundamental problem with the definition and use of 
> PagePerm.php:requiredAuthorityForPagename(). Two possibilities:



> The following choices remain:
>
> a. Make PagePerm.php:requiredAuthorityForPagename() a 2-style thing 
> for real, and moreover somehow translate to old levels for purposes of 
> error messages in main.php.
>
> b. Make main.php call into new PagePerm.php functions to check things 
> and get error messages. I think this is where Reini is headed, but it 
> needs more work.
>
> c. Hidden option c.


I should point out one other option:

d. Disable page permissions for now, since they're not ready.

diff -b -u -r1.3 main.php
--- main.php    14 Apr 2004 21:57:25 -0000      1.3
+++ main.php    29 Apr 2004 22:13:29 -0000
@@ -383,7 +383,7 @@
     }

     function requiredAuthorityForAction ($action) {
-       if (class_exists("PagePermission")) {
+       if (0 && class_exists("PagePermission")) {
            return requiredAuthorityForPage($action);
        } else {
           // FIXME: clean up.

I'm not sure if that would respect all the new flags in index.php.

I'm still somewhat looking into how one would fix page permissions.

Dan

>
> Dan
>
> Joby Walker wrote:
>
>> This should resolve the ALLOW_ANON_EDIT = false problems.
>>
>> The issue was that requiredAuthorityForPage() was returning 
>> WIKIAUTH_FORBIDDEN on failure.  This used to be the correct value for 
>> failure (in the old WikiUser it equaled 11).  But in WikiUserNew, 
>> WIKIAUTH_FORBIDDEN has a value of -1 and signifies a user with no 
>> permissions.  Thus whenever requiredAuthorityForPage() wanted to 
>> return a value signalling that the user was not authorized it was 
>> returning a value that allowed anyone to perform that action.
>>
>> Joby Walker
>

Re: [Phpwiki-talk] Re: [phpwiki-checkins] CVS: phpwiki/lib PagePerm.php,1.8,1.9 WikiUser.php,1.53,1.54 WikiUserNew.php,1.60,1.61 main.php,1.135,1.136

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

Joby,

I thought about this, but it doesn't seem right. There is a more 
fundamental problem with the definition and use of 
PagePerm.php:requiredAuthorityForPagename(). Two possibilities:

1) If you look at the code for 
PagePerm.php:requiredAuthorityForPagename(), it seems focused upon 
returning true/false/undecided. See also, for example, its usage in 
PagePerm.php:mayAccessPage(), which is used in PageList, PagePerm, 
RecentChanges, SOAP, Theme, etc.

2) On the other hand, if you look at its usage in 
main.php:requiredAuthorityForPage(), it looks as if it the client wished 
it returned the appropriate authorization level necessary 
(WIKIAUTH_ANON, WIKIAUTH_BOGO, WIKIAUTH_USER, ..). This level is used to 
generate messages, so true/false/undecided is not enough.

Thus, there is fundamental confusion over what 
requiredAuthorityForPage() is. Your fix presumes it is 2-style, but it 
is not really right now-- only that one else clause looks anything like 
2-style.

Moreover, even if it were 2-style, that would be a mistake. The level 
returned to main.php:requiredAuthorityForPage() is used to generate 
error messages (e.g., "you must be logged in to edit this page"). 
However, there are no error messages even defined for some of the new 
ACL-style levels (e.g., ACL_CREATOR, ACL_OWNER, ACL_HASHOMEPAGE). Thus, 
it is not even right to translate the ACL-style things to the old 
level-style things.

The following choices remain:

a. Make PagePerm.php:requiredAuthorityForPagename() a 2-style thing for 
real, and moreover somehow translate to old levels for purposes of error 
messages in main.php.

b. Make main.php call into new PagePerm.php functions to check things 
and get error messages. I think this is where Reini is headed, but it 
needs more work.

c. Hidden option c.

Dan

Joby Walker wrote:

> This should resolve the ALLOW_ANON_EDIT = false problems.
>
> The issue was that requiredAuthorityForPage() was returning 
> WIKIAUTH_FORBIDDEN on failure.  This used to be the correct value for 
> failure (in the old WikiUser it equaled 11).  But in WikiUserNew, 
> WIKIAUTH_FORBIDDEN has a value of -1 and signifies a user with no 
> permissions.  Thus whenever requiredAuthorityForPage() wanted to 
> return a value signalling that the user was not authorized it was 
> returning a value that allowed anyone to perform that action.
>
> Joby Walker
>
>
>
>
> Joseph (Joby) Walker wrote:
>
>> Update of /cvsroot/phpwiki/phpwiki/lib
>> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv6194/lib
>>
>> Modified Files:
>>     PagePerm.php WikiUser.php WikiUserNew.php main.php Log Message:
>> Fixes permission failure issues.  With PagePermissions and Disabled 
>> Actions when user did not have permission WIKIAUTH_FORBIDDEN was 
>> returned.  In WikiUser this was ok because WIKIAUTH_FORBIDDEN had a 
>> value of 11 -- thus no user could perform that action.  But 
>> WikiUserNew has a WIKIAUTH_FORBIDDEN value of -1 -- thus a user 
>> without sufficent permission to do anything.  The solution is a new 
>> high value permission level (WIKIAUTH_UNOBTAINABLE) to be the default 
>> level for access failure.
>>
>> Index: PagePerm.php
>> ===================================================================
>> RCS file: /cvsroot/phpwiki/phpwiki/lib/PagePerm.php,v
>> retrieving revision 1.8
>> retrieving revision 1.9
>> diff -u -2 -b -p -d -r1.8 -r1.9
>> --- PagePerm.php    14 Mar 2004 16:24:35 -0000    1.8
>> +++ PagePerm.php    29 Apr 2004 17:18:19 -0000    1.9
>> @@ -156,5 +156,5 @@ function requiredAuthorityForPage ($acti
>>          return $GLOBALS['request']->_user->_level;
>>      else
>> -        return WIKIAUTH_FORBIDDEN;
>> +        return WIKIAUTH_UNOBTAINABLE;
>>  }
>>  
>> @@ -544,4 +544,7 @@ class PagePermission {
>>  
>>  // $Log$
>> +// Revision 1.9  2004/04/29 17:18:19  zorloc
>> +// Fixes permission failure issues.  With PagePermissions and 
>> Disabled Actions when user did not have permission WIKIAUTH_FORBIDDEN 
>> was returned.  In WikiUser this was ok because WIKIAUTH_FORBIDDEN had 
>> a value of 11 -- thus no user could perform that action.  But 
>> WikiUserNew has a WIKIAUTH_FORBIDDEN value of -1 -- thus a user 
>> without sufficent permission to do anything.  The solution is a new 
>> high value permission level (WIKIAUTH_UNOBTAINABLE) to be the default 
>> level for access failure.
>> +//
>>  // Revision 1.8  2004/03/14 16:24:35  rurban
>>  // authenti(fi)cation spelling
>>
>> Index: WikiUser.php
>> ===================================================================
>> RCS file: /cvsroot/phpwiki/phpwiki/lib/WikiUser.php,v
>> retrieving revision 1.53
>> retrieving revision 1.54
>> diff -u -2 -b -p -d -r1.53 -r1.54
>> --- WikiUser.php    10 Apr 2004 05:34:35 -0000    1.53
>> +++ WikiUser.php    29 Apr 2004 17:18:19 -0000    1.54
>> @@ -16,10 +16,11 @@ rcs_id('$Id$');
>>  //       If no homepage, fallback to prefs in cookie as in 1.3.3.
>>  
>> +define('WIKIAUTH_FORBIDDEN', -1); // Completely not allowed.
>>  define('WIKIAUTH_ANON', 0);
>>  define('WIKIAUTH_BOGO', 1);     // any valid WikiWord is enough
>>  define('WIKIAUTH_USER', 2);     // real auth from a 
>> database/file/server.
>>  
>> -define('WIKIAUTH_ADMIN', 10);
>> -define('WIKIAUTH_FORBIDDEN', 11); // Completely not allowed.
>> +define('WIKIAUTH_ADMIN', 10);  // Wiki Admin
>> +define('WIKIAUTH_UNOBTAINABLE', 100);  // Permissions that no user 
>> can achieve
>>  
>>  $UserPreferences = array(
>> @@ -722,4 +723,7 @@ class UserPreferences {
>>  
>>  // $Log$
>> +// Revision 1.54  2004/04/29 17:18:19  zorloc
>> +// Fixes permission failure issues.  With PagePermissions and 
>> Disabled Actions when user did not have permission WIKIAUTH_FORBIDDEN 
>> was returned.  In WikiUser this was ok because WIKIAUTH_FORBIDDEN had 
>> a value of 11 -- thus no user could perform that action.  But 
>> WikiUserNew has a WIKIAUTH_FORBIDDEN value of -1 -- thus a user 
>> without sufficent permission to do anything.  The solution is a new 
>> high value permission level (WIKIAUTH_UNOBTAINABLE) to be the default 
>> level for access failure.
>> +//
>>  // Revision 1.53  2004/04/10 05:34:35  rurban
>>  // sf bug#830912
>>
>> Index: WikiUserNew.php
>> ===================================================================
>> RCS file: /cvsroot/phpwiki/phpwiki/lib/WikiUserNew.php,v
>> retrieving revision 1.60
>> retrieving revision 1.61
>> diff -u -2 -b -p -d -r1.60 -r1.61
>> --- WikiUserNew.php    27 Apr 2004 18:20:54 -0000    1.60
>> +++ WikiUserNew.php    29 Apr 2004 17:18:19 -0000    1.61
>> @@ -97,4 +97,5 @@ define('WIKIAUTH_BOGO', 1);       // Any
>>  define('WIKIAUTH_USER', 2);       // Bogo user with a password.
>>  define('WIKIAUTH_ADMIN', 10);     // UserName == ADMIN_USER.
>> +define('WIKIAUTH_UNOBTAINABLE', 100);  // Permissions that no user 
>> can achieve
>>  
>>  if (!defined('COOKIE_EXPIRATION_DAYS')) 
>> define('COOKIE_EXPIRATION_DAYS', 365);
>> @@ -2803,4 +2804,7 @@ extends UserPreferences
>>  
>>  // $Log$
>> +// Revision 1.61  2004/04/29 17:18:19  zorloc
>> +// Fixes permission failure issues.  With PagePermissions and 
>> Disabled Actions when user did not have permission WIKIAUTH_FORBIDDEN 
>> was returned.  In WikiUser this was ok because WIKIAUTH_FORBIDDEN had 
>> a value of 11 -- thus no user could perform that action.  But 
>> WikiUserNew has a WIKIAUTH_FORBIDDEN value of -1 -- thus a user 
>> without sufficent permission to do anything.  The solution is a new 
>> high value permission level (WIKIAUTH_UNOBTAINABLE) to be the default 
>> level for access failure.
>> +//
>>  // Revision 1.60  2004/04/27 18:20:54  rurban
>>  // sf.net patch #940359 by rassie
>>
>> Index: main.php
>> ===================================================================
>> RCS file: /cvsroot/phpwiki/phpwiki/lib/main.php,v
>> retrieving revision 1.135
>> retrieving revision 1.136
>> diff -u -2 -b -p -d -r1.135 -r1.136
>> --- main.php    26 Apr 2004 12:15:01 -0000    1.135
>> +++ main.php    29 Apr 2004 17:18:19 -0000    1.136
>> @@ -289,5 +289,5 @@ class WikiRequest extends Request {
>>          $what = $this->getActionDescription($this->getArg('action'));
>>  
>> -        if ($require_level == WIKIAUTH_FORBIDDEN) {
>> +        if ($require_level == WIKIAUTH_UNOBTAINABLE) {
>>              $this->finish(fmt("%s is disallowed on this wiki.",
>>                                
>> $this->getDisallowedActionDescription($this->getArg('action'))));
>> @@ -886,4 +886,7 @@ main();
>>  
>>  // $Log$
>> +// Revision 1.136  2004/04/29 17:18:19  zorloc
>> +// Fixes permission failure issues.  With PagePermissions and 
>> Disabled Actions when user did not have permission WIKIAUTH_FORBIDDEN 
>> was returned.  In WikiUser this was ok because WIKIAUTH_FORBIDDEN had 
>> a value of 11 -- thus no user could perform that action.  But 
>> WikiUserNew has a WIKIAUTH_FORBIDDEN value of -1 -- thus a user 
>> without sufficent permission to do anything.  The solution is a new 
>> high value permission level (WIKIAUTH_UNOBTAINABLE) to be the default 
>> level for access failure.
>> +//
>>  // Revision 1.135  2004/04/26 12:15:01  rurban
>>  // check default config values
>>
>>
>>
>> -------------------------------------------------------
>> 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-checkins mailing list
>> php...@li...
>> https://lists.sourceforge.net/lists/listinfo/phpwiki-checkins
>
>
>
> -------------------------------------------------------
> 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] cvs nameserver problems

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

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/' \{\} \;
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] Re: [phpwiki-checkins] CVS: phpwiki/lib PagePerm.php,1.8,1.9 WikiUser.php,1.53,1.54 WikiUserNew.php,1.60,1.61 main.php,1.135,1.136

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

This should resolve the ALLOW_ANON_EDIT = false problems.

The issue was that requiredAuthorityForPage() was returning 
WIKIAUTH_FORBIDDEN on failure.  This used to be the correct value for 
failure (in the old WikiUser it equaled 11).  But in WikiUserNew, 
WIKIAUTH_FORBIDDEN has a value of -1 and signifies a user with no 
permissions.  Thus whenever requiredAuthorityForPage() wanted to return 
a value signalling that the user was not authorized it was returning a 
value that allowed anyone to perform that action.

Joby Walker




Joseph (Joby) Walker wrote:
> Update of /cvsroot/phpwiki/phpwiki/lib
> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv6194/lib
> 
> Modified Files:
> 	PagePerm.php WikiUser.php WikiUserNew.php main.php 
> Log Message:
> Fixes permission failure issues.  With PagePermissions and Disabled Actions when user did not have permission WIKIAUTH_FORBIDDEN was returned.  In WikiUser this was ok because WIKIAUTH_FORBIDDEN had a value of 11 -- thus no user could perform that action.  But WikiUserNew has a WIKIAUTH_FORBIDDEN value of -1 -- thus a user without sufficent permission to do anything.  The solution is a new high value permission level (WIKIAUTH_UNOBTAINABLE) to be the default level for access failure.
> 
> Index: PagePerm.php
> ===================================================================
> RCS file: /cvsroot/phpwiki/phpwiki/lib/PagePerm.php,v
> retrieving revision 1.8
> retrieving revision 1.9
> diff -u -2 -b -p -d -r1.8 -r1.9
> --- PagePerm.php	14 Mar 2004 16:24:35 -0000	1.8
> +++ PagePerm.php	29 Apr 2004 17:18:19 -0000	1.9
> @@ -156,5 +156,5 @@ function requiredAuthorityForPage ($acti
>          return $GLOBALS['request']->_user->_level;
>      else
> -        return WIKIAUTH_FORBIDDEN;
> +        return WIKIAUTH_UNOBTAINABLE;
>  }
>  
> @@ -544,4 +544,7 @@ class PagePermission {
>  
>  // $Log$
> +// Revision 1.9  2004/04/29 17:18:19  zorloc
> +// Fixes permission failure issues.  With PagePermissions and Disabled Actions when user did not have permission WIKIAUTH_FORBIDDEN was returned.  In WikiUser this was ok because WIKIAUTH_FORBIDDEN had a value of 11 -- thus no user could perform that action.  But WikiUserNew has a WIKIAUTH_FORBIDDEN value of -1 -- thus a user without sufficent permission to do anything.  The solution is a new high value permission level (WIKIAUTH_UNOBTAINABLE) to be the default level for access failure.
> +//
>  // Revision 1.8  2004/03/14 16:24:35  rurban
>  // authenti(fi)cation spelling
> 
> Index: WikiUser.php
> ===================================================================
> RCS file: /cvsroot/phpwiki/phpwiki/lib/WikiUser.php,v
> retrieving revision 1.53
> retrieving revision 1.54
> diff -u -2 -b -p -d -r1.53 -r1.54
> --- WikiUser.php	10 Apr 2004 05:34:35 -0000	1.53
> +++ WikiUser.php	29 Apr 2004 17:18:19 -0000	1.54
> @@ -16,10 +16,11 @@ rcs_id('$Id$');
>  //       If no homepage, fallback to prefs in cookie as in 1.3.3.
>  
> +define('WIKIAUTH_FORBIDDEN', -1); // Completely not allowed.
>  define('WIKIAUTH_ANON', 0);
>  define('WIKIAUTH_BOGO', 1);     // any valid WikiWord is enough
>  define('WIKIAUTH_USER', 2);     // real auth from a database/file/server.
>  
> -define('WIKIAUTH_ADMIN', 10);
> -define('WIKIAUTH_FORBIDDEN', 11); // Completely not allowed.
> +define('WIKIAUTH_ADMIN', 10);  // Wiki Admin
> +define('WIKIAUTH_UNOBTAINABLE', 100);  // Permissions that no user can achieve
>  
>  $UserPreferences = array(
> @@ -722,4 +723,7 @@ class UserPreferences {
>  
>  // $Log$
> +// Revision 1.54  2004/04/29 17:18:19  zorloc
> +// Fixes permission failure issues.  With PagePermissions and Disabled Actions when user did not have permission WIKIAUTH_FORBIDDEN was returned.  In WikiUser this was ok because WIKIAUTH_FORBIDDEN had a value of 11 -- thus no user could perform that action.  But WikiUserNew has a WIKIAUTH_FORBIDDEN value of -1 -- thus a user without sufficent permission to do anything.  The solution is a new high value permission level (WIKIAUTH_UNOBTAINABLE) to be the default level for access failure.
> +//
>  // Revision 1.53  2004/04/10 05:34:35  rurban
>  // sf bug#830912
> 
> Index: WikiUserNew.php
> ===================================================================
> RCS file: /cvsroot/phpwiki/phpwiki/lib/WikiUserNew.php,v
> retrieving revision 1.60
> retrieving revision 1.61
> diff -u -2 -b -p -d -r1.60 -r1.61
> --- WikiUserNew.php	27 Apr 2004 18:20:54 -0000	1.60
> +++ WikiUserNew.php	29 Apr 2004 17:18:19 -0000	1.61
> @@ -97,4 +97,5 @@ define('WIKIAUTH_BOGO', 1);       // Any
>  define('WIKIAUTH_USER', 2);       // Bogo user with a password.
>  define('WIKIAUTH_ADMIN', 10);     // UserName == ADMIN_USER.
> +define('WIKIAUTH_UNOBTAINABLE', 100);  // Permissions that no user can achieve
>  
>  if (!defined('COOKIE_EXPIRATION_DAYS')) define('COOKIE_EXPIRATION_DAYS', 365);
> @@ -2803,4 +2804,7 @@ extends UserPreferences
>  
>  // $Log$
> +// Revision 1.61  2004/04/29 17:18:19  zorloc
> +// Fixes permission failure issues.  With PagePermissions and Disabled Actions when user did not have permission WIKIAUTH_FORBIDDEN was returned.  In WikiUser this was ok because WIKIAUTH_FORBIDDEN had a value of 11 -- thus no user could perform that action.  But WikiUserNew has a WIKIAUTH_FORBIDDEN value of -1 -- thus a user without sufficent permission to do anything.  The solution is a new high value permission level (WIKIAUTH_UNOBTAINABLE) to be the default level for access failure.
> +//
>  // Revision 1.60  2004/04/27 18:20:54  rurban
>  // sf.net patch #940359 by rassie
> 
> Index: main.php
> ===================================================================
> RCS file: /cvsroot/phpwiki/phpwiki/lib/main.php,v
> retrieving revision 1.135
> retrieving revision 1.136
> diff -u -2 -b -p -d -r1.135 -r1.136
> --- main.php	26 Apr 2004 12:15:01 -0000	1.135
> +++ main.php	29 Apr 2004 17:18:19 -0000	1.136
> @@ -289,5 +289,5 @@ class WikiRequest extends Request {
>          $what = $this->getActionDescription($this->getArg('action'));
>  
> -        if ($require_level == WIKIAUTH_FORBIDDEN) {
> +        if ($require_level == WIKIAUTH_UNOBTAINABLE) {
>              $this->finish(fmt("%s is disallowed on this wiki.",
>                                $this->getDisallowedActionDescription($this->getArg('action'))));
> @@ -886,4 +886,7 @@ main();
>  
>  // $Log$
> +// Revision 1.136  2004/04/29 17:18:19  zorloc
> +// Fixes permission failure issues.  With PagePermissions and Disabled Actions when user did not have permission WIKIAUTH_FORBIDDEN was returned.  In WikiUser this was ok because WIKIAUTH_FORBIDDEN had a value of 11 -- thus no user could perform that action.  But WikiUserNew has a WIKIAUTH_FORBIDDEN value of -1 -- thus a user without sufficent permission to do anything.  The solution is a new high value permission level (WIKIAUTH_UNOBTAINABLE) to be the default level for access failure.
> +//
>  // Revision 1.135  2004/04/26 12:15:01  rurban
>  // check default config values
> 
> 
> 
> -------------------------------------------------------
> 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-checkins mailing list
> php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwiki-checkins

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

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

Reini Urban wrote:

>> Reini?
>
>
> Yes, it's a bug, but I'm in a middle of a influenza and other 
> problems, and will need some more days to be able to analyse and fix 
> that correctly. Let's say 2-3 days.


Thanks for the info. I hope you are well soon. Take all the time you 
need, of course.

I am looking into it to understand, but most likely I will not 
understand well enough to fix it .. I'll do what I can.

Dan

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

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

Dan Frankowski schrieb:
> Okay, maybe I can rephrase this question a little.
> - HomePage is getting checked for page permissions
> - requiredAuthorityForPage is returning WIKIAUTH_FORBIDDEN (seems good)
> - The non-logged-in user is a _ForbiddenUser, who has level 
> WIKIAUTH_FORBIDDEN
> - hasAuthority says "return $this->_level >= $require_level;" .. in 
> other words, "yep, that's authorized"
> 
> Help? Which of these is not right? Possibilities:
> 
> 1. a _ForbiddenUser should have level < WIKIAUTH_FORBIDDEN
> 2. hasAuthority should be testing >, not >=.
> 3. This is expected behavior.
> 4. Hidden option 4. (There's always hidden option 4.)
> 
> Reini?

Yes, it's a bug, but I'm in a middle of a influenza and other problems, 
and will need some more days to be able to analyse and fix that 
correctly. Let's say 2-3 days.

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

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

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

Dan, I'll take a look but the problem seems to be in the formation of 
the default permissions (defaultPerms()).  Since you have 
ALLOW_ANON_EDIT and ALLOW_BOGO_LOGIN set to false then the default 
authority level required (returned by requiredAuthorityForPage) should 
be WIKIAUTH_USER.  If requiredAuthorityForPage returns 
WIKIAUTH_FORBIDDEN, then everyone will be able to perform that action 
since that functions return value is the miminum value necessary to 
perform that action and WIKIAUTH_FORBIDDEN is the minimum value.

jbw

Dan Frankowski wrote:
> Okay, maybe I can rephrase this question a little.
> 
> - HomePage is getting checked for page permissions
> - requiredAuthorityForPage is returning WIKIAUTH_FORBIDDEN (seems good)
> - The non-logged-in user is a _ForbiddenUser, who has level 
> WIKIAUTH_FORBIDDEN
> - hasAuthority says "return $this->_level >= $require_level;" .. in 
> other words, "yep, that's authorized"
> 
> Help? Which of these is not right? Possibilities:
> 
> 1. a _ForbiddenUser should have level < WIKIAUTH_FORBIDDEN
> 2. hasAuthority should be testing >, not >=.
> 3. This is expected behavior.
> 4. Hidden option 4. (There's always hidden option 4.)
> 
> Reini?
> 
> Dan
> 
> 
> Dan Frankowski wrote:
> 
>> Frederik De Bleser wrote:
>>
>>> Hi,
>>>
>>> I'm using phpwiki 1.3.9. My current user authentication configuration 
>>> is:
>>>
>>> ENABLE_USER_NEW        true
>>>
>>> ALLOW_ANON_USER         true
>>> ALLOW_ANON_EDIT         false
>>> ALLOW_BOGO_LOGIN        false
>>> ALLOW_USER_PASSWORDS    true
>>>
>>> USER_AUTH_ORDER        db
>>> USER_AUTH_POLICY    first-only
>>>
>>> Somehow, I can edit pages without being logged in -- just by adding 
>>> ?action=create or ?action=edit , I can create and edit pages. 
>>> Shouldn't phpwiki give an error?
>>
>>
>>
>>
>> I also can edit my HomePage without logging in, although I have 
>> ALLOW_ANON_EDIT false. I can just click the 'edit' button, I don't 
>> have to add anything to a URL. On my test site, I have the same 
>> settings as above, only
>>
>> USER_AUTH_ORDER    "PersonalPage", "Db"
>> USER_AUTH_POLICY   'stacked'
>>
>> because I am playing.
>>
>> I have traced the code, and kind of understand what is happening, but 
>> I don't understand if it is wrong, and if so, what the fix should be. 
>> I'll say what I know so far.
>>
>> Here is the call stack. Line #s may vary a little because I've 
>> modified my files to print stuff.
>>
>> ...
>> main.php:107:updateAuthAndPrefs()
>>  $require_level = $this->requiredAuthority($this->getArg('action'));
>>  main.php:365:requiredAuthority()
>>    main.php:386:requiredAuthorityForAction()
>>      PagePerm.php:153:requiredAuthorityForPage()
>>        PagePerm.php:205:_requiredAuthorityForPagename('edit', 
>> 'HomePage');
>>          PagePerm.php:205:_requiredAuthorityForPagename('edit', '.');
>>          if (! $page->exists() ) {
>>            $perm = new PagePermission();
>>            return ($perm->isAuthorized($access,$request->_user) === 
>> true);
>>          }
>>            PagePerm.php:312:isAuthorized('edit', $user)
>>            return -1; // undecided
>>  WikiUserNew.php:502:hasAuthority() says
>>   return $this->_level >= $require_level;
>>
>> In English (I think):
>>
>> - check page permissions
>> - HomePage has no page perms, check its parent ('.')
>> - '.' doesn't exist, so check permissions from a new PagePermission 
>> object, which returns -1 ("undecided")
>> - Required authorization is now -1, known authorization from the user 
>> is -1 (anon), that's good enough, allow edit
>>
>> I do not understand enough about page permissions to know what's going 
>> wrong, or if it's config, or what. It seems to me that page 
>> permissions of HomePage being -1 seems wrong, but not sure.
>>
>> Dan
>>
>>
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
>> For a limited time only, get FREE Ground shipping on all orders of $35
>> or more. Hurry up and shop folks, this offer expires April 30th!
>> http://www.thinkgeek.com/freeshipping/?cpg=12297
>> _______________________________________________
>> Phpwiki-talk mailing list
>> Php...@li...
>> https://lists.sourceforge.net/lists/listinfo/phpwiki-talk
> 
> 
> 
> 
> 
> -------------------------------------------------------
> 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] allow_anon_edit false doesn't seem to work?

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

Okay, maybe I can rephrase this question a little.

- HomePage is getting checked for page permissions
- requiredAuthorityForPage is returning WIKIAUTH_FORBIDDEN (seems good)
- The non-logged-in user is a _ForbiddenUser, who has level 
WIKIAUTH_FORBIDDEN
- hasAuthority says "return $this->_level >= $require_level;" .. in 
other words, "yep, that's authorized"

Help? Which of these is not right? Possibilities:

1. a _ForbiddenUser should have level < WIKIAUTH_FORBIDDEN
2. hasAuthority should be testing >, not >=.
3. This is expected behavior.
4. Hidden option 4. (There's always hidden option 4.)

Reini?

Dan


Dan Frankowski wrote:

> Frederik De Bleser wrote:
>
>> Hi,
>>
>> I'm using phpwiki 1.3.9. My current user authentication configuration 
>> is:
>>
>> ENABLE_USER_NEW        true
>>
>> ALLOW_ANON_USER         true
>> ALLOW_ANON_EDIT         false
>> ALLOW_BOGO_LOGIN        false
>> ALLOW_USER_PASSWORDS    true
>>
>> USER_AUTH_ORDER        db
>> USER_AUTH_POLICY    first-only
>>
>> Somehow, I can edit pages without being logged in -- just by adding 
>> ?action=create or ?action=edit , I can create and edit pages. 
>> Shouldn't phpwiki give an error?
>
>
>
> I also can edit my HomePage without logging in, although I have 
> ALLOW_ANON_EDIT false. I can just click the 'edit' button, I don't 
> have to add anything to a URL. On my test site, I have the same 
> settings as above, only
>
> USER_AUTH_ORDER    "PersonalPage", "Db"
> USER_AUTH_POLICY   'stacked'
>
> because I am playing.
>
> I have traced the code, and kind of understand what is happening, but 
> I don't understand if it is wrong, and if so, what the fix should be. 
> I'll say what I know so far.
>
> Here is the call stack. Line #s may vary a little because I've 
> modified my files to print stuff.
>
> ...
> main.php:107:updateAuthAndPrefs()
>  $require_level = $this->requiredAuthority($this->getArg('action'));
>  main.php:365:requiredAuthority()
>    main.php:386:requiredAuthorityForAction()
>      PagePerm.php:153:requiredAuthorityForPage()
>        PagePerm.php:205:_requiredAuthorityForPagename('edit', 
> 'HomePage');
>          PagePerm.php:205:_requiredAuthorityForPagename('edit', '.');
>          if (! $page->exists() ) {
>            $perm = new PagePermission();
>            return ($perm->isAuthorized($access,$request->_user) === 
> true);
>          }
>            PagePerm.php:312:isAuthorized('edit', $user)
>            return -1; // undecided
>  WikiUserNew.php:502:hasAuthority() says
>   return $this->_level >= $require_level;
>
> In English (I think):
>
> - check page permissions
> - HomePage has no page perms, check its parent ('.')
> - '.' doesn't exist, so check permissions from a new PagePermission 
> object, which returns -1 ("undecided")
> - Required authorization is now -1, known authorization from the user 
> is -1 (anon), that's good enough, allow edit
>
> I do not understand enough about page permissions to know what's going 
> wrong, or if it's config, or what. It seems to me that page 
> permissions of HomePage being -1 seems wrong, but not sure.
>
> Dan
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
> For a limited time only, get FREE Ground shipping on all orders of $35
> or more. Hurry up and shop folks, this offer expires April 30th!
> http://www.thinkgeek.com/freeshipping/?cpg=12297
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwiki-talk

Re: [Phpwiki-talk] Patch for notification pref help, notification subject line

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

Whit Blauvelt wrote:

>>>I think "PageChange Notification" and "PagechangeNotification" are both 
>>>not normal English. They would not be published in a newspaper. They are 
>>>multiple words run together with unusual capitalization. 
>>>      
>>>
>>Well, this is wiki and not a newspaper.
>>Users do strange - almost german :) -  things with words in wikis. Since 
>>this is just about a subject line, and not about webpage usability for 
>>random users, I don't think that "normal english" would overrule 
>>"technical english".
>>
>>    
>>
>>>Also, simple English favors short words. "changed" is 2 syllables, 
>>>"notification" is 5 syllables, so I am trying to avoid that word.
>>>      
>>>
>>Sure.
>>    
>>
>
>How about "Page Change Notice" (or "PageChangeNotice" or whatever)?
>

Why not just "Page change"? What does "notice" add? Of course it's a 
notice, I just got an email about it.

>What's at issue here is really the Norman Invasion ..
>

While it is true that the Norman invasion had a strong effect on the 
English language, and that part of that influence is that informal words 
are often Germanic, more formal words Latin, I'd rather focus on this: 
whatever current English conventions for good speech and writing are at 
present, let's use those.

Dan

Re: [Phpwiki-talk] Patch for UserPreferences link, notification pref help, notification subject line

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

Reini Urban wrote:

> Dan Frankowski schrieb:
>
>> Reini Urban wrote:
>>
>>> Dan Frankowski schrieb:
>>>
>>>> Reini Urban wrote:
>>>
>>> add this to your navbar:
>>>     <?php if (!empty($user) && $user->isSignedIn()) { ?>
>>>      <?=$s?><?= WikiLink(_("UserPreferences"), "","Preferences") ?>
>>>     <?php } ?>
>>
>
> Will be added to the default navbar.tmpl, before "Admin".
>
>> Sounds good. Well, I'm glad that it's in somewhere. I'd say:
>>
>> a. It should be in the default theme.
>> b. I would claim it should be as near to the username as possible. 
>> When I think my username, I also think about preferences. Thus, I 
>> will leave it in the signin bar in my copy, since that's where the 
>> username is. I understand that you may disagree, and that's okay. Of 
>> course I'd prefer it if that made it to the mainline, but not crucial.
>
>
> And what I don't like is that navbar links look like actionbar 
> buttons. (technically they are, but...)
> I changed that in the latest "smaller" theme, where the navbar 
> consists entirely of WikiLinks, and the actionbar of the rounded buttons.


I see. When I looked at "smaller" this all made more sense. I agree that 
all links or all buttons looks better. I had users complain about that, 
too. However:

- It should be in the default theme, then. I was looking all default. 
(You said that's the plan.) Not only the prefs link, but the all-links 
all-buttons idea.

- Even in "smaller", the userid is still in the lower right, and it's 
still a link among buttons. Hence, I'd still put prefs near the id. On 
the other hand, it might be cool to put the signin and id at the top. I 
had several users ask me about that ("I can't find where to sign in.").

>
>>> Enter pages separated by space or comma. The wildcards * and ? are 
>>> allowed as in file globbing. For example use * for all pages,
>>> Php* for all all pages starting with Php,
>>> and use Home? for the pages Home1, Home2, HomeA, but not HomeOther.
>>
>>
>> How about:
>>
>> Enter pages separated by space or comma. Use wildcards * to match any 
>> text, and ? to match any single character. Examples using *: * for 
>> all pages, Php* for all pages starting with Php. Examples using ?: 
>> Home? for the pages Home1, Home2, HomeA, but not HomeOther.
>>
>> I am trying to avoid "file globbing." I know what that means, but 
>> most people don't.
>
>
> Adding it in parentheseis doesn't hurt for the users who know what it 
> means, they will to skip the whole paragraph, because they know about
> ^.*$ and ?* then.


Yikes. I would put this at the end, then. I thought I knew about 
file-globbing, but I didn't understand all this. I know ^ (begin-line), 
$ (end-line), * (match string), ? (match char), but .?  In general, make 
your audience as wide as possible.

>
>>> Maybe "PagechangeNotification"?
>>> Seems to sound more unwiki to me.
>>
>>
>> I am not looking for unwiki (i.e., not Wiki-like). I'm looking for 
>> understandable to any user, even those who don't know about wikis, 
>> even nontechnical users. I think most users would understand "Page 
>> changed: %s". I think it's easy and robust to filter on "] Page 
>> changed:".
>>
>> I think "PageChange Notification" and "PagechangeNotification" are 
>> both not normal English. They would not be published in a newspaper. 
>> They are multiple words run together with unusual capitalization. 
>
>
> Well, this is wiki and not a newspaper.
> Users do strange - almost german :) -  things with words in wikis. 
> Since this is just about a subject line, and not about webpage 
> usability for random users, I don't think that "normal english" would 
> overrule "technical english".


I would love to convince you otherwise!  In general, I am aiming for an 
application that anyone can use for the basics, but motivated users can 
learn more and do more. That means wherever possible, normal English is 
better. This *is* about webpage usability for random users. My explicit 
goal in WikiLens is:

1. Anyone who knows how to use a web browser can find items, rate them, 
and get value from that (recommendations, most popular, whatever).
2. Motivated users (say, top 10% of web browsing people) can learn how 
to add items. They may have to know how the Wiki works, but I hope not.
3. Unusually motivated users (say, top 10% of item-adding people) can 
learn how to add categories.

This is a crucial point, because I plan to invest significant effort to 
try to respond to my type-1 users' comments that it is hard to use by 
making the UI more friendly to the average user. If you believe that the 
Wiki is for technical users first, all of my changes will be objected 
to, discarded, and useless. You could say, "Make your own theme", but 
this reaches much deeper than theme! This wording is an example, where I 
can't control it in a theme. I know, you plan to make it configurable, 
but I strongly believe the underlying philosophy of the *whole system* 
should be 'average users where possible'! This kind of usability will 
not ultimately be themeable, it needs buy-in from the developers; there 
will always be new features, etc.

The fact that this is an email subject line makes it even *more* 
important to be normal English, not less, because it's not even a Wiki. 
It's an email, and users expect emails to be in their world, not a 
foreign Wiki world.

I like Wikis fine, but I believe to the extent possible (!) they should 
look like what people want, not train people to understand how this Wiki 
works. The reason is that then I will be able to get 10X more users, 
because 90% of the web browsing people will not bother to learn about 
unfriendly Wikis, they'll just leave.

Another example: Logins should not have to be a Wiki word. I plan to 
make this mod later on. Current behavior goes against web convention. No 
user I explain WikiLens to likes the fact that their login has to be a 
Wiki word.

- "What's a Wiki word?"
- "Why isn't DanF enough?"
- "I tried to create login foobar and it said 'Insufficient 
permissions'. Do you have to open the Wiki up?" (That's yet another 
thing: it's got to distinguish Insufficient permissions and illegal 
login name.)

Blah blah. It's just not worth the hassle to them. I have to explain it 
to everyone, and I can't do that much explaining. It's got to be easy or 
they won't use it. Note that Wikipedia allows a login that looks like 
other web logins.

This non-Wiki-ish usability for browsing and rating is absolutely 
crucial! What can I do to help convince you?

Dan

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

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

Frederik De Bleser wrote:

> Hi,
>
> I'm using phpwiki 1.3.9. My current user authentication configuration is:
>
> ENABLE_USER_NEW        true
>
> ALLOW_ANON_USER         true
> ALLOW_ANON_EDIT         false
> ALLOW_BOGO_LOGIN        false
> ALLOW_USER_PASSWORDS    true
>
> USER_AUTH_ORDER        db
> USER_AUTH_POLICY    first-only
>
> Somehow, I can edit pages without being logged in -- just by adding 
> ?action=create or ?action=edit , I can create and edit pages. 
> Shouldn't phpwiki give an error?


I also can edit my HomePage without logging in, although I have 
ALLOW_ANON_EDIT false. I can just click the 'edit' button, I don't have 
to add anything to a URL. On my test site, I have the same settings as 
above, only

USER_AUTH_ORDER    "PersonalPage", "Db"
USER_AUTH_POLICY   'stacked'

because I am playing.

I have traced the code, and kind of understand what is happening, but I 
don't understand if it is wrong, and if so, what the fix should be. I'll 
say what I know so far.

Here is the call stack. Line #s may vary a little because I've modified 
my files to print stuff.

...
main.php:107:updateAuthAndPrefs()
  $require_level = $this->requiredAuthority($this->getArg('action'));
  main.php:365:requiredAuthority()
    main.php:386:requiredAuthorityForAction()
      PagePerm.php:153:requiredAuthorityForPage()
        PagePerm.php:205:_requiredAuthorityForPagename('edit', 'HomePage');
          PagePerm.php:205:_requiredAuthorityForPagename('edit', '.');
          if (! $page->exists() ) {
            $perm = new PagePermission();
            return ($perm->isAuthorized($access,$request->_user) === true);
          }
            PagePerm.php:312:isAuthorized('edit', $user)
            return -1; // undecided
  WikiUserNew.php:502:hasAuthority() says
   return $this->_level >= $require_level;

In English (I think):

- check page permissions
- HomePage has no page perms, check its parent ('.')
- '.' doesn't exist, so check permissions from a new PagePermission 
object, which returns -1 ("undecided")
- Required authorization is now -1, known authorization from the user is 
-1 (anon), that's good enough, allow edit

I do not understand enough about page permissions to know what's going 
wrong, or if it's config, or what. It seems to me that page permissions 
of HomePage being -1 seems wrong, but not sure.

Dan

Re: [Phpwiki-talk] phpwiki-1.2.2 patches

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

Reini Urban schrieb:
> This is a patch the classic stable phpwiki-1.2.2 version, to

> 2) add support for the mostpopular nearby feature for dba

This nice old feature will be re-implemented as new 1.3.x plugin 
PopularNearby, btw.
This is why I came to detect the 1.2.2 problems.


5 best incoming links: TextFormattingRules (4), RecentChanges (3), 
PhpWikiAdministration (2), TestPage (1)
5 best outgoing links: WikiWikiWeb (6), AddingPages (4), HowToUseWiki 
(4), MostPopular (3), RecentChanges (3)
5 most popular nearby: PhpWikiAdministration (1), ReleaseNotes (0), 
SandBox (0), TextFormattingRules (0), TestPage (0)

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

[Phpwiki-talk] phpwiki-1.2.2 patches

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

If someone is concerned:
This is a patch the classic stable phpwiki-1.2.2 version, to

1) fix a minor aesthetic bug in the info action, without showsource 
(don't print a warning)
2) add support for the mostpopular nearby feature for dba
3) add remove support to dba

I'll add the patch to the sf.net patches tracker also, post the url for 
the release candidate tgz, wait for one week and make then a new 1.2.3 
release. Comments?
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] Patch for notification pref help, notification subject line

[Whit B. <wh...@tr...>]

> >I think "PageChange Notification" and "PagechangeNotification" are both 
> >not normal English. They would not be published in a newspaper. They are 
> >multiple words run together with unusual capitalization. 
> 
> Well, this is wiki and not a newspaper.
> Users do strange - almost german :) -  things with words in wikis. Since 
> this is just about a subject line, and not about webpage usability for 
> random users, I don't think that "normal english" would overrule 
> "technical english".
> 
> >Also, simple English favors short words. "changed" is 2 syllables, 
> >"notification" is 5 syllables, so I am trying to avoid that word.
> 
> Sure.

How about "Page Change Notice" (or "PageChangeNotice" or whatever)? A
"notice" may also be called a "notification," but that's a bit of a bastard
word mostly used on envelopes falsely suggesting that you've won some
million-dollar contest. When the law requires a public statment be published
in a newspaper, the standard heading is "Public Notice", _not_
"Notification."

What's at issue here is really the Norman Invasion, and the injection of
pretentious Latinate vocabulary among the fine Germanic grunts previously
practiced by the English ... in any case "notification" is a bullshit
(pardon my Anglo-Saxon) word in most of its uses. Running it together like
German is normal computer-speak since at least WordStar, but going French
with it...? ; >

Whit

Re: [Phpwiki-talk] Patch for UserPreferences link, notification pref help, notification subject line

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

Dan Frankowski schrieb:
> Reini Urban wrote:
>> Dan Frankowski schrieb:
>>> Reini Urban wrote:
>> add this to your navbar:
>>     <?php if (!empty($user) && $user->isSignedIn()) { ?>
>>      <?=$s?><?= WikiLink(_("UserPreferences"), "","Preferences") ?>
>>     <?php } ?>

Will be added to the default navbar.tmpl, before "Admin".

> Sounds good. Well, I'm glad that it's in somewhere. I'd say:
> 
> a. It should be in the default theme.
> b. I would claim it should be as near to the username as possible. When 
> I think my username, I also think about preferences. Thus, I will leave 
> it in the signin bar in my copy, since that's where the username is. I 
> understand that you may disagree, and that's okay. Of course I'd prefer 
> it if that made it to the mainline, but not crucial.

And what I don't like is that navbar links look like actionbar buttons. 
(technically they are, but...)
I changed that in the latest "smaller" theme, where the navbar consists 
entirely of WikiLinks, and the actionbar of the rounded buttons.

>> Enter pages separated by space or comma. The wildcards * and ? are 
>> allowed as in file globbing. For example use * for all pages,
>> Php* for all all pages starting with Php,
>> and use Home? for the pages Home1, Home2, HomeA, but not HomeOther.
> 
> How about:
> 
> Enter pages separated by space or comma. Use wildcards * to match any 
> text, and ? to match any single character. Examples using *: * for all 
> pages, Php* for all pages starting with Php. Examples using ?: Home? for 
> the pages Home1, Home2, HomeA, but not HomeOther.
> 
> I am trying to avoid "file globbing." I know what that means, but most 
> people don't.

Adding it in parentheseis doesn't hurt for the users who know what it 
means, they will to skip the whole paragraph, because they know about
^.*$ and ?* then.

>> Maybe "PagechangeNotification"?
>> Seems to sound more unwiki to me.
> 
> I am not looking for unwiki (i.e., not Wiki-like). I'm looking for 
> understandable to any user, even those who don't know about wikis, even 
> nontechnical users. I think most users would understand "Page changed: 
> %s". I think it's easy and robust to filter on "] Page changed:".
> 
> I think "PageChange Notification" and "PagechangeNotification" are both 
> not normal English. They would not be published in a newspaper. They are 
> multiple words run together with unusual capitalization. 

Well, this is wiki and not a newspaper.
Users do strange - almost german :) -  things with words in wikis. Since 
this is just about a subject line, and not about webpage usability for 
random users, I don't think that "normal english" would overrule 
"technical english".

> Also, simple English favors short words. "changed" is 2 syllables, "notification" is 
> 5 syllables, so I am trying to avoid that word.

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

Re: [Phpwiki-talk] Patch for UserPreferences link, notification pref help, notification subject line

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

Reini Urban wrote:

> Dan Frankowski schrieb:
>
>> Reini Urban wrote:
>>
>>> Hmm, don't they see their "Preferences" actionbar.tmpl link at the top?
>>> This appears for every authenticated user. (based on the default theme)
>>
> >
>
>> 1. I apologize for my denseness, but I cannot find this. I can't see 
>> it on a page (try http://www.wikilens.org), and I can't find any 
>> reference to preferences  or users in actionbar.tmpl. Also, the only 
>> template included is 'signin' at the bottom. I am missing something 
>> obvious. By the way, our actionbar.tmpl is like 1.3.9. I do see some 
>> stuff in head.tmpl, but cannot figure out where that is being 
>> included. I read Map.pdf, and am still confused. :-( Sorry.
>
>
> Sorry, i mixed it up. So far it's only in
> themes/smaller/templates/navbar.tmpl:
>
> add this to your navbar:
>     <?php if (!empty($user) && $user->isSignedIn()) { ?>
>      <?=$s?><?= WikiLink(_("UserPreferences"), "","Preferences") ?>
>     <?php } ?>
>
> (actionbar is the bottom line, navbar the top line)


Sounds good. Well, I'm glad that it's in somewhere. I'd say:

a. It should be in the default theme.
b. I would claim it should be as near to the username as possible. When 
I think my username, I also think about preferences. Thus, I will leave 
it in the signin bar in my copy, since that's where the username is. I 
understand that you may disagree, and that's okay. Of course I'd prefer 
it if that made it to the mainline, but not crucial.

>
>> 2. Even if that were true, there should be a preferences link 
>> whenever you are logged in even if you are not authenticated yet, 
>> because the only way to get authenticated is to visit your 
>> preferences and set your email. Am I missing something here too?
>
>
> email has nothing to do with authentication. you just have to login 
> with the correct password, or if none, if none set.


Ah, thanks for that clarification.

>
>>>> "Enter pages separated by space or comma. Wildcards * and ? 
>>>> allowed.  For example, to see all pages, just put *; to see all 
>>>> pages Home1, Home2, HomeA, but not HomeAB, put Home?."
>>>
>>>
>>> Hmm, good idea, but not the best example. We should avoid a dot.
>>
>>
>> You mean the period at the very end? Probably true. How about:
>>
>> _("Enter pages separated by space or comma. Wildcards * and ? 
>> allowed.  For example, to see all pages, just put \"*\" (without the 
>> quotes); to see all pages Home1, Home2, HomeA, but not HomeAB, put 
>> \"Home?\" (without the quotes).")
>
>
> Enter pages separated by space or comma. The wildcards * and ? are 
> allowed as in file globbing. For example use * for all pages,
> Php* for all all pages starting with Php,
> and use Home? for the pages Home1, Home2, HomeA, but not HomeOther.


How about:

Enter pages separated by space or comma. Use wildcards * to match any 
text, and ? to match any single character. Examples using *: * for all 
pages, Php* for all pages starting with Php. Examples using ?: Home? for 
the pages Home1, Home2, HomeA, but not HomeOther.

I am trying to avoid "file globbing." I know what that means, but most 
people don't.

>>>> + $subject = sprintf(_("Page '%s' changed"),$this->_pagename);
>>>
>>>
>>> 3) Email notifications subject line
>>>
>>> This makes filtering harder.
>>
>>
>> Every notification I get has "[WikiLens]" at the beginning (the name 
>> of the Wiki from index.php), which nicely looks very much like other 
>> notification tags (e.g., Mailman). This is what I would filter on. Is 
>> that bad?
>
> - $subject = sprintf(_("PageChange Notification %s"),$this->_pagename);
>
> That's the first filter criterion for the wikisite.
> The second criterion is the string "PageChange Notification". I have 
> multiple wiki's to follow. My folders layout e.g. is:
> phpwiki -> demo -> notify
>         -> phpwiki -> notify
>         -> acadwiki -> notify
>         -> arch.x -> notify
>         -> other  -> notify
> Or maybe:
> phpwiki -> talk
>         -> checkins
>         -> forums
>         -> notify -> demo
>                   -> phpwiki
>                   -> acadwiki
>                   -> arch.x
>                   -> other
> To have a strong enough filter for the default notify case
> I prefer (contains "] PageChange Notification ") over
> (contains "] Page ")
>
>> I was just looking to change the text to something that a Wiki-naive 
>> user would not be afraid of. "PageChange" is unusual capitalization 
>> for English. Also, "PageChange Notification" is very official. Could 
>> do "Page changed: %s".
>
>
> Maybe "PagechangeNotification"?
> Seems to sound more unwiki to me.


I am not looking for unwiki (i.e., not Wiki-like). I'm looking for 
understandable to any user, even those who don't know about wikis, even 
nontechnical users. I think most users would understand "Page changed: 
%s". I think it's easy and robust to filter on "] Page changed:".

I think "PageChange Notification" and "PagechangeNotification" are both 
not normal English. They would not be published in a newspaper. They are 
multiple words run together with unusual capitalization. Also, simple 
English favors short words. "changed" is 2 syllables, "notification" is 
5 syllables, so I am trying to avoid that word.

Thanks for your attention.

Dan

Re: [Phpwiki-talk] Patch for UserPreferences link, notification pref help, notification subject line

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

Dan Frankowski schrieb:
> Reini Urban wrote:
>> Hmm, don't they see their "Preferences" actionbar.tmpl link at the top?
>> This appears for every authenticated user. (based on the default theme)
 >
> 1. I apologize for my denseness, but I cannot find this. I can't see it 
> on a page (try http://www.wikilens.org), and I can't find any reference 
> to preferences  or users in actionbar.tmpl. Also, the only template 
> included is 'signin' at the bottom. I am missing something obvious. By 
> the way, our actionbar.tmpl is like 1.3.9. I do see some stuff in 
> head.tmpl, but cannot figure out where that is being included. I read 
> Map.pdf, and am still confused. :-( Sorry.

Sorry, i mixed it up. So far it's only in
themes/smaller/templates/navbar.tmpl:

add this to your navbar:
     <?php if (!empty($user) && $user->isSignedIn()) { ?>
      <?=$s?><?= WikiLink(_("UserPreferences"), "","Preferences") ?>
     <?php } ?>

(actionbar is the bottom line, navbar the top line)


> 2. Even if that were true, there should be a preferences link whenever 
> you are logged in even if you are not authenticated yet, because the 
> only way to get authenticated is to visit your preferences and set your 
> email. Am I missing something here too?

email has nothing to do with authentication. you just have to login with 
the correct password, or if none, if none set.

>>> "Enter pages separated by space or 
>>> comma. Wildcards * and ? allowed.  For example, to see all pages, 
>>> just put *; to see all pages Home1, Home2, HomeA, but not HomeAB, put 
>>> Home?."
>>
>> Hmm, good idea, but not the best example. We should avoid a dot.
> 
> You mean the period at the very end? Probably true. How about:
> 
> _("Enter pages separated by space or comma. Wildcards * and ? allowed.  
> For example, to see all pages, just put \"*\" (without the quotes); to 
> see all pages Home1, Home2, HomeA, but not HomeAB, put \"Home?\" 
> (without the quotes).")

Enter pages separated by space or comma. The wildcards * and ? are 
allowed as in file globbing. For example use * for all pages,
Php* for all all pages starting with Php,
and use Home? for the pages Home1, Home2, HomeA, but not HomeOther.

>>> - $subject = sprintf(_("PageChange Notification %s"),$this->_pagename);
>>> + $subject = sprintf(_("Page '%s' changed"),$this->_pagename);
>>
>> 3) Email notifications subject line
>>
>> This makes filtering harder.
> 
> Every notification I get has "[WikiLens]" at the beginning (the name of 
> the Wiki from index.php), which nicely looks very much like other 
> notification tags (e.g., Mailman). This is what I would filter on. Is 
> that bad?

That's the first filter criterion for the wikisite.
The second criterion is the string "PageChange Notification". I have 
multiple wiki's to follow. My folders layout e.g. is:
phpwiki -> demo -> notify
         -> phpwiki -> notify
         -> acadwiki -> notify
         -> arch.x -> notify
         -> other  -> notify
Or maybe:
phpwiki -> talk
         -> checkins
         -> forums
         -> notify -> demo
                   -> phpwiki
                   -> acadwiki
                   -> arch.x
                   -> other
To have a strong enough filter for the default notify case
I prefer (contains "] PageChange Notification ") over
(contains "] Page ")

> I was just looking to change the text to something that a Wiki-naive 
> user would not be afraid of. "PageChange" is unusual capitalization for 
> English. Also, "PageChange Notification" is very official. Could do 
> "Page changed: %s".

Maybe "PagechangeNotification"?
Seems to sound more unwiki to me.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] INCLUDE_PATH + Pear changes, CVS CreateTocPlugin unstable, mysql quirks

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

Current CVS is unstable.

I thought I fixed the CreateTocPlugin in current CVS (works for me), but=20
as it shows it breaks the sf.net wiki if enabled on any page - such as=20
the demo HomePage. Even more hairy code as the last version, to support=20
all kind of special markup in the headers: WikiLinks and WikiWords.
I'll try to debug it in the next days.

I made some important Pear changes to announce:
Pear is now stable and good enough, we don't need our own copies anymore.
* Our shipped pear path is now added automatically to the include_path,
   and all our files don't load our pear per se,
   instead it tries the pear files from the standard path.
* This way you can simply update your pear to the latest version and
   use it with phpwiki. Our pear is for now the same as the latest pear.
   (Besides the still broken File_Passwd.php. That's the only one
   so far.)
   Before we changed the load paths in each pear file to use our
   pear files.
* If you define your own include_path WITHOUT phpwiki/lib/pear, you must
   have your own current pear repository installed and setup in the
   include_path!
AGAIN:
   either don't define *include_path* or add your pear path
   (e.g. ".:/usr/share/pear") or add our phpwiki/lib/pear
   (e.g. ".:/home/user/phpwiki/lib/pear")

Normally you don't have to touch include_path anymore, even with a=20
PrettyWiki setup with start scripts from completely different=20
directories. You only have to define DATA_PATH then.

My and Joby's massive config changes from the last week seem to=20
stabilize. And the influenza from my last week surfing sessions
(1.50m waves, but 12=B0 C water temp.) seems to have gone also.
So I dared to commit my latest adodb versions with transaction support,=20
and locking for the stupid databases (as before). Current CVS db code is=20
unstable.

MySQL really is the worst of all crap. Not that you have to do
LOCK page WRITE, version WRITE;
This way you cannot select from or write to other other tables also.
All tables seem to be locked! So you have to read and write block all=20
tables for a single atomic transaction. (v4.0.x)
Does anybody know more about this special mysql feature?
I tried custom application locks with the GET_LOCK/RELEASE_LOCK=20
functions but this is not yet tested enough.

$ mysql phpwiki
mysql> lock tables page write;
mysql> select * from version where id=3D1;
ERROR 1100: Table 'version' was not locked with LOCK TABLES
mysql> unlock tables;
mysql> lock tables page write, version read;
mysql> select * from version where id=3D1;
mysql> unlock tables;
--=20
Reini Urban
http://phpwiki.sf.net/

Re: [Phpwiki-talk] Patch for UserPreferences link, notification pref help, notification subject line

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

Reini Urban wrote:

> Dan Frankowski schrieb:
>
>> Three little patches with rewording or interface. Take them or not at 
>> your convenience.
>>
>> Dan
>>
>> 1) UserPreferences link
>>
>> I have found it awkward to explain to people how to change their user 
>> preferences. Thus, I put a link to UserPreferences next to their 
>> login when logged in. I am not sure this is the right interface yet 
>> (gotta see how people react to it). However, I submit a patch for it 
>> anyway.
>
>
> Hmm, don't they see their "Preferences" actionbar.tmpl link at the top?
> This appears for every authenticated user. (based on the default theme)


1. I apologize for my denseness, but I cannot find this. I can't see it 
on a page (try http://www.wikilens.org), and I can't find any reference 
to preferences  or users in actionbar.tmpl. Also, the only template 
included is 'signin' at the bottom. I am missing something obvious. By 
the way, our actionbar.tmpl is like 1.3.9. I do see some stuff in 
head.tmpl, but cannot figure out where that is being included. I read 
Map.pdf, and am still confused. :-( Sorry.

2. Even if that were true, there should be a preferences link whenever 
you are logged in even if you are not authenticated yet, because the 
only way to get authenticated is to visit your preferences and set your 
email. Am I missing something here too?

> To add it to the signin message after login is also okay, but then we 
> should make it more verbose.
> But at the lower right we don't have enough room for that.


I think I will understand this better once I see the message you are 
referring to.

>> --- themes/default/templates/signin.tmpl        14 Apr 2004 21:23:06 
>> -0000     1.1.1.2
>> +++ themes/default/templates/signin.tmpl        23 Apr 2004 20:59:37 
>> -0000
>> @@ -15,7 +15,8 @@
>>     $Sep = $Theme->getButtonSeparator();
>>     $SignOutB = $Theme->makeButton(_("Sign Out"), 
>> "javascript:SignOut();", 'wikiaction');
>> ?>
>> -  <?= fmt("Authenticated as %s", 
>> WikiLink($user->getAuthenticatedId(), 'auto')) ?>
>> +  <?= fmt("Authenticated as %s (%s)", 
>> WikiLink($user->getAuthenticatedId(), 'auto'),
>> +          WikiLink(_("UserPreferences"), 'auto')) ?>
>>   <?=$Sep?>
>>   <script language="JavaScript" type="text/javascript"><!--
>>     document.write('<input type="hidden" name="auth[logout]" 
>> value="0" />');
>
> diff -w -b -u -r1.1.1.2 signin.tmpl
>
>> 2) Email notifications help text
>> Here is a minor rewording of the help text for the email 
>> notifications page.
>> -    <td><span class="hint"><?=_("Enter pages seperated by space or 
>> comma. Wildcards (fileglobbing) allowed.")?></span></td>
>> +    <td><span class="hint"><?=_("Enter pages separated by space or 
>> comma. Wildcards * and ? allowed.  For example, to see all pages, 
>> just put *; to see all pages Home1, Home2, HomeA, but not HomeAB, put 
>> Home?.")?></span></td>
>
>
> Hmm, good idea, but not the best example. We should avoid a dot.


You mean the period at the very end? Probably true. How about:

_("Enter pages separated by space or comma. Wildcards * and ? allowed.  
For example, to see all pages, just put \"*\" (without the quotes); to 
see all pages Home1, Home2, HomeA, but not HomeAB, put \"Home?\" 
(without the quotes).")


>> - $subject = sprintf(_("PageChange Notification %s"),$this->_pagename);
>> + $subject = sprintf(_("Page '%s' changed"),$this->_pagename);
>
> 3) Email notifications subject line
>
> This makes filtering harder.


Every notification I get has "[WikiLens]" at the beginning (the name of 
the Wiki from index.php), which nicely looks very much like other 
notification tags (e.g., Mailman). This is what I would filter on. Is 
that bad?

I was just looking to change the text to something that a Wiki-naive 
user would not be afraid of. "PageChange" is unusual capitalization for 
English. Also, "PageChange Notification" is very official. Could do 
"Page changed: %s".

Thanks for your attention to these.

Dan

Re: [Phpwiki-talk] Translating

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

Keeton schrieb:
>>Did you try the new _WikiTranslation plugin?
>><?plugin _WikiTranslation ?>
>>
>>Clicking on the [T] adds a translation to the
>><UserName>/ContributedTranslations page, for admins to pick it up there.
> 
> I tried and it coud use some improvement. Like the feature that an admin
> should't have to manually change the .po file. If I am wrong in thinking
> this, please let me know, it would come in very handy. Also, how to add more
> admins without editing index.php?
> 
> The file TranslateText.php missed a few characters in the line that adds the
> suggested changes, line 98. This was mostly seen as the <verbatum> tag needs
> a new line to start and the spaces to have the indent of the verbatim
> correct. I changed it to this:
>     $text .= "\n  <verbatim>\n  locale/po/$lang.po:\n msgid
> \"".$pagename."\"\n  msgstr \"".$trans."\"\n </verbatim>\n";

thanks.

>>Make them available somehow.
>>Either post them on your website and announce it here, or post it to the
>>sf.net patches site.
> 
> I will use the website we now have and after we are satisfied with (some)
> results, we will send them through the PhpWiki talk list. Is that fine with
> everybody?

The strings are short, but if you post the full pgsrc please zip it.
but sf.net doesn't allow zip attachments so rename the extension for the 
attachment.

> BTW, is it possible to add all the language Psrc files without having to
> edit index.php a few times? Wait, I think I know (through the admin menu
> change the default language a few times or have users do this over time). It
> would be nice to have this as a standard option.

PhpWikiAdministration => Load File
and point to the directory of your locale/nl/pgsrc/

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

[Phpwiki-talk] OOOOPS

[Keeton <ke...@cw...>]

Okee, so change the line 98 to:

-----
                $text .= "\n  <verbatim>\n  locale/po/$lang.po:\n  msgid
\"".$pagename."\"\n  msgstr \"".$trans."\"\n  </verbatim>\n";
-----

Sorry for the error.

There goes my credibility!

Grtz,
Koen



http://www.hondaheaven.org/
"Ik ben de vliegenier en vliegend zie ik alles."
S. Marres

Re: [Phpwiki-talk] Translating

[Keeton <pnk...@cw...>]

> Did you try the new _WikiTranslation plugin?
> <?plugin _WikiTranslation ?>
>
> Clicking on the [T] adds a translation to the
> <UserName>/ContributedTranslations page, for admins to pick it up there.
I tried and it coud use some improvement. Like the feature that an admin
should't have to manually change the .po file. If I am wrong in thinking
this, please let me know, it would come in very handy. Also, how to add more
admins without editing index.php?

The file TranslateText.php missed a few characters in the line that adds the
suggested changes, line 98. This was mostly seen as the <verbatum> tag needs
a new line to start and the spaces to have the indent of the verbatim
correct. I changed it to this:
    $text .= "\n  <verbatim>\n  locale/po/$lang.po:\n msgid
\"".$pagename."\"\n  msgstr \"".$trans."\"\n </verbatim>\n";

> Make them available somehow.
>
> Either post them on your website and announce it here, or post it to the
> sf.net patches site.

I will use the website we now have and after we are satisfied with (some)
results, we will send them through the PhpWiki talk list. Is that fine with
everybody?

BTW, is it possible to add all the language Psrc files without having to
edit index.php a few times? Wait, I think I know (through the admin menu
change the default language a few times or have users do this over time). It
would be nice to have this as a standard option.

Grtz,
Koen



http://www.hondaheaven.org/
"Ik ben de vliegenier en vliegend zie ik alles."
S. Marres
----- Original Message -----
From: "Reini Urban" <ru...@x-...>
To: <php...@li...>
Cc: <pnk...@cw...>
Sent: Monday, April 26, 2004 12:47 AM
Subject: Re: [Phpwiki-talk] Translating


> pnk...@cw... schrieb:
> > For reasons of boredom and general interest in Wiki I registered the
> > domain http://www.phpwiki.nl/ . The installation on this domain is 1.3.9
> > and it went as smooth as can be. Standard language setting is en, no
> > problems here.
> >
> > I need some input on the following issues:
> > - I want to have the standard pages from the core translated to Dutch.
> > Some have been done already and I can do some work myself, but not all
> > (and I am not in a hurry). For the Dutch readers, feel free to visit and
> > contribute.
> > - I do not understand how to use the PgsrcTranslation in easily
> > translating the main Wikiwords. Could someone please shed some light
here?
>
> Did you try the new _WikiTranslation plugin?
> <?plugin _WikiTranslation ?>
>
> Clicking on the [T] adds a translation to the
> <UserName>/ContributedTranslations page, for admins to pick it up there.
>
> You need to have the TranslateText action page with the <?plugin
> TranslateText ?> as content.
>
> > - When pages are translated, how to submit them to the project?
>
> Make them available somehow.
>
> Either post them on your website and announce it here, or post it to the
> sf.net patches site.
> --
> Reini Urban
> http://xarch.tu-graz.ac.at/home/rurban/
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: The Robotic Monkeys at ThinkGeek
> For a limited time only, get FREE Ground shipping on all orders of $35
> or more. Hurry up and shop folks, this offer expires April 30th!
> http://www.thinkgeek.com/freeshipping/?cpg=12297
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwiki-talk

Re: [Phpwiki-talk] Patch for UserPreferences link, notification pref help, notification subject line

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

Dan Frankowski schrieb:
> Three little patches with rewording or interface. Take them or not at 
> your convenience.
> 
> Dan
> 
> 1) UserPreferences link
> 
> I have found it awkward to explain to people how to change their user 
> preferences. Thus, I put a link to UserPreferences next to their login 
> when logged in. I am not sure this is the right interface yet (gotta see 
> how people react to it). However, I submit a patch for it anyway.

Hmm, don't they see their "Preferences" actionbar.tmpl link at the top?
This appears for every authenticated user. (based on the default theme)

To add it to the signin message after login is also okay, but then we 
should make it more verbose.
But at the lower right we don't have enough room for that.

> diff -w -b -u -r1.1.1.2 signin.tmpl
> --- themes/default/templates/signin.tmpl        14 Apr 2004 21:23:06 
> -0000     1.1.1.2
> +++ themes/default/templates/signin.tmpl        23 Apr 2004 20:59:37 -0000
> @@ -15,7 +15,8 @@
>     $Sep = $Theme->getButtonSeparator();
>     $SignOutB = $Theme->makeButton(_("Sign Out"), 
> "javascript:SignOut();", 'wikiaction');
> ?>
> -  <?= fmt("Authenticated as %s", WikiLink($user->getAuthenticatedId(), 
> 'auto')) ?>
> +  <?= fmt("Authenticated as %s (%s)", 
> WikiLink($user->getAuthenticatedId(), 'auto'),
> +          WikiLink(_("UserPreferences"), 'auto')) ?>
>   <?=$Sep?>
>   <script language="JavaScript" type="text/javascript"><!--
>     document.write('<input type="hidden" name="auth[logout]" value="0" 
> />');

> 2) Email notifications help text
> Here is a minor rewording of the help text for the email notifications 
> page.
> -    <td><span class="hint"><?=_("Enter pages seperated by space or 
> comma. Wildcards (fileglobbing) allowed.")?></span></td>
> +    <td><span class="hint"><?=_("Enter pages separated by space or 
> comma. Wildcards * and ? allowed.  For example, to see all pages, just 
> put *; to see all pages Home1, Home2, HomeA, but not HomeAB, put 
> Home?.")?></span></td>

Hmm, good idea, but not the best example. We should avoid a dot.

> 3) Email notifications subject line
> - $subject = sprintf(_("PageChange Notification %s"),$this->_pagename);
> + $subject = sprintf(_("Page '%s' changed"),$this->_pagename);

This makes filtering harder.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] =?windows-1251?B?zvLi5fIg7eAgwuD4IOfg7/Du8SAvLy8g4iD14u7x8uUsIOrg6iDx6u7w?= =?windows-1251?B?7iD/8fLw5eEg7eD37eXyIPno7+Dy/CDv8uj28ywg?=

[Slaphappier H. O. <vo...@ro...>]

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4=2e0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3dContent-Type content=3d"text/html; charset=3dwindows-1=
251">
<META content=3d"MSHTML 6=2e00=2e2737=2e800" name=3dGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3d#ffffff>
<DIV><FONT face=3dArial color=3d#ffff00 size=3d2><IMG alt=3d"" hspace=3d0=
=20
src=3d"cid:paralegals=2egif" align=3dbaseline=20
border=3d0></FONT></DIV>
<DIV><FONT face=3dArial color=3d#ffff00 size=3d2></FONT>&nbsp;</DIV>
<DIV><FONT face=3dArial color=3d#ffff00=20
size=3d2>=ed=e5=e4=f0=e5=ec=eb=fe=f9=e8=ec  =e3=eb=e0=e7=ee=ec,  =f1=e5=e9=
=f7=e0=f1 =f1=ef=f0=ff=f7=e5=f2=f1=ff =e2  =f2=f0=e0=e2=f3,  </FONT></DIV=
></BODY></HTML>