Re: Release Candidate available

On Monday 31 March 2008, Andreas Gohr wrote:
> This release adds several frontend improvements like an AJAXified
> index, a completely rewritten ACL manager, better RSS support, support
> for diffs between arbitrary revisions and much more. An XMLRPC
> interface was added and several improvements for plugin and template
> writers were made. Security measurements against CSRF attacks were
> introduced and several minor bugs have been fixed.
>
> More details are available at http://wiki.splitbrain.org/wiki:changes

the changes page says:
 - Better plugin support for modifying DokuWiki forms
	! removes *FORM_INJECTION events

i cant seem to find any docs on what this "better support" is or how to use 
it ... is there a wiki page that we could link to from this change notice ?  
i'm currently using one of those injection events, so i'll need to fix my 
plugin ...
-mike

Re: Release Candidate available

>
> the changes page says:
> - Better plugin support for modifying DokuWiki forms
> 	! removes *FORM_INJECTION events
>
> i cant seem to find any docs on what this "better support" is or how  
> to use
> it ... is there a wiki page that we could link to from this change  
> notice ?
> i'm currently using one of those injection events, so i'll need to  
> fix my
> plugin ...
> -mike

Form handling has been standardised, the events_list page at  
splitbrain details them.   The event will have a similar name,  
INJECTION being replaced by OUTPUT and the event data is now a  
Doku_Form object.  You'll find the class defined in 'inc/form.php'

This is the patch which made the change

http://dev.splitbrain.org/darcsweb/darcsweb.cgi?r=dokuwiki;a=commit;h=20070730215007-6942e-a0cf08197f939e224a2b28c40aec5431b118ea94.gz

- Chris
--

-- 
DokuWiki mailing list - more info at
http://wiki.splitbrain.org/wiki:mailinglist

Re: Release Candidate available

As always, "Thank You!" to everyone for the fine work in keeping DokuWiki my 
first choice of wiki tools.

Todd Augsburger
todd <at> rollerorgans.com
Roller Organs
www.rollerorgans.com

--

-- 
DokuWiki mailing list - more info at
http://wiki.splitbrain.org/wiki:mailinglist

Re: Release Candidate available

darcs changes 2008-04-01

Good Morning!

This are the darcs changes for DokuWiki committed
yesterday. Please test them and report bugs.

---------------------------------------------------------------------
Tue Apr  1 01:00:01 CEST 2008  Andreas Gohr <andi[at]splitbrain.org>
  tagged develsnap 2008-04-01

Tue Apr  1 00:38:07 CEST 2008  Andreas Gohr <andi[at]splitbrain.org>
  * Make sure there is never posted data on GET requests
  This is an addition to the previous patch to make sure there can not
  accidentally $data be passed on a GET request.

Tue Apr  1 00:10:16 CEST 2008  Andreas Gohr <andi[at]splitbrain.org>
  * fixed bug in HTTPClient breaking GET requests on certain servers
  The change of a parameter default made the HTTP client send data after
  sending the headers for a GET request.

Mon Mar 31 23:04:52 CEST 2008  Andreas Gohr <andi[at]splitbrain.org>
  * Slovak language update

Mon Mar 31 20:09:24 CEST 2008  Andreas Gohr <andi[at]splitbrain.org>
  tagged release candidate 2008-03-31

Mon Mar 31 20:06:49 CEST 2008  Andreas Gohr <andi[at]splitbrain.org>
  * release preparations

Mon Mar 31 11:54:02 CEST 2008  Michael Klier <chi[at]chimeric.de>
  * XMLRPC: getPage() should honour namespace templates

Mon Mar 31 19:53:53 CEST 2008  Andreas Gohr <andi[at]splitbrain.org>
  * fixed search engine referrer highlighting

Mon Mar 31 19:39:31 CEST 2008  Andreas Gohr <andi[at]splitbrain.org>
  * Italian language update
---------------------------------------------------------------------

Single patches can be downloaded from
http://dev.splitbrain.org/darcs/index.cgi/dokuwiki/?c=patches

Bye,
your darcs changelog mailer

--

-- 
DokuWiki mailing list - more info at
http://wiki.splitbrain.org/wiki:mailinglist

preventing commit mails for acl-locked pages

ive posted this a few times in the past, but cant seem to get anyone to 
notice :x

we have a [mostly] public wiki.  there are a few pages that we lock down for 
internal use only via acls and https (it has sensitive information).  as 
such, we dont want commit diffs being sent out to the public mailing list.

the solution is to just add an auth_aclcheck() to the top of notify() ... if 
the $id does not allow any access, then dont send an e-mail.

if (auth_aclcheck($id, '', '') == AUTH_NONE)
	return;

any thoughts on how to get this merged in some form ?
-mike

What are those "_dummy" files?

Hello,

i've found many _dummy files in /data directories of the darcs pull.
What is their purpose? I cant find any code using these files? are  
they darcs-specific?

Oliver Geisen
--

-- 
DokuWiki mailing list - more info at
http://wiki.splitbrain.org/wiki:mailinglist

Re: What are those "_dummy" files?

Oliver Geisen writes:

> Hello,
> 
> i've found many _dummy files in /data directories of the darcs pull.
> What is their purpose? I cant find any code using these files? are  
> they darcs-specific?

They make sure stupid Windows software will create the directories they are 
in. Some Windows unpackers won't create empty directories.

Andi

--

-- 
DokuWiki mailing list - more info at
http://wiki.splitbrain.org/wiki:mailinglist

Re: Multi-site installation

Hello,

i too tried to use dokuwiki as multi-site installation and came  
across some approches to do so.
Well, dokuwiki's concept layouts a single directory installation,  
which is fine for web-space provided application.
For providers (in any way, not just commercial, but also application  
delivery providers) would whish a better integration into the host  
system.
So because we are using Debian on many hosts, it's no wonder that  
dokuwiki must be "debianzied" to fit into that structure.
This means to break up the single-directory structure into different  
logical parts. This is also needed to be complaint to FHS and LSB.

STATIC INCLUDES AND LIBRARIES from /inc into /usr/share/dokuwiki/inc  
(also doku.php, index.php, feed.php) (root:root 755 should be used  
for each file here!)
INSTANCE DIRECTORY FOR EACH WIKI in /var/www/{INSTANCE}
DYNAMIC DATA from /data into /var/lib/dokuwiki/{INSTANCE}/data/  
(linked later from /var/www/{INSTANCE}/data)
CONFIGURATION FILES inside /conf into /etc/dokuwiki

I think doing it the Debian way is the right one, even for multi- 
installations, but i admitt that having all in one subdir is neat for  
small installations with restricted user rights. Therefore doing it  
the one or the other way is always 50% right and 50% wrong.
This is important because it's not only a question where to put the  
files in the local filesystem, but also what paths need to be  
configurable inside dokuwiki.
There must be structural changes to fit into both worlds. But i think  
it would be worth it, so one can decide how to install: as Single-Dir  
or Fully-Integrated.
This could maybe be handled by an installation-tool, which  
distributes the files to their places, depending on the installation  
type.

One big issue with multi-site installations is what to use globally  
(for all instances) and what locally (per instance), resp. which  
local parts may override global parts.
I can think of providing a dokuwiki instance by giving a user a  
service directory like
   /var/www/yourwiki/
containing:
   ./conf
   ./conf/acl.auth.php, users.auth.php, dokuwiki.php
   ./data
   ./doku.php
   ./feed.php
   ./index.php

This could be handled by a helper app, which creates a new instance  
by giving some information like "wikiname, admin user/password". It  
could also create an apache config for an virtual hosts.

Oliver Geisen
--

-- 
DokuWiki mailing list - more info at
http://wiki.splitbrain.org/wiki:mailinglist

Re: What are those "_dummy" files?

Am 01.04.2008 um 09:04 schrieb Andreas Gohr:
> Oliver Geisen writes:
>
>> Hello,
>> i've found many _dummy files in /data directories of the darcs pull.
>> What is their purpose? I cant find any code using these files?  
>> are  they darcs-specific?
>
> They make sure stupid Windows software will create the directories  
> they are in. Some Windows unpackers won't create empty directories.

I see. So it's safe for me to delete them.
Thank you!

Oliver Geisen

P.S.: I've wrote that into FAQ
--

-- 
DokuWiki mailing list - more info at
http://wiki.splitbrain.org/wiki:mailinglist