diff options
author | intrigeri <intrigeri@boum.org> | 2009-01-01 13:34:00 +0100 |
---|---|---|
committer | intrigeri <intrigeri@boum.org> | 2009-01-01 13:34:00 +0100 |
commit | 5c2f6cb8935f828274511ba5ca0d92b586632740 (patch) | |
tree | 0c72d1f73c0424236a98a1d51d192ee5e0e507ae /doc | |
parent | c3af3840a295780e0f32df398f2dc7d34653e75e (diff) | |
parent | 8202cfe19e65867d7e41339944a8d7ca6daffa22 (diff) |
Merge commit 'upstream/master' into prv/po
Diffstat (limited to 'doc')
-rw-r--r-- | doc/download.mdwn | 2 | ||||
-rw-r--r-- | doc/ikiwiki-transition.mdwn | 36 | ||||
-rw-r--r-- | doc/ikiwiki/directive.mdwn | 16 | ||||
-rw-r--r-- | doc/ikiwiki/pagespec.mdwn | 19 | ||||
-rw-r--r-- | doc/news/ikiwiki_version_3.0.mdwn | 42 | ||||
-rw-r--r-- | doc/plugins/aggregate.mdwn | 36 | ||||
-rw-r--r-- | doc/plugins/contrib.mdwn | 2 | ||||
-rw-r--r-- | doc/plugins/discussion.mdwn | 9 | ||||
-rw-r--r-- | doc/plugins/embed.mdwn | 8 | ||||
-rw-r--r-- | doc/plugins/googlecalendar.mdwn | 20 | ||||
-rw-r--r-- | doc/plugins/htmlscrubber.mdwn | 8 | ||||
-rw-r--r-- | doc/plugins/lockedit.mdwn | 2 | ||||
-rw-r--r-- | doc/plugins/write.mdwn | 6 | ||||
-rw-r--r-- | doc/plugins/write/tutorial.mdwn | 2 | ||||
-rw-r--r-- | doc/roadmap.mdwn | 53 | ||||
-rw-r--r-- | doc/security.mdwn | 2 | ||||
-rw-r--r-- | doc/tips/embedding_content.mdwn | 35 | ||||
-rw-r--r-- | doc/tips/github.mdwn | 67 | ||||
-rw-r--r-- | doc/tips/upgrade_to_3.0.mdwn | 95 | ||||
-rw-r--r-- | doc/todo/firm_up_plugin_interface.mdwn | 2 | ||||
-rw-r--r-- | doc/todo/need_global_renamepage_hook.mdwn | 6 | ||||
-rw-r--r-- | doc/users/smcv/gallery.mdwn | 266 | ||||
-rw-r--r-- | doc/wikiicons/openidlogin-bg.gif | bin | 142 -> 336 bytes |
23 files changed, 599 insertions, 135 deletions
diff --git a/doc/download.mdwn b/doc/download.mdwn index 1099045b5..067938f87 100644 --- a/doc/download.mdwn +++ b/doc/download.mdwn @@ -26,7 +26,7 @@ There is a backport of a recent version of ikiwiki for Debian 4.0 at Fedora versions 8 and newer have RPMs of ikiwiki available. -There is also an unofficial backport of ikiwiki for Ubuntu Hardy, provided by +There is also an unofficial backport of ikiwiki for Ubuntu Intrepid, provided by [[Paweł_Tęcza|users/ptecza]], at [http://gpa.net.icm.edu.pl/ubuntu/](http://gpa.net.icm.edu.pl/ubuntu/index-en.html). diff --git a/doc/ikiwiki-transition.mdwn b/doc/ikiwiki-transition.mdwn index 8b7c3579f..18836d5f5 100644 --- a/doc/ikiwiki-transition.mdwn +++ b/doc/ikiwiki-transition.mdwn @@ -8,24 +8,23 @@ ikiwiki-transition type ... # DESCRIPTION -`ikiwiki-transition` aids in converting wiki pages when -there's a major change in ikiwiki syntax. It also handles other transitions -not involving wiki pages. +`ikiwiki-transition` aids in converting wiki pages when there's a major +change in ikiwiki syntax. It also handles other transitions not involving +wiki pages. -# prefix_directives +# prefix_directives your.setup -The `prefix_directives` mode converts the specified ikiwiki page from -the old preprocessor directive syntax, requiring a space, to the new -syntax, prefixed by '!'. +The `prefix_directives` mode converts all pages from the old preprocessor +directive syntax, requiring a space, to the new syntax, prefixed by '!'. Preprocessor directives which already use the new syntax will remain unchanged. -Note that if the page contains wiki links with spaces, which some +Note that if a page contains wiki links with spaces, which some older versions of ikiwiki accepted, the prefix_directives transition will treat these as preprocessor directives and convert them. -# setupformat +# setupformat your.setup The `setupformat` mode converts a setup file from using a single `wrappers` block to using `cgi_wrapper`, `git_wrapper`, etc. @@ -33,25 +32,30 @@ to using `cgi_wrapper`, `git_wrapper`, etc. Note that all comments and any unusual stuff like perl code in the setup file will be lost, as it is entirely rewritten by the transition. -# aggregateinternal +# aggregateinternal your.setup The `aggregateinternal` mode moves pages aggregated by the aggregate plugin so that the `aggregateinternal` option can be enabled. -# indexdb +# moveprefs your.setup + +Moves values that used to be admin preferences into the setup file. + +Note that all comments and any unusual stuff like perl code in the setup +file will be lost, as it is entirely rewritten by the move. + +# indexdb srcdir The `indexdb` mode handles converting a plain text `.ikiwiki/index` file to -a binary `.ikiwiki/indexdb`. In this mode, you should specify the srcdir of -the wiki as the second parameter. You do not normally need to run +a binary `.ikiwiki/indexdb`. You do not normally need to run `ikiwiki-transition indexdb`; ikiwiki will automatically run it as necessary. -# hashpassword +# hashpassword srcdir The `hashpassword` mode forces any plaintext passwords stored in the `.ikiwiki/userdb` file to be replaced with password hashes. (The -Authen::Passphrase perl module is needed to do this.) In this mode, you -should specify the srcdir of the wiki as the second parameter. +Authen::Passphrase perl module is needed to do this.) If this is not done explicitly, a user's plaintext password will be automatically converted to a hash when a user logs in for the first time diff --git a/doc/ikiwiki/directive.mdwn b/doc/ikiwiki/directive.mdwn index c4342dee8..fb88aa72d 100644 --- a/doc/ikiwiki/directive.mdwn +++ b/doc/ikiwiki/directive.mdwn @@ -28,15 +28,13 @@ of text with triple-quotes: 3. "baz" """]] -ikiwiki also has an older syntax for directives, which requires a -space in directives to distinguish them from [[wikilinks|ikiwiki/wikilink]]. -This syntax has several disadvantages: it requires a space after directives -with no parameters (such as `\[[pagecount ]]`), and it prohibits spaces in -[[wikilinks|ikiwiki/wikilink]]. ikiwiki now provides the `!`-prefixed syntax -shown above as the preferred alternative. However, ikiwiki still supports -wikis using the older syntax, if the `prefix_directives` option is not enabled. -For backward compatibility with existing wikis, this option currently -defaults to off, so ikiwiki supports the old syntax. +ikiwiki also has an older syntax for directives, which requires a space in +directives to distinguish them from [[wikilinks|ikiwiki/wikilink]]. This +syntax has several disadvantages: it requires a space after directives with +no parameters (such as `\[[pagecount ]]`), and it prohibits spaces in +[[wikilinks|ikiwiki/wikilink]]. ikiwiki now provides the `!`-prefixed +syntax shown above as default. However, ikiwiki still supports wikis using +the older syntax, if the `prefix_directives` option is disabled. [[!if test="enabled(listdirectives)" then=""" Here is a list of currently available directives in this wiki: diff --git a/doc/ikiwiki/pagespec.mdwn b/doc/ikiwiki/pagespec.mdwn index d4dd265cc..86abe5745 100644 --- a/doc/ikiwiki/pagespec.mdwn +++ b/doc/ikiwiki/pagespec.mdwn @@ -72,22 +72,3 @@ filenames of the pages in the wiki, so a pagespec "foo" used on page "a/b" will not match a page named "a/foo" or "a/b/foo". To match relative to the directory of the page containing the pagespec, you can use "./". For example, "./foo" on page "a/b" matches page "a/foo". - -## Old syntax - -The old PageSpec syntax was called a "GlobList", and worked differently in -two ways: - -1. "and" and "or" were not used; any page matching any item from the list - matched. -2. If an item was prefixed with "`!`", then no page matching that item - matched, even if it matched an earlier list item. - -For example, here is the old way to match all pages except for the SandBox -and Discussion pages: - - * !SandBox !*/Discussion - -Using this old syntax is still supported. However, the old syntax is -deprecated and will be removed at some point, and using the new syntax is -recommended. diff --git a/doc/news/ikiwiki_version_3.0.mdwn b/doc/news/ikiwiki_version_3.0.mdwn new file mode 100644 index 000000000..7ca636cf2 --- /dev/null +++ b/doc/news/ikiwiki_version_3.0.mdwn @@ -0,0 +1,42 @@ +Ikiwiki has reached version 3.0 and entered a new phase in its +[[development_cycle|roadmap]]. + +The 3.0 release of ikiwiki changes several defaults and finishes +some transitions. You will need to modify your wikis to work with +ikiwiki 3.0. A document explaining the process is available +in [[tips/upgrade_to_3.0]]. + +The highlights of the changes in version 3.0 include: + +* Support for uploading [[attachments|plugins/attachment]]. +* Can [[plugins/rename]] and [[plugins/remove]] pages and files via the web. +* [[Web_based_setup|plugins/websetup]]. +* Blog-style [[plugins/comments]] as an alternative to Discussion pages. +* Many other new plugins including [[plugins/htmlbalance]], [[plugins/format]], + [[plugins/progress]], [[plugins/color]], [[plugins/autoindex]], + [[plugins/cutpaste]], [[plugins/hnb]], [[plugins/creole]], [[plugins/txt]], + [[plugins/amazon_s3]], [[plugins/pinger]], [[plugins/pingee]], + [[plugins/edittemplate]] +* The RecentChanges page is compiled statically, not generated from the CGI. +* Support for additional revision control systems: [[rcs/bzr]], + [[rcs/monotone]] +* Support for [[tips/untrusted_git_push]]. +* A new version (3.00) of the plugin API, exporting additional + commonly used functions from `IkiWiki.pm`. +* Nearly everything in ikiwiki is now a plugin, from WikiLinks to + page editing, to RecentChanges. +* Far too many bug fixes, features, and enhancements to list here. + +Thanks to the many contributors to ikiwiki 3.0, including: + + Jelmer Vernooij, Recai Oktaş, William Uther, Simon McVittie, Axel Beckert, + Bernd Zeimetz, Gabriel McManus, Paweł Tęcza, Peter Simons, Manoj + Srivastava, Patrick Winnertz, Jeremie Koenig, Josh Triplett, thm, Michael + Gold, Jason Blevins, Alexandre Dupas, Henrik Brix Andersen, Thomas Keller, + Enrico Zini, intrigeri, Scott Bronson, Brian May, Adeodato Simó, Brian + Downing, Nis Martensen. (And anyone I missed.) + +Also, thanks to the users, bug submitters, and documentation wiki editors. +Without you, ikiwiki would just be a little thing I use for my home page. + +--[[Joey]] diff --git a/doc/plugins/aggregate.mdwn b/doc/plugins/aggregate.mdwn index 6fc87853b..e2efcd83f 100644 --- a/doc/plugins/aggregate.mdwn +++ b/doc/plugins/aggregate.mdwn @@ -5,10 +5,6 @@ This plugin allows content from other feeds to be aggregated into the wiki. To specify feeds to aggregate, use the [[ikiwiki/directive/aggregate]] [[ikiwiki/directive]]. -New users of aggregate should enable the `aggregateinternal => 1` option in the -.setup file. If you don't do so, you will need to enable the [[html]] plugin -as well as aggregate itself, since feed entries will be stored as HTML. - The [[meta]] and [[tag]] plugins are also recommended. Either the [[htmltidy]] or [[htmlbalance]] plugin is suggested, since feeds can easily contain html problems, some of which these plugins can fix. @@ -27,37 +23,19 @@ visit is `http://whatever/ikiwiki.cgi?do=aggregate_webtrigger`. Anyone can visit the url to trigger an aggregation run, but it will only check each feed if its `updateinterval` has passed. -## internal pages and `aggregateinternal` +## aggregated pages This plugin creates a page for each aggregated item. If the `aggregateinternal` option is enabled in the setup file (which is -recommended), aggregated pages are stored in the source directory with a +the default), aggregated pages are stored in the source directory with a "._aggregated" extension. These pages cannot be edited by web users, and do not generate first-class wiki pages. They can still be inlined into a blog, but you have to use `internal` in [[PageSpecs|IkiWiki/PageSpec]], like `internal(blog/*)`. -For backward compatibility, the default is that these pages have the -".html" extension, and are first-class wiki pages -- each one generates -a separate HTML page in the output, and they can even be edited. - -That turns out to not be ideal for aggregated content, because publishing -files for each of those pages is a waste of disk space and CPU, and you -probably don't want to allow them to be edited. So, there is an alternative -method that can be used (and is recommended), turned on by the -`aggregateinternal` option in the setup file. - -If you are already using aggregate and want to enable `aggregateinternal`, -you should follow this process: - -1. Update all [[PageSpecs|ikiwiki/PageSpec]] that refer to the aggregated - pages -- such as those in inlines. Put "internal()" around globs - in those PageSpecs. For example, if the PageSpec was `foo/*`, it should - be changed to `internal(foo/*)`. This has to be done because internal - pages are not matched by regular globs. -2. Turn on `aggregateinternal` in the setup file. -3. Use [[ikiwiki-transition]] to rename all existing aggregated `.html` - files in the srcdir. The command to run is - `ikiwiki-transition aggregateinternal $setupfile`, -4. Refresh the wiki. (`ikiwiki -setup your.setup -refresh`) +If `aggregateinternal` is disabled, you will need to enable the [[html]] +plugin as well as aggregate itself, since feed entries will be stored as +HTML, and as first-class wiki pages -- each one generates +a separate HTML page in the output, and they can even be edited. This +option is provided only for backwards compatability. diff --git a/doc/plugins/contrib.mdwn b/doc/plugins/contrib.mdwn index 7a28edaba..e22b13f71 100644 --- a/doc/plugins/contrib.mdwn +++ b/doc/plugins/contrib.mdwn @@ -2,6 +2,6 @@ Contributed [[plugins]]: (See [[install]] for installation help.) -[[!inline pages="plugins/contrib/* !*/Discussion" +[[!inline pages="plugins/contrib/* and !*/Discussion" feedpages="created_after(plugins/contrib/navbar)" archive="yes" rootpage="plugins/contrib" postformtext="Add a new plugin named:" show=0]] diff --git a/doc/plugins/discussion.mdwn b/doc/plugins/discussion.mdwn index 70157f1e2..854307a98 100644 --- a/doc/plugins/discussion.mdwn +++ b/doc/plugins/discussion.mdwn @@ -34,12 +34,3 @@ Any objections to listing plugins alphabetically rather than by creation date? >> "recently changed" list with the 10 most recently changed plugins >> at the top. That would allow what you suggested, but still allow >> the main list to be alphabetical. -- [[Will]] - -How about adding a deprecated tag in order to clean up the plugin list? - -> AFAIK it's currently the only one. --[[Joey]] - -For instance [[googlecalendar]] is listed as plugin but should probably be removed from Ikiwiki in a future major version (v3?). - --- [[AlexandreDupas]] - diff --git a/doc/plugins/embed.mdwn b/doc/plugins/embed.mdwn index 1d43061e0..85592cb72 100644 --- a/doc/plugins/embed.mdwn +++ b/doc/plugins/embed.mdwn @@ -13,6 +13,14 @@ In the examples below, the parts of the html that you can change are denoted with "XXX"; everything else must appear exactly as shown to be accepted by the plugin. +**This plugin is deprecated.** Rather than relying on these complex lists +of safe content, which constantly fall out of date, you're recommended to +configure the [[htmlscrubber]] to not scrub some pages, which only trusted +users can edit. Then you can embed anything from anywhere on those pages. +See [[tips/embedding_content]] for details and examples. +This plugin's lists of safe embedded content will not be maintained, and +the plugin will be removed in a future release. + ## google maps Use html like this to embed a map: diff --git a/doc/plugins/googlecalendar.mdwn b/doc/plugins/googlecalendar.mdwn deleted file mode 100644 index bca2ae74f..000000000 --- a/doc/plugins/googlecalendar.mdwn +++ /dev/null @@ -1,20 +0,0 @@ -[[!template id=plugin name=googlecalendar author="[[Joey]]"]] -[[!tag type/special-purpose]] - -*Note*: This plugin is deprecated. Please switch to the [[embed]] plugin. - -This plugin allows embedding a google calendar iframe in the wiki. -Normally, if the [[htmlscrubber]] is enabled, such iframes are scrubbed out -of the wiki content since they're not very safe if created by malicious -users. But some iframes are legitimate, and safe, if you trust the embedded -content. This plugin is an example of how to deal with this in ikiwiki. - -Example use: - - \[[!googlecalendar html=""" - <iframe src="http://www.google.com/calendar/embed?src=adkrdken8mupngh13jshlbenoc%40group.calendar.google.com&title=OSEL%20Calendar&chrome=NAVIGATION&bgcolor=%2371d873&height=588" style=" border-width:0 " width="480" frameborder="0" height="588"></iframe> - """]] - -The iframe should be the one provided by google. Note that it's used in a -way that avoids cross-site scripting attacks, assuming you trust google's -content. diff --git a/doc/plugins/htmlscrubber.mdwn b/doc/plugins/htmlscrubber.mdwn index b9f7e6d22..c59b46e14 100644 --- a/doc/plugins/htmlscrubber.mdwn +++ b/doc/plugins/htmlscrubber.mdwn @@ -32,10 +32,10 @@ other HTML-related functionality, such as whether [[meta]] allows potentially unsafe HTML tags. The `htmlscrubber_skip` configuration setting can be used to skip scrubbing -of some pages. Set it to a [[ikiwiki/PageSpec]], such as "!*/Discussion", and pages -matching that can have all the evil CSS, JavsScript, and unsafe html -elements you like. One safe way to use this is to use [[lockedit]] to lock -those pages, so only admins can edit them. +of some pages. Set it to a [[ikiwiki/PageSpec]], such as "!*/Discussion", +and pages matching that can have all the evil CSS, JavsScript, and unsafe +html elements you like. One safe way to use this is to use [[lockedit]] to +lock those pages, so only admins can edit them. ---- diff --git a/doc/plugins/lockedit.mdwn b/doc/plugins/lockedit.mdwn index d2e98e07a..c8f64ea47 100644 --- a/doc/plugins/lockedit.mdwn +++ b/doc/plugins/lockedit.mdwn @@ -4,7 +4,7 @@ This plugin allows the administrator of a wiki to lock some pages, limiting who can edit them using the online interface. This doesn't prevent anyone who can commit to the underlying revision control system from editing the -pages, however. +pages, however. (Unless you set up [[tips/untrusted_git_push]].) The `locked_pages` setting configures what pages are locked. It is a [[ikiwiki/PageSpec]], so you have lots of control over what kind of pages diff --git a/doc/plugins/write.mdwn b/doc/plugins/write.mdwn index d024a5dd4..eb50ca4ef 100644 --- a/doc/plugins/write.mdwn +++ b/doc/plugins/write.mdwn @@ -19,7 +19,7 @@ that can be fleshed out to make a useful plugin. `IkiWiki::Plugin::pagecount` is another simple example. All perl plugins should `use IkiWiki` to import the ikiwiki plugin interface. It's a good idea to include the version number of the plugin interface that your plugin -expects: `use IkiWiki 2.00`. +expects: `use IkiWiki 3.00`. An external plugin is an executable program. It can be written in any language. Its interface to ikiwiki is via XML RPC, which it reads from @@ -442,7 +442,7 @@ describes the plugin as a whole. For example: To import the ikiwiki plugin interface: - use IkiWiki '2.00'; + use IkiWiki '3.00'; This will import several variables and functions into your plugin's namespace. These variables and functions are the ones most plugins need, @@ -497,7 +497,7 @@ use the following hashes, using a page name as the key: destination file. * `%pagesources` contains the name of the source file for each page. -Also, the %IkiWiki::version variable contains the version number for the +Also, the `%IkiWiki::version` variable contains the version number for the ikiwiki program. ### Library functions diff --git a/doc/plugins/write/tutorial.mdwn b/doc/plugins/write/tutorial.mdwn index e1b34b800..5345f71f2 100644 --- a/doc/plugins/write/tutorial.mdwn +++ b/doc/plugins/write/tutorial.mdwn @@ -27,7 +27,7 @@ important one is the IkiWiki module. use warnings; use strict; - use IkiWiki 2.00; + use IkiWiki 3.00; Ok, boilerplate is out of the way. Now to add the one function that ikiwiki expects to find in any module: `import`. The import function is called when diff --git a/doc/roadmap.mdwn b/doc/roadmap.mdwn index 9ed5742eb..2f79f7978 100644 --- a/doc/roadmap.mdwn +++ b/doc/roadmap.mdwn @@ -7,10 +7,7 @@ This is the roadmap for ikiwiki development. Released 29 April 2006. -The 1.x series changed a great deal over the more than 50 releases in its -lifetime. It is now in maintenance mode, only security issues or really bad -bugs will be fixed in 1.x going forward. 1.x will stop being supported with -the release of 3.0. +The 1.x series is no longer supported. ---- @@ -32,27 +29,43 @@ the release of 3.0. Released 30 April 2007. -The 2.x series is expected to undergo continuing development for some time, -adding improvements and new features, but avoiding changes that break -backwards compatability. +The 2.x series is now in maintenance mode. Only security fixes and fixes for +really bad bugs will be applied going forward. ---- # 3.0 -Version 3.0 will be an opportunity to make significant transitions. - -* Default to using `prefix_directives`. -* Default to using `aggregateinternal`. -* Remove deprecated prefs form settings for `allowed_attachments` and - `locked_pages`. -* Finalise a new version of the plugin API, exporting additional commonly - used functions from IkiWiki.pm. See [[todo/firm_up_plugin_interface]] - -It will include a vast number of new features, bugfixes, and other -improvements, far too many to list here. - -Release is planned for fall^Wlate, 2008. +Version 3.0 is an opportunity to make significant transitions. +Read [[tips/upgrade_to_3.0]] for the steps you will need to +follow when upgrading your wiki to this version. + +The highlights of the changes in version 3.0 include: + +* Support for uploading [[attachments|plugins/attachment]]. +* Can [[plugins/rename]] and [[plugins/remove]] pages and files via the web. +* [[Web_based_setup|plugins/websetup]]. +* Blog-style [[plugins/comments]] as an alternative to Discussion pages. +* Many other new plugins including [[plugins/htmlbalance]], [[plugins/format]], + [[plugins/progress]], [[plugins/color]], [[plugins/autoindex]], + [[plugins/cutpaste]], [[plugins/hnb]], [[plugins/creole]], [[plugins/txt]], + [[plugins/amazon_s3]], [[plugins/pinger]], [[plugins/pingee]], + [[plugins/edittemplate]] +* The RecentChanges page is compiled statically, not generated from the CGI. +* Support for additional revision control systems: [[rcs/bzr]], + [[rcs/monotone]] +* Support for [[tips/untrusted_git_push]]. +* A new version (3.00) of the plugin API, exporting additional + commonly used functions from `IkiWiki.pm`. +* Nearly everything in ikiwiki is now a plugin, from WikiLinks to page + editing, to RecentChanges. +* Far too many bug fixes, features, and enhancements to list here. + +Released 31 December, 2008. + +The 3.x series is expected to undergo continuing development for some time, +adding improvements and new features, but avoiding changes that break +backwards compatability. ---- diff --git a/doc/security.mdwn b/doc/security.mdwn index b067a8a16..939d65d01 100644 --- a/doc/security.mdwn +++ b/doc/security.mdwn @@ -416,4 +416,4 @@ attack. intrigeri discovered this problem on 12 Nov 2008 and a patch put in place later that day, in version 2.70. The fix was backported to testing as version -2.53.2, and to stable as version 1.33.7. +2.53.3, and to stable as version 1.33.7. diff --git a/doc/tips/embedding_content.mdwn b/doc/tips/embedding_content.mdwn new file mode 100644 index 000000000..142acd16e --- /dev/null +++ b/doc/tips/embedding_content.mdwn @@ -0,0 +1,35 @@ +Content from sites such as YouTube can be embedded into a web page. Maybe +you want to do this. But you'll find that the [[plugins/htmlscrubber]] +doesn't let you. It blocks the tags used to embed such content, because +they can be abused in many evil ways. + +Some plugins have been written to try to work around this problem, by +whitelisting the html needed to embed things from a few sites like Google +maps, calendar, videos, and YouTube. The problem with these plugins is that +they have to be kept up to date to add new sites, and follow changes to the +html such sites use for embedding. + +(Digression: The real problem with the plugins is that they hide the +underlying trust relationship. If you decide to embed html from a site, +you'd better trust that site. And if ikiwiki lets you enter such html, it +needs to trust you.) + +The [[plugins/htmlscrubber]] offers a different way around this problem. +You can configure it to skip scrubbing certian pages, so that content from +elsewhere can be embedded on those pages. Then use [[plugins/lockedit]] +to limit who can edit those unscrubbed pages. + +For example, suppose your blog is all under `blog/*`, and you want +only yourself to be able to post there, and you'd like to be able to embed +youtube videos etc in your blog. Other users can edit some pages in the +wiki (Discussion pages, say), but not your blog posts. Then you could configure +ikiwiki as follows: + + htmlscrubber_skip => 'blog/* and !*/Discussion', + locked_pages => '!*/Discussion', + +More simply, you might want to allow yourself to embed content anywhere +on the wiki, but scrub content written on Discussion pages: + + htmlscrubber_skip => '!*/Discussion', + locked_pages => '!*/Discussion', diff --git a/doc/tips/github.mdwn b/doc/tips/github.mdwn new file mode 100644 index 000000000..cd1b479d1 --- /dev/null +++ b/doc/tips/github.mdwn @@ -0,0 +1,67 @@ +Here's how to set up a static wiki or blog using ikiwiki with no hosting +feeds. Everything is hosted on github, both the git repository and the web +site. Your laptop is used to generate and publish changes to it. + +This is possible because github now supports +[github pages](http://github.com/blog/272-github-pages). + +Note that github limits free accounts to 100 mb of git storage. It's +unlikely that a small wiki or blog will outgrow this, but we are keeping +two copies of the website in git (source and the compiled site), and all +historical versions too. So it could happen. If it does, you can pay github +for more space, or you can migrate your site elsewhere. + +## github setup + +* Go to [github](http://github.com/) and sign up for an account, if you + haven't already. +* Be sure to add your laptop's ssh key to it so you can push + to github. +* Create a repository on githib named `$YOU.github.com`, substituting your + username. This repository will be used to publish your compiled website. +* Create a repository on github named `$YOU` (or anything else you like). + This repository will be used to publish the source of your website. + This is actually optional. + +## local setup + +* On your laptop, create two empty git repositories to correspond to the + github repositories: + YOU=# your github username here + mkdir ~/$YOU.github.com + cd ~/$YOU.github.com + git init + git remote add origin git@github.com:$YOU/$YOU.github.com.git + mkdir ~/$YOU + cd ~/$YOU + git init + git remote add origin git@github.com:$YOU/$YOU.git +* Add some wiki pages, such as an `index.mdwn`, to `~/$YOU`, and check them + in and commit them to git. You need something to push to github. Run + `git push origin master` to push the source pages to github. + +## publishing to github + +* Now build your wiki with a command such as: + ikiwiki ~/$YOU ~/$YOU.github.com --refresh +* Each time you build the wiki you will need to commit the changes + to git, and push the compiled pages to github: + cd ~/YOU.github.com + git add . + git commit -a -m update + git push origin master + +Your wiki will show up at `http://$YOU.github.com/` within ten +minutes after the first push, and changes you push to it from then on +should show up immediatly. + +## enhancements + +You can follow the instructions in [[laptop_wiki_with_git]] to set up an +editable version of your wiki on your laptop. Then you can use the web +interface for editing. You'll still need to follow the instructions above +to publish your changes to github. + +It would also be possible to teach ikiwiki to push compiled pages to github +itself via a plugin, as was done with the [[plugins/amazon_s3]] plugin. Not +done yet! diff --git a/doc/tips/upgrade_to_3.0.mdwn b/doc/tips/upgrade_to_3.0.mdwn new file mode 100644 index 000000000..b8a75aeca --- /dev/null +++ b/doc/tips/upgrade_to_3.0.mdwn @@ -0,0 +1,95 @@ +Version 3.0 of ikiwiki makes some significant changes, which +you will need to deal with when upgrading from ikiwiki 2.x. + +[[!toc ]] + +## setup file format change + +The layout of the setup file changed in a significant way in version 2.60 +of ikiwiki. If you have not changed yours to the new format, now would be a +good time to do so. Some new features, like the [[plugins/websetup]] +interface, need the new format setup file. + +You can convert old setup files into the new format by running +`ikiwiki-transition setupformat your.setup` + +## moving settings from Preferences page + +The admin preferences page used to have settings for allowed attachments, +locked pages, and banned users. These three settings have moved to the +setup file, and will no longer appear on the admin preferences page once +your wiki is upgraded to 3.0. + +You can move these preferences into the setup file by running +`ikiwiki-transition moveprefs your.setup; ikiwiki -setup your.setup -refresh -wrappers` + +(Make sure you have converted the setup file to the new format first.) + +## prefix directives + +In 3.0, the syntax ikiwiki uses for [[directives|ikiwiki/directive]] has +changed, requiring that the directive start with a bang: + + \[[!directive ...]] + +If you would like to keep the old syntax, it is still supported, add the +following to your setup file: + + prefix_directives => 0, + +To convert to the new syntax, run +`ikiwiki-transition prefix_directives your.setup` + +(And then commit the changes it makes to pages in your srcdir.) + +## GlobLists + +In 3.0, the old "GlobList" syntax for [[PageSpecs|ikiwiki/PageSpec]] is no +longer supported. A GlobList contains multiple term, but does not separate +them with "and" or "or": + + sandbox !*/Discussion + +To convert this to a modern PageSpec, simply add "and" or "or" as +appropriate between terms: + + sandbox and !*/Discussion + +GlobLists have been deprecated for more than two years. If your wiki dates +to the ikiwiki 1.0 era, you should check it for any that might have lurked +unnoticed in it since back then. Ikiwiki version 2.72 will print warnings +about any GlobLists it sees. + +## aggregateinternal + +If your wiki uses the [[aggregate|plugins/aggregate]] plugin, it will start +to aggregate feeds to special "internal" pages. + +If you don't want this change, you can add the following to your setup +file: + + aggregateinternal => 0, + +Otherwise, follow this procedure to upgrade a wiki using the aggregate plugin: + +1. Update all [[PageSpecs|ikiwiki/PageSpec]] that refer to the aggregated + pages -- such as those in inlines. Put "internal()" around globs + in those PageSpecs. For example, if the PageSpec was `foo/*`, it should + be changed to `internal(foo/*)`. This has to be done because internal + pages are not matched by regular globs. +2. Use [[ikiwiki-transition]] to rename all existing aggregated `.html` + files in the srcdir. The command to run is + `ikiwiki-transition aggregateinternal your.setup`, +3. Refresh the wiki. (`ikiwiki -setup your.setup -refresh`) + +## embed / googlecalendar + +The googlecalendar plugin has been deprecated for a long time, and is +removed in 3.0. + +The embed plugin is also now deprecated, though not yet removed. + +If you use either plugin to embed content from google, youtube, etc, +into your wiki, you should instead configure the [[plugins/htmlscrubber]] +to skip sanitising some pages, via the `htmlscrubber_skip` setting. +See [[embedding_content]] for examples. diff --git a/doc/todo/firm_up_plugin_interface.mdwn b/doc/todo/firm_up_plugin_interface.mdwn index c2e190884..c7553f7dd 100644 --- a/doc/todo/firm_up_plugin_interface.mdwn +++ b/doc/todo/firm_up_plugin_interface.mdwn @@ -92,3 +92,5 @@ Probably needs to evolve more and be more widely used before being exported. * %IkiWiki::pagecase (aggregate) * %IkiWiki::backlinks (pagestats) + +[[done]] (until 4.0).. diff --git a/doc/todo/need_global_renamepage_hook.mdwn b/doc/todo/need_global_renamepage_hook.mdwn index 8265497ae..f4e18baa2 100644 --- a/doc/todo/need_global_renamepage_hook.mdwn +++ b/doc/todo/need_global_renamepage_hook.mdwn @@ -25,7 +25,7 @@ It may seem like a corner case, but I want to be very careful when deleting files automatically in `srcdir`, which is not always under version control. -As an sad workaround, I can still disable any deletion in `srcdir` +As a sad workaround, I can still disable any deletion in `srcdir` when it is not under version control. But I think ikiwiki deserves a global `renamepage` hook that would be run once per rename operation. @@ -51,3 +51,7 @@ would solve my problem. Hmmm? --[[intrigeri]] > It might make sense to rename `renamepage` to `renamelink` to make it > clearer what it does. (I'm not very worried about this breaking things, at > this point.) --[[Joey]] + +>> In my `po` branch, I renamed `renamepage` to `renamelink`, and +>> created a `rename` hook that is passed a reference to `@torename`. +>> --[[intrigeri]] diff --git a/doc/users/smcv/gallery.mdwn b/doc/users/smcv/gallery.mdwn new file mode 100644 index 000000000..40e9f6279 --- /dev/null +++ b/doc/users/smcv/gallery.mdwn @@ -0,0 +1,266 @@ +[[!template id=plugin name=smcvgallery author="[[Simon_McVittie|smcv]]"]] +[[!tag type/chrome]] + +This plugin has not yet been written; this page is an experiment in +design-by-documentation :-) + +## Requirements + +This plugin formats a collection of images into a photo gallery, +in the same way as many websites: good examples include the +PHP application [Gallery](http://gallery.menalto.com/), Flickr, +and Facebook's Photos "application". + +The web UI I'm trying to achieve consists of one +[HTML page of thumbnails](http://www.pseudorandom.co.uk/2008/2008-03-08-panic-cell-gig/) +as an entry point to the gallery, where each thumbnail +links to +[a "viewer" HTML page](http://www.pseudorandom.co.uk/2008/2008-03-08-panic-cell-gig/img_0068/) +with a full size image, next/previous thumbnail links, and [[plugins/comments]]. + +(The Summer of Code [[plugins/contrib/gallery]] plugin does the +next/previous UI in Javascript using Lightbox, which means that +individual photos can't be bookmarked in a meaningful way, and +the best it can do as a fallback for non-Javascript browsers +is to provide a direct link to the image.) + +Other features that would be good to have: + +* minimizing the number of separate operations needed to make a gallery - + editing one source file per gallery is acceptable, editing one + source file per photo is not + +* keeping photos outside source code control, for instance in an + underlay + +* assigning [[tags|ikiwiki/directive/tag]] to photos, providing a + superset of Facebook's "show tagged photos of this person" functionality + +* constructing galleries entirely via the web by uploading attachments + +* inserting grouping (section headings) within a gallery; as in the example + linked above, I'd like this to split up the thumbnails but not the + next/previous trail + +* rendering an `<object>/<embed>` arrangement to display videos, and possibly + thumbnailing them in the same way as totem-video-thumbnailer + (my camera can record short videos, so some of my web photo galleries contain + them) + +My plan is to have these directives: + +* \[[!gallery]] registers the page it's on as a gallery, and displays all photos + that are part of this gallery but not part of a \[[!gallerysection]] (below). + + All images (i.e. `*.png *.jpg *.gif`) that are attachments to the gallery page + or its subpages are considered to be part of the gallery. + + Optional arguments: + + * filter="[[ikiwiki/PageSpec]]": only consider images to be part of the + gallery if they also match this filter + + * sort="date|filename": order in which to sort the images + +* \[[!gallerysection filter="[[ikiwiki/PageSpec]]"]] displays all photos in the + gallery that match the filter + +So, [the gallery I'm using as an example](http://www.pseudorandom.co.uk/2008/2008-03-08-panic-cell-gig/) +could look something like this: + + \[[!gallery]] + <!-- replaced with one uncategorized photo --> + + # Gamarra + + \[[!gallerysection filter="link(sometag)"]] + <!-- all the Gamarra photos --> + + # Smokescreen + + \[[!gallerysection filter="link(someothertag)"]] + <!-- all the Smokescreen photos --> + + <!-- ... --> + +## Implementation ideas + +The photo galleries I have at the moment, like the Panic Cell example above, +are made by using an external script to parse XML gallery descriptions (lists +of image filenames, with metadata such as titles), and using this to write IkiWiki +markup into a directory which is then used as an underlay. This is a hack, but it +works. The use of XML is left over from a previous attempt at solving the same +problem using Django. + +The next/previous part this plugin overlaps with [[todo/wikitrails]]. + +A \[[!galleryimg]] directive to assign metadata to images is probably necessary, so +the gallery page can contain something like: + + \[[!galleryimg p1010001.jpg title="..." caption="..." tags="foo"]] + \[[!galleryimg p1010002.jpg title="..." caption="..." tags="foo bar"]] + +Making the viewer pages could be rather tricky. + +One possibility is to write out the viewer pages as a side-effect of preprocessing +the \[[!gallery]] directive. The proof-of-concept implementation below does this. +However, this does mean the viewer pages can't have tags or metadata of their own +and can't be matched by [[pagespecs|ikiwiki/pagespec]] or +[[wikilinks|ikiwiki/wikilink]]. It might be possible to implement tagging by +using \[[!galleryimg]] to assign the metadata to the *images* instead of their +viewers, + +Another is to synthesize source pages for the viewers. This means they can have +tags and metadata, but trying to arrange for them to be scanned etc. correctly +without needing another refresh run is somewhat terrifying. +[[plugins/autoindex]] can safely create source pages because it runs in +the refresh hook, but I don't really like the idea of a refresh hook that scans +all source pages to see if they contain \[[!gallery]]... + +Making the image be the source page (and generate HTML itself) would be possible, +but I wouldn't want to generate a HTML viewer for every `.jpg` on a site, so +either the images would have to have a special extension (awkward for uploads from +Windows users) or the plugin would have to be able to change whether HTML was +generated in some way (not currently possible). + +## Proof-of-concept + + #!/usr/bin/perl + package IkiWiki::Plugin::gallery; + + use warnings; + use strict; + use IkiWiki 2.00; + + sub import { + hook(type => "getsetup", id => "gallery", call => \&getsetup); + hook(type => "checkconfig", id => "gallery", call => \&checkconfig); + hook(type => "preprocess", id => "gallery", + call => \&preprocess_gallery, scan => 1); + hook(type => "preprocess", id => "gallerysection", + call => \&preprocess_gallerysection, scan => 1); + hook(type => "preprocess", id => "galleryimg", + call => \&preprocess_galleryimg, scan => 1); + } + + sub getsetup () { + return + plugin => { + safe => 1, + rebuild => undef, + }, + } + + sub checkconfig () { + } + + # page that is a gallery => array of images + my %galleries; + # page that is a gallery => array of filters + my %sections; + # page that is an image => page name of generated "viewer" + my %viewers; + + sub preprocess_gallery { + # \[[!gallery filter="!*/cover.jpg"]] + my %params=@_; + + my $subpage = qr/^\Q$params{page}\E\//; + + my @images; + + foreach my $page (keys %pagesources) { + # Reject anything not a subpage or attachment of this page + next unless $page =~ $subpage; + + # Reject non-images + # FIXME: hard-coded list of extensions + next unless $page =~ /\.(jpg|gif|png|mov)$/; + + # Reject according to the filter, if any + next if (exists $params{filter} && + !pagespec_match($page, $params{filter}, + location => $params{page})); + + # OK, we'll have that one + push @images, $page; + + my $viewername = $page; + $viewername =~ s/\.[^.]+$//; + $viewers{$page} = $viewername; + + my $filename = htmlpage($viewername); + will_render($params{page}, $filename); + } + + $galleries{$params{page}} = \@images; + + # If we're just scanning, don't bother producing output + return unless defined wantarray; + + # actually render the viewers + foreach my $img (@images) { + my $filename = htmlpage($viewers{$img}); + debug("rendering image viewer $filename for $img"); + writefile($filename, $config{destdir}, "# placeholder"); + } + + # display a list of "loose" images (those that are in no section); + # this works because we collected the sections' filters during the + # scan stage + + my @loose = @images; + + foreach my $filter (@{$sections{$params{page}}}) { + my $_; + @loose = grep { !pagespec_match($_, $filter, + location => $params{page}) } @loose; + } + + my $_; + my $ret = "<ul>\n"; + foreach my $img (@loose) { + $ret .= "<li>"; + $ret .= "<a href=\"" . urlto($viewers{$img}, $params{page}); + $ret .= "\">$img</a></li>\n" + } + return "$ret</ul>\n"; + } + + sub preprocess_gallerysection { + # \[[!gallerysection filter="friday/*"]] + my %params=@_; + + # remember the filter for this section so the "loose images" section + # won't include these images + push @{$sections{$params{page}}}, $params{filter}; + + # If we're just scanning, don't bother producing output + return unless defined wantarray; + + # this relies on the fact that we ran preprocess_gallery once + # already, during the scan stage + my @images = @{$galleries{$params{page}}}; + @images = grep { pagespec_match($_, $params{filter}, + location => $params{page}) } @images; + + my $_; + my $ret = "<ul>\n"; + foreach my $img (@images) { + $ret .= "<li>"; + $ret .= htmllink($params{page}, $params{destpage}, + $viewers{$img}); + $ret .= "</li>"; + } + return "$ret</ul>\n"; + } + + sub preprocess_galleryimg { + # \[[!galleryimg p1010001.jpg title="" caption="" tags=""]] + my $file = $_[0]; + my %params=@_; + + return ""; + } + + 1 diff --git a/doc/wikiicons/openidlogin-bg.gif b/doc/wikiicons/openidlogin-bg.gif Binary files differindex c8f43d08e..a3bfe1098 100644 --- a/doc/wikiicons/openidlogin-bg.gif +++ b/doc/wikiicons/openidlogin-bg.gif |