phpwiki-talk

[Phpwiki-talk] Re: Another use for Google's 'rel='nofollow''?

[Charles C. <ch...@ru...>]

On Thu, January 27, 2005 17:31, Charles Corrigan said:
> I just looked at the access log for my site and noticed
> that google was indexing it. And it was trying every
> possible link from every page!
>
> Would it make sense to add a "rel='nofollow'" to links
> such as "edit text" where it makes no sense for a robot
> to follow?

When I wrote that, it was already 7 days after Reini had started putting
the nofollow attribute onto some of the links! My only excuse (hah!) is
that CVS and then the lists had problems last week.

Anyway, I took a look and found that the changes did not work for me - I
did not spend any time trying to work out why.  I just put a couple of
changes in that worked in my testing.

/lib/Theme.php

- line 1184 - 4 lines in Button->Button()
           // Google honors this
           if (in_array(strtolower($text),
array('edit','create','diff','pdf'))
               and !$request->_user->isAuthenticated())
               $this->setAttr('rel', 'nofollow');
replaced with
           // Google honors this
           $this->setAttr('rel', 'nofollow');

- line 1210 - 4 lines in ImageButton->ImageButton()
           // Google honors this
           if (in_array(strtolower($text),
array('edit','create','diff','pdf'))
               and !$GLOBALS['request']->_user->isAuthenticated())
               $this->setAttr('rel', 'nofollow');
replaced with
           // Google honors this
           $this->setAttr('rel', 'nofollow');


OK, some justification is required. In my opinion
1 - it does not matter whether the user is authenticated or not, only that
if the user is google or another search engine, we do not want them to
follow these links
2 - while there are some of the action buttons that it would be good for
google to follow (RecentChanges, BackLinks), most of them I would prefer
it did not.

The downside of my changes is that there will be an unconditional
additional 15 characters per action link in the HTML sent to the client.

regards,
Charles

Re: [Phpwiki-talk] phpwiki-1.2.8 and 1.3.11 soon

[Stefan <son...@ba...>]

Error

when using latest CVS Version the following Error on end of page is shown

lib/PageType.php (In template 'body' < 'html'):144: Notice: Undefined 
variable: intermap

maybe because i use it in german, what todo?

Regards Stefan

Re: [Phpwiki-talk] phpwiki-1.2.8 and 1.3.11 soon

[Stefan <son...@ba...>]

Hello,

tried the last cvs 5 minutes ago.

the language selection did not function correct. The buttons like 
"RecentChanges", "FindPage" ... are not translated to german when setting

DEFAULT_LANGUAGE = de
THEME = default
CHARSET = iso-8859-1


Regards Stefan

Reini Urban schrieb:

> Just detected a register_globals = off broken logic in 1.2.7, which 
> requires a new release.
>
> For the upcoming 1.3.11 release we fixed now the most important bugs,
> and I just want to add some minor features:
>
> * blog pages and plugins for new blog theme to be useful at all.
> * finish ModeratedPage
> * finish configurator.php
> * check wikilens
>
> and check the new reports:
> locale broken,
> peardbpassuser not loaded on pref change,
> session problems (I think I fixed that now).

Re: [Phpwiki-talk] headers in email sent by a wiki

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

Joel Uckelman schrieb:
> Thus spake Reini Urban:
>>Joel Uckelman schrieb:
>>
>>>Would anyone else besides me find it useful to be able to set certain 
>>>headers (e.g., From, Reply-to) in mail sent by a wiki in that wiki's config
>>>file?
>>>
>>>Say, in the config file you could have:
>>>
>>>EMAIL_HEADER_FROM = MyWiki <my...@ex...>
>>>EMAIL_HEADER_REPLY_TO = MyWikiAdmin <wik...@ex...>
>>>EMAIL_HEADER_X_ARBITRARY_JUNK = foo, bar!
>>>
>>>and those would be used in all outgoing mail from the wiki.
>>
>>Sure.
>>And we really need a Mailer class, which should produce
>>all outgoing mails.
>>But I wanted to defer that to the next release.
> 
> 
> I have a basic Mailer class hammered out now, and I have a few questions about
> how we're handling constants.
> 
> 1. I see that I would need to register nonboolean EMAIL_* constants in
> IniConfig.php, yes?
> 
> 2. Which would be preferable:
> 
> a) EMAIL_HEADER_FROM and EMAIL_HEADER_REPLY_TO contain just the header
> value, while EMAIL_HEADER_n contains the whole header
> 
> b) Every header constant contains the whole header, while EMAIL_HEADER_FROM
> and EMAIL_HEADER_REPLY_TO are named for convenience (rather than numbered)
> because they'll be the ones people most often want to set.
 >
> c) Every header constant contains only the header value, and the header
> name is deduced from the constant name: e.g., when we process the constant
> EMAIL_HEADER_FROM, we look at the part after EMAIL_HEADER_, lower case it
> and capitalize the first letter to get the header name.
> 
> d) Something else, like reading all of the user defined headers from a
> file.

I would say three constants:
EMAIL_HEADER_FROM = "my name"
EMAIL_HEADER_REPLY_TO = "my...@em...rver"
EMAIL_HEADER_REST = "x-noarchive: yes\nx-sender: phpwiki"

> I like c) myself, but I think it would involve a call to
> get_defined_constants() and then a loop over the whole mess of them just to
> find the ones which start with EMAIL_HEADER_. That might be unacceptably slow;
> I'm not sure. (Unless we have a global dictionary which contains all of the
> variables defined in config.ini? Do we?)

Nope. Not yet.

I added in some code and logic to dump/restore all config.ini setting 
from a writable config/config.php file for faster loading.
This does some detection but it not used per default, since there's no 
writable config/config.php.

Any pecl extension or other lib may define their own EMAIL_HEADER_* 
constants.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] phpwiki-1.2.8 and 1.3.11 soon

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

Just detected a register_globals = off broken logic in 1.2.7, which 
requires a new release.

For the upcoming 1.3.11 release we fixed now the most important bugs,
and I just want to add some minor features:

* blog pages and plugins for new blog theme to be useful at all.
* finish ModeratedPage
* finish configurator.php
* check wikilens

and check the new reports:
locale broken,
peardbpassuser not loaded on pref change,
session problems (I think I fixed that now).
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] headers in email sent by a wiki

[Joel U. <uck...@no...>]

Thus spake Reini Urban:
> Joel Uckelman schrieb:
> > Would anyone else besides me find it useful to be able to set certain 
> > headers (e.g., From, Reply-to) in mail sent by a wiki in that wiki's config
>  
> > file?
> > 
> > Say, in the config file you could have:
> > 
> > EMAIL_HEADER_FROM = MyWiki <my...@ex...>
> > EMAIL_HEADER_REPLY_TO = MyWikiAdmin <wik...@ex...>
> > EMAIL_HEADER_X_ARBITRARY_JUNK = foo, bar!
> > 
> > and those would be used in all outgoing mail from the wiki.
> 
> Sure.
> And we really need a Mailer class, which should produce
> all outgoing mails.
> But I wanted to defer that to the next release.

I have a basic Mailer class hammered out now, and I have a few questions about
how we're handling constants.

1. I see that I would need to register nonboolean EMAIL_* constants in
IniConfig.php, yes?

2. Which would be preferable:

a) EMAIL_HEADER_FROM and EMAIL_HEADER_REPLY_TO contain just the header
value, while EMAIL_HEADER_n contains the whole header

b) Every header constant contains the whole header, while EMAIL_HEADER_FROM
and EMAIL_HEADER_REPLY_TO are named for convenience (rather than numbered)
because they'll be the ones people most often want to set.

c) Every header constant contains only the header value, and the header
name is deduced from the constant name: e.g., when we process the constant
EMAIL_HEADER_FROM, we look at the part after EMAIL_HEADER_, lower case it
and capitalize the first letter to get the header name.

d) Something else, like reading all of the user defined headers from a
file.

I like c) myself, but I think it would involve a call to
get_defined_constants() and then a loop over the whole mess of them just to
find the ones which start with EMAIL_HEADER_. That might be unacceptably slow;
I'm not sure. (Unless we have a global dictionary which contains all of the
variables defined in config.ini? Do we?)

[Phpwiki-talk] php5 now fixed in CVS

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

I had to add another php5 eval hack, but now it works finally.

clone() was needed because php5 doesn't do deep object copies,
it just copies the pointer on $obj1 = $obj2.

Ja, and I added another useful plugin: AsciiMath
See http://www.jcphysics.com/ASCIIMath/
So you are not forced to use TeX syntax for MathML notations,
and it needs no cached png procesor, just simple MathML.
-- 
Reini Urban
http://phpwiki.org//

Re: [Phpwiki-talk] Re: [ phpwiki-Patches-1094143 ] Put memory usage on every page if debug mode is on

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

Dan Frankowski schrieb:
> I saw you applied this in a nicer way than suggested in the patch. Thanks.

It's still not perfect. I'll fix it later.
1. unit tests need to load stdlib.php now before loading pear and 
phpwiki, which fools the memory stats.
2. it shouldn't print "Memory: 0"

> I saw your request for me to do it. I would have to have a CVS mainline 
> going and a reasonable confidence that what I checked in was 
> cross-platform safe. Especially the second I wasn't sure about.

Ok.
cgi or local debugging for example crashes if any exe (ps or pslist) is 
not found.

PS: I'm almost done with the php5 fixes. I clearly isolated the problem 
now, why BlockParser_Input::advance() doesn't work in PHP5.
-- 
Reini

Re: [Phpwiki-talk] png optimization

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

Joel Uckelman schrieb:
> Thus spake Reini Urban:
>>But beware that pngout likes to destroy certain png's, so you have to 
>>check all of them manually afterwards.
> 
> When it goes bad, does it do it an an obvious way? I glanced over all of
> the ones it optimized before I committed them, and they seemed fine.

Yes, they look fine.
Broken pngout png's have an ugly (dark) pixel on the lower right (or 
lower-left?) corner. That's all.

> Also, I noticed that lots of the MacOSX theme buttons don't pass the alpha
> channel test. None of the Spanish, Dutch, and Italian, and French ones do; a
> few of the English and German ones have the same problem. (Lots of graphics
> from the other themes don't, either. Extending the alpha test to all of the
> themes was the easiest way for me to check all of the pngs after optimizing
> them.) Having noticed that, I'd fix it, but I'm not sure that I'd be able
> to do a good job with the graphics.

That's usually Carsten's job. He got all the MacOSX progs.
He described it in the mail archive, if you wanna have a try.

There are also some more of the MacOSX buttons missing.
-- 
Reini Urban

[Phpwiki-talk] phpwiki+mySQL not work on ISP(1.3.10) bug???

[Hiller, D. D \(Dean\) <dh...@av...>]

When using phpwiki with mySQL on my ISP where I think the webserver
can't write to files(only to db), I think 1.3.10 does not work.  It must
still be writing to disk for somethings????

=20

The behavior I see is I can log in(I heavily locked the wiki down), but
then trying to create homepage, clicking on admin, or prefs all bring me
back to the home page.  It is like that writing to disk is needed or I
am screwed.  Is this true?

Thanks,

dean

[Phpwiki-talk] Re: [ phpwiki-Patches-1094143 ] Put memory usage on every page if debug mode is on

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

Reini,

I saw you applied this in a nicer way than suggested in the patch. Thanks.

I saw your request for me to do it. I would have to have a CVS mainline 
going and a reasonable confidence that what I checked in was 
cross-platform safe. Especially the second I wasn't sure about.

Dan

SourceForge.net wrote:

>Patches item #1094143, was opened at 2005-01-01 19:41
>Message generated for change (Comment added) made by rurban
>You can respond by visiting: 
>https://sourceforge.net/tracker/?func=detail&atid=306121&aid=1094143&group_id=6121
>
>Category: None
>Group: None
>Status: Open
>  
>
>>Resolution: Accepted
>>    
>>
>Priority: 5
>Submitted By: Dan F (dfrankow)
>  
>
>>Assigned to: Reini Urban (rurban)
>>    
>>
>Summary: Put memory usage on every page if debug mode is on
>
>Initial Comment:
>This isn't visually the prettiest, but it works. This
>is important information if you wish to keep memory
>usage down. I just took it from Reini's unit tests.
>
>Dan
>
>cvs diff -bu debug.tmpl
>Index: debug.tmpl
>===================================================================
>RCS file: .../phpwiki/themes/default/templates/debug.tmpl,v
>retrieving revision 1.1.1.1
>diff -b -u -r1.1.1.1 debug.tmpl
>--- debug.tmpl  29 Jan 2004 14:30:35 -0000      1.1.1.1
>+++ debug.tmpl  1 Jan 2005 18:37:23 -0000
>@@ -16,6 +16,13 @@
> </div>
> </td><td>
> <span class="debug"><?=fmt("Page Execution took %s
>seconds", $RUNTIMER->getStats())?></span>
>+<?php
>+if (function_exists('memory_get_usage') and
>memory_get_usage()) {
>+    $mem = memory_get_usage();
>+    echo "<br/><br/><span class=\debug\>Memory
>usage: $mem bytes</span>";
>+}
>+?>
>+
> </td></tr></table>
> <?php // This keeps the valid XHTML! icons from
>"hanging off the bottom of the screen" ?>
>
>
>----------------------------------------------------------------------
>
>  
>
>>Comment By: Reini Urban (rurban)
>>    
>>
>Date: 2005-01-23 01:28
>
>Message:
>Logged In: YES 
>user_id=13755
>
>Looks fine, just will most likely not work on windows.
>Do you want to commit it by yourself?
>
>----------------------------------------------------------------------
>
>You can respond by visiting: 
>https://sourceforge.net/tracker/?func=detail&atid=306121&aid=1094143&group_id=6121
>  
>

Re: [Phpwiki-talk] png optimization

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

Joel Uckelman schrieb:
> I noticed that Reini had used pngout to convert some gifs to pngs, and that 
> it significantly reduced the size of lots of the converted files. I was 
> curious whether it would further optimize the pngs we already had, so I ran 
> it on all of them. In total, it reduced the size of our pngs by 27k at no 
> cost in quality.
> 
> So, to sum up: Great pngs, less filling. :)

But beware that pngout likes to destroy certain png's, so you have to 
check all of them manually afterwards.
-- 
Reini Urban

Re: [Phpwiki-talk] user hunting ...

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

Arnaud Fontaine schrieb:
> I have a difficult problem on some public wikis I rule :
> 
> I have to block someone's contributions and delete his tracks (past
> contribs).

block:
   apache conf: deny from ip

revert modifications by user:
   AllPagesLastEditedByMe?author=SomeUser

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

[Phpwiki-talk] png optimization

[Joel U. <uck...@no...>]

I noticed that Reini had used pngout to convert some gifs to pngs, and that 
it significantly reduced the size of lots of the converted files. I was 
curious whether it would further optimize the pngs we already had, so I ran 
it on all of them. In total, it reduced the size of our pngs by 27k at no 
cost in quality.

So, to sum up: Great pngs, less filling. :)

-- 
J.

Re: [Phpwiki-talk] phpwiki archive page not created.

[donnie j. <don...@gm...>]

Also, it is the flat-file database.
Any suggestions on how to fix the archive pages
not being created?  or what may cause that to not occur?

Thank you.
__
Donnie


On Thu, 20 Jan 2005 08:43:11 -0500, donnie jones
<don...@gm...> wrote:
> Sorry forgot to mention the version...
> Yes, version 1.2.6
> 
> Any ideas what would be causing the archive page to not be created?
> Thank you.
> __
> Donnie
> 
> On Thu, 20 Jan 2005 10:16:04 +0100, Reini Urban <ru...@x-...> wrote:
> > donnie jones schrieb:
> > > I am having some problems with phpwiki not creating
> > > archive pages, which also doesn't allow for me to see the "diff"
> > > of any pages...
> > >
> > > I have checked the permissions of the "archive" directory, and
> > > it is owned by www:www with 0777 permissions.
> > >
> > > I am not sure what else could be preventing the archive
> > > pages from being created...Any help would be great.
> >
> > Which version?
> > I assume some 1.2.x with $WhichDatabase = 'file'.
> > I fixed flatfile in the 1.2.6 release.
> >
> > --
> > Reini Urban
> > http://xarch.tu-graz.ac.at/home/rurban/
> >
>

Re: [Phpwiki-talk] PrevNext buttons, bug 1045585

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

Reini Urban wrote:

> Dan Frankowski schrieb:
>
>> Reini Urban wrote:
>>
>>> Of course if someone will come with less uglier buttons and most 
>>> agree, we can replace them.
>>
>>
>> A forward look: our StormZebra release of WikiLens has nice-looking 
>> paging, with prev/next, page #s, and asc/descending sorting, all with 
>> nice graphics and look and feel. I'd be happy if you 'stole' it when 
>> it comes out.
>
>
> Who should get the attribution for those buttons of yours?


Hmm. Scott Yilek. Wait until you see them first; they might not fit your 
bill. For example, we do only text for Next/Prev; the buttons are for 
asc/desc sort.

Dan

[Phpwiki-talk] user hunting ...

[Arnaud F. <ar...@cr...>]

Hi all,

I have a difficult problem on some public wikis I rule :

I have to block someone's contributions and delete his tracks (past
contribs).

Any technical idea ?

Arnaud

[Phpwiki-talk] HIDE_TOOLBARS ...

[Arnaud F. <ar...@cr...>]

Hi all,

I don't get why the HIDE_TOOLBARS global isn't set properly if I test it
in body.tmpl ...

<?php
  global $HIDE_TOOLBARS;
  if(!$HIDE_TOOLBARS) {
?>
<div id="actionbar">
<?= Template('actionbar') ?>
</div>
<?php } ?>

this code is from my body.tmpl and $HIDE_TOOLBARS isn't set ...


Any clue ?

Arnaud

Re: [Phpwiki-talk] What to do?

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

Arnaud Fontaine schrieb:
> Le 26 janv. 05, à 15:03, Reini Urban a écrit :
>> ke...@ch... schrieb:
>>
>>> I reinstalled and now I get the same thing. What am I doing and how 
>>> do I correct
>>> what is.
>>> The following is at the top of all my pages:
>>> lib/Request.php:299: Warning[2]: ob_start(): output handler 
>>> 'ob_gzhandler'
>>> cannot be used after 'URL-Rewriter'
>>> Can you help?
>>
>> config.ini:
>> COMPRESS_OUTPUT = false
>> or use current CVS.

keith:
edit config/config.ini
search for "COMPRESS_OUTPUT ="
and change it to:
COMPRESS_OUTPUT = false

Or install current CVS.

> Did you correct the compression stuff with RSS feeds (ie. do you still 
> compress rss output) ?

Yes, this was fixed in lib/Request.php:364

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

Re: [Phpwiki-talk] PrevNext buttons, bug 1045585

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

Dan Frankowski schrieb:
> Reini Urban wrote:
>> Of course if someone will come with less uglier buttons and most 
>> agree, we can replace them.
> 
> A forward look: our StormZebra release of WikiLens has nice-looking 
> paging, with prev/next, page #s, and asc/descending sorting, all with 
> nice graphics and look and feel. I'd be happy if you 'stole' it when it 
> comes out.

Who should get the attribution for those buttons of yours?

> Our MoonBadger version is done, but we still have not gotten our hacked 
> machine up (grr), so we can't release it. StormZebra is intended to 
> feature freeze around mid-February, out by early March I think.


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

[Phpwiki-talk] Another use for Google's "rel='nofollow'"?

[Charles C. <ch...@ru...>]

I just looked at the access log for my site and noticed that google was
indexing it. And it was trying every possible link from every page!

Would it make sense to add a "rel='nofollow'" to links such as "edit text"
where it makes no sense for a robot to follow?

regards,
Charles

[Phpwiki-talk] RFC Securing PhpWiki - revised

[Charles C. <ch...@ru...>]

Here is a revised version of the PhpWiki security document, including
better formatting for insertion into a page.  It is written in a very
conversational manner and refers to several issues with the SetACL
functionality - but I would be grateful for review and suggestions.

The SetACL issues that I have seen are
# the settings are not carried over from the first page to the
confirmation page
# attempting to remove a negative/deny/no-access ACL does not work but
removing a positive/allow/access ACL does work.

I suspect that unwanted line breaks will be introduced into this message
by my mail software, particularly into the config.ini settings and the
long "  acl=" line. If necessary, I can mail again as an attachment.

regards,
Charles

================================================================

_I hate [WikiSpam|http://en.wikipedia.org/wiki/Wikispam]!_

Being technically minded and based in the Asia time zone while my
co-authors are mainly in Europe and some in the US, it became my
unofficial role to clean up the WikiSpam each day in a 1.2 based PhpWiki.
The WikiSpam that I see is mostly created during the evening in the US
time zone - which is the morning for me.

I started working on PhpWiki 1.3/1.4 with a view to upgrade our wiki,
implementing security to:
* let anyone view our work,
* let anyone register themselves as users,
* but require new users to be authorised before editing or creating pages.

While testing and fixing bugs, I discovered some interesting and useful
things about security in PhpWiki. I hope my knowledge will help others.
This is the recipe that I used. There are many variations that will work
just as well or even better for you. Note that for most of the actions,
you need to be logged into the wiki as an administrator.

!!!1 - Generic security setup.
For the configuration that I describe above, the following parameters
should be set in config/config.ini (and are further documented there).
This requires that you have read and write access to the filestore on the
webserver.
----
<pre>
; require the new login code - the default
;ENABLE_USER_NEW = true

; allow ACL based permissions on pages - the default
;ENABLE_PAGEPERM = true

; allow unknown/anonymous users to by default read the content
ALLOW_ANON_USER = true

; prevent unknown/anonymous users from editing/creating pages
ALLOW_ANON_EDIT = false

; prevent users just creating a temporary user
; (I am skating over the complexities of this setting)
ALLOW_BOGO_LOGIN = false

; to require users to have passwords
; (this is not independent of the other settings above)
ALLOW_USER_PASSWORDS = true

; require passwords to have a minimum length
; I am not trying to protect national security,
; just encourage the vandals to go elsewhere
PASSWORD_LENGTH_MINIMUM = 6

; use a database to check user-ids and passwords.
; Note that there many other settings database settings that
; need careful attention but that is out of scope for this HOW-TO
USER_AUTH_ORDER = "Db"
USER_AUTH_POLICY = first-only

; Store group information in wiki pages
; there’s no need to develop a complex front end for a database.
; Note that in performance terms this is the most expensive option.
GROUP_METHOD = WIKIPAGE

; the master page listing the groups - I just used the default
; CATEGORY_GROUP_PAGE = ~CategoryGroup

; The following SQL queries/statements are stored in
; config/config.ini so that they can easily be changed
; if there an existing user database. Several of these have
; alternatives documented in config/config.ini
DBAUTH_AUTH_USER_EXISTS = "SELECT userid FROM user WHERE userid="$userid""
DBAUTH_AUTH_CHECK = "SELECT IF(passwd=PASSWORD("$password"),1,0) AS ok
FROM user WHERE userid="$userid""
DBAUTH_AUTH_CRYPT_METHOD = plain
DBAUTH_AUTH_UPDATE = "UPDATE user SET passwd=PASSWORD("$password") WHERE
userid="$userid""
DBAUTH_AUTH_CREATE = "INSERT INTO user SET
passwd=PASSWORD("$password"),userid="$userid""
DBAUTH_PREF_SELECT = "SELECT prefs FROM pref WHERE userid="$userid""
DBAUTH_PREF_UPDATE = "REPLACE INTO pref SET
prefs="$pref_blob",userid="$userid""

; I am paranoid about undiscovered cross-site scripting
; vulnerabilities so I prevent users injecting HTML directly into
; pages. It may be safe to allow the latter 2 options
ENABLE_RAW_HTML = false
ENABLE_RAW_HTML_LOCKEDONLY = false
ENABLE_RAW_HTML_SAFE = false
</pre>
----

!!!2 - User Group management
Create group pages in the wiki.
*First, in page CategoryGroup, add the name of the group in the bulleted
list.  This may either be a WikiWord or enclosed in "~[" and "~]" and
there must be nothing else on the line. For example, while editing
CategoryGroup, add
<pre>* ~[Writers]
* ~UserManagement
</pre>
  and save. I will use these two groups as examples.

* Create the two group pages by clicking on the links in the CategoryGroup
page and add the list of users as a bulleted list (as above).
  - In the Writers group, list the users that are allowed to edit and
create pages.
  - In the UserManagement group, list the users that may authorise new
users (or remove existing users).
  - A user may be a member of both groups and new users may be added at
any time.
* Lock all three pages CategoryGroup, Writers and UserManagement.
* Unlock all three pages. _I am not certain that these last two steps are
necessary but various comments around the documentation indicate that it
is and, anyway, it did no harm._

!!!3 - change the default page permissions.

Create a page named . to hold these default permissions. _Yes, named "."._

The recommended way to do this is to
* go your HomePage
* remove "HomePage" from the url and replace with the parameters
"?pagename=.&action=create"
* enter some text like "This page holds the default ACLs for all pages"
and save
* go your HomePage
* remove "HomePage" from the url and replace with the parameters
"?pagename=.&action=setacl"
* change the ACLs for EDIT and for CREATE to
  - +Administrators
  - +Owner
  - +Writers
  - -Authenticated Users
  - -Signed Users
  - -Bogo Users
* _Where + means the ACL allows that kind of access and – means the ACL
does not allow that kind of access._
* change the ACLs for CHANGE and REMOVE to
  - +Administrators
  - +Owner
  - -Authenticated Users
  - -Signed Users
  - -Bogo Users

!3a Alternative method to create page "." and set the ACLs correctly.
I found some bugs in the SetACL user interface (that I have not yet looked
into / fixed), so I used an alternative mechanism to set the ACLs.
* export a Zip Dump (via the PhpWikiAdministration page)
* extract one of the files from this zip - initially, it might look like
----
<pre>Subject: ~AppendText
From: foo@bar (~PhpWiki)
To: foo@bar (~PhpWiki)
Date: Wed, 5 Jan 2005 17:09:46 +0800
Mime-Version: 1.0 (Produced by ~PhpWiki 1.3.11pre-20050108)
Content-Type: application/x-phpwiki;
  pagename=~AppendText;
  flags="";
  author=The%20PhpWiki%20programming%20team;
  version=1;
  lastmodified=1104916186;
  created=1104916186;
  author_id=The%20PhpWiki%20programming%20team;
  markup=2;
  charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

~<?plugin ~AppendText ?>
</pre>
----
* rename and edit this file (I called it "dot" but this does not matter).
The contents should look something like
----
<pre>Subject: .
From: foo@bar (~PhpWiki)
To: foo@bar (~PhpWiki)
Date: Mon, 17 Jan 2005 15:54:59 +0800
Mime-Version: 1.0 (Produced by ~PhpWiki 1.3.11pre-20050108)
Content-Type: application/x-phpwiki;
  pagename=.;
  flags="";
  author=Admin;
  version=1;
  lastmodified=1105949000;
  created=1105949000;
  author_id=Admin;
  markup=2;
  acl="view:_EVERY;
edit:_ADMIN,_OWNER,Writers,-_SIGNED-_BOGOUSER,-_AUTHENTICATED;
create:_ADMIN,_OWNER,Writers,-_SIGNED,-_BOGOUSER,-_AUTHENTICATED;
list:_EVERY; remove:_ADMIN,_OWNER,-_SIGNED,-_BOGOUSER,-_AUTHENTICATED;
change:_ADMIN,_OWNER,-_SIGNED,-_BOGOUSER,-_AUTHENTICATED; dump:_EVERY";
  charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

This page holds the default permissions for all pages
</pre>
----
* The author and author_id should be the name of the administrator account.
* The important line is the one starting "  acl=". This lists the
groups/login types allowed to perform various actions on a page.
  - Names starting with an _ and all in capitals ("_ADMIN","_OWNER" etc.)
are built-in PhpWiki groups.
  - A - in front of the name means that that group is not allowed perform
an action, so "edit:-_AUTHENTICATED" means that a user that has logged
in is not allowed edit a page (unless they are also a member of another
group that is allowed).
* The example acl= line above implements the policy that I described near
the start of this page.
* Load the file back into the database through the PhpWikiAdministration
page.
* Check the permissions are what you need in PhpWikiAdministration/SetAcl
- this can be done on any page, not just on the "." page. _Use the setacl
button to see the permissions on a page._

* If you have to alter the ACL, I suggest that you bump the values for
version, lastmodified and created before reloading (I found problems
removing groups in the UI, so use the dump page, manual edit and reload
page mechanism documented above).

* Set any additional/specific restrictions on an individual page by page
basis.
* In particular, to have a limited list of users that can manage adding
and removing users from the Writers group, you should
  - on pages Writers, UserManagement, CategoryGroup and CategoryCategory
  - add UserManagement to edit and create permissions
  - remove Writers from edit and create permissions

* Test the permissions work as expected.

Re: [Phpwiki-talk] PrevNext buttons, bug 1045585

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

Reini Urban wrote:

> Of course if someone will come with less uglier buttons and most 
> agree, we can replace them.


A forward look: our StormZebra release of WikiLens has nice-looking 
paging, with prev/next, page #s, and asc/descending sorting, all with 
nice graphics and look and feel. I'd be happy if you 'stole' it when it 
comes out.

Our MoonBadger version is done, but we still have not gotten our hacked 
machine up (grr), so we can't release it. StormZebra is intended to 
feature freeze around mid-February, out by early March I think.

Dan

Re: [Phpwiki-talk] gifs

[Joel U. <uck...@no...>]

Thus spake Reini Urban:
> Joel Uckelman schrieb:
> > There are 17 gifs left in the project tree. Some of them have notes in the
> > changelog to the effect that we kept the gifs for compatibility with older
> > browsers, but these notes are mostly from 2002. Has it been long enough for
> > us to convert these to pngs now? (If so, I'll do that.)
> 
> That would be really great.
> But please fix the src & templates also, if there's some direct link to 
> a gif.

Done. No more gifs, and all of the hard-coded references have been changed
accordingly.

Re: [Phpwiki-talk] gifs

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

Joel Uckelman schrieb:
> There are 17 gifs left in the project tree. Some of them have notes in the
> changelog to the effect that we kept the gifs for compatibility with older
> browsers, but these notes are mostly from 2002. Has it been long enough for
> us to convert these to pngs now? (If so, I'll do that.)

That would be really great.
But please fix the src & templates also, if there's some direct link to 
a gif.
-- 
Reini Urban