phpwiki-talk

Re: [Phpwiki-talk] Re: Fatal Error restoring from .zip file

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

Micki Kaufman schrieb:
> Using the latest dev code from CVS, checked out and installed well, but 
> it won't recognize a .zip file under 'Restoring'.
> 
> Using the same 'Upload File' method, I get a "'fatal PhpWiki Error' No 
> uploaded file to upload?" message.
> 
> Is this a known issue? Thanks so much, this build is looking GOOD!

Micki, is it fixed now?

I found some possible problems and made a workaround in is_upladed_file()
Works fine for me now. Also for my win32 \r\r\n problem.

The only problem/feature is that conflicts are skipped and not overwritten.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] Line breaks in new markup

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

Paul Bloomfield schrieb:
> Is the change to the way line breaks work in new markup intentional?

I think so.

> It seems that a single end-of-line (EOL) is parsed as an end of line in
> the HTML, rather than a <br />. To get a <br /> you have to force it
> with %%%. I cannot work with this - it is unlike any other wiki I know.

Well, we wanted to overcome wrapped text problems in certain 
envoriments, like this email client here. you simply don't know if the 
text is autmatiaccyl warpped or manually broken. you decide to break it 
either by starting a new paragrahp, or by using %%% or <br>.

> What would work much better is for the default for an end of a line to
> be a <br />, unless that line were terminated with a / or something, in
> which case it would flow on. Double EOLs of course stay as closing a
> </p>.

we never thought of a terminating "/". maybe jeff will try to implement 
this in his block parser.

> Is this already switchable, if not can it be made switchable (or got rid
> of altogether), or does the community prefer what we have now with %%%
> anyway so I'd better just get on and code it myself?

why not use <br> for intentional linebreaks?
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

RE: [Phpwiki-talk] Line breaks in new markup

[Paul B. <pa...@pa...>]

Why disable for pages with old style markup - EOL -> <br /> was how the
old markup worked?

/_ is a good idea, it will not IMO be needed very often, on the other
hand you could always put a space after a / at the end of line to
'escape' it if you wanted to display the / - it would not affect the
rendering (just white space in HTML).

I am still trying to find where this happens in the code (excellent code
BTW - generating valid HTML is much harder than it looks, the
inline/block level rules being particularly unhelpful)...


-----Original Message-----
From: electron [mailto:ele...@mg...] 
Sent: 24 February 2004 16:27
To: 'Paul Bloomfield'; php...@li...
Subject: RE: [Phpwiki-talk] Line breaks in new markup


This has been a user requested feature.

2 ways to do it:

1) Assume as you said, parse EOL as <br />

2) Replace EOL with %%% and let user decide in preview. New option to
disable auto formatting?

I suggest 1 and we only parse as such on pages that don't have old style
markup checked. Also would suggest /_ as that is a combination that is
infrequently used.

-Jtp


----

Is the change to the way line breaks work in new markup intentional?

It seems that a single end-of-line (EOL) is parsed as an end of line in
the HTML, rather than a <br />. To get a <br /> you have to force it
with %%%. I cannot work with this - it is unlike any other wiki I know.

What would work much better is for the default for an end of a line to
be a <br />, unless that line were terminated with a / or something, in
which case it would flow on. Double EOLs of course stay as closing a
</p>.

Is this already switchable, if not can it be made switchable (or got rid
of altogether), or does the community prefer what we have now with %%%
anyway so I'd better just get on and code it myself?

Paul




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Phpwiki-talk mailing list
Php...@li...
https://lists.sourceforge.net/lists/listinfo/phpwiki-talk



-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Phpwiki-talk mailing list
Php...@li...
https://lists.sourceforge.net/lists/listinfo/phpwiki-talk

[Phpwiki-talk] Email Notification

[Micki K. <mic...@co...>]

Hey there.

Wondering about EmailNotification - any plans to implement a per-page 
notification process, like at
http://phpwiki.sourceforge.net/phpwiki/EmailNotification

I know there's a notify section of UserPreferences - but this 
approach seems logical, and indeed seems like a natural adjunct to 
PagePermissions.

Thanks,
Micki
-- 

Micki
mailto:mic...@co...

RE: [Phpwiki-talk] Line breaks in new markup

[John K. <li...@ke...>]

At 10:26 am -0600 24/2/04, electron wrote:
>This has been a user requested feature.
>
>2 ways to do it:
>
>1) Assume as you said, parse EOL as <br />
>
>2) Replace EOL with %%% and let user decide in preview. New option to
>disable auto formatting?
>
>I suggest 1 and we only parse as such on pages that don't have old style
>markup checked. Also would suggest /_ as that is a combination that is
>infrequently used.

A long time ago I added ';;' as an alternative to the very ugly %%%, 
since ; is a 'breaking' character, and changed %%% to <br clear=all> 
since I'd added left/right alignment to images.

If you're looking for an alternative to %%%, that's not used in 
normal text, might ;; be an option?

John.

RE: [Phpwiki-talk] Line breaks in new markup

[electron <ele...@mg...>]

This has been a user requested feature.

2 ways to do it:

1) Assume as you said, parse EOL as <br />

2) Replace EOL with %%% and let user decide in preview. New option to
disable auto formatting?

I suggest 1 and we only parse as such on pages that don't have old style
markup checked. Also would suggest /_ as that is a combination that is
infrequently used.

-Jtp


----

Is the change to the way line breaks work in new markup intentional?

It seems that a single end-of-line (EOL) is parsed as an end of line in
the HTML, rather than a <br />. To get a <br /> you have to force it
with %%%. I cannot work with this - it is unlike any other wiki I know.

What would work much better is for the default for an end of a line to
be a <br />, unless that line were terminated with a / or something, in
which case it would flow on. Double EOLs of course stay as closing a
</p>.

Is this already switchable, if not can it be made switchable (or got rid
of altogether), or does the community prefer what we have now with %%%
anyway so I'd better just get on and code it myself?

Paul




-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Phpwiki-talk mailing list
Php...@li...
https://lists.sourceforge.net/lists/listinfo/phpwiki-talk

RE: [Phpwiki-talk] UTF-8 0xA0

[electron <ele...@mg...>]

Lets start by creating a road map


From User End:

Browser->Post to Web Server (Is the browser converting this?)

Server End:

Web Server->PHP (Is it here?)
PHP->PhpWiki (Here?)

PhpWiki

Finally, If we get inside PHPWiki:
Inside Request?
Inside parser?
Does it convert when we throw it to the DB?
Does it convert when cached?

Output:

Output Back through server (Here?)
Browser display. (Here?)

-Jtp

----

Hi,
This is really interesting, but my possibilities to debug this problem 
is limited. I have no mule-enabled Xemacs (yet). And with my 
mule-enabled emacs I just cannot enter these characters.

On my screen 0xa0 looks like 0x20. There's no dot.
Can that be a PHP problem?

Do you know any 0xa0 combination that actually represents another 
character that doesn't look like a space?
Or some hints how to debug this?
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] UTF-8 0xA0

[Gea-Suan L. <gs...@cc...>]

There dots are generated by hexdump, not by php or other else.

URL:
http://wiki.abpe.org/index.php/SandBox

Screenshot:
http://netnews.nctu.edu.tw/~gslin/tmp/sandbox.png

You can use wget and hexdump to see it about 00000f60 ~ 00000f80:

% wget http://wiki.abpe.org/index.php/SandBox
% hexdump -C Sandbox
	:
	:
00000f60  6e 61 62 6c 65 20 62 6f  74 74 6f 6d 22 3e 55 54  |nable bottom=
">UT|
00000f70  46 2d 38 20 e9 20 81 e9  9d a2 e6 b8 ac e8 a9 a6  |F-8 ?.?=A2=E6=
=B8=AC=E8=A9=A6|
00000f80  3c 2f 70 3e 0a 3c 2f 64  69 76 3e 0a 0a 3c 64 69  |</p>.</div>.=
.<di|
	:
	:

On Tue, Feb 24, 2004 at 04:54:11PM +0100, Reini Urban wrote:
> Hi,
> This is really interesting, but my possibilities to debug this problem=20
> is limited. I have no mule-enabled Xemacs (yet). And with my=20
> mule-enabled emacs I just cannot enter these characters.
>=20
> On my screen 0xa0 looks like 0x20. There's no dot.
> Can that be a PHP problem?
>=20
> Do you know any 0xa0 combination that actually represents another=20
> character that doesn't look like a space?
> Or some hints how to debug this?
> --=20
> Reini Urban
> http://xarch.tu-graz.ac.at/home/rurban/

--=20
* Gea-Suan Lin  (public key: http://ccreader.nctu.edu.tw/~gslin/key.txt)
* If you cannot convince them, confuse them.           -- Harry S Truman

[Phpwiki-talk] Line breaks in new markup

[Paul B. <pa...@pa...>]

Is the change to the way line breaks work in new markup intentional?

It seems that a single end-of-line (EOL) is parsed as an end of line in
the HTML, rather than a <br />. To get a <br /> you have to force it
with %%%. I cannot work with this - it is unlike any other wiki I know.

What would work much better is for the default for an end of a line to
be a <br />, unless that line were terminated with a / or something, in
which case it would flow on. Double EOLs of course stay as closing a
</p>.

Is this already switchable, if not can it be made switchable (or got rid
of altogether), or does the community prefer what we have now with %%%
anyway so I'd better just get on and code it myself?

Paul

Re: [Phpwiki-talk] UTF-8 0xA0

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

Gea-Suan Lin schrieb:
>   I use UTF-8 (for Traditional Chinese) as phpwiki charset, and there
> are some problem:
> 
>   When phpwiki translates data to html, char 0xA0 will translate to
> space (0x20).
> 
>   You may see the html source code in http://wiki.abpe.org/index.php/SandBox :
> 
> 00000f60  6e 61 62 6c 65 20 62 6f  74 74 6f 6d 22 3e 55 54  |nable bottom">UT|
> 00000f70  46 2d 38 20 e9 20 81 e9  9d a2 e6 b8 ac e8 a9 a6  |F-8 ?.?Ｘ葫閰帆
> 00000f80  3c 2f 70 3e 0a 3c 2f 64  69 76 3e 0a 0a 3c 64 69  |</p>.</div>..<di|
> 
>   and the original statement:
> 
> 00000000  55 54 46 2d 38 20 e9 a0  81 e9 9d a2 e6 b8 ac e8  |UTF-8 ?.?Ｘ葫鋧
> 00000010  a9 a6                                             |岫|

Hi,
This is really interesting, but my possibilities to debug this problem 
is limited. I have no mule-enabled Xemacs (yet). And with my 
mule-enabled emacs I just cannot enter these characters.

On my screen 0xa0 looks like 0x20. There's no dot.
Can that be a PHP problem?

Do you know any 0xa0 combination that actually represents another 
character that doesn't look like a space?
Or some hints how to debug this?
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] Ready for 1.3.8 ?

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

I found and fixed another error in action=upload with win 32 only.
But found another one with merge edit then.
Will be fixed soon.

electron schrieb:
> To be done for 1.4.0:
> * improve WikiAdminSetAcl, test PagePerms.
> * implement paging for long lists:
>      requires ->_backend->get_num_pages(),
>      and enable the limit support in PageList
>      just display prev + next buttons
> * fix minor dumping problems.
> * use lib/removepage for WikiAdminRemove
> * check the sf.net patches and bug submssions.
> 
> My additions:
> 
> * Trim WikiUserNew so its not calling itself for upgrading. Possibly split
>   it to a WikiAuth folder/backend style ala WikiDB

This is the best method I came up with, supporting all the wanted features.

> * Move Admin/PW out index.php and into the DB. Create a "superuser" group.

This was voted down many times before. Simplicity. Most people use just 
gdbm.

> * Rip out any place except WikiDB where we are checking DBParams for dbtype
>   (breaks portability)

Sure.

> * Move diff.php to a plugin and add some requested features. (colorization)
> * Native XML dumping. Create a wiki schema if none exists.
> * Clean UserPreferences.tmpl into the plugin.
> * Try and make more plugins use templating.
> * Touch as many todos and fixmes as possible.
> * More dynamic configuration and installer stuff.
> * Update Doc, Doc Doc...and more Doc!

Sure.

> * Consider a better translation system.

Suggestions?

> * Clean up and organize sourceforge.net site.

Steve.

> And not necessarily in that order.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] UTF-8 0xA0

[Gea-Suan L. <gs...@cc...>]

Hello,

  I use UTF-8 (for Traditional Chinese) as phpwiki charset, and there
are some problem:

  When phpwiki translates data to html, char 0xA0 will translate to
space (0x20).

  You may see the html source code in http://wiki.abpe.org/index.php/Sand=
Box :

00000f60  6e 61 62 6c 65 20 62 6f  74 74 6f 6d 22 3e 55 54  |nable bottom=
">UT|
00000f70  46 2d 38 20 e9 20 81 e9  9d a2 e6 b8 ac e8 a9 a6  |F-8 ?.?=A2=E6=
=B8=AC=E8=A9=A6|
00000f80  3c 2f 70 3e 0a 3c 2f 64  69 76 3e 0a 0a 3c 64 69  |</p>.</div>.=
.<di|

  and the original statement:

00000000  55 54 46 2d 38 20 e9 a0  81 e9 9d a2 e6 b8 ac e8  |UTF-8 ?.?=A2=
=E6=B8=AC=E8|
00000010  a9 a6                                             |=A9=A6|

--=20
* Gea-Suan Lin  (public key: http://ccreader.nctu.edu.tw/~gslin/key.txt)
* If you cannot convince them, confuse them.           -- Harry S Truman

[Phpwiki-talk] Installer Patch, Slim!

[electron <ele...@mg...>]

Here is the installer patch slimmed a bit without WikiSettings. This is safe
to include with 1.3.8. Nothing new, just cutting the bloat.

Updated the patches in the Tracker on SF as well.

Remove .gz extension and unzip. SF is blocking .zip extensions.

-Jtp

Re: [Phpwiki-talk] Ready for 1.3.8 ?

[John K. <li...@ke...>]

At 12:05 am +0100 24/2/04, Reini Urban wrote:
>Are we ready for the intermediate 1.3.8 release?

Wow - phpwiki's looking better all the time.

Great work guys :)

John.

RE: [Phpwiki-talk] Ready for 1.3.8 ?

[electron <ele...@mg...>]

To be done for 1.4.0:
* improve WikiAdminSetAcl, test PagePerms.
* implement paging for long lists:
     requires ->_backend->get_num_pages(),
     and enable the limit support in PageList
     just display prev + next buttons
* fix minor dumping problems.
* use lib/removepage for WikiAdminRemove
* check the sf.net patches and bug submssions.

My additions:

* Trim WikiUserNew so its not calling itself for upgrading. Possibly split
it to a WikiAuth folder/backend style ala WikiDB
* Move Admin/PW out index.php and into the DB. Create a "superuser" group.
* Rip out any place except WikiDB where we are checking DBParams for dbtype
(breaks portability)
* Move diff.php to a plugin and add some requested features. (colorization)
* Native XML dumping. Create a wiki schema if none exists.
* Clean UserPreferences.tmpl into the plugin.
* Try and make more plugins use templating.
* Touch as many todos and fixmes as possible.
* More dynamic configuration and installer stuff.
* Update Doc, Doc Doc...and more Doc!
* Consider a better translation system.
* Clean up and organize sourceforge.net site.

And not necessarily in that order.


New Features:
* The long-awaited WikiUserNew class,
   a OOP rewrite of the marginally enabled auth code, which does:

   * optional external user authentification against databases,
     LDAP, IMAP and Files, in spirit to libnss and linux PAM.
     See doc/README.phpwiki-auth
   * optionally read and store user preferences in a database. (not
     in cookies or the users homepage)

[Phpwiki-talk] Release hold: [Fwd: Fatal Error on zip upload]

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

Steve,
Another show stopper in private email.
Please hold the release until we fix this fatal bug with "Upload File"...
I have to stop for this night now, back again tomorrow, in about 12hrs.

And please add the new WikiPoll plugin to the Release Notes.
   WikiPoll is stable, just the admin functionality is missing,
   which is not a must. (view and reset statistics)

...
* New other plugins:
   WikiPoll: Configurable polls
...
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] Ready for 1.3.8 ?

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

Reini Urban wrote:

> Are we ready for the intermediate 1.3.8 release?


> I wrote a ReleaseNote, we still have to change the src to disable 
> DEBUG and the version number.
>
> Steve, if you make the release,
> please change the version to 1.3.8, disable DEBUG, and tag the sources.


Let me join malcolmr in saying:

1. PhpWiki has great potential.
2. Releasing something stable is good.

Also, I would really like to use some of the things in 1.3.8, e.g. 
strong user authentication.

I know people asking you to release without doing any work can be 
irritating, but you have to take it in the spirit given: you have an 
attentive user base.

Dan

[Phpwiki-talk] Tables

[Alessandro V. <av...@sc...>]

I am writing:

aaa |
    bbb
    ccc

And this is what I get: 
http://www.scdi.org/~avernet/misc/phpwiki-table.png

I expected to have the "ccc" in a new cell below "bbb", and have the 
"aaa" cover both "bbb" and "ccc" (i.e. rowspan=2). Am I doing 
something wrong?

Alex

Re: [Phpwiki-talk] Installer, Phase 2.

[Stan B. <sb...@po...>]

Is this patch by electron included in what will be 1.3.8 or not?=20

electron wrote:

>Big Patch here, last patch was broke. All files are included this time.
>Download a CVS version, patch it and run install.php. Should end up with=
 a
>configured wiki rather quickly.
>
>Too big to attach, so it's here:
>http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D900056&grou=
p_id=3D612
>1&atid=3D306121
>
>1) Working Installer for mysql and ADODB. More support to come, this
>installer uses regex on index.php.=20
>
>2) Most of the ugly defines are replaced with Global Variables. No more
>tinkering with index.php! PhpWiki is now a bit more dynamic which leads =
to:
>
>3) WikiSettings Plugin! Configure your wiki on the fly. Its ugly but it
>works. This will be smoothed out in the next Phase.=20
>
>
>Most of the previous defines are now stored as metadata of "PhpWiki".=20
>
>Enjoy the fat filesize, it's a big patch. (Some bloat due to postnuke
>installer)=20
>
>Phase 3 will move the doc in index.php to WikiSettings.
>
>Phase 4 will rewrite installation docs.
>
>Phase 5 will add more support to the installer and clean that up a bit.
>
>-Jtp
>
>Who do I talk to to join the team? I'd like CVS access...
>
>
>
>
>
>
>
>
>-------------------------------------------------------
>SF.Net is sponsored by: Speed Start Your Linux Apps Now.
>Build and deploy apps & Web services for Linux with
>a free DVD software kit from IBM. Click Now!
>http://ads.osdn.com/?ad_id=1356&alloc_id438&op=CCk
>_______________________________________________
>Phpwiki-talk mailing list
>Php...@li...
>https://lists.sourceforge.net/lists/listinfo/phpwiki-talk
>
>
> =20
>

[Phpwiki-talk] Ready for 1.3.8 ?

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

Are we ready for the intermediate 1.3.8 release?

The only issues are longstanding minor problems with serial dumps on 
windows only, but all other show stoppers has been been fixed to my 
knowledge.

I leave PagePerm's as it is now. You can change it internally, but the 
interface has to be improved, and is not tested enough. This should work 
for 1.4.0

I wrote a ReleaseNote, we still have to change the src to disable DEBUG 
and the version number.

Steve, if you make the release,
please change the version to 1.3.8, disable DEBUG, and tag the sources.

To be done for 1.4.0:
* improve WikiAdminSetAcl, test PagePerms.
* implement paging for long lists:
     requires ->_backend->get_num_pages(),
     and enable the limit support in PageList
     just display prev + next buttons
* fix minor dumping problems.
* use lib/removepage for WikiAdminRemove
* check the sf.net patches and bug submssions.


ReleaseNote for 1.3.8:

This is the first release with the new WikiUser class and
page permissions. Full page permission support will be enabled
in the upcoming 1.4.0 release.

New Features:
* The long-awaited WikiUserNew class,
   a OOP rewrite of the marginally enabled auth code, which does:

   * optional external user authentification against databases,
     LDAP, IMAP and Files, in spirit to libnss and linux PAM.
     See doc/README.phpwiki-auth
   * optionally read and store user preferences in a database. (not
     in cookies or the users homepage)

* New PagePerm class, Solaris/Windows-style ACL for stricter
   permissions per page. Translates original permissions
   to default ACL's. (cannot be managed yet, => 1.4.0)
* Minor Pear DB update from Pear.
* PageList sortable by pagename, mtime and hits.
   Working against paging support for longer lists (limit arg).
   New layout for such pagelists (grid-style)
* New WikiAdmin plugins to administrate selectable pages
   ("Page Explorer"), for Rename, Search & Replace.
* New other plugins:
   UpLoad: Basic UpLoad support by a special Upload: interwiki map
     by NathanGass <ga...@io...>, ReiniUrban <ru...@x-...> and
     qubit <rt...@da...>
   IncludeSiteMap: A combination of IncludePage and SiteMap
   RichTable: Allow rich formatting in table cells, See RichTablePlugin
   by Sameer D. Sahasrabuddhe
* Basic Japanese language support (no pgsrc yet),
   by Tadashi Jokagi <web...@el...>
* PhpWiki as PostNuke module improved, by Jason Potkanski (electrawn)
* Allow inlining of images from a InterWiki url, for Upload support
      * [Upload:my_image.gif] inlines the image,
      * Upload:my_image.gif shows a plain inter-wiki link,
      * [what a pic|Upload:my_image.gif] shows a named inter-wiki
         link to the gif
      * [Upload:my_image.gif|what a pic] shows a inlined image
         linked to the page "what a pic"
* New WikiGroup class enabled with the backends:
     NONE, WIKIPAGE, DB, FILE, LDAP
   (needed for page permissions in 1.4.0)

Internally:
* a session holds more user information than before.
* htmlarea3 was tested. Seems to be too complicated to fit
   into the current usage policy. Only HTML can be written back from the
   textarea, and a HTML => Wiki format converter seems to be hard
   to write, esp. full roundtrips. Partial support (HTML PageType)
   seems to be against PhpWiki spirit. Use Guiki instead for now.
* fpdf was tested to support PDF dumps (not yet enabled),
* A SpellCheck feature was tested (not yet enabled),
* moved interwiki.php code to PageType.php
* internal _AuthInfo plugin to see the current auth settings.
* intermediate InterWikiSearch revamp. (not yet working)
* working on a dynamic upgrader
   (update pgsrc, enable new features, update deprecated features, ...)
* working on a dynamic installer
   (initial work by electrawn for PostNuke)
* UserPreferences has some options enabled, which do not work yet
   (notify by email, email check)

Fixed Bugs:
* Revived WikiAdminSelect and WikiAdminRemove,
* Fixed XHTML dumps (wrong basepage, recursion detection),
* ADODB limit code

ReiniUrban <ru...@x-...>

Re: [Phpwiki-talk] Page Rename

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

Stan Berka schrieb:
> Thanks, Reini.  I have a general question.  Is there anywhere a list of 
> all plugins available?  At least stables ones?  I couldn't find it 
> anywhere.

See the PluginManager page for all your plugins (dynamic).

The new pgsrc/WikiPlugin page is also updated, with the docs you 
requested and the static list of all supported plugings.

If you have no PluginManager page, create one with this line:
<?plugin PluginManager?>
or get it from CVS:

http://cvs.sourceforge.net/viewcvs.py/*checkout*/phpwiki/phpwiki/pgsrc/PluginManager?rev=1.2
http://cvs.sourceforge.net/viewcvs.py/*checkout*/phpwiki/phpwiki/pgsrc/WikiPlugin?rev=1.9

Unstable is currently only WikiAdminSetAcl and WikiAdminChmod. (These 
are only for 1.4.0)

> Reini Urban wrote:
>> Stan Berka schrieb:
>>
>>> I saw your note about the work in progress on this plugin.  What is 
>>> the status?
>>
>> WikiAdminRename, WikiAdminRemove and WikiAdminSearchReplace work fine 
>> for me. Now also with WikiAdminSelect again.
>>
>> WikiAdminChmod is in the works.
>>
>> WikiAdminRemove currently does a "full" remove, which might be the 
>> wrong thing. RecentChanges is not aware of it right now. This might be 
>> changed to a Revision remove only.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] Page Rename

[Stan B. <sb...@po...>]

Thanks, Reini.  I have a general question.  Is there anywhere a list of 
all plugins available?  At least stables ones?  I couldn't find it anywhere.

Reini Urban wrote:

> Stan Berka schrieb:
>
>> I saw your note about the work in progress on this plugin.  What is 
>> the status?
>
>
> WikiAdminRename, WikiAdminRemove and WikiAdminSearchReplace work fine 
> for me. Now also with WikiAdminSelect again.
>
> WikiAdminChmod is in the works.
>
> WikiAdminRemove currently does a "full" remove, which might be the 
> wrong thing. RecentChanges is not aware of it right now. This might be 
> changed to a Revision remove only.

[Phpwiki-talk] Where are section headings defined?

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

Hi,

Is InlineParser.php where section headings (!, !!, !!!) get handled? 

Is there any way to have a plugin alter (extend) the action taken when the
section heading is output, or does that require adding code to base files
(such as InlineParser)?

What I would like to do is either have any page toggleable so that all
section headings are of an extended type, or else define a parallel set of
codes (some other character than !) which produce this second sort of
heading. The difference in this sort of heading is that each one would be
accompanied by a link to a subpage for comments on that section. Then I want
to present an option to "unfold" these individual subpages (via a variation
on the current UnfoldSubpages.php that just goes for a single subpage) into
right-aligned half-page-width tables starting at each section head. So each
section head would alternately be accompanied by a "comment" link, or by a
table on the right showing any existing comments as well as an "additional
comment" link.

I'm unclear whether the plugin architecture is rich enough to do this or
whether I just need to hack PhpWiki's base files - which looks like it
should be fairly simple once I can decipher just how those section headings
get mangled. I'd rather make a proper plugin of it if that's possible for
action on the level of the whole page, rather than just - like the plugins
I've looked at so far - in a single spot on the page given over to the
plugin.

Thanks for any advice. The code is impressively concise, it's just taking a
bit of study to get up to speed on it.

Whit

[Phpwiki-talk] PageTrail patch-- ignorereloads

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

Folks,

Congrats on PhpWiki. Very cool. Below is a patch to PageTrail for 
'ignorereloads'. That is, if you reload the page, that duplicate page 
doesn't enter into the trail. The patch is against 1.3.7, but I think 
applies to the current CVS snapshot as well (I took a peek).

I would think one would want 'ignorereloads' on by default, but I left 
it false for backward compatibility.

Dan

-- 
Dan Frankowski    dfr...@cs...

 % cvs diff -bu PageTrail.php
Index: PageTrail.php
===================================================================
RCS file: /project/Grouplens/cvs-repository/phpwiki/lib/plugin/PageTrail.php,v
retrieving revision 1.1.1.1
diff -b -u -r1.1.1.1 PageTrail.php
--- PageTrail.php       29 Jan 2004 14:30:28 -0000      1.1.1.1
+++ PageTrail.php       23 Feb 2004 18:32:59 -0000
@@ -57,6 +57,7 @@
     function getDefaultArguments() {
         return array('numberlinks' => $this->def_numberlinks,
                      'invisible' => false,
+                     'ignorereloads' => false
                      );
     }

@@ -71,7 +72,10 @@
         $thispage = $request->getArg('pagename');
         $thiscookie = $request->cookies->get("Wiki_PageTrail");
         $Pages = explode(':', $thiscookie);
+        $lastpage = $Pages[0];
+        if (!$ignorereloads || ($thispage != $lastpage)) {
         array_unshift($Pages, $thispage);
+        }
         $request->cookies->set("Wiki_PageTrail", implode(':', $Pages));

         if (! $invisible) {

[Phpwiki-talk] Installer, Phase 2.

[electron <ele...@mg...>]

Big Patch here, last patch was broke. All files are included this time.
Download a CVS version, patch it and run install.php. Should end up with =
a
configured wiki rather quickly.

Too big to attach, so it's here:
http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D900056&group=
_id=3D612
1&atid=3D306121

1) Working Installer for mysql and ADODB. More support to come, this
installer uses regex on index.php.=20

2) Most of the ugly defines are replaced with Global Variables. No more
tinkering with index.php! PhpWiki is now a bit more dynamic which leads =
to:

3) WikiSettings Plugin! Configure your wiki on the fly. Its ugly but it
works. This will be smoothed out in the next Phase.=20


Most of the previous defines are now stored as metadata of "PhpWiki".=20

Enjoy the fat filesize, it's a big patch. (Some bloat due to postnuke
installer)=20

Phase 3 will move the doc in index.php to WikiSettings.

Phase 4 will rewrite installation docs.

Phase 5 will add more support to the installer and clean that up a bit.

-Jtp

Who do I talk to to join the team? I'd like CVS access...