+++ /dev/null
-title: Command line options
-linktitle: Cmdline
-parent: Configuration
-ctime: 2009-06-24
-
-= Help =
-
-As usualy, you can get command line help with "`-h`" or "`--help`":
-
- usage: webber [options]
-
- options:
- -h, --help show this help message and exit
- -i DIR, --in=DIR input directory
- -o DIR, --out=DIR output directory
- --style-dir=STYLE directory with style sheets
- -v, --verbose print status messages to stdout
- -k, --keepgoing keep going past errors if possible
- -V, --test_verbose print status messages to stdout
-
-= Input directory =
-
-"`-i`" or "`--in`" defaults to "`in`" and specifies where webber
-search for source files.
-
-You can access this via "`cfg.in_dir`" (or "`file.in_dir`", see
-[[inheritance]]).
-
-= Output directory =
-
-"`-o`" or "`--out`" defaults to "`out`" and specifies where webber
-writes the output files.
-
-
-= Template (Style) =
-
-You can define the style of the generated website via HTML templates. If
-you have more of them, you switch between different ones via "`--style-dir`".
-The default is "`in/style`".
-
-
-= Verbosity =
-
-A common option is "`-v`" (or "`--verbose`") to increase the verbosity. Repeat
-to increase even more.
-
-
-= Continue on errors =
-
-With "`-k`" or "`--keepgoing`" you can tell webber to ignore errors in one
-page and continue with the next page.
-
-
+++ /dev/null
-title: Configuration
-parent: Webber
-ctime: 2009-06-24
-
-Configuration happens either the [[commandline]] or
-via the configuration file (described below). All Configurations are
-[[inherited|inheritance]] and or overwritable on a per-directory and
-per-file basis.
-
-The main means for configuration is the config file:
-
-= Format =
-
-Webber expects a `webber.conf` file in it's root directory. It should look like this:
-
- template: "default"
- date_format: "%d.%m.%Y"
- input_encoding: "iso-8859-1"
- output_encoding: "iso-8859-1"
- plugins: [
- "skeleton",
- "hierarchy",
- "link",
- "read_rst",
- "read_html",
- "read_copyonly",
- "read_markdown",
- "template_mako",
- ]
- exclude_dir: [
- "webber.conf",
- "*.tmpl",
- ]
- exclude_files: [
- ]
-
-You could also some options with are normally defined by [[commandline]].
-This saves you from specifying them on ever run of webber:
-
- in_dir: "in"
- out_dir: "out"
- style_dir: "in/style"
- verbose: 5
-
-Beside those entries, you can specify any additional entries that will then
-be available in your plugins or templates.
-
-= Meaning =
-
-== template ==
-
-Used by the [[template_mako]] to select the template.
-
-== date_format ==
-
-Used in `format_date()`.
-
-== input_encoding ==
-
-Encoding ('utf-8', 'iso-8859-1' etc) used for reading files.
-
-== output_encoding ==
-
-Encoding ('utf-8', 'iso-8859-1' etc) used when writing the final HTML pages.
-
-== plugins ==
-
-List of [[plugins]] to load.
-
-== exclude_dirs ==
-
-List of directories below `cfg.in_dir` to skip.
-
-== exclude_files ==
-
-List of files below `cfg.in_dir` to skip.
-
-== in_dir, out_dir, style_dir ==
-
-See [[commandline]].
+++ /dev/null
-title: Functions
-parent: Webber
-ctime: 2009-06-24
-
-= Calling functions =
-
-You can call functions only from [[template_mako]]. An example:
-
- Modified ${format_date(mtime)}
-
-Here's list of functions defined by webber and it's default plugins:
-
-
-== format_date(timestamp) ==
-
-Takes a timestamp (seconds since 1st January 1970) and converts it into
-a string, using to `cfg.date_format`.
-
-Defined in `webber.py`.
-
-
-== get_time() ==
-
-Returns the current date/time as a string according to `cfg.date_format`.
-
-Defined in `webber.py`.
-
-
-== get_breadcrumbs() ==
-
-Returns the breadcrumbs as "`(page, link)`" tuples, where "`page`" is a "`class
-File`"-object and link is a relative link from the current page to "`page`".
-
-Defined in [[hierarchy.py|hierarchy]], where you find an example.
-
-
-== get_current_file() ==
-
-Returns the current "`class File`" object.
-
-Defined in `webber.py`.
-
-
-== get_recently(page) ==
-
-Returns a list of up to 10 pages below the specified page. If you don't
-specify a page, the current page will be used. For each page, you'll get a
-"`(page, link)`" tuple back, where "`page`" is a "`class File`"-object and
-link is a relative link from the current page to "`page`".
-
-Defined in [[hierarchy.py|hierarchy]], where you find an example.
-
-
-== get_sidemenu(root) ==
-
-Returns a menu for the current page. For each page in this menu you'll get
-back a "`(level, part_of_path, is_current, page, link)`" tuple, where
-"`page`" is a "`class File`"-object and link is a relative link from the
-current page to "`page`".
-
-You'll need to specify "`root`" if your top-most page isn't named "`Home`".
-
-Defined in [[hierarchy.py|hierarchy]], where you find an example.
-
-
-== get_sitemap(root, show_orphans) ==
-
-Returns all pages as "`(level, page, link)`" tuples, where "`page`" is a
-"`class File`"-object and link is a relative link from the current page to
-"`page`".
-
-You'll need to specify "`root`" if your top-most page isn't named "`Home`".
-
-To put pages into the sitemap that are outside the parent/child relationships,
-specify "`True`" for "`show_orphans`".
-
-Defined in [[hierarchy.py|hierarchy]], where you find an example.
-
-
-== func ==
-
-A sample function in the [[skeleton.py|skeleton]]. See below.
-
-
-= Writing functions =
-
-A function is a simply python function which returns HTML. The function needs
-to be decorated with "`@set_function(name)`". There's an example in
-[[skeleton.py|skeleton]], which looks like:
-
- :::python
- @set_function("func")
- def sample_func():
- if cfg.test_verbose:
- print "in macro skeleton.sample_func"
- return "{ output from sample function }"
-
-Inside your template, you can call the function without parameters or
-with arbitrary parameters, like this:
-
- ${func(a=1, b="test")}
-
-Inside your function you can access this as ...
-
-* "`params.a`" which contains the integer "`1`"
-* "`params.b`" which contains the string "`test`"
+++ /dev/null
-title: Hooks
-parent: Webber
-ctime: 2009-06-24
-
-= At Startup =
-
-== addoptions ==
-
-Can be used by plugins to add their own command line options.
-
-"`params.parser`" contains the "`optparse`" based parser.
-
-Example:
-
- :::python
- @set_hook("addoptions")
- def test_addoptions(params):
- params.parser.add_option("-V", "--test_verbose", action="count",
- dest="test_verbose", default=0,
- help="print status messages to stdout")
-
-== checkconfig ==
-
-After the command-line options have been processed and incorporated into
-config object, this hook is called. Here each plugin can check if the
-specified configurations are sane.
-
-* "`params`" is empty, you should use "`cfg`" directly:
-
-Example:
-
- :::python
- @set_hook("checkconfig")
- def test_checkconfig(params):
- if cfg.test_verbose:
- print "WARNING: I'll be now much more noisy"
- # I could also directly modify the configuration:
- cfg.foo = "mooh"
-
-== start ==
-
-This hook is called just before walking the directory tree.
-
-* "`params`" is empty:
-
-Example:
-
- :::python
- @set_hook("start")
- def test_start(params):
- print "in start hook"
-
-
-= While reading source files =
-
-== read ==
-
-Now webber walks the directory tree specified in "`cfg.in_dir"`, excluding
-anything from "`cfg.exclude_dir`" and "`cfg.exclude_file"`. For each of the
-remaining files this hook is called.
-
-Usually the the "`read_*`" plugins implement this hook. And usually they look
-at the file-extension and decide if they the can procecess this file or not.
-If they do, the plugin should also set "`file.render`" is normally "`html"`.
-However, it can be something else. In this case "`file.render`" specifies a
-hook that get's called for this file.
-
-The first hook that returns contents wins, no other hooks will be called.
-
-* "`params.direc`" contains a "`class Directory`" object
-* "`params.file`" contains a "`class File`" object
-
-Example:
-
- :::python
- @set_hook("read")
- def read(params):
- file = params.file
- if file.rel_path.endswith(".html"):
- file.render = "html"
- f = file.read_keywords()
- return f.read()
-
-== filter ==
-
-Any file that got read will be filtered. At this stage the text is still in the
-original format.
-
-Currently no webber-supplied plugin implements this.
-
-* "`params.direc`" contains a "`class Directory`" object
-* "`params.file`" contains a "`class File`" object
-* "`params.contents`" contains the text
-
-Example:
-
- :::python
- @set_hook("filter")
- def filter(params):
- params.content = params.content.replace("e", "EEEEE")
-
-
-= After reading files =
-
-At this stage all pages and their meta-information has been read. Now we can
-generate additional data, e.g. page hierarchy, tag-clouds, lists of recently
-changed files, etc. This is done via the following two hooks.
-
-The webber-supplied plugin [[hierarchy]] uses this
-mechanism.
-
-== scan ==
-
-This hook is called once per file with contents:
-
-* "`params.direc`" contains a "`class Directory`" object
-* "`params.file`" has a "`class File`" object
-* "`params.file.contents`" contains the text
-
-== scan_done ==
-
-Finally one "`scan_done`" hook is called. The plugin [[hierarchy]]
-uses this to sort links.
-
-* "`params`" is empty.
-
-= While rendering files =
-
-The following hooks are called for each file that has a rendered in
-"`file.render`" set. See the "`read"`-hook in how to set it.
-
-If "`file.render`" is "`html"`, then the hooks "`htmlize"`, "`linkify`" and
-"`pagetemplate`" are run in this order. Otherwise the hook specified
-in "`file.render`" is called.
-
-== htmlize ==
-
-This hook converts contents into HTML.
-
-The first hook that returns HTML, no other hooks will be called.
-
-* "`params.direc`" contains a "`class Directory`" object
-* "`params.file`" has a "`class File`" object
-* "`params.file.contents`" contains the text
-
-== linkify ==
-
-This hook should contain any link to html. Implemented by the plugin
-[[link]].
-
-* "`params.direc`" contains a "`class Directory`" object
-* "`params.file`" has a "`class File`" object
-* "`params.file.contents`" contains the HTML for the body text of the page
-
-== pagetemplate ==
-
-The implementation for this is responsible to generate the final html page,
-ready to be written. Implemented by [[template_mako]] plugin.
-
-The first hook that returns a finished HTML page, no other hooks will be
-called.
-
-* "`params.direc`" contains a "`class Directory`" object
-* "`params.file`" has a "`class File`" object
-* "`params.file.contents`" contains the HTML for the body text of the page
-
-== copyfile ==
-
-This is one local hook, run instead of the "`htmlize"`, "`linkify`" and
-"`pagetemplate`" hooks. It's defined and implemented by the plugin
-[[read_copyonly]].
-
-The first hook that returs anything wins, no other hooks will be called.
-
-* "`params.direc`" contains a "`class Directory`" object
-* "`params.file`" has a "`class File`" object
-
-= At the end =
-
-Now everythings has been converted to HTML and written out. And we're just
-one hook away from finishing webber:
-
-== finish ==
-
-This hook is called at the end of webber's execution. No webber-supplied
-plugin uses it currently, but you could use this to save local state into some
-file.
-
-* "`params`" is empty
+++ /dev/null
-title: Configuration inheritance
-linktitle: Inheritance
-parent: Webber
-ctime: 2009-06-24
-
-= Overview =
-
-Internally, webber uses a bunch of `Holder` classes to store information
-(command-line options, config file options, parameters for a directory,
-parameters for a file).
-
-Each `Holder` "inherits" configuration entries from the layer above:
-
-* `options` for command-line options
-* `cfg` for entries from the command line
-* `direc` for information about a directory
-* `file` (either directly or via `get_current_file()` for data about the
- currently rendered file
-
-= Example =
-
-Due to parsing the [[command line|commandline]] there will exist an entry
-`options.style_dir`.
-
-However, you can also access this same value via `cfg.style_dir`,
-`direc.style_dir` and `file.style_dir`. Any one of them however could
-over-write the settings that originally was in `options`.
-
-Quite often you'll use this for the page template. In `webber.conf`, you
-specify `template: "default"`, which will be used for most pages. Any
-page that needs a different template will get `template: history` entry
-in it's header.
+++ /dev/null
-title: Macros
-parent: Webber
-ctime: 2009-06-24
-
-= Calling macros =
-
-Macros are executed whenever the sequence
-"<code>[</code><code>[!name]]</code>" or
-"<code>[</code><code>[!name args]]</code>" is in the source-file.
-
-Webber itself doesn't define any macros.
-
-
-= Defining macros =
-
-A macro is a simply python function which returns HTML. The function needs
-to be decorated with "`@set_macro(name)`". There's an example in
-[[skeleton.py|skeleton]], which looks like:
-
- :::python
- @set_macro("sample")
- def sample_macro(params):
- if cfg.test_verbose:
- print "in macro skeleton.sample_macro, params:", params
- return "{ output of sample macro }"
-
-If you call this macro, you'll see the output "[[!sample]]".
-
-* "`params.name`" contains the name of the macro
-* "`params.file`" contains the current "`class File`" object
-
-You can submit additional string arguments, e.g. "<code>[</code><code>[!sample
-arg1="string"]]</code>". This will yield
-
-* "`params.arg1`" contains "`string`"
-
+++ /dev/null
-title: Overview
-parent: Webber
-ctime: 2009-06-24
-
-*Webber* is a static web-site generation tool, loosely based on ideas
-from IkiWiki and my own likings.
-
-TODO
+++ /dev/null
-title: Page format
-parent: Webber
-ctime: 2009-06-26
-
-Every page contains a header, then a blank line, and then the text that
-should show up in the web page.
-
-The header consists of several keywords, followed by a color and a space,
-and the the value.
-
-Here's an example:
-
- title: Impressum
-
- Hi, I'm Mario and I won't tell you more about me :-)
-
-
-= Your own keywords =
-
-Inside the template, functions and macros you can access all entries
-by "`file.XXXX`" and you're free to invent your own keywords:
-
- title: Impressum
- subtitle: What you should know about this web-site
-
- Hi, I'm Mario and I won't tell you more about me :-)
-
-Now you can access "`${file.subtitle}`" in your template and as
-"`params.file.subtitle`" in your own [[macros|macros]] or
-[[functions|functions]].
-
-
-= Overriding configuration =
-
-As "`file`" inherits all configuration from "`cfg`" (see [[inheritance]]),
-you can also specify a different template on a per-file basis:
-
- title: Impressum
- template: boring_bg
-
- Hi, I'm Mario and I won't tell you more about me :-)
-
-
-= Webber's keywords =
-
-== title ==
-
-Full (long) title for the page. End's up in
-"`<head><title>...</title></head>`".
-
-Very mandatory. Extremely important. You cannot have a page without a title.
-Never. Forget. The. Title.
-
-Depending on your template it will also be set inside "`<h1>...</h1>`" at the
-start of your web page.
-
-
-== linktitle ==
-
-Sometimes the title is simply too long, e.g. for breadcrumbs. Therefore you
-can specify a link-title, which will be used by [[hierarchy]] when generating
-breadcrumbs and a side-menu.
-
-
-== parent ==
-
-Used by [[hierarchy]] to indicate relationship.
-
-
-== order ==
-
-All pages with the same "`parent`" will end up below the parent on the
-side-menu (see [[hierarchy]] for details). They will be alphabetically sorted.
-
-If you don't want this default sort order, you can specify your own ordering.
-
-The default order is 100, so anything with a lower order will show up on the
-top, anything higher at the bottom of the side-menu.
-
-== links ==
-
-Used by [[hierarchy]] to indicate relationship. Usually it's better to use
-"`parent`" instead.
-
-
-== ctime ==
-
-Here you can specify an ISO formatted date and or time specifier, which contains
-the document creation date/time. Examples:
-
- ctime: 2009-06-29
- ctime: 2009-06-29 14:33
-
-If you don't specify this, then the documents "`mtime`" will be used instead.
-
-
-== mtime ==
-
-Here you can specify an ISO formatted date and or time specifier, which contains
-the document modification date/time. Examples:
-
- mtime: 2009-06-29
- mtime: 2009-06-29 14:33
-
-If you don't specify this, then the "last-modified"-time from the file-system
-will be used instead.
-
-
-== template ==
-
-Allows you to override the default template. Just specify the pure file
-name. For convenience, you can ommit "`.tmpl`".
-
- title: Blog
- template: history
-
-
-== description ==
-
-Anything you specify here will be accessible in the template as ${description}.
-You can use this for HTML meta information, see [[template_make]].
-
-If you don't specify a description, then ${description} will be the empty string.
-
-
-== keywords ==
-
-Anything you specify here will be accessible in the template as ${keywords}.
-You can use this for HTML meta information, see [[template_make]].
-
-If you don't specify a description, then ${keywords} will be the empty string.
-
-
-== main_url ==
-
-Used by [[google_sitemap]]:
-
-Internally, [[Webber]] works with relative URLs and is quite agonistic about
-the final website. However, the [[google_sitemap]] plugin needs absolute URLs,
-complete with host name. So we need this configuration ...
-
-Used by [[google_sitemap]]:
-
-
-== sitemap_priority ==
-
-Used by [[google_sitemap]] to specify a relative important-ness of a page.
-Should be between "`0.0`" and "`1.0`" (including).
-
-
-== sitemap_changefreq ==
-
-Used by [[google_sitemap]] as an estimate about how often a page might change.
-
-Should be one of the following values:
-
-* always
-* hourly
-* daily
-* weekly
-* monthly
-* yearly
-* never
+++ /dev/null
-title: Google Sitemap generation
-linktitle: google_sitemap.py
-parent: Plugins
-keywords: Google, XML, Sitemap generator
-ctime: 2009-06-26
-
-This plugins write an XML "`sitemap.xml`" file into the out-directory. The
-format is documented at [[http://www.sitemaps.org]].
-
-
-= Configuration =
-
-The sitemap generator needs three [[Configuration]] items:
-
- main_url: "www.holgerschurig.de"
- sitemap_changefreq: "monthly"
- sitemap_priority: 0.5
-
-
-== main_url ==
-
-This is the main URL of your website, without the "`http://`" stuff.
-
-
-== sitemap_changefreq ==
-
-You can define an estimated change frequency on each page by specifying
-this keyword at the header of each [[page|Page format]]. However, the
-"`sitemap_changefreq`" from the configuration file will be used as a
-default.
-
-
-== sitemap_priority ==
-
-You can define an relative page importance on each page by specifying
-this keyword at the header of each [[page|Page format]]. However, the
-"`sitemap_priority`" from the configuration file will be used as a
-default.
-
-
-= robots.txt =
-
-Please note that you'll also specify the sitemap in your "`robots.txt`" file,
-e.g.:
-
- User-agent: *
- Disallow: /logs/
- Sitemap: http://www.holgerschurig.de/sitemap.xml
-
-Also make sure that your "`robots.txt`" file get's copied, by adding
-
- copy_files: [
- ...
- "robots.txt",
- ...
- ]
-
-to "`webber.conf`".
+++ /dev/null
-title: Generate hierarchy
-linktitle: hierarchy.py
-parent: Plugins
-ctime: 2009-06-26
-
-This is one of the more complex plugins, used to generate menus and
-breadcrumbs. For this, it reads certain keyword from the
-[[pageformat]], built an internal parent-child representation.
-
-This is later used for by the functions "`get_breadcrumbs()`" and
-"`get_sidemenu()`", which you call from the [[template_mako]].
-
-= Page attributes =
-
-At the "`scan`" [[hook|hooks]], the plugin looks for entries like:
-
- parent: Home
-
-or
-
- childs: Cmdline, Inheritance
-
-Here's an example of five pages with different attributes:
-
----
-
- title: Homepage
- linktitle: Home
-
----
-
- title: Impressum
- parent: Home
-
----
-
- title: Job
- parent: Home
-
----
-
- title: CV
- parent: Job
-
----
-
- title: Knowledge
- parent: Job
-
----
-
-= Internal representation =
-
-the plugin would populate the variables "`_childs`" and "`_parent`" like this:
-
- _parent = {
- 'Impressum': 'Home',
- 'CV': 'Job',
- 'Knowledge': 'Job',
- 'Job': 'Home'
- }
-
- _childs = {
- 'Home': [(100, 'Job'),
- (100, 'Impressum')],
- 'Job': [(100, 'CV'),
- (100, 'Knowledge')]}
-
-That's all you need to generate a sidemap, breadcrumbs or a side-menu.
-
-The pages are first ordered by some number, then by the "`linktitle`". If
-a page has no "`linktitle:`" attribute, then the normal title will be used
-instead.
-
-If you want to modify the sort-order, simply specify a "`order: 200`" in the
-page itself.
-
-= Generation of breadcrumbs =
-
-This is done via a suitable [[template_mako]]. The template uses the
-function "`get_breadcrumbs()`" and returns (linktitle, link) tuples. As a
-bonus: all the links are always relative to the calling page.
-
-Here's a sample Mako template excerpt:
-
- <ul>\
- % for page, link in get_breadcrumbs():
- <li><a href="${link}">${page.linktitle}</a></li>\
- % endfor
- </ul>\
-
-
-= Generation of a side-menu =
-
-This again is done via a suitable [[template_mako]]. The
-template uses the function "`get_sidemenu()`" and returns (level,
-part_of_path, is_current, title, link) tuples. Again all links are relative
-to the calling page.
-
-* "`level`" is the indendation level, starting with 0. You can use this for
- CSS "`id=`" or "`class`" attributes
-* "`part_of_path`" is a flag telling you if the mentioned page is part
- of your path, i.e. if the specified page is in the breadcrumbs.
-* "`is_current`" is a flag marking the current page.
-* "`title`" is the full title for the page
-* "`link`" is the relative URL to the page
-
-Here's a sample Mako template excerpt that converts this into a HTML menu:
-
- <ul id="sidebar">
- % for level, part_of_path, current, page, link in get_sidemenu():
- <li class="sidebar${level}"\
- % if current:
- id="sidebar_current">${page.linktitle | entity}</li>
- % else:
- ><a href="${link}">${page.linktitle | entity}</a></li>
- % endif
- % endfor
- </ul>
-
-= Generate a list of recently changed pages =
-
-To get a list of recently changed pages, do this:
-
- <%
- history = get_recently())
- %>
- % if len(history)>1:
- <h2>Recent changed</h2>
- % for page, link in history:
- % if page.mtime > page.ctime:
- Modified ${format_date(page.mtime)}\
- % else:
- Created ${format_date(page.ctime)}\
- % endif
- : <a href="${link}">${page.title | entity}</a><br />
- % endfor
- % endif
-
-
-= Generate a sitemap =
-
-To generate a site map for your whole project, do something like
-this:
-
- <%
- site = get_sitemap()
- %>
- <ul>
- % for level, page, link in site:
- <li id="sidemap${level}"><a href="${link}">${page.title}</a></li>
- % endfor
- </ul>
-
-Now you'd need to use CSS to indent the entries. If you prefer a more
-normal "`<ul>..<li><ul><li></li></ul>..</il>`" style, you'd could do this
-with some more advanced Mako template magic:
-
- <%
- site = get_sitemap()
- lvl = -1
- %>
- % for level, page, link in site:
- ### Adjust level by indenting/detenting via <ul> or </ul>:
- % while lvl < level:
- <ul><% lvl += 1 %>
- % endwhile
- % while lvl > level:
- </ul><% lvl -= 1 %>
- % endwhile
- ### Print out the <li>
- <li id="sidemap${level}"><a href="${link}">${page.title}</a></li>
- % endfor
- ### At the end of the sitemap, detent back to level -1
- % while lvl >= 0:
- </ul><% lvl -= 1 %>
- % endwhile
+++ /dev/null
-title: Plugins
-parent: Webber
-ctime: 2009-06-26
-
-Webber doesn't do much on it's own. Almost all the real work is delegated
-to plugins. Those plugins do:
-
-* Read files and generate HTML snippets ([[read_rst.py|read_rst]],
- [[read_markdown.py|read_markdown]], [[read_html.py|read_html]])
- or copy files verbatim, e.g. for graphics
- ([[read_copyonly.py|read_copyonly]])
-* Update internal state or modify HTML snippets
- ([[hierarchy.py|hierarchy]], [[link.py|link]])
-* Create HTML pages ([[template_mako.py|template_mako]])
-* Create additional output files ([[google_sitemap.py||Google Sitemap generation]])
-
-There's another plugin there ([[skeleton.py|skeleton]]), which is
-is just a demo for plugin-programmers.
-
-Plugins simply reside in the "`plugins/`" directory. However, webber
-doesn't load all of them automatically. Instead you specify in the
-configuration file [[webber.conf|configuration]] which
-plugins you want.
-
-Once plugins are loaded, webber orchestrates the work of itself and
-all plugins via [[hooks]].
+++ /dev/null
-title: Create HTML links
-linktitle: link.py
-parent: Plugins
-ctime: 2009-06-26
-
-This plugin converts strings in the form
-
-<pre><code>[</code><code>[url]]
-[</code><code>[text|url]]
-[</code><code>[#anchor]]
-[</code><code>[text|url#anchor]]
-</code></pre>
-
-into HTML `<a href=...>` tags.
-
-= Automatic linkification =
-
-Instead of an URL you can also specify the following things:
-
-* the page title
-* the short link title
-* the basename of the file (filename without extension and directory name)
-
-In this case the link plugin will search throught all pages and take the
-first match.
-
-Example:
-
-Suppose you've two file "`testfile.md`" and "`testfile2.md`" which looks like this:
-
- title: Foo
- linktitle: bar
-
----
-
- title: Test2
-
-then the following two links
-
-<pre><code>[</code><code>[Foo]]
-[</code><code>[bar]]
-[</code><code>[testfile2]]
-</code></pre>
-
-will produce two links to the first file and one link to the second file.
-All text part of the HTML link will be substituted with the title of the
-referred pages, except you specify a text by yourself.
+++ /dev/null
-title: Read and copy binary files
-linktitle: read_copyonly.py
-parent: Plugins
-ctime: 2009-06-26
-
-This plugin copies files (e.g. graphics files) into the destination
-folder.
-
-To configure which files should be copied you modify
-[[webber.conf|configuration.html]]. An example snippet migth be:
-
- copy_files: [
- "*.png",
- "*.jpg",
- "*.gif",
- "*.css",
- "robots.txt",
- ]
+++ /dev/null
-title: Read HTML
-linktitle: read_html.py
-parent: Plugins
-ctime: 2009-06-26
-
-This plugin reads HTML snippets from "`*.html`" files.
-
-Please note that currently the plugin assumes that this is a HTML snippet.
-That means: the snippes should only contain what is inside "`<body>`" and
-"`</body>`", but without those tags themselfes.
-
-A sample "`test.html`" document looks like this:
-
- title: Job
- parent: Home
- ctime: 2008-10-01
-
- <p>What I did in the past:<P>
- <!-- to be continued -->
-
-You'll find more about "`title:`", "`parent:`" and "`ctime:`" in the
-[[page format|pageformat.html]] description.
+++ /dev/null
-title: Read Markdown
-linktitle: read_markdown.py
-parent: Plugins
-ctime: 2009-06-26
-
-This plugin reads "`*.md`" files and converts them to HTML.
-
-"[[Markdown|http://daringfireball.net/projects/markdown/]]" is a wiki-like
-text format. The plugin "`read_markdown.py`" doesn't use the
-standard Python module "`markdown`", but instead the faster and simpler
-[[markdown2|http://code.google.com/p/python-markdown2/]] modoule.
-
-A sample "`test.md`" document looks like this:
-
- title: Impressum
- parent: Home
- ctime: 2008-10-01
-
- # Address
-
- Mario Marionetti
- 10, Mariott St
- Marioland 1007
-
- Don't send me spam, *ever*!
-
-You'll find more about "`title:`", "`parent:`" and "`ctime:`" in the
-[[page format|pageformat.html]] description.
-
-= Modifications =
-
-This implementation is based on python-markdown2 version 1.0.1.12, but has been
-changed this way:
-
-* file-vars (emacs-style settings inside the file) have been disabled
-* "Standardize line endings" removed
-* call to _do_links() removed (we have the [[linkify|link.html]] pass for
- this)
-* logging removed
-* allow "= Header =" in addition to "# Header #"
+++ /dev/null
-title: Read RST
-linktitle: read_rst.py
-parent: Plugins
-ctime: 2009-06-26
-
-This plugin reads "`*.rst`" files and converts them to HTML.
-
-"RST" is the abbreviation for
-[[reStructuredText|http://docutils.sourceforge.net/rst.html]], a format
-common for many python programmers. The plugin "`read_rst.py`" uses the
-standard Python module "`docutils`" to convert RST into HTML. A sample
-"`test.rst`" document looks like this:
-
- title: Impressum
- parent: Home
- ctime: 2008-10-01
-
- Address
- =======
-
- |Mario Marionetti
- |10, Mariott St
- |Marioland 1007
-
- Don't send me spam, *ever*!
-
-You'll find more about "`title:`", "`parent:`" and "`ctime:`" in the
-[[page format|pageformat.html]] description.
\ No newline at end of file
+++ /dev/null
-title: Sample plugin skeleton
-linktitle: skeleton.py
-parent: Plugins
-ctime: 2009-06-26
-
-TODO
+++ /dev/null
-title: Web page template
-linktitle: template_mako.py
-parent: Plugins
-ctime: 2009-06-26
-
-TODO
+++ /dev/null
-title: Sitemap
-parent: Webber
-template: sitemap
-
-The following pages exist:
+++ /dev/null
-title: Templates
-parent: Webber
-ctime: 2009-06-24
-
-TODO
projects / oss-web.git / commitdiff