[ewiki] Re: Minor fix to Wikidump

Hi,

> For better compatibility with Mozilla it is useful to change line 88 of
> page_wikidump.php to: 
>       header("Content-Type: application/x-gzip");

Did the "app/x-tar" spawn any errors I should know about?  (I didn't have
any errors until now - but the "/x-tar" is actually in my /etc/mime.types)

>       Could you explain the meaning of EWIKI_PROTECTED_MODE_HIDING==2?  I
> noticed you added it in line 1013 (within ewiki_page_info()) and assume it
> must mean "paranoid, like Andy" but maybe you have a different definition or
> purpose for it?

Really, I initially liked to use another constant called someting like
EWIKI_PARANONID_ANDY_AUTHENTICATION_CHECKS for it, but then wrongly decided
to make some distincting within the _HIDING setting.
But yep, it is really for you - I changed it to this instead of your
suggestion, to not make the allowed and unallowed links distinctable by your
users - and after all I'd say, the clickable backlinks inside of the info/
screen are just visual nonsense, because the backlinks are already available
with the more easily accessible links/ action for ordinary users.

But there's another ==2 check now with EWIKI_PROTECTED_MODE - which is
useful to set, if someone wishes to use the ewiki_auth mode without loading
a permission plugin.

> Adding:
>   if (!ewiki_auth($id, $data, 'initialize', $ring=0, $request_auth=0)) {
> in ewiki_eventually_initialize() inside the first if (line 2648 in CVS
> 1.105) will add authentication and prevent accidental initialization.  I'm
> not sure quite how to remove the explicit ring, but perhaps it is ok for
> this kind of admin call?

Do you really feel this is neccessary? I mean this plugin is just run once,
and can safely be ignored afterwards, because it would never activate again
until the FrontPage was deleted again (I guess even this wouldn't work
anymore), and after all couldn't even overwrite any existing pages. I'd
really say this _initialize() function is harmless enough to completely
ignore the _PROTECTED_MODE here.

On the other hand I already thought about an external _initialization plugin
contained inside ./init-pages (with an integrated setup wizard or so),
because this function then was run just once, and everybody tweaking ewiki
(not using the default ewiki tarball dirtree and example layouts) could
probably manage to insert those initial pages herself. But I fear
overcomplicating things with such a temporary initialization-wizard-plugin
(and it would only free a few lines in the core script).
 
> > Not at all. I try to change code as soon as patches arrive. But of course
> Perhaps a bug tracker of some sort?  Do you have a preference?  Does anyone
> else on this list have suggestions?  With a bug tracker we would have a
> point of reference for issues like the binary plugin hook.

SourceForge of course also provides a bugtracker (I have crippled it to not
show up anymore). But as usual I don't like it - as I don't like the rest
of the slow and anti-lynx-devoted sourceforge site. But of course we could
use reintegrate it, or add a bugtracker as ewiki plugin or via spages. But
currently there are just to few BugReports (only lots of FeatureRequests,
but I had already produced a large list of them on my own ;)  So does this
make sense besides the "solved bug #175805" entries in the changelog (if
however bug report numbers reach that count for any project, the bugtracker
didn't add any value).


Regards,
mario

Other related posts: