Italics? What should the syntax for this be? I'd go with forward slashes (/word/) or underlines (word) -- AlanBailward
/Slashes/ might do it. I think underlines are already being used for underlines
Interesting idea. I'd converted underscores to do italics instead of underlining, but maybe slashes would work. However you'd have to watch out for filenames. --jammin
A critique of HTML::FromText is available on PerlMonks (http://perlmonks.org/index.pl?node=HTML%3A%3AFromText) which links to a number of patches (http://perlmonks.org/index.pl?node_id=195914) by Matt Olson to provide exactly what you want and more! -- Michael Erskine
I don't know how /. does it but I've used the chiq_chaq method where a "quoted string" immediately preceding a URL is used as its link title. --jammin
Add standard headers and footers ... why do we lose our FVLUG header when we go in the Wiki? --someone
Let me explain. This Wiki site contains quite a few technical pages and sites, there don't belong strictly under the "Linux" or "FVLUG" content umbrellas. Some of it may be of interest, but not particularly Linux related. Drill down through the main Site Map to see what I mean. I thought about seperating the content areas. Bigger problems arise with that though: all the content is related and linked to each other. I added a feature to MiniWiki, so that if a pagename contains the letters "fvlug", the FVLUG template is used. So as soon as you leave the FVLUG pages, you get the normal standard template. Not much different, but enough to cause some confusion. So, it's a bit of quandry that we are in. If you have a better idea, let me know... --Wim
Add some means of identifying where you are in the Wiki and what's close - navigating a Wiki is like being in Florida and losing your map, then getting blindfolded, spun around 5 times, and stuck in a swamp. (OK, maybe not quite that bad!)
No. Honestly, do you find a page like this one has that problem? The trick is educating everyone to put in nice links, including "See also" or "related information" at the bottom of the page. Correct me if I'm wrong, but I find the "Back to...", "See also ..." etc footers useful. Pages with no links: definetly useful. I'm going to encourage people to not only put meaningful links to other pages in, but also add links to pages that they stumble onto that don't have good links. Comments? --Wim
I have a question regarding the authentification. Is is possible that this can be done by an external instance/program which then only provides an ENV_USER variable ? I'm just in the early discovery stage with MiniWiki :) --Andreas Wittkemper ?
That should work fine. Just set it up as a mod_perl AuthenHandler or some such, and MiniWiki will be none the wiser that that's going on. --Wim
I made some fairly small changes to the local version of MiniWiki, so it should run faster. Previously, it was doing an RCS checkout of every single page on every hit. The reason for this is that it's possible to view older revisions, so I wanted to ensure the user always sees the right version. I've changed the behaviour, so that now after viewing a revision that is not HEAD, it automatically does another checkout of HEAD after the user is given the older page. It feels more responsive to me, anyway.
I've been thinking of adding a couple of features to MiniWiki:
Most Site Changes, list of pages who have recieved the most edits. Not sure how the list found make a better wiki but could make for some intresting navel gazing.
Ok, I've added the backwards thing... see listchangesOptions --Wim
Well done on this module - I love it to bits!
sub prettify {
my ($text) = @_;
# Before we leap in and use text2html, lets pull out the <html_inline> blocks
# and replace them with a placeholder...
# We'll use the quick (to code) and dirty non-greedy grouping method from
# the Perl Cookbook: /BEGIN((?:(?!BEGIN).)*)END/ ...
my @b;
push @b, $1 while($text =~ s/<html_inline>((?:(?!<html_inline>).)*)<\/html_inline>/~~PLACEHOLDER~~/so);
$text = text2html( $text,
urls => 1, email => 0, bold => 1,
underline =>1, paras => 1, bullets => 1, numbers=> 1,
headings => 1, blockcode => 1, tables => 1,
title => 1, code => 1
);
# Replace the blocks. We may find that text2html has wrapped our placeholders
# with <p class="hft-paras"></p> because of surrounding
# whitespace circumstances so let's abandon them too...
$text =~ s/(<p class="hft-paras">\s*)?~~PLACEHOLDER~~(\s*<\/p>)?/$_/so foreach @b;
return $text;
}Yeah, I know it's probably insecure and rather brittle (a malicious user might trash your carefully formatted template) but I trust all our editors (all authenticated) and, moreover, it works so far!
The caveats: -
Another tweak that I'm testing for my local site (http://www.tecspy.com/wiki/) is a simple set of emoticons ("smileys"): the text "[i smile]" will be replaced with the image "/emoticons/smile.png", "[i grin]" will be replaced with the image "/emoticons/grin.png", etc., etc. It uses the same technique as the inline html hack above: withholding blocks from the call to text2html() and replacing them afterwards (this time with an img tag). There is no checking for image file existence and the filename root is purposefully restrictive (see the regex: \w+) which should avoid most exploits I can think of. However, all my users are authenticated and know what they're doing(!) so use with caution or modify to suit. I'm using a nice little set of emoticons found under /usr/share/apps/kopete/pics/emoticons/Plain on my Debian Sarge Kopete package.
# Pull out icons too... my @i; push @i, '<img src="/emoticons/'.$2.'.png" alt="['.$2.']"/>' while($text =~ s/(\s+)\[\s*i\s+(\w+)\s*\](\s+)/$1~~ICON_HERE~~$3/o); $text = text2html( $text, urls => 1, email => 0, bold => 1, underline =>1, paras => 1, bullets => 1, numbers=> 1, headings => 1, blockcode => 1, tables => 1, title => 1, code => 1 ); # Replace icons... $text =~ s/~~ICON_HERE~~/$_/ foreach @i;
Any work on allowing attachments (i.e gif's, jpg's) to be displayed on the page or available for download (zip's) ?