phpwiki-talk

RE: [Phpwiki-talk] Diff as plugin

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

Addendum: 

Line 28: <?=$Sep?><?= Button(array('diffname' => $page->getName()),
_("Diff"), "Diff") ?>  

[Phpwiki-talk] Diff as plugin

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

This was easier than I thought. Diff now comes to you as a plugin!

With Diff as a plugin, it obeys templating. Now pnPhpWiki can move to =
beta.
I would also like to depreciate most actions and move them to plugins.
PageHistory ET all. Now a user can include a diff in a page. Diff could =
help
in some WikiFlameWars and other causes. :D


Installing:

Simply add a page Diff to your wiki, with <?plugin Diff ?>

Change line 28 in themes/default/templates/actionbar.tmpl to

<?=3D$Sep?><?=3D LinkURL(WikiUrl(_("Diff"), array( 'diffname' =3D>
$page->getName())), 'Diff') ?>

I'll leave it to the rest of you to form a button link.=20

-Jtp

I've stopped 7,393 spam messages. You can too!
One month FREE spam protection at www.cloudmark.com

Re: [Phpwiki-talk] "private" wiki

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

Malcolm Ross Kinsella Ryan schrieb:
> Some FAQs which I cannot find answers to on the Wiki:
> * I want to set up a "personal" wiki - ie publicly readable but only I can
> modify it. I know this isn't the "wiki-way", but it'd be terribly useful.
> Is PhpWiki up to this? 

sure, even better. individual permissions per page, user, group and 
action soon. it basically works but you cannot set the permissions yet.

easiest is to disallow editing and you as admin may edit alone.
REQUIRE_SIGNIN_BEFORE_EDIT = true
ALLOW_BOGO_LOGIN = false

simple HTTP AUTH (.htaccess) is also possible.

see http://phpwiki.sourceforge.net/phpwiki/UserAuthentication for the 
new system.

> * What software do I need to make the latest version run? 
>   What versions of PHP, MySQL etc?

any php > 4.0.6 I think and any database.
easiest is gdbm, db3 or mysql or flatfiles.

> * Is this mailing list archived?

see our sf.net projects site.
http://sourceforge.net/mail/?group_id=6121
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] "private" wiki

[<mal...@cs...>]

Hi all,

Some FAQs which I cannot find answers to on the Wiki:

* I want to set up a "personal" wiki - ie publicly readable but only I can
modify it. I know this isn't the "wiki-way", but it'd be terribly useful.
Is PhpWiki up to this? 

* What software do I need to make the latest version run? 
  What versions of PHP, MySQL etc?

* Is this mailing list archived?

Thanks,

Malcolm

-- 
Malcolm Ryan - mal...@cs... - http://www.cse.unsw.edu.au/~malcolmr/

                         "Blessed are the peacemakers,
                    for they will be called children of God."    -- Matt 5:9

[Phpwiki-talk] new feature - 'quiet' option for FullTextSearch

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

I have created a 'quiet' option for FullTextSearch, to allow one to 
display either the page name alone (a la BackLinks) or the context, 
as it currently does.

Just add
<?plugin FullTextSearch s="TermOne TermTwo -TermThree" quiet=1 ?>

and the result will be
* PageNameOne
* PageNameTwo
* PageNameThree
* PageNameFour

Just like BackLinks.

This is useful, because it allows a similar 'clean' presentation to 
BackLinks, with the added functionality of allowing multiple keywords.

Thanks,
Micki

a simple diff/code snippet is below:

lib/plugin/FullTextSearch.php

- add 'quiet' option

THE DIFF

44a45
>                       'quiet' => false,
64a66,67
>    if (!$quiet)
>  {
66c69,74
<
---
>  }
>  else
>  {
>          $list = HTML::ul();
>  }
>  ;
69a78,83
>  if ($quiet)
>      {
>              $list->pushContent(HTML::li(WikiLink($name)));
>  }
>  else
>  {
70a85,89
>
>  }
>  ;
>  if (!$quiet)
>  {
72a92,93
>  };
>        

THE FULL CODE

function getDefaultArguments() {
         return array('s'	=> false,
                      'noheader'	=> false,
                      'quiet'	=> false);
         // TODO: multiple page exclude
     }

     function run($dbi, $argstr, $request) {

         $args = $this->getArgs($argstr, $request);
         if (empty($args['s']))
             return '';

         extract($args);

         $query = new TextSearchQuery($s);
         $pages = $dbi->fullSearch($query);
         $lines = array();
         $hilight_re = $query->getHighlightRegexp();
         $count = 0;
         $found = 0;




if (!$quiet)
{
         $list = HTML::dl();
}
else
{
         $list = HTML::ul();
}
;
         while ($page = $pages->next()) {
             $count++;
             $name = $page->getName();
if ($quiet)
{
             $list->pushContent(HTML::li(WikiLink($name)));
}
else
{
             $list->pushContent(HTML::dt(WikiLink($name)));

}
;
if (!$quiet)
{
             if ($hilight_re)
                 $list->pushContent($this->showhits($page, $hilight_re));
};
         }
         if (!$list->getContent())
             $list->pushContent(HTML::dd(_("<no matches>")));

         if ($noheader)
             return $list;

         return HTML(HTML::p(fmt("Full text search results for '%s'", $s)),
                     $list);
     }

     function showhits($page, $hilight_re) {
         $current = $page->getCurrentRevision();
         $matches = preg_grep("/$hilight_re/i", $current->getContent());
         $html = array();
         foreach ($matches as $line) {
             $line = $this->highlight_line($line, $hilight_re);
             $html[] = HTML::dd(HTML::small(array('class' => 
'search-context'), $line));
         }
         return $html;
     }

     function highlight_line ($line, $hilight_re) {
         while (preg_match("/^(.*?)($hilight_re)/i", $line, $m)) {
             $line = substr($line, strlen($m[0]));
             $html[] = $m[1];    // prematch
             $html[] = HTML::strong(array('class' => 'search-term'), 
$m[2]); // match
         }
         $html[] = $line;        // postmatch
         return $html;
     }
};




-- 

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

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

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

"Paul Bloomfield" <pa...@pa...> writes:

>> why not use <br> for intentional linebreaks?
>
> The answer to that question, at least, is easy! It just isn't
> wiki. The first thing people like about a wiki is that what you type
> in the edit box appears on the web page, you don't need to use <p>
> or <br /> tags.  If you type a new line in the edit box, you want a
> new line on the web page, otherwise you wouldn't have typed it!

No, I always break my lines at around 60-70 characters when I edit my
wiki pages, just like I do when I edit code, emails or any other ASCII
text document.

Without those linebreaks the text in the textarea is more difficult to
real (IMHO) and more importantly: it also makes the diffs more
difficult to read because a one letter change in a huge paragraph
(consisting of only a single long line) makes you compare the old long
line with the new long line.  I know how the changes within a line are
highlighted, but I still don't want to see the rest of the huge line
in the diff.

-- 
Martin Geisler                       My GnuPG Key: 0xF7F6B57B

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

Re: [Phpwiki-talk] do we need a nice-n-shiny new set of themes?

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

Le mer 25/02/2004 =E0 01:45, Micki Kaufman a =E9crit :
> With a 'LeftMenu' and some glossy eye candy, we could look lots=20
> better than 'nuke...
>=20
> Important? Irrelevant?

You can do a LeftMenu in your template using the IncludePage plugin.

the menu will be the content of the section you'll include ...=20

I do this to add a left menu and a "what's new" box ...
--=20
Arnaud Fontaine
Jabber: sh...@ra...
ICQ: 3504789

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

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

The Mac OS/X problem with action=upload and zip files only
is most likely because of a bug in the ZipReader (gzinflate or gzopen) 
or some problem with the is_uploaded_file() handling with zip files.

It fails with an simple "Fatal PhpWiki Error
  No uploaded file to upload?"

The temp. workaround is to use action=loadfile which doesn't restore all 
versions, only the latest version.

Can some experienced developer with Mac OS X (Micki has php 4.3.2)
debug this? (Carsten?)

I would say that we should release 1.3.8 even with this known bug,
which existed before. It just should prominently noted.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] More features (me too)

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

Sascha Carlin schrieb:
> Reini Urban wrote:
>> And phpBB looks bad and is overkill.
> 'Looks bad': phpBB is template based, so if you don't like the look, go 
> ahead and change it.
> 
> 'Overkill': phpBB is one of the most mature forums out there with a 
> decent set of out-of-the-box features. Regarding using some of the phpBB 
> code for a threaded mode wiki page: yes, that would probably be 
> overkill, even if a stripped down phpBB contains not much more than some 
> 15 files plus templates.
> 
> Anyway, just _had_ to reply to this one.

:)

Somehow PhpWiki has to justify its code bloat :)
And if it's just a forum in one php page, with 80 other files sitting 
around.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] do we need a nice-n-shiny new set of themes?

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

With a 'LeftMenu' and some glossy eye candy, we could look lots 
better than 'nuke...

Important? Irrelevant?

Micki

At 3:55 PM -0800 2/24/04, php...@li... wrote:
>Message: 8
>Date: Wed, 25 Feb 2004 00:50:01 +0100
>From: Reini Urban <ru...@x-...>
>To: php...@li...
>Subject: [Phpwiki-talk] More features (me too)
>
><snip>
>Why this?
>PhpWiki is technically soo much better than postnuke, so it makes
>writing new modules here more fun than there. It just looks better
>there, admitted.
>And phpBB looks bad and is overkill.
>I won't mention phpnuke, this is a coding nightmare.
>--
>Reini Urban
>http://xarch.tu-graz.ac.at/home/rurban/


-- 

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

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

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

Nope, no joy.

I have the latest and on mac osx/php 4.3.2, and I'm still getting a 
fatal error on restoring.

Thanks,
Micki

At 3:55 PM -0800 2/24/04, php...@li... wrote:
>Message: 5
>Date: Tue, 24 Feb 2004 19:34:24 +0100
>From: Reini Urban <ru...@x-...>
>To: php...@li...
>Subject: Re: [Phpwiki-talk] Re: Fatal Error restoring from .zip file
>
>This is a multi-part message in MIME format.
>--------------010202090902010904060908
>Content-Type: text/plain; charset=us-ascii; format=flowed
>Content-Transfer-Encoding: 7bit
>
>Micki Kaufman schrieb:
>>  Unfortunately, after pulling down the latest build I'm still getting the
>>  bug. 'Fatal PhpWiki Error
>>  No uploaded file to upload? '.
>>
>>  Although is it possible your committed code isn't available for updating
>>  locally yet?
>
>loadsave.php -r1.88
>Request.php -r1.38
>should have fixed it.
>
>attached is a patch from the versions above for these two.
>--
>Reini Urban
>http://xarch.tu-graz.ac.at/home/rurban/
>


-- 

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

Re: [Phpwiki-talk] feature idea - TOC (de facto IncludeHeadings)

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

I would do it this way:

! any page content
<?plugin AnyPlugin ?>
! more headers
<?plugin AutoToc ?>
nothing really important here at the footer

AutoToc sees the HTML tree from the previous plugin's and page content, 
and modifies it accordingly by recursively stepping through the tree.

This seems to be fun to code and the most painless solution.
(I am a former lisp programmer :)

Micki Kaufman schrieb:
> What if we approached it differently:
> 
> 1. The plugin is an include of the basepage, but only the headings. Each 
> is formatted with an anchor href, according to a nomenclature to be 
> decided (like perhaps h-1, h-11, h-111, h-2, h-22, h-23, h-3, h-4, 
> etc.). Since one recursive include is allowed, this should be possible 
> (except for TextFormattingRules).
> 
> 2. The page belowis rendered as usual, but the presence of the AutoToc 
> modifies the display so that the sections are rendered out with 
> invisible anchor tags, named using the exact same nomenclature as in 1.
> 
> This way you don't need two passes, or jscript.
> 
> A known limitation: any !'s above the plugin declaration would perhaps 
> not have anchors, since they'd be rendered before the appearance of the 
> declaration.
> 
> What do you think?
> Micki
> 
>> Message: 9
>> Date: Wed, 25 Feb 2004 00:53:29 +0100
>> From: Reini Urban <ru...@x-...>
>> To: php...@li...
>> Subject: Re: [Phpwiki-talk] feature idea - TOC (de facto IncludeHeadings)
>>
>> Micki Kaufman schrieb:
>>  > I frequently have use for a bunch of named links - to function like an
>>  > online table of contents.
>>  >
>>  > For an example, see the beginning of the latest build's
>>  > PhpWikiAdministration.
>>
>> <?plugin AutoToc jscript_hide=1 headers=1,2,3 ?>
>>
>> Yes, MoinMoin (I think) has a cool jscript based heading navigator.
>> The only problem is that such targets must provide the appropriate
>> <a name=""> tags and gyriations as in PhpWikiAdministration.
>>
>>  > Would be great to be able to insert a code like %%TOC%% or the
>>  > equivalent, and have a series of links display based on heading 1, 
>> 2 and
>>  > 3. Named links aren't as important here, because one can use the 
>> desired
>>  > text for the headings themselves.
>> -- 
>> Reini Urban
>> http://xarch.tu-graz.ac.at/home/rurban/
> 
> 
> 


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

Re: [Phpwiki-talk] feature idea - TOC (de facto IncludeHeadings)

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

What if we approached it differently:

1. The plugin is an include of the basepage, but only the headings. 
Each is formatted with an anchor href, according to a nomenclature to 
be decided (like perhaps h-1, h-11, h-111, h-2, h-22, h-23, h-3, h-4, 
etc.). Since one recursive include is allowed, this should be 
possible (except for TextFormattingRules).

2. The page belowis rendered as usual, but the presence of the 
AutoToc modifies the display so that the sections are rendered out 
with invisible anchor tags, named using the exact same nomenclature 
as in 1.

This way you don't need two passes, or jscript.

A known limitation: any !'s above the plugin declaration would 
perhaps not have anchors, since they'd be rendered before the 
appearance of the declaration.

What do you think?
Micki

>Message: 9
>Date: Wed, 25 Feb 2004 00:53:29 +0100
>From: Reini Urban <ru...@x-...>
>To: php...@li...
>Subject: Re: [Phpwiki-talk] feature idea - TOC (de facto IncludeHeadings)
>
>Micki Kaufman schrieb:
>  > I frequently have use for a bunch of named links - to function like an
>  > online table of contents.
>  >
>  > For an example, see the beginning of the latest build's
>  > PhpWikiAdministration.
>
><?plugin AutoToc jscript_hide=1 headers=1,2,3 ?>
>
>Yes, MoinMoin (I think) has a cool jscript based heading navigator.
>The only problem is that such targets must provide the appropriate
><a name=""> tags and gyriations as in PhpWikiAdministration.
>
>  > Would be great to be able to insert a code like %%TOC%% or the
>  > equivalent, and have a series of links display based on heading 1, 2 and
>  > 3. Named links aren't as important here, because one can use the desired
>  > text for the headings themselves.
>--
>Reini Urban
>http://xarch.tu-graz.ac.at/home/rurban/


-- 

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

[Phpwiki-talk] SplitWikiWords - single-letter words and regex

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

Hi there!

Can anyone suggest a regex mod to make
HowToAddAPage

split properly to:

How To Add A Page

instead of what happens:

How To AddA Page

Coincidentally, I'm currently learning regex, but I thought if folks 
have already encountered this that there might be some info out there.

Thanks,
Micki
-- 

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

Re: [Phpwiki-talk] feature idea - TOC (de facto IncludeHeadings)

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

Micki Kaufman schrieb:
> I frequently have use for a bunch of named links - to function like an 
> online table of contents.
> 
> For an example, see the beginning of the latest build's 
> PhpWikiAdministration.

<?plugin AutoToc jscript_hide=1 headers=1,2,3 ?>

Yes, MoinMoin (I think) has a cool jscript based heading navigator.
The only problem is that such targets must provide the appropriate
<a name=""> tags and gyriations as in PhpWikiAdministration.

> Would be great to be able to insert a code like %%TOC%% or the 
> equivalent, and have a series of links display based on heading 1, 2 and 
> 3. Named links aren't as important here, because one can use the desired 
> text for the headings themselves.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] More features (me too)

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

I seem to like postnuke's features.

Here's a list of plugins I'm currently working on:

WhoIsOnline mode=summary|detail
* Show summary information of the current user sessions.
  (useful only with USE_DB_SESSION)
* Formatting and idea borrowed from postnuke.

WikiForum
* This plugin handles a threaded list of comments/news associated with a
* particular page (one page per topic) and provides an input form for
* adding new comments.
*
*   <?plugin WikiForum info=title,replies,author,views,lastpost ?>
*
* To provide information for the MainForum page (CategoryForum)
* summary output mode is possible.
*
*   <?plugin WikiForum page=SubTopic1
*            mode=summary info=forum,topics,posts,last_post ?>
*   <?plugin WikiForum page=SubTopic2
*             mode=summary info=forum,topics,posts,last_post ?>

It totally looks like postnuke, but is template based.
WikiPoll will be converted to templates also soon.

Why this?
PhpWiki is technically soo much better than postnuke, so it makes 
writing new modules here more fun than there. It just looks better 
there, admitted.
And phpBB looks bad and is overkill.
I won't mention phpnuke, this is a coding nightmare.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

[Phpwiki-talk] Re: Phpwiki-talk digest, Vol 1 #918 - 14 msgs

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

>The only problem/feature is that conflicts are skipped and not overwritten.
>--
>Reini Urban

Hi Reini:

The patch Carsten sent me should allow an 'upload and overwrite' 
function, which will retrieve and restore ALL page versions, not just 
the first.

I'd consider the current behavior a bug, since it only loads the 
first version of the page, not the latest - if it only loaded the 
latest it would only be a 'functionality gap', in my opinion.

I attached the patch below for your review. Rock on!

Thanks,
Micki



PATCH

>Admittedly the loadsave functions do need some more work. In the 
>mean time, here's a quick hack I whipped up to do exactly what you 
>need.
>
>Add this line to PhpWikiAdministration:

  <?plugin WikiForm action=upload buttontext="Upload & OVERWRITE" overwrite=1 ?>

>Patch lib/plugin/WikiForm.php with the enclosed patch.
>
>It should go without saying, but here it is anyway: BE CAREFUL you 
>don't do something silly like upload the wrong file! :)
>
>Carsten

Index: WikiForm.php
===================================================================
RCS file: /cvsroot/phpwiki/phpwiki/lib/plugin/WikiForm.php,v
retrieving revision 1.9
diff -U2 -r1.9 WikiForm.php
--- WikiForm.php	26 Feb 2003 01:56:52 -0000	1.9
+++ WikiForm.php	7 Dec 2003 17:08:54 -0000
@@ -43,4 +43,5 @@
                       'default' => false,
                       'buttontext' => false,
+                     'overwrite' => false, // HACK ALERT
                       'size' => 50);
      }
@@ -107,4 +108,8 @@

          $input = HTML::input($input);
+        if ($overwrite)
+            $input->pushContent(HTML::input(array('name' => 'overwrite',
+                                                  'value' =>  1,
+                                                  'type'  => 'hidden')));
          $input->addTooltip($buttontext);
          $button = Button('submit:', $buttontext, $class);



-- 

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

[Phpwiki-talk] feature idea - TOC (de facto IncludeHeadings)

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

Hey there.

Here's an idea.

I frequently have use for a bunch of named links - to function like 
an online table of contents.

For an example, see the beginning of the latest build's PhpWikiAdministration.

Would be great to be able to insert a code like %%TOC%% or the 
equivalent, and have a series of links display based on heading 1, 2 
and 3. Named links aren't as important here, because one can use the 
desired text for the headings themselves.

I had brainstormed a bit with Joe Edelman about the use of 
IncludePage, to provide what is in essence an 'IncludeHeadings' TOC.

What do you folks think?

Micki
-- 

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

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

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

Micki Kaufman schrieb:
> Unfortunately, after pulling down the latest build I'm still getting the 
> bug. 'Fatal PhpWiki Error
> No uploaded file to upload? '.
> 
> Although is it possible your committed code isn't available for updating 
> locally yet?

loadsave.php -r1.88
Request.php -r1.38
should have fixed it.

attached is a patch from the versions above for these two.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

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

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

> why not use <br> for intentional linebreaks?

The answer to that question, at least, is easy! It just isn't wiki. The
first thing people like about a wiki is that what you type in the edit
box appears on the web page, you don't need to use <p> or <br /> tags.
If you type a new line in the edit box, you want a new line on the web
page, otherwise you wouldn't have typed it!

Please do not be offended, but you may as well say why not use <a href="
for links!


> we wanted to overcome wrapped text problems in certain Envoriments

The wrap="virtual" property which is being set in <textarea /> sorts out
most browsers surely? You could try overflow: auto; in the CSS as well
(I have not tested this and it won't work for older browsers). If this
doesn't work, the answer must be an 'I am using a stupid browser'
checkbox on the edit form for the remaining problems, rather than nerf
everybody. Or are you talking about e-mail submission of wiki pages?
Cool! Again though that is a special case that can be pre-parsed to make
it work.

Paul

Re: [Phpwiki-talk] Ready for 1.3.8 ?

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

Arnaud Fontaine schrieb:
> Make a "format" directory where you store plugins to handle ouput
> format.
> 
> Then it will be easier to add new output formats without hacking the
> core of phpwiki.

This doesn't fit into our plugin architecture.

It would fit to PageType subclassing, where we define the format method 
for various types.

Output formats are:
   (divided into screen and filedump. printer via special
    printer stylesheet)
   WikiHTML, DumpHTML, XML (not yet), PDF (not yet), MIME, plain file,
   RSS

Now used special PageTypes are:
   wikitext (=WikiHTML), interwikimap, blog,
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

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

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

Hi Reini.

Unfortunately, after pulling down the latest build I'm still getting 
the bug. 'Fatal PhpWiki Error
No uploaded file to upload? '.

Although is it possible your committed code isn't available for 
updating locally yet?

Thanks,
Micki

>Message: 12
>Date: Tue, 24 Feb 2004 18:27:27 +0100
>From: Reini Urban <ru...@x-...>
>To: php...@li...
>Subject: Re: [Phpwiki-talk] Re: Fatal Error restoring from .zip file
>
>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/
>


-- 

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

Re: [Phpwiki-talk] Ready for 1.3.8 ?

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

Steve,
I think we are ready now for 1.3.8.

I just wrote another simple plugin to avoid caching of certain dynamic 
plugins, called NoCache. This should be added to ReleaseNotes also. See 
below.

Reini Urban schrieb:
> 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.

fixed.

> 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

     Nocache: Prevent certain pages from caching.
     WikiPoll: Simple configurable poll

> * 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

* Fixed "\r\r\n" EOL on serial dumps on Windows servers.
* Workaround for uploading problems on certain environments.
* POST->GET args handling improved to get rid of warnings (sortby
   buttons and others)

> ReiniUrban <ru...@x-...>
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] Email Notification

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

Micki Kaufman schrieb:
> 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.

Sure for 1.4.0, but not for 1.3.8.

I reenabled it to help in testing, but it's not yet implemented.
Similar to PagePermissions.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] Ready for 1.3.8 ?

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

Yet another suggestion :

Make a "format" directory where you store plugins to handle ouput
format.

Then it will be easier to add new output formats without hacking the
core of phpwiki.
-- 
Arnaud Fontaine
Jabber: sh...@ra...
ICQ: 3504789