phpwiki-talk

RE: [Phpwiki-talk] PhpWiki markup engine bug

[Frank S. <fra...@rn...>]

> >>> "sb...@po..." 11/12/03 22:19 >>>
> 
> Hi,
> Try this snippet in the SandBox.  It shows an incorrect empty line 
> before the second level item.  It does not, however, if there are no
> empty lines between items of the first level list.  Can it be 
> corrected?
> 
>  >>>
> *  A first level list item and this time it's a very very very very
>     very very very very very very very very very very very
>     very long line.
>     *  A second level
>     *  Another item on the 2nd level
> *  Back to the first level again.
> 
> *  Another item.  Note there is an empty line before it.
>  >>>

I'm running 1.3.4pre, and I don't see a blank line before it, unless I'm
missing something. Look at http://roke.angband.za.org/frank/SandBox. Is
this the layout you were expecting?

frank

Re: [Phpwiki-talk] phpWebNotes

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

At 12:38 pm +0000 11/11/03, John Kershaw wrote:
>I'm interested in the idea of adding phpWebNotes to some of my 
>phpwiki sites, since visitors who aren't brave enough to 'edit' a 
>page are often confident enough to add a comment to a page, which 
>could then be translated into page content if relevant.

I've now got it working - seems like there was a problem with both 
systems wanting to connect to different databases. I incorporated the 
phpWebNotes tables into the wiki database and now all is working 
beautifully:

http://www.kershaw.org/library/HomePage

John.
-- 
-------------------------------------------
    01274 581519  / 07944 755613
jo...@ke... / http://www.kershaw.org
  AOL johnkershaw / Y! & MSN john_m_kershaw

[Phpwiki-talk] PhpWiki markup engine bug

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

Hi,
Try this snippet in the SandBox.  It shows an incorrect empty line 
before the second level item.  It does not, however, if there are no
empty lines between items of the first level list.  Can it be corrected?

 >>>
*  A first level list item and this time it's a very very very very
    very very very very very very very very very very very
    very long line.
    *  A second level
    *  Another item on the 2nd level
*  Back to the first level again.

*  Another item.  Note there is an empty line before it.
 >>>

Stan Berka

Re: [work] Re: [sf] Re: [Phpwiki-talk] Patch for warnings

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

I had this issue with my first installation of PhpWiki (Win2000, eng, 
PHP 4.3.2, PhpWiki  1.3.3).  And I had to do modify formatDate function 
to get the day displayed.  However, the second and 3rd installations, 
(similar environment but PhpWiki 1.3.4) didn't have this problem.

Stan Berka

 >>>>>
On Monday, March 10, 2003, at 07:37  am, Andrey Cherezov wrote:

Next issue. I'm using PhpWiki under Windows 2000 more than year,
and in each PhpWiki version I'm forced to change the default
date/time format, because defaults
  $Theme->setDateFormat("%A, %B %e, %Y");
  $Theme->setTimeFormat("%l:%M:%S %p");
not working under Windows:
%e not prints day of month, and %l prints nothing (%l is not
documented in PHP at all). So, date/time show like this:
Last edited on Friday, March , 2003 :38:13 pm.
(PHP4.3.1/Windows2000/English)

Re: [work] Re: [Phpwiki-talk] Have to relogin after close the last browser

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

I'm using IE 6.0 for browsing and for Mozilla 1.2.1 for email.

OK!  I agree it must be that these cookies are not stored on disk on the 
desktop.  I guess that's what I expected.  That for certain period, or 
even indefinitly, browser would find the cookie stored in the browser's 
standard location.  It seems however, that these are cookies kept just 
in memory, by each process.  

Since it seems you experience the same behaviour, I'm satisfied.  Thanks!

Stan Berka

Norberto Meijome wrote:

> Session cookies expiry when you close your browser (we all agree on 
> that much ;-).
>
> I've just tested under WinXP Pro, PHPWiki authed against Active 
> Directory via LDAP, sessions kept in cookies:
> IE 6 : If you log in, and then do Ctrl-N (New Window off the one 
> opened), you are still logged in. If you launch a new IE from a 
> shortcut, you are NOT logged in.  Cookies are not shared across 
> processes.
>
> Mozilla: If you launch a new Moz browser from your shortcut, you still 
> appear logged in. Possibly Moz checks if you already have an instance 
> opened and then shares the session cookies. (i.e., u can't have 2 
> mozillas opened).
>
> I wouldn't say this is related to PHP cookies or PHPWiki related, 
> rather how session cookies behave differently in each browser.
>
> Regards,
> Beto
> PS: glad to see the project coming back to life!
>
> Carsten Klapp wrote:
>
>> Hi Stan,
>>
>> Actually I'm not sure how PHP itself or various browsers handle the 
>> session cookies generated by PHP, or what the official proper 
>> handling of session-based cookies is supposed to be.
>>
>> I've never run into this situation before, but then again I don't use 
>> Mozilla very often--except to test my CSS code--and I didn't take 
>> note how often I have to re-login again to a PhpWiki. It may simply 
>> be that this is the proper handling of cookies from the browser point 
>> of view: once the last window for a particular site has been closed, 
>> then the session has "ended" as far as cookie expirations go. (That 
>> is to say, I can't imagine how any PHP site could detect that the 
>> last browser window has been closed for a given site, it's probably a 
>> browser-cookie-expiry thing).
>>
>> Does the same happen with any other browsers?
>>
>> If not, I will try to look into why it happens only with Mozilla. (By 
>> your email headers I assume you are using Mozilla?) I have wanted to 
>> clean up the cookie code of PhpWiki a bit anyway... for autologins & 
>> imrpoved auto- preference recognition.
>>
>> Cheers,
>> Carsten
>>
>> On Tuesday, November 11, 2003, at 01:36  pm, Stanislaw Berka wrote:
>>
>>> Hi,
>>> I'm using PhpWiki as a daily weblog/scratch pad etc.  That is, among 
>>> other uses.  When I open the page and login, the login is remembered 
>>> unless I close all browsers.  If I do this, I have to relogin again.
>>>
>>> Is it how it should be or is there something wrong in my installation?
>>>
>>> Stan Berka,
>>> Pope & Talbot, Portland, OR
>>

RE: [sf] Re: [Phpwiki-talk] Patch for warnings

[Andrey C. <an...@ch...>]

> Would you send me the date/time format string you hopefully
> figured out
> for your own windows server? :) I will try to somehow, automatically
> integrate it into PhpWiki.

I'm using this format on the Windows server:
$Theme->setDateFormat("%d.%m.%Y");
$Theme->setTimeFormat("%H:%M:%S");

> > date/time format, because defaults
> >   $Theme->setDateFormat("%A, %B %e, %Y");
> >   $Theme->setTimeFormat("%l:%M:%S %p");
> > not working under Windows:
> > %e not prints day of month, and %l prints nothing (%l is not
> > documented in PHP at all). So, date/time show like this:
> > Last edited on Friday, March , 2003 :38:13 pm.
> > (PHP4.3.1/Windows2000/English)
> > See notes in http://www.php.net/manual/ru/function.strftime.php :
> > Not all conversion specifiers may be supported by your C
> library, in
> > which
> > case they will not be supported by PHP's strftime(). This
> means that
> > e.g.
> > %e, %T, %R and %D (there might be more) will not work on Windows.

Re: [sf] Re: [Phpwiki-talk] Patch for warnings

[Carsten K. <car...@ya...>]

Hi Andrey,

Sorry for the delay in replying.

* Actually, I made a mistake: there really should be an "!" in there:
  if (!defined("CHARSET")) define("CHARSET", "iso-8859-1");
If you have heavily modified your PhpWiki's index.php, it would be a 
good idea to make sure that CHARSET is also not being defined anywhere 
else.

Sorry if this caused any confusion.

Would you send me the date/time format string you hopefully figured out 
for your own windows server? :) I will try to somehow, automatically 
integrate it into PhpWiki.

Cheers,
Carsten

On Monday, March 10, 2003, at 07:37  am, Andrey Cherezov wrote:

>>> if (defined("CHARSET")) define("CHARSET", "iso-8859-1");
>> Okay, done.
>
> Thank you! There is my mistake - "defined" instead of "!defined".
>
> Next issue. I'm using PhpWiki under Windows 2000 more than year,
> and in each PhpWiki version I'm forced to change the default
> date/time format, because defaults
>   $Theme->setDateFormat("%A, %B %e, %Y");
>   $Theme->setTimeFormat("%l:%M:%S %p");
> not working under Windows:
> %e not prints day of month, and %l prints nothing (%l is not
> documented in PHP at all). So, date/time show like this:
> Last edited on Friday, March , 2003 :38:13 pm.
> (PHP4.3.1/Windows2000/English)
> See notes in http://www.php.net/manual/ru/function.strftime.php :
> Not all conversion specifiers may be supported by your C library, in 
> which
> case they will not be supported by PHP's strftime(). This means that 
> e.g.
> %e, %T, %R and %D (there might be more) will not work on Windows.
>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwiki-talk
>

Re: [Phpwiki-talk] Have to relogin after close the last browser

[Norberto M. <nu...@me...>]

Session cookies expiry when you close your browser (we all agree on that 
much ;-).

I've just tested under WinXP Pro, PHPWiki authed against Active 
Directory via LDAP, sessions kept in cookies:
IE 6 : If you log in, and then do Ctrl-N (New Window off the one 
opened), you are still logged in. If you launch a new IE from a 
shortcut, you are NOT logged in.  Cookies are not shared across processes.

Mozilla: If you launch a new Moz browser from your shortcut, you still 
appear logged in. Possibly Moz checks if you already have an instance 
opened and then shares the session cookies. (i.e., u can't have 2 
mozillas opened).

I wouldn't say this is related to PHP cookies or PHPWiki related, rather 
how session cookies behave differently in each browser.

Regards,
Beto
PS: glad to see the project coming back to life!

Carsten Klapp wrote:

> Hi Stan,
>
> Actually I'm not sure how PHP itself or various browsers handle the 
> session cookies generated by PHP, or what the official proper handling 
> of session-based cookies is supposed to be.
>
> I've never run into this situation before, but then again I don't use 
> Mozilla very often--except to test my CSS code--and I didn't take note 
> how often I have to re-login again to a PhpWiki. It may simply be that 
> this is the proper handling of cookies from the browser point of view: 
> once the last window for a particular site has been closed, then the 
> session has "ended" as far as cookie expirations go. (That is to say, 
> I can't imagine how any PHP site could detect that the last browser 
> window has been closed for a given site, it's probably a 
> browser-cookie-expiry thing).
>
> Does the same happen with any other browsers?
>
> If not, I will try to look into why it happens only with Mozilla. (By 
> your email headers I assume you are using Mozilla?) I have wanted to 
> clean up the cookie code of PhpWiki a bit anyway... for autologins & 
> imrpoved auto- preference recognition.
>
> Cheers,
> Carsten
>
> On Tuesday, November 11, 2003, at 01:36  pm, Stanislaw Berka wrote:
>
>> Hi,
>> I'm using PhpWiki as a daily weblog/scratch pad etc.  That is, among 
>> other uses.  When I open the page and login, the login is remembered 
>> unless I close all browsers.  If I do this, I have to relogin again.
>>
>> Is it how it should be or is there something wrong in my installation?
>>
>> Stan Berka,
>> Pope & Talbot, Portland, OR
>
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: ApacheCon 2003,
> 16-19 November in Las Vegas. Learn firsthand the latest
> developments in Apache, PHP, Perl, XML, Java, MySQL,
> WebDAV, and more! http://www.apachecon.com/
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwiki-talk

Re: [Phpwiki-talk] Have to relogin after close the last browser

[Carsten K. <car...@us...>]

Hi Stan,

Actually I'm not sure how PHP itself or various browsers handle the 
session cookies generated by PHP, or what the official proper handling 
of session-based cookies is supposed to be.

I've never run into this situation before, but then again I don't use 
Mozilla very often--except to test my CSS code--and I didn't take note 
how often I have to re-login again to a PhpWiki. It may simply be that 
this is the proper handling of cookies from the browser point of view: 
once the last window for a particular site has been closed, then the 
session has "ended" as far as cookie expirations go. (That is to say, I 
can't imagine how any PHP site could detect that the last browser 
window has been closed for a given site, it's probably a 
browser-cookie-expiry thing).

Does the same happen with any other browsers?

If not, I will try to look into why it happens only with Mozilla. (By 
your email headers I assume you are using Mozilla?) I have wanted to 
clean up the cookie code of PhpWiki a bit anyway... for autologins & 
imrpoved auto- preference recognition.

Cheers,
Carsten

On Tuesday, November 11, 2003, at 01:36  pm, Stanislaw Berka wrote:

> Hi,
> I'm using PhpWiki as a daily weblog/scratch pad etc.  That is, among 
> other uses.  When I open the page and login, the login is remembered 
> unless I close all browsers.  If I do this, I have to relogin again.
>
> Is it how it should be or is there something wrong in my installation?
>
> Stan Berka,
> Pope & Talbot, Portland, OR

Re: [Phpwiki-talk] Wiki spam, an emerging trend?

[Neale P. <ne...@wo...>]

Carsten Klapp <car...@us...> writes:

> Have you tried this setting in index.php? This might trip-up or at
> least slow down any automatic WikiSpamScripts, by forcing a (BOGO- or
> WikiWord- user-name) login first:
>
> if (!defined('ALLOW_BOGO_LOGIN')) define('ALLOW_BOGO_LOGIN', true);
> if (!defined('REQUIRE_SIGNIN_BEFORE_EDIT'))
> define('REQUIRE_SIGNIN_BEFORE_EDIT', true);

I haven't set that up yet, since it's just been this isolated incident.
Perhaps if wiki maintainers are diligent, the spammers will find that
such edits are pointless.  On the other hand, it would be pretty easy to
throw together a script that replaces every page in a wiki with an ad,
and that would be very difficult to clean up.  So we'll see.

> Maybe it would be a good idea to set these as the defaults in
> index.php for the next release? Any thoughts?

I'm not sure.  On the one hand, it gives you some security.  On the
other hand, it's in opposition to the whole idea of Wiki.  (Well, to my
idea of it, at least.)  In the end, it's probably inevitable that folks
will have to put passwords around their wikis, just like it was
inevitable that multi-user computer systems all got passwords
eventually.

So it's a tough call, and I don't envy you folks for having to make it
:}

Neale

Re: [Phpwiki-talk] Wiki spam, an emerging trend?

[Carsten K. <car...@us...>]

On Sunday, November 9, 2003, at 01:54  pm, Neale Pickett wrote:

> I got some spam on my wiki last night :<  It appears this fellow is  
> going
> through google to find PHPWiki-rendered pages, and inserting his little
> advertisement.  You can see the result here:
>
>   http://wiki.woozle.org/BuyingaNewComputer?action=diff&version=5
>
> Sure, it was easy to take out, but when someone writes a program to do
> this automatically, I guess we're all going to have to require
> authentication for edits, or spend large chunks of time removing ads.
>
>
> Weblog entry point:
>
>   wiki.woozle.org 202.156.2.138 - - [09/Nov/2003:00:00:05 -0800] "GET  
> /BuyingaNewComputer HTTP/1.1" 200 16099  
> "http://www.google.com.sg/ 
> search?q=computer+Page+Execution+took++Edit&hl=en&lr=&ie=UTF-8&oe=UTF- 
> 8&start=10&sa=N" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0;  
> .NET CLR 1.1.4322)"
>
>
> Neale
> (Please Cc me in replies)

Hi Neale,

This does indeed sound like a very disturbing trend, thanks for the  
heads-up.

Have you tried this setting in index.php? This might trip-up or at  
least slow down any automatic WikiSpamScripts, by forcing a (BOGO- or  
WikiWord- user-name) login first:

if (!defined('ALLOW_BOGO_LOGIN')) define('ALLOW_BOGO_LOGIN', true);
if (!defined('REQUIRE_SIGNIN_BEFORE_EDIT'))  
define('REQUIRE_SIGNIN_BEFORE_EDIT', true);


Maybe it would be a good idea to set these as the defaults in index.php  
for the next release? Any thoughts?


Carsten

[Phpwiki-talk] Have to relogin after close the last browser

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

Hi,
I'm using PhpWiki as a daily weblog/scratch pad etc.  That is, among 
other uses.  When I open the page and login, the login is remembered 
unless I close all browsers.  If I do this, I have to relogin again.

Is it how it should be or is there something wrong in my installation?

Stan Berka,
Pope & Talbot, Portland, OR

[Phpwiki-talk] Re: Phpwiki-talk digest, Vol 1 #805 - 9 msgs

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

This is very encouraging news. We've got a few large wiki sites in 
our software dev group, and phpwiki receiving this kind of renewed 
attention is quite confidence-inspiring.

In positioning the wiki as our 'Microsoft Office antidote', I've had 
the need/oppty to build a fully back-end pdf generator into our wiki 
(section structure becomes pdf bookmarks, toc, etc.), and I posted 
the info on the phpwiki site at
http://phpwiki.sourceforge.net/phpwiki/PhpWikiToDocBookAndPDF if 
anyone is interested in incorporating it into their environment.

Great work all, on 1.3.5... and here's to great things ahead!

Micki

>--__--__--
>
>Message: 2
>Date: Mon, 10 Nov 2003 12:49:01 +0100
>From: Reini Urban <ru...@x-...>
>To: aphid <me...@ap...>
>Cc: php...@li...
>Subject: Re: [Phpwiki-talk] 1.4 before Christmas
>
>  > Hm, any chance at external db user auth making it into 1.4?  That would
>>  like Christmas in December.. err.. you know what I mean.
>
>Yes, the chance is good, since I quit my dayjob which really exhausted
>me, and I have much more time now.
>
>I just need some weeks to setup my infrastructure to continue where I left.
>--
>Reini Urban
>http://xarch.tu-graz.ac.at/home/rurban/
>
>I should be able to get the group checking working too.
>
>jbw
>
>I hook my RSS reader (netnewswire for mac, feedreader for pc) up to the
>RecentEdits feed so I know more or less instantaneously when the wiki
>has been updated.
>
>a
>
>
>
>--__--__--
>
>Message: 7
>From: Steve Wainstead <sw...@pa...>
>Date: Mon, 10 Nov 2003 13:42:39 -0500
>To: php...@li...
>Subject: [Phpwiki-talk] 1.4 before Christmas plus 1.3.6, 1.3.7
>
>Then let's shoot for December 24th for 1.4. Goals:
>
>* documentation up to date, including pages for all PlugIns and up to
>date installation instructions (me)
>
>* external DB user auth, plus group checking (Reini and Joby)
>


-- 

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

[Phpwiki-talk] phpWebNotes

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

Hi,

I'm interested in the idea of adding phpWebNotes to some of my 
phpwiki sites, since visitors who aren't brave enough to 'edit' a 
page are often confident enough to add a comment to a page, which 
could then be translated into page content if relevant.

I have it working just fine for plain html/php pages, but not for 
wiki pages. I moved the initial require into the phpwiki/index.php 
file and left the pwn_head / pwn_body function calls in the template, 
but I get this error:

ERROR: QUERY FAILED: SELECT *, UNIX_TIMESTAMP(last_updated) as last_updated
FROM phpWN_page_table WHERE (page='HomePage') LIMIT 1

at http://www.kershaw.org/library/HomePage

I've tried 'faking' the page name to a page that *has* been indexed 
(the /otherkershaws.php) and got the same error, so I think the 
problem lies somewhere in the page_id checking routines.

Anybody successfully got this system working with phpwiki? It seems 
like an ideal pairing!

http://webnotes.sourceforge.net/

John.
-- 
-------------------------------------------
    01274 581519  / 07944 755613
jo...@ke... / http://www.kershaw.org
  AOL johnkershaw / Y! & MSN john_m_kershaw

[Phpwiki-talk] Plugin for musical scores

[Cheyenne <j.m...@10...>]

Hello,

I made  a small plugin  to typeset  musical scores in  a wiki. It  is an
extension to WikiPluginCached and uses ABC notation to enter the score.

You    can   have    more    information   about    ABC   notation    at
http://www.gre.ac.uk/~c.walshaw/abc/,  and about  the  plugin itself  at
http://10pouces.homelinux.net/phpwiki/index.php/AbcPlugin.

As it is GPL, feel free to use it, modify it...


=2D-=20
J=E9r=F4me Marrec

Montre-leur qu'il existe un autre langage
Montre-leur que tout commence par le partage
Montre-leur qu'il existe un autre langage
Tous citoyens du monde
    -- Freedom for King-Kong - L'impasse

Re: [Phpwiki-talk] 1.4 before Christmas plus 1.3.6, 1.3.7

[Zot O'C. <zo...@wh...>]

On Mon, 2003-11-10 at 10:42, Steve Wainstead wrote:
> Then let's shoot for December 24th for 1.4. Goals:
> 
> * documentation up to date, including pages for all PlugIns and up to 
> date installation instructions (me)
> 
> * external DB user auth, plus group checking (Reini and Joby)
> 
> It would be sweet if we had email notification by then, but I'm willing 
> to wait on the 1.5 branch to add that. 

If we cab have the basis for email notification, i.e. callouts to
function vs the hacks to editpage we have now.

My reasoning is that short term every edit is cool, but long term it is
spammish.  I do not need every edit user X made to 5 pages over a 10
minute period (40 emails).

I do see that this will need some time to develop.  If we can have two
functions that get called, something like:

CheckShouldWeDoEmailNotify(calling function, page, user) returns bool
EmailNotify(calling function, page, user, new content)

Then we can just put the hacks in the appropriate lib (perhaps its own
for now) and people can develop it conjunction with their other
processes (i.e. if they have a hack user base, then perhaps they have a
hacked email notify).




-- 
Zot O'Connor

http://www.ZotConsulting.com
http://www.WhiteKnightHackers.com

[Phpwiki-talk] 1.4 before Christmas plus 1.3.6, 1.3.7

[Steve W. <sw...@pa...>]

Then let's shoot for December 24th for 1.4. Goals:

* documentation up to date, including pages for all PlugIns and up to 
date installation instructions (me)

* external DB user auth, plus group checking (Reini and Joby)

It would be sweet if we had email notification by then, but I'm willing 
to wait on the 1.5 branch to add that. In the meantime, I plan on a 
release of 1.3.6 by November 15th, and 1.3.7 by December 15th; however 
I can fudge those dates by a day or two if someone needs it, or bugs 
pop up in testing that prevent PhpWiki from working at all.

~swain

On Nov 10, 2003, at 10:32 AM, Joby Walker wrote:

> Reini Urban wrote:
>> aphid schrieb:
>>> On Nov 9, 2003, at 11:53 AM, Steve Wainstead wrote:
>>>
>>>> I'd like to work on documentation and get the current code base 
>>>> released as 1.4 before Christmas.
>>>
>>>
>>>
>>> Hm, any chance at external db user auth making it into 1.4?  That 
>>> would like Christmas in December.. err.. you know what I mean.
>> Yes, the chance is good, since I quit my dayjob which really 
>> exhausted me, and I have much more time now.
>> I just need some weeks to setup my infrastructure to continue where I 
>> left.
>
> I should be able to get the group checking working too.
>
> jbw
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: ApacheCon 2003,
> 16-19 November in Las Vegas. Learn firsthand the latest
> developments in Apache, PHP, Perl, XML, Java, MySQL,
> WebDAV, and more! http://www.apachecon.com/
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwiki-talk
>

Re: [Phpwiki-talk] Wiki spam, an emerging trend?

[aphid <me...@ap...>]

On Nov 10, 2003, at 4:05 AM, Oliver Betz wrote:

>
> Ack. Another reason for some kind of user management/authentication.
>
> I'm also afraid about vandalism, spam, illegal contents etc.
>
> Having some small and not very active Wikis for small groups, there
> is no large community to check for changes, and sometimes I don't
> visit the pages for weeks.

I hook my RSS reader (netnewswire for mac, feedreader for pc) up to the 
RecentEdits feed so I know more or less instantaneously when the wiki 
has been updated.

a

Re: [Phpwiki-talk] 1.4 before Christmas

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

Reini Urban wrote:
> aphid schrieb:
> 
>> On Nov 9, 2003, at 11:53 AM, Steve Wainstead wrote:
>>
>>> I'd like to work on documentation and get the current code base 
>>> released as 1.4 before Christmas.
>>
>>
>>
>> Hm, any chance at external db user auth making it into 1.4?  That 
>> would like Christmas in December.. err.. you know what I mean.
> 
> 
> Yes, the chance is good, since I quit my dayjob which really exhausted 
> me, and I have much more time now.
> 
> I just need some weeks to setup my infrastructure to continue where I left.

I should be able to get the group checking working too.

jbw

Re: [Phpwiki-talk] Wiki spam, an emerging trend?

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

At 1:05 pm +0100 10/11/03, Oliver Betz wrote:
>  > First blogs, and now wikis. There ain't no justice.
>
>Ack. Another reason for some kind of user management/authentication.
>
>I'm also afraid about vandalism, spam, illegal contents etc.
>
>Having some small and not very active Wikis for small groups, there
>is no large community to check for changes, and sometimes I don't
>visit the pages for weeks.

I made a mod for 1.3.2 that I use on all my wiki installations. 
Whenever someone alters a page the server emails me the new page 
text, saying who changed it & adding a link to the diff page:
http://phpwiki.sourceforge.net/phpwiki/EmailNotificationHack

I just visited that page and note that some kind persons have updated 
it for 1.3.3

I find it a very useful security add-on, especially for my more open 
wiki sites - my sixth form college site took a beating a few weeks 
ago from a disgruntled student writing rude words on a dozen or so 
pages. Because I got immediate notification, I'd started reverting 
the changes to the first few pages before he'd even finished the 
later ones! As you can imagine, he gave up fairly promptly, seeing 
his clever alterations had all disappeared.

I also find it handy to monitor submissions from wiki novices who 
maybe haven't got their heads round either the syntax or the 
structure of the site - I can quickly amend their changes before 
anyone sees them.

Perhaps this idea might be included in the 1.4 distribution in some 
way? It gives people who've not encountered wiki before and feel a 
little nervous a reassuring safety blanket. In practice I find my 
wikis are rarely abused.

John.
-- 
-------------------------------------------
    01274 581519  / 07944 755613
jo...@ke... / http://www.kershaw.org
  AOL johnkershaw / Y! & MSN john_m_kershaw

Re: [Phpwiki-talk] Wiki spam, an emerging trend?

[Oliver B. <ob...@de...>]

Steve Wainstead wrote:

> First blogs, and now wikis. There ain't no justice.

Ack. Another reason for some kind of user management/authentication.

I'm also afraid about vandalism, spam, illegal contents etc.

Having some small and not very active Wikis for small groups, there 
is no large community to check for changes, and sometimes I don't 
visit the pages for weeks.

Oliver

Re: [Phpwiki-talk] 1.4 before Christmas

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

aphid schrieb:
> On Nov 9, 2003, at 11:53 AM, Steve Wainstead wrote:
> 
>> I'd like to work on documentation and get the current code base 
>> released as 1.4 before Christmas.
> 
> 
> Hm, any chance at external db user auth making it into 1.4?  That would 
> like Christmas in December.. err.. you know what I mean.

Yes, the chance is good, since I quit my dayjob which really exhausted 
me, and I have much more time now.

I just need some weeks to setup my infrastructure to continue where I left.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/

Re: [Phpwiki-talk] Wiki spam, an emerging trend?

[Steve W. <sw...@pa...>]

First blogs, and now wikis. There ain't no justice.

~swain

On Nov 9, 2003, at 1:54 PM, Neale Pickett wrote:

> I got some spam on my wiki last night :<  It appears this fellow is  
> going
> through google to find PHPWiki-rendered pages, and inserting his little
> advertisement.  You can see the result here:
>
>   http://wiki.woozle.org/BuyingaNewComputer?action=diff&version=5
>
> Sure, it was easy to take out, but when someone writes a program to do
> this automatically, I guess we're all going to have to require
> authentication for edits, or spend large chunks of time removing ads.
>
>
> Weblog entry point:
>
>   wiki.woozle.org 202.156.2.138 - - [09/Nov/2003:00:00:05 -0800] "GET  
> /BuyingaNewComputer HTTP/1.1" 200 16099  
> "http://www.google.com.sg/search? 
> q=computer+Page+Execution+took++Edit&hl=en&lr=&ie=UTF-8&oe=UTF 
> -8&start=10&sa=N" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0;  
> .NET CLR 1.1.4322)"
>
>
> Neale
> (Please Cc me in replies)
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: ApacheCon 2003,
> 16-19 November in Las Vegas. Learn firsthand the latest
> developments in Apache, PHP, Perl, XML, Java, MySQL,
> WebDAV, and more! http://www.apachecon.com/
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwiki-talk
>

Re: [Phpwiki-talk] 1.4 before Christmas

[aphid <me...@ap...>]

On Nov 9, 2003, at 11:53 AM, Steve Wainstead wrote:

> I'd like to work on documentation and get the current code base 
> released as 1.4 before Christmas.

Hm, any chance at external db user auth making it into 1.4?  That would 
like Christmas in December.. err.. you know what I mean.

A

Re: [Phpwiki-talk] 1.4 before Christmas

[Carsten K. <car...@us...>]

On Sunday, November 9, 2003, at 02:53  pm, Steve Wainstead wrote:

> I'd like to work on documentation and get the current code base 
> released as 1.4 before Christmas. Reasons:
>
> * 1.2.2 is a really old base and noone should be burdened with 
> supporting it anymore
> * 1.3.5 is really stable
>
> I want to do an audit of the default pages, make sure all PlugIns are 
> documented and have examples, and make sure the installation 
> instructions are up to date.
>
> any thoughts?
>
> cheers,
> ~swain

Sounds fine by me, Steve!

Re: [Phpwiki-talk] Notes for 1.3.5
Offhand the list of changes looks complete to me.

I agree that 1.2 is old, and that 1.3.5 is stable enough for production 
use. With a little more documentation and some minor cleanups I see no 
major barriers to a 1.4 release by the year's end.

AFAIK most of the English pgsrc and strings (LC_MESSAGES) are up to 
date. The other languages however, are in need of many updates (to both 
locale/xx/pgsrc & LC_MESSAGES) due to all the changes we've seen in 
1.3.4 & 1.3.5.

Cheers,
Carsten