FemHack !

• To participate, edit this page by adding your name :: laptop - kids - toys- food *
• or confirm your presence (with those informations) at: foufem@lists.riseup.net.

* Pour rajouter ton nom, clique juste sur le bouton edit, tu seras autorisée à écrire une petite étape plus loin * To add your name: just click on the edit button, you'll be allowed to edit in 1 step

---

Participants

• Christina Haralanova :: 1 laptop, dslr - trempette + brie + crudités
• AnneGoldenberg :: 3 laptops - chips and humus
• Valerie D Walker :: 1 laptop - 1 child, 14 year - Spinach-cheese pan pizza & churros
• Maia Iotzova:: (10-13h30) laptop, video-camera -- food.
• Suzon :: laptop -
• Nancy Mauro Flude :: 1 laptop - 1 child, 1 year -
• Steffi S: 1 laptop -
• Alex Ruaux: laptop, 3D printer --
• Sophie Toupin :: 1 laptop - a video camera - Salade aux lentilles.
• Jess:: 2 children
• Rachade Hmamouchi : laptop - - salade de pate
• Stephanie Lagueux : (10h-14h )1 enfant (9 ans) - jouet(s) - salade pommes/noix + scones
• Zinta :: pens, markers, paper - apple, carrot, cabbage salad
• Maya :: laptop, markers
• Zile :: laptop, food
• pascale malaterre :
• julie chateauvert:(pm) 1 laptop- bouffe
• pascale malaterre (pm)
• Gabrielle :: laptop - - -
• Lucia :: laptop - tablet - jug of iced tea and popcorn
• Steffi N:: laptop - cake
• Ileana : Laptop - pie - friend (maybe)
• Isabelle Bégin
• Lucia
• Steffi (Autriche)
• Marie Thomas
*

------------

Contact and adress

• 10 am - 6pm @ Espace Fibre: 2665, rue Augustin-Cantin, 2nd Floor Montreal http://www.espacefibre.com/, foufem@lists.riseup.net

• Chez girlgeek

avec Pascal et Elise ?

*A Gathering of Feminist Women for Hacking Technologies *

(as part of http://www.htmlles.net/2012/ )

(the event will be bilingual cf FemHack en français - a mettre à jour)

November 17th 2012

• 10am - 6pm @ Espace Fibre: 2665 rue Augustin-Cantin, 2nd Floor http://www.espacefibre.com/ (MAP : http://goo.gl/maps/rdJjP)
• To participate, edit the Participants page or confirm your presence at: foufem@lists.riseup.net

---

Organized by Foufem, the Montreal Women and Feminist Hacker group, this whole-day event represents a marathon of activities on a number of tech & art topics. The aim is to demystify technologies, learn from peers, and create a core group of local women interested in technologies and hacking. There will be hands-on workshops, presentations, art performances & craft experiments. The event is experiment-friendly, diversity-friendly, innovation-friendly and errors-friendly. It is dedicated to (self-identified) women, techno-feminists, their children and allies.

HackFem will have four spaces of parallel activities:

• presentation session
• free sharing and learning space
• children workshops
• discussion hangs out corner

Program of the day

• 9h30-10h00: Welcome, coffee and visit the Espace Fibre

• 10h00-10h30: Introduction session

• 10h30-11h20: Nancy Mauro-Flude, Hands:On Tactical Magick: social software: fiction, action-at-a-distance and dolls [Presentation]

Nancy Mauro Flude http://sister0.org/, http://www.miss-hack.org/ our special guest from Australia, will open the day by sharing her experience with founding of a female-friendly hackerspaces and organizing kids-friendly feminist hacking activities.

Rather then speaking as an programming expert, my presentation is as an acknowledged outsider, as a performing artist who has a vested interest in redefining models of engagement and access to knowledge, but whose expertise is not necessarily those of a IT professional although I do programme and point to computer culture and most importantly engage with it in a speculative manner. I refer to Miss Despoina's Critical Engineering space, the /Eclectic Tech Carnival (/etc) http://www.eclectictechcarnival.org/ and other so called 'hackspaces' and their associated 'public sphere’. I ground the analysis in my experience as a developer/& or founder of these events or spaces. I rethink self-organising meeting and visibility spaces by considering gender approaches to in computer subcultures and software/hardware development. MORE INFO: http://bit.ly/software_dolls

Parallel sessions:

• 11h30-12h20: Valery Walker WomenSpeak => ComputersListen [Presentation]
  My talk will be on approaching technology as a new language which one has to learn how to use. I'll link in a bit herstory via ada lovelace, the loom as computer concept, the basic parts of a computer: what they do and how we work with them, the web browser as computer interface, an overview of software Design aka coding aka translanting one's thoughts into machine thought, which should set them up for learning python next.

• 11h30-12h20: Alex Ruaux Intro to 3D printing [Workshop] Imagine a world where you can print solid objects from your computer, where virtual designs can be made tangible from within the comfort of your own home. Are you interested in finding out what the 3D printing hype is really all about, what it can do and want to see it in action? Then this is workshop is for you. See various printers in action, see some of the cool objects and learn more about the whole process.

12h30-13h30: Lunch-Potluck! Bring a dish of your favorite meal and share with the other participants.

• 13h30-14h20: Anne Goldenberg Some Laptop AutoPsy [Workshop]

Inspired by the project Effeuillage d'Ordinateur­ http://vimeo.com/38361339 by Annie abramams, but focusing on the innerworld of your own laptop, Some LaptopAutoPsys questions the relation we have to our own computer, through an intimate dissection among electonics fragilities, mysteris and discoveries.

• 13h20-14h20: Suzon Fuks: Water-Wheel [Presentation]

Waterwheel offre une plate-forme pour activistes, artistes, scientifiques et enseignants afin de débattre, présenter, archiver et échanger des informations et idées à propos de l'Eau. Waterwheel permet le partage créatif et constructif sur le sujet essentiel de l'Eau, grâce à son système unique et gratuit de vidéoconférence et mixage de médias : le Tap - une sorte de combinaison de Skype groupe vidéo (jusqu'à 6 webcams) et YouTube pour toutes sortes de médias. http://vimeo.com/waterwheel/demo

• 14h30-15h20: Stefanie Schirmer: Introduction to Python [Presentation/Workshop]

Here we will learn to program in Python together. Python is a clear and expressive programming language, both suited for beginners and complex tasks. No previous knowledge is required, everybody is welcome. If possible, bring a computer with Python (http://www.python.org/getit/ -> pick 2.7.x) and a text editor (gedit, sublimeText2, notepad or whatever you have / prefer) installed. We can also help you installing those.

• 15h30-16h20: Sophie Toupin Intersectional feminism and hackerspaces

• 16h30-17h00: Foufem

• 17h00-19h00 - 5@7 (bring your drinks, there's no bar)

flyers !

This event is proudly and happily part of the HTMlles http://www.htmlles.net/ ?log EN grey.png

We will contribute to the next geek out. http://geeksout.org/events/doctor-who-planet-giants-paley-center

The inline directive is supplied by the inline plugin.

This is a directive that allows including one wiki page inside another. The most common use of inlining is generating blogs and RSS or Atom feeds.

Example:

[[!inline  pages="blog/* and !*/Discussion" limit="10" rootpage="blog"]]

Any pages that match the specified PageSpec (in the example, any SubPage of "blog") will be part of the blog, and the newest 10 of them will appear in the page. Note that if files that are not pages match the PageSpec, they will be included in the feed using RSS enclosures, which is useful for simple podcasting; for fuller-featured podcast feeds, enclose media files in blog posts using meta.

The optional rootpage parameter tells the wiki that new posts to this blog should default to being SubPages of "blog", and enables a form at the top of the blog that can be used to add new items.

If you want your blog to have an archive page listing every post ever made to it, you can accomplish that like this:

[[!inline  pages="blog/* and !*/Discussion" archive="yes"]]

You can even create an automatically generated list of all the pages on the wiki, with the most recently added at the top, like this:

[[!inline  pages="* and !*/Discussion" archive="yes"]]

If you want to be able to add pages to a given blog feed by tagging them, you can do that too. To tag a page, just make it link to a page or pages that represent its tags. Then use the special link() PageSpec to match all pages that have a given tag:

[[!inline  pages="link(life)"]]

Or include some tags and exclude others:

[[!inline  pages="link(debian) and !link(social)"]]

usage

There are many parameters you can use with the inline directive. These are the commonly used ones:

• pages - A PageSpec of the pages to inline.
• limit - Specify the maximum number of matching pages to inline. Default is 10, unless archiving, when the default is to show all. Set to 0 to show all matching pages. In older versions of IkiWiki this parameter was called show, which also still works.
• archive - If set to "yes", only list page titles and some metadata, not full contents.
• title - Sets the title of the rss feed if one is generated. Defaults to the name of the page.
• description - Sets the description of the rss feed if one is generated. Defaults to the name of the wiki.
• skip - Specify a number of pages to skip displaying. Can be useful to produce a feed that only shows archived pages.
• postform - Set to "yes" to enable a form to post new pages to a blog.
• postformtext - Set to specify text that is displayed in a postform.
• rootpage - Enables the postform, and allows controling where newly posted pages should go, by specifiying the page that they should be a SubPage of.

Here are some less often needed parameters:

• actions - If set to "yes" add links to the bottom of the inlined pages for editing and discussion (if they would be shown at the top of the page itself).
• rss - controls generation of an rss feed. If the wiki is configured to generate rss feeds by default, set to "no" to disable. If the wiki is configured to allowrss, set to "yes" to enable.
• atom - controls generation of an atom feed. If the wiki is configured to generate atom feeds by default, set to "no" to disable. If the wiki is configured to allowatom, set to "yes" to enable.
• feeds - controls generation of all types of feeds. Set to "no" to disable generating any feeds.
• emptyfeeds - Set to "no" to disable generation of empty feeds. Has no effect if rootpage or postform is set.
• id - Set to specify the value of the HTML id attribute for the feed links or the post form. Useful if you have multiple forms in the same page.
• template - Specifies the template to fill out to display each inlined page. By default the inlinepage template is used, while the archivepage template is used for archives. Set this parameter to use some other, custom template, such as the titlepage template that only shows post titles or the microblog template, optimised for microblogging. Note that you should still set archive=yes if your custom template does not include the page content.
• raw - Rather than the default behavior of creating a blog, if raw is set to "yes", the page will be included raw, without additional markup around it, as if it were a literal part of the source of the inlining page.
• sort - Controls how inlined pages are sorted. The default is to sort the newest created pages first, and if pages were created in the same commit, sort them by the name of the page (equivalent to sort="age title").
• reverse - If set to "yes", causes the sort order to be reversed.
• feedlimit - Specify the maximum number of matching pages to include in the rss/atom feeds. The default is the same as the limit value above. In older versions of IkiWiki this parameter was called feedshow, which also still works.
• feedonly - Only generate the feed, do not display the pages inline on the page.
• quick - Build archives in quick mode, without reading page contents for metadata. This also turns off generation of any feeds.
• timeformat - Use this to specify how to display the time or date for pages in the blog. The format string is passed to the strftime(3) function.
• feedpages - A PageSpec of inlined pages to include in the rss/atom feeds. The default is the same as the pages value above, and only pages matched by that value are included, but some of those can be excluded by specifying a tighter PageSpec here.
• guid - If a URI is given here (perhaps a UUID prefixed with urn:uuid:), the Atom feed will have this as its <id>. The default is to use the URL of the page containing the inline directive.
• feedfile - Can be used to change the name of the file generated for the feed. This is particularly useful if a page contains multiple feeds. For example, set "feedfile=feed" to cause it to generate page/feed.atom and/or page/feed.rss. This option is not supported if the wiki is configured not to use usedirs.
• pagenames - If given instead of pages, this is interpreted as a space-separated list of absolute page names (LinkingRules are not taken into account), and they are inlined in exactly the order given: the sort and pages parameters cannot be used in conjunction with this one.
• trail - If set to "yes" and the trail plugin is enabled, turn the inlined pages into a trail with next/previous links, by passing the same options to trailitems. The skip and limit options are ignored by the trail, so the next/previous links traverse through all matching pages.

The trailitems directive is supplied by the trail plugin. It adds pages to the trail represented by the current page, without producing any output on that page.

[[!trailitems  pages="posts/*" sort="age"]]

[[!trailitems  pagenames="a b c"]]

Options are similar to inline:

• pages: adds pages that match a PageSpec to the trail (cannot be used with pagenames)

• pagenames: if used instead of pages, this is interpreted as a space-separated list of absolute page names (LinkingRules are not taken into account) to add to the trail

• sort: add the pages matched by pages to the trail in this sorting order (cannot be used with pagenames)

• reverse: reverse the order of sort (cannot be used with pagenames)

The graph directive is supplied by the graphviz plugin.

This directive allows embedding graphviz graphs in a page. Example usage:

[[!graph  src="a -> b -> c; a -> c;"]]

Nodes on the graph can link to external urls using regular graphviz syntax, and a clickable imagemap will be created. As a special extension for ikiwiki, WikiLinks can also be used. For example:

[[!graph  src="""
google [ href="http://google.com/" ]
sandbox [ href=SandBox ]
help [ href=formatting ]
newpage [ href=?NewPage ]

google -> sandbox -> help -> newpage -> help -> google;
"""]]

The graph directive supports the following parameters:

• src - The graphviz source to render.
• file - A file in the wiki containing the graphviz source.
• type - The type of graph to render: graph or digraph. Defaults to digraph.
• prog - The graphviz program to render with: dot, neato, fdp, twopi, or circo. Defaults to dot.
• height, width - Limit the size of the graph to a given height and width, in inches. You must specify both to limit the size; otherwise, graphviz will choose a size, without any limit.

The ymlfront directive is supplied by the ymlfront plugin.

This directive allows the user to define arbitrary meta-data in YAML format.

[[!ymlfront  data="""
 foo: fooness
 bar: The Royal Pigeon
 baz: 2
 """]]

There is one argument to this directive.

• data: The YAML-format data. This should be enclosed inside triple-quotes to preserve the data correctly.

If more than one ymlfront directive is given per page, the result is undefined. Likewise, it is inadvisable to try to mix the non-directive ymlfront format with the directive form of the data.

The xslt directive is supplied by the xslt plugin.

This directive processes an input XML data file with XSLT, and outputs the result in the page where the directive was called.

[[!xslt  file="data1.xml" stylesheet="style1.xsl"]]

There are two arguments to this directive.

• file: The file which contains XML data to be processed. This file must have a .xml extension (filename.xml). This file is searched for using the usual IkiWiki mechanism, thus finding the file first in the same directory as the page, then in the directory above, and so on.

• stylesheet: The file which contains XSLT stylesheet to apply to the XML data. This file must have a .xsl extension (filename.xsl). This file is searched for using the usual IkiWiki mechanism, thus finding the file first in the same directory as the page, then in the directory above, and so on.

It is expected that the XSLT stylesheet will output valid HTML markup.

The report directive is supplied by the report plugin.

This enables one to report on the structured data ("field" values) of multiple pages; the output is formatted via a template. This depends on the ?field plugin.

The pages to report on are selected by a PageSpec given by the "pages" parameter. The template is given by the "template" parameter. The template expects the data from a single page; it is applied to each matching page separately, one after the other.

Additional parameters can be used to fill out the template, in addition to the "field" values. Passed-in values override the "field" values.

There are two places where template files can live. One is in the /templates directory on the wiki. These templates are wiki pages, and can be edited from the web like other wiki pages.

The second place where template files can live is in the global templates directory (the same place where the page.tmpl template lives). This is a useful place to put template files if you want to prevent them being edited from the web, and you don't want to have to make them work as wiki pages.

OPTIONS

template: The template to use for the report.

pages: A PageSpec to determine the pages to report on.

pagenames: If given instead of pages, this is interpreted as a space-separated list of links to pages, and they are shown in exactly the order given: the sort and pages parameters cannot be used in conjunction with this one. If they are used, they will be ignored.

trail: A page or pages to use as a "trail" page.

When a trail page is used, the matching pages are limited to (a subset of) the pages which that page links to; the "pages" pagespec in this case, rather than selecting pages from the entire wiki, will select pages from within the set of pages given by the trail page.

Additional space-separated trail pages can be given in this option. For example:

trail="animals/cats animals/dogs"

This will take the links from both the "animals/cats" page and the "animals/dogs" page as the set of pages to apply the PageSpec to.

start: Start the report at the given page-index; the index starts from zero.

count: Report only on N pages where count=N.

sort: A SortSpec to determine how the matching pages should be sorted.

here_only: Report on the current page only.

This is useful in combination with "prev_" and "next_" variables to make a navigation trail. If the current page doesn't match the pagespec, then no pages will be reported on.

Headers

An additional option is the "headers" option. This is a space-separated list of field names which are to be used as headers in the report. This is a way of getting around one of the limitations of HTML::Template, that is, not being able to do tests such as "if this-header is not equal to previous-header".

Instead, that logic is performed inside the plugin. The template is given parameters "HEADER1", "HEADER2" and so on, for each header. If the value of a header field is the same as the previous value, then HEADER*N* is set to be empty, but if the value of the header field is new, then HEADER*N* is given that value.

Example

Suppose you're writing a blog in which you record "moods", and you want to display your blog posts by mood.

[[!report  template="mood_summary"
pages="blog/*"
sort="Mood Date title"
headers="Mood"]]

The "mood_summary" template might be like this:

<TMPL_IF NAME="HEADER1">
## <TMPL_VAR NAME="HEADER1">
</TMPL_IF>
### <TMPL_VAR NAME="TITLE">
(<TMPL_VAR NAME="DATE">) ?&lt;TMPL VAR NAME="PAGE"&gt;
<TMPL_VAR NAME="DESCRIPTION">

Multi-page Reports

Reports can now be split over multiple pages, so that there aren't too many items per report-page.

per_page: how many items to show per report-page.

first_page_is_index: If true, the first page of the report is just an index which contains links to the other report pages. If false, the first page will contain report-content as well as links to the other pages.

Advanced Options

The following options are used to improve efficiency when dealing with large numbers of pages; most people probably won't need them.

maketrail:

Make a trail; if true, then this report is called in "scan" mode and the pages which match the pagespec are added to the list of links from this page. This can be used by another report by setting this page to be a "trail" page in that report.

It is not possible to use "trail" and "maketrail" at the same time. By default, "maketrail" is false.

TEMPLATE PARAMETERS

The templates are in HTML::Template format, just as ?template and ftemplate are. The parameters passed in to the template are as follows:

Fields

The structured data from the current matching page. This includes "title" and "description" if they are defined.

Common values

Values known for all pages:

• page (the current page)
• destpage (the destination page)
• basename (the base name of the page)
• recno (N if the page is the Nth page in the report)

Prev_Page And Next_Page

The "prev_page" and "next_page" variables will give the value of the previous page in the matching pages, or the next page in the matching pages. This is mainly useful for a "here_only" report.

Passed-in values

Any additional parameters to the report directive are passed to the template; a parameter will override the matching "field" value. For example, if you have a "Mood" field, and you pass Mood="bad" to the report, then that will be the Mood which is given for the whole report.

Generally this is useful if one wishes to make a more generic template and hide or show portions of it depending on what values are passed in the report directive call.

For example, one could have a "hide_mood" parameter which would hide the "Mood" section of your template when it is true, which one could use when the Mood is one of the headers.

Headers

See the section on Headers.

First and Last

If this is the first page-record in the report, then "first" is true. If this is the last page-record in the report, then "last" is true.

The jssearchfield directive is supplied by the jssearchfield plugin.

This enables one to search the structured data ("field" values) of multiple pages. A search form is constructed, and the searching is done with Javascript, which means that the entire thing is self-contained. This depends on the plugins/contrib/field plugin.

The pages to search are selected by a PageSpec given by the "pages" parameter. The fields to search are given by the "fields" parameter. By default, the field name is given, and the user can type the search parameter for that field into a text input field.

OPTIONS

pages: A PageSpec to determine the pages to search through.

fields: The fields to put into the search form, and to display in the results.

tagfields: Display the given fields as a list of tags that can be selected from, rather than having a text input field. Every distinct value of that field will be listed, so it is best used for things with short values, like "Author" rather than long ones like "Description". Note that "tagfields" must be a subset of "fields".

sort: A SortSpec to determine how the matching pages should be sorted; this is the "default" sort order that the results will be displayed in. The search form also gives the option of "random" sort, which will display the search results in random order.

SEARCHING

The search form that is created by this directive contains the following:

• for each search field, a label, plus either a text input field, or a list of checkboxes with values next to them if the field is also a tagfield. Note that the lists of checkboxes are initially hidden; one must click on the triangle next to the label to display them.
• a "sort" toggle. One can select either "default" or "random".
• A "Search!" button, to trigger the search if needed (see below)
• A "Reset" button, which will clear all the values.

The searching is dynamic. As soon as a value is changed, either by tabbing out of the text field, or by selecting or de-selecting a checkbox, the search results are updated. Furthermore, for tagfields, the tagfield lists themselves are updated to reflect the current search results.

The ftemplate directive is supplied by the ftemplate plugin.

This is like the template directive, with the addition that one does not have to provide all the values in the call to the template, because ftemplate can query structured data ("fields") using the ?field plugin.

Templates are files that can be filled out and inserted into pages in the wiki, by using the ftemplate directive. The directive has an id parameter that identifies the template to use.

Additional parameters can be used to fill out the template, in addition to the "field" values. Passed-in values override the "field" values.

There are two places where template files can live. One is in the /templates directory on the wiki. These templates are wiki pages, and can be edited from the web like other wiki pages.

The second place where template files can live is in the global templates directory (the same place where the page.tmpl template lives). This is a useful place to put template files if you want to prevent them being edited from the web, and you don't want to have to make them work as wiki pages.

EXAMPLES

Example 1

PageA:

[[!meta  title="I Am Page A"]]
[[!meta  description="A is for Apple."]]
[[!meta  author="Fred Nurk"]]
[[!ftemplate  id="mytemplate"]]

Template "mytemplate":

# <TMPL_VAR NAME="TITLE">
by <TMPL_VAR NAME="AUTHOR">

**Summary:** <TMPL_VAR NAME="DESCRIPTION">

This will give:

<h1>I Am Page A</h1>
<p>by Fred Nurk</p>
<p><strong>Summary:</strong> A is for Apple.

Example 2: Overriding values

PageB:

[[!meta  title="I Am Page B"]]
[[!meta  description="B is for Banana."]]
[[!meta  author="Fred Nurk"]]
[[!ftemplate  id="mytemplate" title="Bananananananas"]]

This will give:

<h1>Bananananananas</h1>
<p>by Fred Nurk</p>
<p><strong>Summary:</strong> B is for Banana.

Example 3: Loops

(this example uses the ?ymlfront plugin)

Page C:

---
BookAuthor: Georgette Heyer
BookTitle: Black Sheep
BookGenre:
  - Historical
  - Romance
---
?ftemplate id="footemplate"

I like this book.

Template "footemplate":

# <TMPL_VAR BOOKTITLE>
by <TMPL_VAR BOOKAUTHOR>

<TMPL_IF BOOKGENRE>(
<TMPL_LOOP GENRE_LOOP><TMPL_VAR BOOKGENRE>
<TMPL_UNLESS __last__>, </TMPL_UNLESS>
</TMPL_LOOP>
)</TMPL_IF>

This will give:

<h1>Black Sheep</h1>
<p>by Georgette Heyer</p>

<p>(Historical, Romance)</p>

<p>I like this book.</p>

LIMITATIONS

One cannot query the values of fields on pages other than the current page. If you want to do that, check out the ?report plugin.

[[!template Error: failed to process template <span class="createlink"><a href="/ikiwiki.cgi?do=create&amp;from=ikiwiki%2Fdirective%2Ffield&amp;page=%2Ftemplates%2Fplugin" rel="nofollow">?</a>plugin</span> template plugin not found ]]

NAME

IkiWiki::Plugin::field - front-end for per-page record fields.

SYNOPSIS

# activate the plugin
add_plugins => [qw{goodstuff field ....}],

# simple registration
field_register => [qw{meta}],

# simple registration with priority
field_register => {
meta => 'last'
foo => 'DD'
},

# allow the config to be queried as a field
field_allow_config => 1,

# flag certain fields as "tags"
field_tags => {
BookAuthor => '/books/authors',
BookGenre => '/books/genres',
MovieGenre => '/movies/genres',
}

DESCRIPTION

This plugin is meant to be used in conjunction with other plugins in order to provide a uniform interface to access per-page structured data, where each page is treated like a record, and the structured data are fields in that record. This can include the meta-data for that page, such as the page title.

Plugins can register a function which will return the value of a "field" for a given page. This can be used in a few ways:

• In page templates; all registered fields will be passed to the page template in the "pagetemplate" processing.
• In PageSpecs; the "field" function can be used to match the value of a field in a page.
• In SortSpecs; the "field" function can be used for sorting pages by the value of a field in a page.
• By other plugins, using the field_get_value function, to get the value of a field for a page, and do with it what they will.

CONFIGURATION OPTIONS

The following options can be set in the ikiwiki setup file.

field_allow_config

field_allow_config => 1,

Allow the $config hash to be queried like any other field; the keys of the config hash are the field names with a prefix of "CONFIG-".

field_register

field_register => [qw{meta}],

field_register => {
meta => 'last'
foo => 'DD'
},

A hash of plugin-IDs to register. The keys of the hash are the names of the plugins, and the values of the hash give the order of lookup of the field values. The order can be 'first', 'last', 'middle', or an explicit order sequence between 'AA' and 'ZZ'. If the simpler type of registration is used, then the order will be 'middle'.

This assumes that the plugins in question store data in the %pagestatus hash using the ID of that plugin, and thus the field values are looked for there.

This is the simplest form of registration, but the advantage is that it doesn't require the plugin to be modified in order for it to be registered with the "field" plugin.

field_tags

field_tags => {
BookAuthor => '/books/authors',
BookGenre => '/books/genres',
MovieGenre => '/movies/genres',
}

A hash of fields and their associated pages. This provides a faceted tagging system.

The way this works is that a given field-name will be associated with a given page, and the values of that field will be linked to sub-pages of that page, the same way that the [[!tag ]] directive does.

This also provides a field with the suffix of -tagpage which gives the name of the page to which that field-value is linked.

For example:

BookGenre: SF

will link to "/books/genres/SF", with a link-type of "bookgenre".

If one was using a template, then the following template:

Genre: <TMPL_VAR BOOKGENRE>
GenrePage: <TMPL_VAR BOOKGENRE-TAGPAGE>
GenreLink: ?&lt;TMPL VAR BOOKGENRE-TAGPAGE&gt;

would give:

Genre: SF
GenrePage: /books/genres/SF
GenreLink: <a href="/books/genres/SF/">SF</a>

PageSpec

The field plugin provides a few PageSpec functions to match values of fields for pages.

• field
  • field(name glob)
  • field(bar Foo*) will match if the "bar" field starts with "Foo".
• destfield
  • destfield(name glob)
  • as for "field" but matches against the destination page (i.e when the source page is being included in another page).
• field_item
  • field_item(name glob)
  • field_item(bar Foo) will match if one of the values of the "bar" field is "Foo".
• destfield_item
  • destfield_item(name glob)
  • as for "field_item" but matches against the destination page.
• field_null
  • field_null(name)
  • matches if the field is null, that is, if there is no value for that field, or the value is empty.
• field_tagged
  • field_tagged(name glob)
  • like tagged, but this uses the tag-bases and link-types defined in the field_tags configuration option.
• destfield_tagged
  • destfield_tagged(name glob)
  • as for "field_tagged" but matches against the destination page.

SortSpec

The "field" SortSpec function can be used to sort a page depending on the value of a field for that page. This is used for directives that take sort parameters, such as inline or report.

field(name)

For example:

sort="field(bar)" will sort by the value og the "bar" field.

Additionally, the "field_natural" SortSpec function will use the Sort::Naturally module to do its comparison (though it will fail if that module is not installed).

FUNCTIONS

field_register

field_register(id=>$id);

Register a plugin as having field data. The above form is the simplest, where the field value is looked up in the %pagestatus hash under the plugin-id.

Additional Options:

call=>&myfunc

A reference to a function to call rather than just looking up the value in the %pagestatus hash. It takes two arguments: the name of the field, and the name of the page. It is expected to return (a) an array of the values of that field if "wantarray" is true, or (b) a concatenation of the values of that field if "wantarray" is not true, or (c) undef if there is no field by that name.

sub myfunc ($$) {
my $field = shift;
my $page = shift;

...

return (wantarray ? @values : $value);
}

first=>1

Set this to be called first in the sequence of calls looking for values. Since the first found value is the one which is returned, ordering is significant. This is equivalent to "order=>'first'".

last=>1

Set this to be called last in the sequence of calls looking for values. Since the first found value is the one which is returned, ordering is significant. This is equivalent to "order=>'last'".

order=>$order

Set the explicit ordering in the sequence of calls looking for values. Since the first found value is the one which is returned, ordering is significant.

The values allowed for this are "first", "last", "middle", or a two-character ordering-sequence between 'AA' and 'ZZ'.

field_get_value($field, $page)

my $value = field_get_value($field, $page);

my $value = field_get_value($field, $page, foo=>'bar');

Returns the value of the field for that page, or undef if none is found. It is also possible to override the value returned by passing in a value of your own.

DOWNLOAD

• browse at GitHub: http://github.com/rubykat/ikiplugins/blob/master/IkiWiki/Plugin/field.pm
• git repo at git://github.com/rubykat/ikiplugins.git

This wiki has shortcuts enabled.

Some examples of using shortcuts include:

[[!google  foo]]
[[!wikipedia  War_of_1812]]
[[!debbug  12345]]
Check the [[!google  ikiwiki desc="google search for %s"]].

This page controls what shortcut links the wiki supports.

• shortcut google points to https://encrypted.google.com/search?q=%s
• shortcut archive points to http://web.archive.org/*/%S
• shortcut gmap points to https://maps.google.com/maps?q=%s
• shortcut gmsg points to https://groups.google.com/groups?selm=%s
• shortcut wikipedia points to https://en.wikipedia.org/wiki/%W
• shortcut wikitravel points to https://wikitravel.org/en/%s
• shortcut wiktionary points to https://en.wiktionary.org/wiki/%s
• shortcut debbug points to http://bugs.debian.org/%S
• shortcut deblist points to https://lists.debian.org/debian-%s
• shortcut debpkg points to http://packages.debian.org/%s
• shortcut debpkgsid points to http://packages.debian.org/sid/%s
• shortcut debpts points to http://packages.qa.debian.org/%s
• shortcut debmsg points to https://lists.debian.org/msgid-search/%s
• shortcut debrt points to https://rt.debian.org/Ticket/Display.html?id=%s
• shortcut debss points to http://snapshot.debian.org/package/%s/
  • Usage: [[!debss package]] or [[!debss package/version]]. See http://snapshot.debian.org/ for details.
• shortcut debwiki points to https://wiki.debian.org/%S
• shortcut debcve points to https://security-tracker.debian.org/tracker/%S
  • also supports Debian bug numbers, packages and whatever the security tracker supports.
• shortcut fdobug points to https://bugs.freedesktop.org/show_bug.cgi?id=%s
• shortcut fdolist points to http://lists.freedesktop.org/mailman/listinfo/%s
• shortcut gnomebug points to https://bugzilla.gnome.org/show_bug.cgi?id=%s
• shortcut linuxbug points to https://bugzilla.kernel.org/show_bug.cgi?id=%s
• shortcut mozbug points to https://bugzilla.mozilla.org/show_bug.cgi?id=%s
• shortcut gnulist points to https://lists.gnu.org/mailman/listinfo/%s
• shortcut marcmsg points to http://marc.info/?i=%s
• shortcut marclist points to http://marc.info/?l=%s
• shortcut gmane points to http://dir.gmane.org/gmane.%s
• shortcut gmanemsg points to http://mid.gmane.org/%s
• shortcut cpan points to http://search.cpan.org/search?mode=dist&query=%s
• shortcut ctan points to http://tug.ctan.org/cgi-bin/ctanPackageInformation.py?id=%s
• shortcut hoogle points to http://haskell.org/hoogle/?q=%s
• shortcut iki points to http://ikiwiki.info/%S/
• shortcut ljuser points to http://%s.livejournal.com/
• shortcut rfc points to https://www.ietf.org/rfc/rfc%s.txt
• shortcut c2 points to http://wiki.c2.com/?%s
• shortcut meatballwiki points to http://www.usemod.com/cgi-bin/mb.pl?%s
• shortcut emacswiki points to http://www.emacswiki.org/cgi-bin/wiki/%s
• shortcut haskellwiki points to http://haskell.org/haskellwiki/%s
• shortcut dict points to http://www.dict.org/bin/Dict?Form=Dict1&Strategy=&Database=&Query=%s
• shortcut imdb points to http://imdb.com/find?q=%s
• shortcut gpg points to http://pgpkeys.mit.edu:11371/pks/lookup?op=vindex&exact=on&search=0x%s
• shortcut perldoc points to http://perldoc.perl.org/search.html?q=%s
• shortcut whois points to http://reports.internic.net/cgi/whois?whois_nic=%s&type=domain
• shortcut cve points to https://cve.mitre.org/cgi-bin/cvename.cgi?name=%s
• shortcut flickr points to https://secure.flickr.com/photos/%s
• shortcut man points to http://manpages.debian.org/%s
• shortcut ohloh points to https://www.ohloh.net/p/%s
• shortcut cpanrt points to https://rt.cpan.org/Ticket/Display.html?id=%s
• shortcut novellbug points to https://bugzilla.novell.com/show_bug.cgi?id=%s
• shortcut ubupkg points to http://packages.ubuntu.com/%s
• shortcut mozillazinekb points to http://kb.mozillazine.org/%s
• shortcut freebsdwiki points to http://wiki.freebsd.org/%s
• shortcut hackage points to http://hackage.haskell.org/package/%s
• shortcut pkgsrc points to http://pkgsrc.se/%S
• shortcut doi points to http://dx.doi.org/%s
• shortcut arxiv points to http://arxiv.org/abs/%s

To add a new shortcut, use the shortcut directive. In the url, "%s" is replaced with the text passed to the named shortcut, after url encoding it, and '%S' is replaced with the raw, non-encoded text. Additionally, %W is replaced with the text encoded just right for Wikipedia. The optional desc parameter controls the description of the link.

Remember that the name you give the shortcut will become a new directive. Avoid using a name that conflicts with an existing directive. These directives also accept a desc parameter that will override the one provided at definition time.

If you come up with a shortcut that you think others might find useful, consider contributing it to the shortcuts page on the ikiwiki wiki, so that future versions of ikiwiki will include your shortcut in the standard underlay.

The waypoint directive is supplied by the osm plugin.

This directive adds a waypoint ot an OpenStreetMap map displayed by the osm directive. See the osm directive for examples and options.

This is the SandBox, a page anyone can edit to learn how to use the wiki.

---

Here's a paragraph.

Here's another one with emphasised text.

Header

Subheader

subsubsuheader

This is a blockquote.

This is the first level of quoting.

This is nested blockquote.

Back to the first level.

Numbered list

1. First item.
2. Another.
3. And another..

Bulleted list

• item
• item

WikiLink

The trailoptions directive is supplied by the trail plugin. It sets options for the trail represented by this page.

[[!trailoptions  sort="meta(title)" circular="no"]]

Options available:

• sort: sets a sorting order for the entire trail, overriding the order in which they were added

• reverse: reverses the order of the trail

• circular: if set to yes or 1, the trail is made into a loop by making the last page's "next" link point to the first page, and the first page's "previous" link point to the last page

The traillink directive is supplied by the trail plugin. It generates a visible WikiLink, and also adds the linked page to the trail represented by the page containing the directive.

In its simplest form, the first parameter is like the content of a WikiLink:

[[!traillink  some_other_page]]

The displayed text can also be overridden, either with a | symbol or with a text parameter:

[[!traillink  Click_here_to_start_the_trail|some_other_page]]
[[!traillink  some_other_page text="Click here to start the trail"]]

The trailitem directive is supplied by the trail plugin. It is used like this:

[[!trailitem  some_other_page]]

to add some_other_page to the trail represented by this page, without generating a visible hyperlink.

The osm directive is supplied by the osm plugin.

This directive inserts an OpenStreetMap map onto a page. It is typically combined with the waypoint directive to add points to the map.

examples

[[!osm ]]
[[!waypoint  lat="45°30N" lon="73°40W" name="My city" tag="city"]]

The osm directive will display the actual map, while the waypoint directive adds waypoints to the map.

The above can also be shortened as:

[[!waypoint  lat="45°30N" lon="73°40W" name="My city" tag="city" embed]]

The tag is also taken from the tags elsewhere in the page, so the above is equivalent to:

[[!waypoint  lat="45°30N" lon="73°40W" name="My city" embed]]
[[!tag  city]]

The icon is also taken from the tag if attached to the tag page as icon.png (default, modifiable)..

map display

• map - map to display, defaults to "map"
• zoom - the level to zoom to on the OSM map
• loc - lattitude and longitude of the map center
• lat - lattitude
• lon - longitude
• editable - add edit controls in a separate layer
• right - float the map right
• left - float the map left (default)
• width - width of the map
• height - height of the map

waypoints

Waypoints can be added to any page. By default the waypoint takes the name of the page, which allows you to easily tag pages and make them appear on the central map.

Waypoints, by default, show up as a image (the icon parameter) link to the main map (or the map parameter provided). That markup can be hidden with the hidden parameter.

• name - the name of this point, defaults to the page name must be unique, otherwise later incantation will overwrite previous ones.
• map - the map to add the point to (defaults to "map")
• desc - description to embed in the map
• loc - lattitude and longitude
• lat - lattitude
• lon - longitude
• tag - the type of points, maps to an icon in the osm_types array
• hidden - do not display the link to the map (will not affect embed)
• icon - URL to the icon to show in the link to the map and within the map
• embed - embed the map display alongside the point, in which case the regular arguments to the map display can be used

Links

If two pages with waypoints have a link between them, that link will magically show up on the map. Now how awesome is that?

Ikiwiki uses many templates for many purposes. By editing its templates, you can fully customise its appearance, and avoid duplicate content.

Ikiwiki uses the HTML::Template module as its template engine. This supports things like conditionals and loops in templates and is pretty easy to learn. All you really need to know to modify templates is this:

• To insert the value of a template variable, use <TMPL_VAR variable>.
• To make a block of text conditional on a variable being set use <TMPL_IF variable>text</TMPL_IF>.
• To use one block of text if a variable is set and a second if it's not, use <TMPL_IF variable>text<TMPL_ELSE>other text</TMPL_IF>

template pages

Template pages are regular wiki pages containing a templatebody directive, used as templates for other pages. The parts of the template page outside the directive can be used to document it.

The template directive allows template pages to be filled out and inserted into other pages in the wiki.

These template pages are currently available:

Add a new template page named:

note

popup

If the template does not contain a templatebody directive, the entire source of the page is used for the template. This is deprecated.

template files

Template files are unlike template pages in that they have the extension .tmpl. Template files are used extensively by Ikiwiki to generate html. They can contain html that would not normally be allowed on a wiki page.

Template files are located in /usr/share/ikiwiki/templates by default; the templatedir setting can be used to make another directory be searched first. Customised template files can also be placed inside the "templates/" directory in your wiki's source -- files placed there override ones in the templatedir.

Here is a full list of the template files used:

• page.tmpl - Used for displaying all regular wiki pages. This is the key template to customise to change the look and feel of Ikiwiki.

• rsspage.tmpl - Used for generating rss feeds for blogs.

• rssitem.tmpl - Used for generating individual items on rss feeds.
• atompage.tmpl - Used for generating atom feeds for blogs.
• atomitem.tmpl - Used for generating individual items on atom feeds.
• inlinepage.tmpl - Used for displaying a post in a blog.
• archivepage.tmpl - Used for listing a page in a blog archive page.
• titlepage.tmpl - Used for listing a page by title in a blog archive page.
• microblog.tmpl - Used for showing a microblogging post inline.
• blogpost.tmpl - Used for a form to add a post to a blog (and rss/atom links)
• feedlink.tmpl - Used to add rss/atom links if blogpost.tmpl is not used.
• aggregatepost.tmpl - Used by the aggregate plugin to create a page for a post.
• searchform.tmpl, googleform.tmpl - Used by the search plugin and google plugin to add search forms to wiki pages.
• searchquery.tmpl - This is a Omega template, used by the search plugin.
• comment.tmpl - Used by the comments plugin to display a comment.
• change.tmpl - Used to create a page describing a change made to the wiki.
• recentchanges.tmpl - Used for listing a change on the RecentChanges page.
• autoindex.tmpl - Filled in by the autoindex plugin to make index pages.
• autotag.tmpl - Filled in by the tag plugin to make tag pages.
• calendarmonth.tmpl, calendaryear.tmpl - Used by ikiwiki-calendar to make calendar archive pages.
• trails.tmpl - Used by the trail plugin to generate links on each page that is a member of a trail.
• notifyemail.tmpl - Used by the notifymail plugin to generate mails about changed pages.
• editpage.tmpl, editconflict.tmpl, editcreationconflict.tmpl, editfailedsave.tmpl, editpagegone.tmpl, pocreatepage.tmpl, editcomment.tmpl commentmoderation.tmpl, renamesummary.tmpl, passwordmail.tmpl, emailauth.tmpl, login-selector.tmpl, revert.tmpl - Parts of ikiwiki's user interface; do not normally need to be customised.

The meta directive is supplied by the meta plugin.

This directive allows inserting arbitrary metadata into the source of a page. Enter the metadata as follows:

[[!meta  field="value"]]
[[!meta  field="value" param="value" param="value"]]

The first form sets a given field to a given value, while the second form also specifies some additional sub-parameters. You can have only one field per meta directive, use more directives if you want to specify more fields.

The field values are treated as HTML entity-escaped text, so you can include a quote in the text by writing " and so on.

Supported fields

• title

  Overrides the title of the page, which is generally the same as the page name.

  Note that if the title is overridden, a "title_overridden" variable will be set to a true value in the template; this can be used to format things differently in this case.

  An optional sortas parameter will be used preferentially when sorting by meta(title):

  [[!meta title="The Beatles" sortas="Beatles, The"]]

  [[!meta title="David Bowie" sortas="Bowie, David"]]

• license

  Specifies a license for the page, for example, "GPL". Can contain WikiLinks and arbitrary markup.

• copyright

  Specifies the copyright of the page, for example, "Copyright 2007 by Joey Hess". Can contain WikiLinks and arbitrary markup.

• author

  Specifies the author of a page.

  An optional sortas parameter will be used preferentially when sorting by meta(author):

  [[!meta author="Joey Hess" sortas="Hess, Joey"]]

• authorurl

  Specifies an url for the author of a page.

• description

  Specifies a short description for the page. This will be put in the html header, and can also be displayed by eg, the map directive.

• keywords

  Specifies keywords summarizing the contents of the page. This information will be put in the html header. Only letters, numbers, spaces and commas are allowed in this string; other characters are stripped. Note that the majority of search engines, including Google, do not use information from the keywords header.

• permalink

  Specifies a permanent link to the page, if different than the page generated by ikiwiki.

• date

  Specifies the creation date of the page. This creates a <meta name="date" content="..."> header in the HTML output, but also modifies the internal ctime in the internal index. The date can be entered in nearly any format, since it's parsed by TimeDate but invalid dates yield an error in 3.20180321 or later.

• stylesheet

  Adds a stylesheet to a page. The stylesheet is treated as a wiki link to a .css file in the wiki, so it cannot be used to add links to external stylesheets. Example:

  [[!meta stylesheet=somestyle rel="alternate stylesheet" title="somestyle"]]

  However, this will be scrubbed away if the htmlscrubber plugin is enabled, since it can be used to insert unsafe content.

• script

  Adds a script to a page. The script is treated as a wiki link to a .js file in the wiki, so it cannot be used to add links to external scripts. The optional defer and async keywords can be used to set the corresponding HTML4 and HTML5 script options. Example:

  [[!meta script=somescript defer async]]

  The tag is subject to scrubbing as with the stylesheet and link fields.

• openid

  Adds html <link> tags to perform OpenID delegation to an external OpenID server. This lets you use an ikiwiki page as your OpenID.

  By default this will delegate for both openid and openid2. To only delegate for one, add a parameter such as delegate=openid.

  An optional xrds-location parameter lets you specify the location of any eXtensible Resource DescriptorS.

  Example:

  [[!meta openid="http://joeyh.myopenid.com/" server="http://www.myopenid.com/server" xrds-location="http://www.myopenid.com/xrds?username=joeyh.myopenid.com"]]

• link

  Specifies a link to another page. This can be used as a way to make the wiki treat one page as linking to another without displaying a user-visible WikiLink:

  [[!meta link=otherpage]]

  It can also be used to insert a html <link> tag. For example:

  [[!meta link="http://joeyh.myopenid.com/" rel="openid.delegate"]]

  However, this latter syntax won't be allowed if the htmlscrubber plugin is enabled, since it can be used to insert unsafe content.

• enclosure

  Specifies a link to a file to be rendered as an "enclosure" in RSS/Atom feeds (and a plain old link in HTML). Useful for podcasting.

• redir

  Causes the page to redirect to another page in the wiki.

  [[!meta redir=otherpage]]

  The default is to redirect without delay. Optionally, a delay (in seconds) can be specified: "delay=10"

  It can also be used to redirect to an external url. For example:

  [[!meta redir="http://example.com/"]]

  However, this latter syntax won't be allowed if the htmlscrubber plugin is enabled, since it can be used to insert unsafe content.

  For both cases, an anchor to jump to inside the destination page may also be specified using the common #ANCHOR syntax.

• robots

  Causes the robots meta tag to be written:

  [[!meta  robots="index, nofollow"]]
  

  Valid values for the attribute are: "index", "noindex", "follow", and "nofollow". Multiple comma-separated values are allowed, but obviously only some combinations make sense. If there is no robots meta tag, "index, follow" is used as the default.

  The value is escaped, but its contents are not otherwise checked.

• guid

  Specifies a globally unique ID for a page. This guid should be a URI, and it will be used to identify the page's entry in RSS and Atom feeds. If not given, the default is to use the page's URL as its guid.

  This is mostly useful when a page has moved, to keep the guids for pages unchanged and avoid flooding aggregators (see tips/howto avoid flooding aggregators).

• updated

  Specifies a fake modification time for a page, to be output into RSS and Atom feeds. This is useful to avoid flooding aggregators that sort by modification time, like Planet: for instance, when editing an old blog post to add tags, you could set updated to be one second later than the original value. The date/time can be given in any format that TimeDate can understand, just like the date field and maps to the <meta name="updated" content="..."> HTML header and internal mtime field.

• foaf

  Adds a Friend of a Friend (FOAF) reference to a page.

  Example:

  [[!meta foaf=foaf.rdf]]

• name

  Adds a HTML <meta> header with this name attribute. Its other attributes are taken from the other parameters, so for example [[!meta name="foo" content="bar" x-non-standard-attribute="baz"]] becomes <meta name="foo" content="bar" x-non-standard-attribute="baz">. This won't be allowed if the htmlscrubber plugin is enabled, since it can be used to insert unsafe content.

Other fields

If the field is not one of the above predefined fields, the metadata will be written to the generated html page as a <meta> header. For example, [[!meta foo="bar"]] becomes <meta name="foo" content="bar">. As with name, this won't be allowed if the htmlscrubber plugin is enabled.

This syntax cannot be used for meta headers with unusual names, in particular names containing : such as flattr:id and twitter:card. Please use [[!meta name="..." content="..."]] for those headers.