The account creation process in the default passwordauth plugin could support account moderation by an administrator. New account signups would go into a queue for approval by an administrator.

(Random, potentially infeasible idea: save their edits and apply them if the account gets approved.)

--JoshTriplett

wishlist

New Version of gallery is available now. Few more features have been added like support for multiple pages, sorting and resizing of images etc.

Gallery repo is now available at http://github.com/joeyh/ikiwiki/tree/gallery

--arpitjain

---

creating a gallery of a bunch of images:

• Display Exif informations
• Display Image informations (like size, date, resolution, compression...)
• Create CSS data for customizing
• Create Thumbnails (maybe in more than one size, eg: full,1024x768,800x600,640x480)
• Descriptions for every image
• Comments
• Ratings
• Watermarks
• Some javascript for easy navigation (see photon for a good example)

It should be possible to disable every feature for every directory.

---

This could be split into two distinct projects. One would be to modify the img plugin to support some of these ideas for extracting and using information such as exif out of images. The other project would be to design something that handles setting up a gallery, which could be just some regular wiki pages using the img plugin, and perhaps some other custom plugins for things like ratings and javascript), and adding new images to a gallery as they are added to the wiki.

That's one way to do it, and it has some nice benefits, like being able to edit the gallery pages like any wiki page, to add comments about images, links, etc. An example of ikiwiki being used like that: http://kitenet.net/~family/pics/guaimaca.html (still room for improvement, clearly).

--Joey

---

I have implemented the first version of the Gallery Plugin for Ikiwiki as part of soc. This plugin would create a nice looking gallery of the images once the directory containing images is specified with some additional parameters. It has been build over the img plugin.

Plugin can be downloaded from here.

It can be used as :
[[!gallery imagedir="images" thumbnailsize="200x200" cols="3" alt="Can not be displayed" title="My Pictures"]]

where-
* imagedir => Directory containing images. It will scan all the files with jpg|png|gif extension from the directory and will put it in the gallery.
* thumbnailsize(optional) => Size of the thumbnail that you want to generate for the gallery.
* alt(optional) => If image can not be displayed, it will display the text contained in alt argument.
* cols(optional) => Number of columns of thumbnails that you want to generate.
* title(optional) => Title of the gallery.

Features of the Gallery Plugin:
* You can go the next image by clicking on the right side of the image or by pressing 'n'.
* Similary, you can go the previous image by clicking on the left side of the image or by pressing 'p'.
* Press esc to close the gallery.
* While on image, nearby images are preloaded in the background, so as to make the browsing fast.

Right now, it features only one template namely Lightbox. Later on, I will add few more templates.
For any feedback or query, feel free to mail me at arpitjain11 [AT] gmail.com

Additional details are available here.

I'd love to merge this into ikiwiki.

However, lightbox.js is licensed under a non-free (Creative Commons) license.

Since I don't much like the lightbox effects anyway (too much resizing motion, too slow), I wonder if another template could be added, perhaps a free one?

Now that ikiwiki is in git, I've downloaded the most recenty version of the gallery and put it in a "gallery" branch of my git repository.

--Joey

---

See also gallery for another implementation of the same sort of thing. Unfortunately, none of the implementation ideas I have there seem quite right either... --smcv

I would love to see a plugin that lets you create one or more BibTeX-formatted bibliography pages and add citations to other pages. The plugin could also render the bibliographies themselves using a chosen BibTeX style and an HTML formatter for LaTeX (such as HeVeA).

--JoshTriplett

There is such a plugin at plugins/contrib/bibtex. --MatthiasIhrke

I work on a plugin to htmlize '.bib' files.

A sample result is shown on my webpage : http://www.adupas.org/research/publications/.

It features the htmlization of the bibtex with 4 types of entry supported (InProceedings, Article, MastersThesis and PhdThesis). I will add the book entry support soon. It creates for each '.bib' file an html version, and for each entry a specific page with abstract as well as an individual bib file. It lack some features like the possibility to have a pdf or ps version of the article attached.

This plugin uses two templates to render the html version of each file.

I have a problem to create a new page that render like any other page in the wiki. I have used the Ikiwiki's internal genpage($$) routine but I suppose that there is another way to do this. My method lack the backlink support for the individual entry files as well as the modification date of these file.

Is it possible to create several wiki page from only one source file?

The source of this plugin could be found on this page : http://www.adupas.org/software/ikiwiki/ .

Feel free to propose any modifications to enhance this plugin.

--AlexandreDupas

I have not found any other approach to build several wiki page with only one source file. Does someone have an idea?

I also try to build a wiki-wide preprocessing of the source file to find reference to my bib entry (citation) but apparently there is no wiki-wide preprocessing hook allowing to collect data from each page before building the site. Do I miss something?

--AlexandreDupas

The scan hook is run on new page content before building --Joey

What notation did you have in mind for citations? A preprocessor directive? Something LaTeX-inspired might be

[[!cite  key="foo"]]

which would output "(Foo, 2008)". With the appropriate options, this could allow for several variations like "Foo (2008)" and "(Foo, 2008, p. 28)". A nocite option could cause the reference to be printed in the bibliography but produce no output.

What about the references section? There are several ways to go about it, for example:

1. It could be included at the bottom of the page automatically for pages with references, with a configurable title and heading level (e.g., <h2>References</h2>) followed by a list of references.

2. Use another preprocessor directive like

    ## References ##
   
    [[!bibliography  ]]
   

   or

    [[!bibliography  title="References" headerlevel="2"]]
   

   with configurable default values. Would it be tedious to do this on every page?

3. Use HTML::Template and allow users to add a bibliography section to page.tmpl to include the bibliography if references are present and loop over the references to emit a list. The downside here is having to ask people to modify their templates (unless the plugin is eventually included in the distribution).

Any thoughts on the best way to proceed?

--JasonBlevins, March 23, 2008 21:41 EDT

Given network access when building the wiki, ikiwiki could retrieve information from bug-tracking systems and apply that information to BTS links. For instance, consider how links from one bugzilla bug to another use strikeout formatting for links to fixed bugs, and use the status and summary of the bug to the link as a title.

This seems somewhat difficult, as ikiwiki would need to maintain a cache of the remote BTS information, and know how to talk to various types of BTS. CPAN modules exist to solve this problem for some types of BTS.

--JoshTriplett

scmbug might help here. --JoshTriplett

How about a plugin adding a preprocessor directive to render some given LaTeX and include it in the page? This could either render the LaTeX as a PNG via dvipng and include the resulting image in the page, or perhaps render via HeVeA, TeX2page, or similar. Useful for mathematics, as well as for stuff like the LaTeX version of the ikiwiki logo.

JasonBlevins has also a plugin for including LaTeX expressions (by means of itex2MML) -- ?mdwn itex (look at his page for the link). --Ivan Z.

I've updated Jason's plugin for ikiwiki 3.x. --wtk

I've updated Jason's pandoc plugin to permit the TeX processing to be managed via Pandoc. See https://github.com/profjim/pandoc-iki for details. --Profjim

---

ikiwiki could also support LaTeX as a document type, again rendering to HTML.

JasonBlevins has also a ?pandoc plugin (look at his page for the link): in principle, Pandoc can read and write LaTeX. --Ivan Z.

---

Conversely, how about adding a plugin to support exporting to LaTeX?

I did some tests with using Markdown and a customized HTML::Latex and html2latex and it appears it will work for me now. (I hope to use ikiwiki for many to collaborate on a printed book that will be generated at least once per day in PDF format.)

--JeremyReed

Have a look at pandoc. It can make PDFs via pdflatex. --?roktas

Interesting, just yesterday I was playing with pandoc to make PDFs from my Markdown. Could someone advise me on how to embed these PDFs into ikiwiki? I need some guidance in implementing this. --JosephTurian

JasonBlevins has a ?pandoc plugin (look at his page for the link). --Ivan Z.

---

here is a first stab at a latex plugin. Examples here. Currently without image support for hevea. And the latex2html output has the wrong charset and no command line switch to change that. Dreamland.

As this link is not working, I setted a mirror here: http://satangoss.sarava.org/ikiwiki/latex.pm.

---

Okay, now is the time for a mid term report i think.

The LaTeX Plugin for ikiwiki is now usable, except for the security check. This means at the moment the latex code is not validated, but only added into a very basic latex template. and the image is generated via this path: latex -> dvips -> convert (.tex -> .dvi -> .ps -> .png). The resulting .png is moved into the imagefolder. The name of this image is the md5hash of the code the user wrote into the wiki. So on a second run there is no need to recreate this image, if it exists. This will fasten up all but the first generation of the page. The generation of the image is done in an temporary folder in /tmp created with tempdir from File::Temp. The tmp-folder name is something like: $md5sumdigest.XXXXXXXX. if there is an .tex file already in this dir it will be overwritten.

So until now i finished the basic things, now the most important task is to make an good input validation. This is a bit eased since it is not possible to execute shell commands in perl. Furthermore adding additional packages won't work since the code comes from the user is inserted after \begin{document}. Therefore this will result in an error (and this will stop latex from working --> no image is created).

So my task for the next weeks is to write an good input validation. I think this progress is okay, since I'll had to learn the last 5-6 weeks for my final exams in university therefore I can't do anything. From now on I have 3 months of freetime and I'll use them to work heavily on this plugin. So I think I'm inside my own timetable.

ps: Since I found nothere the possibility to upload an file, here is an link to my page where you can have a look. Comments are very welcome https://www.der-winnie.de/~winnie/gsoc07/tex.pm

You'll find an demo site here: https://www.der-winnie.de/wiki/opensource/gsoc2007/ I'll add some more complex formulas over the days. But this is basically only pure latex.

-- Patrick Winnertz

Looks like you're very well on schedule.

But I wonder: Do you have any plans to work on the latex to html side of things too? This page kinda combines both uses of latex; creating gifs for formulas etc, and creating html. Dreamland already has a latex2html using plugin submitted above, but it still needs some work, and particularly, needs the same input validation stuff. And then there's the idea of using html2latex, to convert an ikiwiki site into a book. Any plans to work on that too? I guess I'm not sure what the scope is of what you plan to do as part of GSoC.

Yes I plan to write an html -> tex (or pdf) plugin as well. But I think it is better to work first on the first one and complete it and then work and complete the second one. If it is in the scope of GSoC i don't know, but I'll write it since it is fun to write on an Opensource project

For latex-> html: I have the problem that I don't really see the sense to create html code (this means text or charts) from latex code. But if you like I can also add this variant to create html code. In my eyes it is much more important that it is possible to have complex chemical/physical & math formulas on the website without the need to use extern programs. (and upload the pictures manually).

Well, I suppose someone might just like latex and want to use it as the markup for their wiki, rather than learning markdown. I guess Midnight wanted it enough to write his plugin. But the use case is not too compelling to me either, honestly. --Joey

code review

The main problem I see with the code is that you seem to unnecessarily create a dummy div tag in preprocess, and then in format you call create(), which generates an img tag. So, why not just create the img tag in preprocess?

Mh okay, I'll improve this.

Fixed

Another problem: Looks like if latex fails to create the image, the user won't be shown any of its error message, but just "failed to generate image from code". I suspect that in this case being able to see the error message would be important.

Yes, that's true. It would be very hard to provide the user the output of latex since this is really very much. For an simple formula as \frac{1}{2} this could be 2 printed out.

YM 2 printed pages? Yes, I'm familar with latex's insane errors. However, IMHO, it's worth considering this and doing something. Perhaps put the error inside some kind of box in the html so it's delimited from the rest of the page. (Actually, ikiwiki preprocessor directives in general could mark up their errors better.)

Okay, I'll provide the log as an link in the wiki. But there should be a kind of mechanism how they can be removed. This could lead to an DOS (create via a bot so much nonsense code that the disk is full.)

Fixed, the log is now provided if latex will fail.

The url handling could stand to be improved. Currently it uses $config{url}, so it depends on that being set. Some ikiwiki builds don't have an url set. The thing to do is to use urlto(), to generate a nice relative url from the page to the image.

Mh... i choose one single dir explizitly since if you use on several pages the same formula this would really improve the time to generate the formulas and it would waste extra space if you store every formula 3-4 times. But if you really like I'll change this behaviour.

No, that makes sense! (My comments about $config{url} still stand though.

Yes of course, I'll improve the url handling. My comment was only about the several folder

Fixed. Now I use urlto and will_render.

Another (minor) problem with the url handling is that you put all the images in a "teximages" directory in the toplevel of the wiki. I think it would be better to put each image in the subdirectory for the page that created it. See how the img and sparkline plugins handle this.

It looks like if the tempdir already exists, tempdir() will croak(), thus crashing ikiwiki. It would be good to catch a failure there and fail more gracefully.

Okay, I'll improve this behaviour. Maybe: if tempdir croak rerun it to get another not existing dir? (But only x times so that this is no endless loop, with x maybe = 3). Then it would not be necessary to inform the user about not generating the image.

Or just propigate up an error message. If it's failing, someone is probably trying to DOS ikiwiki or something.

Fixed. I now use eval { create_tmp } and then: if ($?) { $returncode = 0 } else { save .tex file ... } ...

I'm not sure why you're sanitising the PATH before calling latex. This could be problimatic on systems where latex is not in /bin or /usr/bin

Okay what do you suggest to use as PATH? I'll have to change the default settings, since we ikiwiki runs in taint mode. (which is good ;-))

But, ikiwiki already sanitises path and deletes the IFS and CDPATH etc. See ikiwiki.in.

Fixed. I'll removed these two lines completly.

---

Okay here an short timetable how I want to proceed further:

• Until weekend (21-22. July) I'll try to fix all errors above. (done)
• From 22.July until 29. July I'll try to set up a first security check My plans are two parts of a security check:
  • One with an array of blacklisted regular expression. (This would blacklist all the well known and easy to fetch things like \include {/path/to/something} and things like closing the math formula environment ($$). (done)
  • the second step will be based on Tom::latex, which will help to parse and get a tree view of the code.

Okay what do you think of this procedure?

--Joey

-- PatrickWinnertz

---

It would be nice if it would output image tags with style="height:1em;" so that the formulas scale with the rest of the text if you change the font size in your browser (ctrl + +/-).

Thanks for the comment.. is fixed. Mh... not really fixed :S I added it into the return but it is somehow ignored. I'll figure out why.

---

Okay, the last version of the tex plugin for ikiwiki can be downloaded here.

I've looked this over, fixed the indenting, fixed some variable names ("$foo" is a bad variable name), removed a gratuotuous use of tie, fixed a bug (the first time it was run, it tried to write the png file before the teximages/ directory existed) and checked the result in.

Can you please flesh out teximg with whatever documentation people who know tex will expect to see?

Okay, I'll fill this up today I think with information about the plugin

Done. Is that docu fine with you?

Perhaps add some documentation about the kind of tex code that can be used, or a link to some documentation so people who don't know latex well can figure this out?

Also, please review my changes. In particular, I changed the @badthings array to use qr//, which is much clearer, but it needs to be tested that I didn't break the checking code when I did it. It would be nice to write a test case that tries to feed it bad code and makes sure it rejects it.

I'll test this now on my server. I'll report here later. Okay, checked. it works fine. My blacklist tests were successfull.

Does it really make sense to have an alt tag for the image that contains the tex code? Will that make any sense when browsing without images?

Mh.. For people who know latex very well this would be enough to imagine how the image would look like. This are of course the minority of people (but I guess also the minority of people are using non-gui browsers).

I'm thinking about renameing the preprocessor directive to teximg. [[!teximg code="" alt="foo"]] makes sense.. Would it make sense to rename the whole plugin, or do you think that other tex stuff should go in this same plugin?

I'll think over this until I'm at work Only for rendering images... not for generating .tex files .../wiki/ the name is all the same i think. If you like teximg better than switch

Note: I removed the style= attribute, since as I've told you, the htmlsanitizer strips those since they can be used to insert javascript. I put in a class=teximage instead; the style sheet could be modified to style that, if you want to send a patch for that.

Ah yes.. sorry forgot to update the plugin in my public_html folder %-). This was my last change in this plugin Sorry.

--Joey

---

I'm using a plugin created by Josef Urban that gets LaTeX into ikiwiki by using LaTeXML. This could well be "the right way" to go (long term) but the plugin still does not render math expressions right, because ikiwiki is filtering out requisite header information. Examples (I recommend you use Firefox to view these!) are available here and here. Compare that last example to the file generated by LaTeXML directly. I posted the sources here for easy perusal. How to get ikiwiki to use the original DOCTYPE and html fields? I could use some help getting this polished off. --jcorneli

update: it seems important to force the browser to think of the content as xml, e.g. http://metameso.org/~joe/math/example.xml has the same source code as http://metameso.org/~joe/math/example.html and the former shows math working, but the latter doesn't. --jcorneli

Looking at the source code, it seems Ikiwiki is doing more than filtering header information - it is filtering out all HTML formatting around MathML constituent objects. In the first example, we see that formatting for tables and such is preserved. --jcorneli

Wikiwyg is a WYSIWYG editor written in javascript for wikis. It allows editing in a gui or in wikitext and converts edits back to wiki format to be saved to the wiki.

It would be awesome to use this in ikiwiki, but to take full advantage of it with ikiwiki, it would need to know about MarkDown. Wikiwyg does allow defining the text that is stuck on each side of a given html element to make it wikified, for example, it can add "# " for a h1, "?" and "" for a link, etc. This seems easily doable.

The other thing that would need doing is a saveChanges function would need to be implemented that saves the text back to ikiwiki. http://svn.wikiwyg.net/code/trunk/wikiwyg/share/Kwiki/lib/Wikiwyg/Kwiki.js seems like a good starting point for building a submit form on the fly.

One other problem: Wikiwyg works by parsing html from a div, turning it back into the wiki markup, and editing/saving that. That seems to assume that there's a way of parsing a page's html and getting back to the underlying wiki markup, which is not always the case in ikiwiki. Unless there's some other way to feed it the actual source for a page, this seems like a problem. According to the developers, it is possible to do that, and start off in WikiText mode.

Project IkiWiki::WIKIWYG v1.6 - http://ikiwiki.xbaud.com/

Wikiwyg is a "What you see is what you get" editor for wikis. It will allow you to double click on the text in a wiki and save it without reloading the page. The IkiWiki version will allow you to edit your wiki in Markdown or WYSIWYG. You will also be able to edit a page with the wikiwyg editor by clicking the "Edit" link at the top of the page.

This plugin requires that you have Archive::Tar intalled.

The plugin can be downloaded from http://ikiwiki.xbaud.com/wikiwyg-1.6.tar.gz

Installation Instructions

1. Copy the files from the wikiwyg tarball to the corrosponding folders in your ikiwiki installation
2. Add "wikiwyg" (no quotes) to the add_plugins section of your ikiwiki.setup
3. Rebuild your wiki
4. That's it!

Current Issues

• Some versions of Mozilla Firefox require you to click Wysiwyg, then another mode, then Wysiwyg again to get Wysiwyg mode working in the Edit link
• Double lists don't work

Upcoming Features

• More supported ikiwiki plugins (such as img, smilies, etc.)
• More wiki languages (such as wiki and otl)
• Ability to upload directly through wikiwyg (pending the upload plugin)
• Personalized settings

As noted in discussion, the url above doesn't work, and I stupidly lost my copy of this before merging it. I hope that this plugin will turn back up. In the meantime, there is a wmd plugin that accomplishes the same basic task of WSYWIG markdown editing. --Joey

Seems the new place is now at Github: https://github.com/audreyt/wikiwyg-js FYI --Olea

No, that's the wikiwyg source, not the ikiwiki plugin to use it. The latter is what's lost. --Joey

Perhaps ikiwiki should support XML-RPC-based blogging, using the standard MetaWeblog protocol. This would allow the use of applets like gnome-blog to post to an ikiwiki blog. The protocol supports multiple blog names, so one standard URL with page names as blog names would work. --JoshTriplett

This would be a great thing to add a plugin for. (Probably using the cgi hook to let ikiwiki act as an RPC server. --Joey

I'd love to see support for this and would be happy to contribute towards a bounty (say US$100) :-). PmWiki has a plugin which implements this in a way which seems fairly sensible as an end user. --AdamShand

Bump. This would be a nice feature, and with the talent on this project I'm sure it could be done safely, too.