]> git.vanrenterghem.biz Git - git.ikiwiki.info.git/blobdiff - debian/NEWS
Sign.
[git.ikiwiki.info.git] / debian / NEWS
index 983d1ae9d969044a20d2c0dff0c3150d930ab17f..a7a145d9bce7ee3a1bf307d73d2473ad862631f3 100644 (file)
@@ -1,3 +1,86 @@
+ikiwiki (2.62) unstable; urgency=low
+
+  TexImg standard preamble changed
+
+  The teximg plugin now has a configurable LaTeX preamble.
+  As part of this change the `mchem` LaTeX package has been removed from
+  the default LaTeX preamble as it wasn't included in many TeX installations.
+
+  The previous behaviour can be restored by adding the following to your
+  ikiwiki setup:
+
+        teximg_prefix => '\documentclass{scrartcl}
+                \usepackage[version=3]{mhchem}
+                \usepackage{amsmath}
+                \usepackage{amsfonts}
+                \usepackage{amssymb}
+                \pagestyle{empty}
+                \begin{document}',
+
+  In addition, the rendering mechanism has been changed to use `dvipng` by
+  default, if available.
+
+ -- Joey Hess <joeyh@debian.org>  Sun, 24 Aug 2008 15:00:40 -0400
+
+ikiwiki (2.60) unstable; urgency=low
+
+  Admin preferences are moving from the web interface to the setup file.
+  There are three new options in the setup file: `locked_pages`, `banned_users`,
+  and `allowed_attachments`. The admin prefs page can still be used, but
+  that's deprecated, and the prefs will be hidden if a value is not already
+  set. If a value is set in the web interface, you're encouraged to move that
+  setting to your setup file now, since version 3.0 will remove the deprecated
+  admin prefs web interface.
+
+  Also, the layout of the setup file has changed in a significant way in this
+  release. Old setup files will continue to work, but new features, like the
+  new websetup interface, require a new format setup file. You can convert
+  old setup files into the new format by running 
+  `ikiwiki-transition setupformat ikiwiki.setup`
+
+ -- Joey Hess <joeyh@debian.org>  Fri, 01 Aug 2008 17:02:14 -0400
+
+ikiwiki (2.52) unstable; urgency=low
+
+  All wikis need to be rebuilt on upgrade to this version. If you listed your
+  wiki in /etc/ikiwiki/wikilist this will be done automatically when the
+  Debian package is upgraded. Or use ikiwiki-mass-rebuild to force a rebuild.
+
+ -- Joey Hess <joeyh@debian.org>  Sun, 06 Jul 2008 15:10:05 -0400
+
+ikiwiki (2.49) unstable; urgency=low
+
+  The search plugin no longer uses hyperestraier. Instead, to use it you
+  will now need to install xapian-omega, and the Search::Xapian,
+  HTML::Scrubber, and Digest::SHA1 perl modules. Ie,
+  `apt-get install xapian-omega libsearch-xapian-perl libhtml-scrubber-perl libdigest-sha1-perl`
+
+  Also, wikis that use the search plugin will need to be rebuilt,
+  since the search form has changed. This will not be done automatically,
+  but can be done by running `ikiwiki-mass-upgrade` as root, or
+  running `ikiwiki -setup` on individual setup files.
+
+ -- Joey Hess <joeyh@debian.org>  Wed, 04 Jun 2008 00:29:28 -0400
+
+ikiwiki (2.48) unstable; urgency=high
+
+  If you allowed password based logins to your wiki, those passwords were
+  stored in cleartext in the userdb. To guard against exposing users'
+  passwords, I recommend you install the Authen::Passphrase perl module, and
+  then run `ikiwiki-transition hashpassword /path/to/srcdir` to replace all
+  existing cleartext passwords with strong (blowfish) hashes.
+
+ -- Joey Hess <joeyh@debian.org>  Thu, 29 May 2008 14:39:34 -0400
+
+ikiwiki (2.46) unstable; urgency=low
+  There were some significant template changes in ikiwiki 2.42 (and 1.33.5).
+  If you have locally modified versions of the templates, they need to be
+  updated. Most notably, the editpage.tmpl has a new FIELD-SID added to it,
+  without which web editing will fail.
+ -- Joey Hess <joeyh@debian.org>  Tue, 06 May 2008 14:30:14 -0400
+
 ikiwiki (2.40) unstable; urgency=low
 
   ikiwiki now has an new syntax for preprocessor directives, using the
@@ -80,7 +163,7 @@ ikiwiki (2.14) unstable; urgency=low
 
   This version of ikiwiki is more picky about symlinks in the path leading
   to the srcdir, and will refuse to use a srcdir specified by such a path.
-  This  was necessary to avoid some potential exploits, but could potentially
+  This was necessary to avoid some potential exploits, but could potentially
   break (semi-)working wikis. If your wiki has a srcdir path containing a
   symlink, you should change it to use a path that does not.