[ewiki] Re: ewiki_nowiki? (no CamelCase) | restricting search | NewFileSystem requests

> ##NOWIKI
>
> What makes Wikis in general seem peculiar or geeky to many, is the "strange" 
> CamelCase-markup. I hope this doesn't sound like blasphemy, but have you 
> thought of the option to __exclude__ wiki-markup from the code? (One reason 
> to do so besides avoiding confusion, would be that BrandNames and emancipated 
> German spelling (BundeskanzlerInnen) using CamelCases wouldn't needed to be 
> escaped (by ! or ~).)

We recently introduced <code> and <pre> everybody knows from HTML, where
<code> disables WikiLinks and most WikiMarkup.

It is based upon the idea of separating the page into "blocks". Each
block in the page can then have associated rendering flags. This is
also explained in the README (very last paragraphs).

This way it was also possible to (this is merely done by adding another
$ewiki_config["block"][...] entry) add a block tag to introduce such
a nowiki area in the page. PhpWiki for example has always used the
<verbatim>...</verbatim> escape for this. Other Wikis use other escapes.
<nowiki> is used at least in TWiki, but then for escaping a single
WikiWord or so.

So this boils down, to that there just wasn't any discussion about
this, and therefore it's yet not enabled in ewiki. It's only a decission
problem here.

(Also, it was possible to completely disable WikiLinking for a page,
by changing the block rendering flags for ["core"] page blocks. This
would be controlled by a page flag or {meta}{meta} setting.)

> Would this increase speed? (I think that ewiki is quick enough.)

Not much, because the WikiWord regex is rather fast. Enabling another
<block> tag could however mean slight slowdown.

>
> ##RESTRICT SEARCH
>
> Has anyone of you thought of combinig the search tools with the 
> authetication-plugins? I ask, because it might be a nice feature to reduce 
> search to pages a searcher has access-rights to. (Though this is not so 
> important.)

Andy does nothing else.  ;-)

Many plugins check for access restrictions, and the code was recently
moved into the database result wrapper code (for SEARCH and GETALL
requests namely), so it is available for all requests, including
the PowerSearch and its page preview. For the search plugin there is
also additional code, which either allows hiding results or displaying
"access denied" instead of the preview text.

And this was in fact important, else poeple could have seen fragments
of pages, they actually weren't allowed to read at all.

If you see something like ' while ($row = $result->get(0, 0x20)) { '
in the code, then the results are already cleaned from access-restricted
pages.

Other related posts: