sub rcs_find_changes ($) {
my $oldrev=shift;
+ # Note that git log will sometimes show files being added that
+ # don't exist. Particularly, git merge -s ours can result in a
+ # merge commit where some files were not really added.
+ # This is why the code below verifies that the files really
+ # exist.
my @raw_lines = run_or_die('git', 'log',
'--pretty=raw', '--raw', '--abbrev=40', '--always', '-c',
'--no-renames', , '--reverse',
foreach my $i (@{$ci->{details}}) {
my $file=$i->{file};
if ($i->{sha1_to} eq $nullsha) {
- delete $changed{$file};
- $deleted{$file}=1;
+ if (! -e "$config{srcdir}/$file") {
+ delete $changed{$file};
+ $deleted{$file}=1;
+ }
}
else {
- delete $deleted{$file};
- $changed{$file}=1;
+ if (-e "$config{srcdir}/$file") {
+ delete $deleted{$file};
+ $changed{$file}=1;
+ }
}
}
}
+ikiwiki (3.20140228) UNRELEASED; urgency=medium
+
+ * only_committed_changes could fail in a git repository merged
+ with git merge -s ours.
+
+ -- Joey Hess <joeyh@debian.org> Sat, 05 Apr 2014 19:08:22 -0400
+
ikiwiki (3.20140227) unstable; urgency=medium
* Added useragent config setting. Closes: #737121
also an equivalent (I suppose) problem when using another plugin, but I hope
it's enough to track it down for this one.
- $ tar -xj < [bug-dep_order.tar.bz2](http://schwinge.homeip.net/~thomas/tmp/bug-dep_order.tar.bz2)
+ $ tar -xj < [bug-dep_order.tar.bz2](http://nic-nac-project.de/~schwinge/ikiwiki/bug-dep_order.tar.bz2)
$ cd bug-dep_order/
$ ./render_locally
[...]
Consider this:
- $ wget http://schwinge.homeip.net/~thomas/tmp/cutpaste_filter.tar.bz2
- $ wget http://schwinge.homeip.net/~thomas/tmp/cutpaste_filter.patch
+ $ wget http://nic-nac-project.de/~schwinge/ikiwiki/cutpaste_filter.tar.bz2
+ $ wget http://nic-nac-project.de/~schwinge/ikiwiki/0001-cutpaste.pm-missing-filter-call.patch
$ tar -xj < cutpaste_filter.tar.bz2
$ cd cutpaste_filter/
`backlink(plugins/goodstuff)` up to a million times, with various pages and locations.
--[[smcv]]
+
+> [[!template id=gitbranch branch=smcv/ready/perf
+author="[[Simon McVittie|smcv]]"
+browse=http://git.pseudorandom.co.uk/smcv/ikiwiki.git/shortlog/refs/heads/ready/perf]]
+> [[!tag patch]]
+>
+> Previously, if a page like `plugins/trail` contained a conditional like
+>
+> \[[!if test="backlink(plugins/goodstuff)" all=no]]
+>
+> (which it gets via `templates/gitbranch`), then the
+> [[plugins/conditional]] plugin would give `plugins/trail` a dependency on
+> `(backlink(plugins/goodstuff)) and plugins/trail`. This dependency is
+> useless: that pagespec can never match any page other than
+> `plugins/trail`, but if `plugins/trail` has been modified or deleted,
+> then it's going to be rendered or deleted *anyway*, so there's no point
+> in spending time evaluating match_backlink for it.
+>
+> Conversely, the influences from the result were not taken into account,
+> so `plugins/trail` did not have the
+> `{ "plugins/goodstuff" => $DEPEND_LINKS }` dependency that it should.
+>
+> We should invert that, depending on the influences but not on the test.
+>
+> This is at least an order of magnitude faster: when I edit the docwiki
+> as described above, a refresh takes 37s with nytprof overhead, compared
+> with 458s with nytprof overhead before this change. Without nytprof,
+> that refresh takes 14s, which is faster than the 24s rebuild again.
+> I didn't record how long the refresh took without nytprof before this
+> change, but it was something like 200s.
+>
+> `bestlink` is still the single most expensive function in this refresh
+> at ~ 9.5s, with `match_glob` at ~ 5.2s as the runner-up.
+> --[[smcv]]
--- /dev/null
+For some more flexibility in creating a stylesheet for ikiwiki, it would be nice if there were a few unused elements on the page that one can move around and assign content to using CSS.
+
+For instance, something like this:
+
+ <div class='aux' id='aux1'></div>
+ <div class='aux' id='aux2'></div>
+
+etc. For bonus points, the number could be configurable. To avoid empty content, style.css should have something like this:
+
+ .aux {
+ display: none;
+ }
+
+This can then be used to move things around. For instance, I have on my website's CSS stylesheet the following:
+
+ #aux1 {
+ position: fixed;
+ width: 150px;
+ height: 150px;
+ bottom: 0px;
+ left: 0px;
+ background-image: url("wouter3.png");
+ background-position: top right;
+ background-repeat: no-repeat;
+ background-origin: content-box;
+ display-block;
+ }
+
+which adds my hackergochi to the bottom left of the webpage, with some margin.
+
+I tried looking for something like this, but I couldn't find it. Perhaps I just didn't look in the right places, though; apologies if that is the case.
+
+> This can easily be achieved by modifying [[templates]]. Simply copy the default page template to the template directory of your wiki, and modify it to add your empty divs.
+>
+> -- [[Louis|spalax]]
--- /dev/null
+If you have a page like
+
+ \[[!if test="enabled(smileys)" then=":-P"]]
+
+then enabling or disabling the smileys plugin will not rebuild it.
+
+Unfortunately, I can't think of a good way to solve this without
+introducing a special case for `enabled()` in Render.pm, either a
+new dependency type `"enabled(smileys)" => $DEPENDS_ENABLED`
+or a special case that treats `"enabled(smileys)" => $DEPENDS_PRESENCE`
+differently. --[[smcv]]
--- /dev/null
+If you use the rescaling feature of the directive [[ikiwiki/directive/img/]] with a smaller image it will distort. E.g. an image with 150x250 rescaled into size=200x200. --bastla
>>> "add_reachable". On the other hand, maybe that's too computationally
>>> intensive to actually do; I haven't tried it.
>>> --[[smcv]]
+>>>>
+>>>> (I'll interpet Joeys silence as a good sign ;-). Is there a difference between "link to it" and "path to it"? If we assume autoindex produces bonafide "first class" links there shouldn't be one!?
+>>>>
+>>>> So far your idea sounds great, says me without any knowledge of the source. I'll try to grok it. Is there a medium for silly questions, a wiki seems not the right fit for that? -- [[holger]]
+>>>>> Yes, there *has* to be a difference between a first class wikilink
+>>>>> and the thing to which `map` and `inline` can contribute.
+>>>>> `map` and `inline` use a pagespec to decide what they include,
+>>>>> and pagespecs can't be evaluated and get a correct answer until the
+>>>>> set of links has been collected, because their results often depend
+>>>>> on the set of links. Otherwise, suppose you had a page `foo` whose only
+>>>>> contents were this:
+>>>>>
+>>>>> \[[!inline pages="!backlink(foo)"]]
+>>>>>
+>>>>> If `inline` generated links, it would inline exactly those pages that
+>>>>> it doesn't inline. That's never going to end well :-) --[[smcv]]
+>>>>>> We have to differentiate between what users of ikiwiki consider first class links and what internally is happening. For the user any link contributing to the structured access tree is first class. The code on the other hand has to differentiate between the static links, then generated links, then orphan links. Three "passes", even your proposed solution could be seen as adding another pass since the orphan plugin has to run after all the plugins generating (first class user) links. -- [[holger]]
+
--- /dev/null
+On some ikiwikis that I run, I get the following error on OpenID logins:
+
+ no_identity_server: Could not determine ID provider from URL.
+
+I seem recall having that error before, and fixing it, but it always seems to come back and I forget how to fix it. So I'll just open this bug and document it if i can figure it out... -- [[users/anarcat]]
+
+The Perl module manual says:
+
+> "no_identity_server"
+> (CV) Tried to do discovery on a URL that does not seem to have any providers at all.
+
+Yet on the server side, I see no request coming in on the OpenID provider...
+
+Adding debugging helps in figuring out wtf is going on:
+
+~~~~
+anarcat@marcos:~$ diff -u ~/src/ikiwiki/IkiWiki/Plugin/openid.pm /usr/share/perl5/IkiWiki/Plugin/openid.pm
+--- /home/anarcat/src/ikiwiki/IkiWiki/Plugin/openid.pm 2014-02-03 20:21:09.502878631 -0500
++++ /usr/share/perl5/IkiWiki/Plugin/openid.pm 2014-04-13 11:45:25.413297420 -0400
+@@ -257,6 +256,7 @@
+ return Net::OpenID::Consumer->new(
+ ua => $ua,
+ args => $q,
++ debug => 1,
+ consumer_secret => sub { return shift()+$secret },
+ required_root => auto_upgrade_https($q, $cgiurl),
+ );
+~~~~
+
+In my case, I see:
+
+
+~~~~
+[Sun Apr 13 11:45:35.796531 2014] [cgi:error] [pid 7299] [client 162.223.3.24:39547] AH01215: [DEBUG Net::OpenID::Consumer] Cache MISS for https://id.koumbit.net/anarcat, referer: http://cats.orangeseeds.org/ikiwiki.cgi?do=signin&action=verify&openid_identifier=https%3A%2F%2Fid.koumbit.net%2Fanarcat
+[Sun Apr 13 11:45:35.842520 2014] [cgi:error] [pid 7299] [client 162.223.3.24:39547] AH01215: [DEBUG Net::OpenID::Consumer] Cache MISS for https://id.koumbit.net/anarcat, referer: http://cats.orangeseeds.org/ikiwiki.cgi?do=signin&action=verify&openid_identifier=https%3A%2F%2Fid.koumbit.net%2Fanarcat
+[Sun Apr 13 11:45:35.845603 2014] [cgi:error] [pid 7299] [client 162.223.3.24:39547] AH01215: [DEBUG Net::OpenID::Consumer] semantic info (https://id.koumbit.net/anarcat) = , referer: http://cats.orangeseeds.org/ikiwiki.cgi?do=signin&action=verify&openid_identifier=https%3A%2F%2Fid.koumbit.net%2Fanarcat
+[Sun Apr 13 11:45:35.845672 2014] [cgi:error] [pid 7299] [client 162.223.3.24:39547] AH01215: [DEBUG Net::OpenID::Consumer] fail(no_identity_server) Could not determine ID provider from URL., referer: http://cats.orangeseeds.org/ikiwiki.cgi?do=signin&action=verify&openid_identifier=https%3A%2F%2Fid.koumbit.net%2Fanarcat
+~~~~
+
+There are three places in the code the original error message happens:
+
+* Net::OpenID::claimed_identity
+* Net::OpenID::verified_identity
+* Net::OpenID::_find_openid_server
+
+We'll look at the last one because it's where the URL data is actually fetched.
+
+[[!format perl """
+sub _find_openid_server {
+ my Net::OpenID::Consumer $self = shift;
+ my $url = shift;
+ my $final_url_ref = shift;
+
+ my $sem_info = $self->_find_semantic_info($url, $final_url_ref) or
+ return;
+
+ return $self->_fail("no_identity_server") unless $sem_info->{"openid.server"};
+ $sem_info->{"openid.server"};
+}
+"""]]
+
+From there we look at `_find_semantic_info()`, which is supposed to hit the OpenID server, but doesn't somehow.... By cranking up debugging, we can see that the consumer fails to verify the HTTPS signature on the host:
+
+~~~~
+[Sun Apr 13 11:58:30.284511 2014] [cgi:error] [pid 11141] [client 162.223.3.24:39563] AH01215: [DEBUG Net::OpenID::Consumer] url dump (https://id.koumbit.net/anarcat, SCALAR(0x3275ac0)) = 500 Can't verify SSL peers without knowing which Certificate Authorities to trust, referer: http://cats.orangeseeds.org/ikiwiki.cgi?do=signin&action=verify&openid_identifier=https%3A%2F%2Fid.koumbit.net%2Fanarcat
+[Sun Apr 13 11:58:30.284551 2014] [cgi:error] [pid 11141] [client 162.223.3.24:39563] AH01215: , referer: http://cats.orangeseeds.org/ikiwiki.cgi?do=signin&action=verify&openid_identifier=https%3A%2F%2Fid.koumbit.net%2Fanarcat
+[Sun Apr 13 11:58:30.284573 2014] [cgi:error] [pid 11141] [client 162.223.3.24:39563] AH01215: This problem can be fixed by either setting the PERL_LWP_SSL_CA_FILE, referer: http://cats.orangeseeds.org/ikiwiki.cgi?do=signin&action=verify&openid_identifier=https%3A%2F%2Fid.koumbit.net%2Fanarcat
+[Sun Apr 13 11:58:30.284593 2014] [cgi:error] [pid 11141] [client 162.223.3.24:39563] AH01215: envirionment variable or by installing the Mozilla::CA module., referer: http://cats.orangeseeds.org/ikiwiki.cgi?do=signin&action=verify&openid_identifier=https%3A%2F%2Fid.koumbit.net%2Fanarcat
+[Sun Apr 13 11:58:30.284597 2014] [cgi:error] [pid 11141] [client 162.223.3.24:39563] AH01215: , referer: http://cats.orangeseeds.org/ikiwiki.cgi?do=signin&action=verify&openid_identifier=https%3A%2F%2Fid.koumbit.net%2Fanarcat
+~~~~
+
+To get this little wonder, I had to change the `_find_semantic_info()` as followed:
+
+[[!format perl """
+sub _find_semantic_info {
+ my Net::OpenID::Consumer $self = shift;
+ my $url = shift;
+ my $final_url_ref = shift;
+
+ my $doc = $self->_get_url_contents($url, $final_url_ref);
+ $self->_debug("url dump ($url, $final_url_ref) = " . $doc) if $self->{debug};
+ my $info = _document_to_semantic_info($doc);
+ $self->_debug("semantic info ($url) = " . join(", ", map { $_.' => '.$info->{$_} } keys %$info)) if $self->{debug};
+
+ return $info;
+}
+"""]]
+
+A minimal test case would be:
+
+~~~~
+perl -e 'use LWPx::ParanoidAgent;
+ print $LWPx::ParanoidAgent::VERSION, " $]: ";
+ print length(LWPx::ParanoidAgent->new->get
+ ("https://id.koumbit.net/anarcat")
+ ->decoded_content), "\n";'
+~~~~
+
+And the results vary according to the version of perl:
+
+* wheezy: 1.07 5.014002: 5720
+* jessie: 1.10 5.018002: 398
+
+Thanks [jwz](http://www.jwz.org/blog/2014/03/apple-broke-lwp-in-a-new-and-exciting-way-on-10-9-2/) for that.. Mozilla::CA *could* have been packaged in Debian, except it overlaps with the `ca-certificates` package, so it was [basically barred entry](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=702124).
+
+I tried the workaround of hardcoding the path to the CA root, using `PERL_LWP_SSL_CA_PATH=/etc/ssl/certs`, but then I hit *another* bug in LWP: [#738493](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=738493).
+
+Note that this bug is similar to [[bugs/ssl_certificates_not_checked_with_openid/]], but backwards: it checks the SSL certs but then fails to verify.
+
+I filed this bug in the Debian BTS as [#702124](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=702124). Downgrading to wheezy's version of LWPx::ParanoidAgent doesn't fix the problem, instead i get this error:
+
+ 500 Can't read entity body: Resource temporarily unavailable
+
+... yet the commandline client works fine... I'm out of ideas for this sucker.
+
+Update: i found a way to reproduce the problem even with LWPx::ParanoidAgent 1.07:
+
+~~~~
+$ perl -e 'use LWPx::ParanoidAgent;
+ print $LWPx::ParanoidAgent::VERSION, " $]\n";
+ $ua = new LWPx::ParanoidAgent; for (my $i = 0; $i< 10 ; $i++) { $c = LWPx::ParanoidAgent->new->get
+ ("https://id.koumbit.net/anarcat")
+ ->decoded_content; if (length($c) < 100) { print $c; } else { print length($c),"\n";}}'
+1.07 5.018002
+5720
+500 Can't read entity body: Ressource temporairement non disponible
+500 Can't read entity body: Ressource temporairement non disponible
+500 Can't read entity body: Ressource temporairement non disponible
+500 Can't read entity body: Ressource temporairement non disponible
+500 Can't read entity body: Ressource temporairement non disponible
+500 Can't read entity body: Ressource temporairement non disponible
+500 Can't read entity body: Ressource temporairement non disponible
+500 Can't read entity body: Ressource temporairement non disponible
+500 Can't read entity body: Ressource temporairement non disponible
+~~~~
+
+Workaround - disable error checking:
+
+~~~~
+--- /home/anarcat/src/ikiwiki/IkiWiki/Plugin/openid.pm 2014-02-03 20:21:09.502878631 -0500
++++ /usr/share/perl5/IkiWiki/Plugin/openid.pm 2014-04-13 16:00:06.875744596 -0400
+@@ -237,7 +237,7 @@
+
+ my $ua;
+ eval q{use LWPx::ParanoidAgent};
+- if (! $@) {
++ if (! $@ && 0) {
+ $ua=LWPx::ParanoidAgent->new;
+ }
+ else {
+~~~~
--- /dev/null
+Similar to [[bugs/syslog_fails_with_non-ASCII_wikinames]], this bug happens when the wiki name has non-ascii characters in the site name. In my case, it has the "CⒶTS" string.
+
+We get the following error in a password reset:
+
+ Error: Wide character in subroutine entry at /usr/share/perl5/Mail/Sendmail.pm line 308.
+
+Help! :) --[[anarcat]]
+
+> I assume this means Mail::Sendmail doesn't know how to send Unicode
+> strings, so any string passed to it (or any message body, or something?)
+> will need to be passed through `encode_utf8()`. It looks as though
+> Mail::Sendmail also defaults to
+>
+> Content-Type: 'text/plain; charset="iso-8859-1"'
+>
+> so it'll need a `'Content-Type' => 'text/plain; charset="utf-8"'`
+> too.
+>
+> I'm disappointed to see how many of the library modules used by ikiwiki
+> are not Unicode-clean... but then again, Mail::Sendmail was last released
+> in 2003 so it's hardly surprising. I wonder whether [[!cpan Email::Sender]]
+> is any better?
+>
+> (If you know Python 2, the analogous situation would be "doesn't
+> know how to send unicode objects, so you have to get a str object
+> with `a_unicode_object.encode('utf-8')`".) --[[smcv]]
+
+>> Shameless plug: [[todo/passwordauth:_sendmail_interface]]. Though, I have
+>> no idea whether that is UTF-8-safe. --[[tschwinge]]
--- /dev/null
+[[!template id=gitbranch branch=smcv/ready/comments author="[[smcv]]"
+browse="http://git.pseudorandom.co.uk/smcv/ikiwiki.git/shortlog/refs/heads/ready/comments"]]
+[[!tag patch]]
+
+The ability to post comments depends on several factors:
+
+* `comments_pagespec` controls whether comments on a particular
+ page will be displayed
+* `comments_closed_pagespec` controls whether comments on
+ a particular page are allowed
+* the `check_canedit` call controls whether comments are allowed
+ for a particular combination of page and user
+
+If `check_canedit` says that a user can post a comment
+(in particular, if [[plugins/opendiscussion]] is enabled or
+[[plugins/lockedit]] is disabled or permissive),
+and `comments_closed_pagespec` does not contradict it,
+then users who construct a `do=comment` CGI URL manually
+can post comments that will not be displayed. I don't think
+this is a security flaw as such, which is why I'm not
+reporting it privately, but it violates least-astonishment.
+
+My `ready/comments` branch fixes this, by changing the test
+at submission time from (pseudocode)
+
+ !comments_closed_pagespec && check_canedit
+
+to
+
+ comments_pagespec && !comments_closed_pagespec && check_canedit
+
+--[[smcv]]
--- /dev/null
+[[!template id=gitbranch branch=chrysn/more-proxy-utf8-fail author="[[chrysn]]"]]
+
+the recently introduced fixes for [[crashes in the python proxy even if disabled]]
+caused the typical python2 implicit conversion failures ("'ascii' codec
+can't...") on my debian sid system -- to fix it, i had to revert commit 154c4ea9e.
+
+i did not dig down all the way to the xml / xmlrpc modules, but my impression
+is that some module changed its behavior between stable and sid and now
+generates `unicode` strings instead of `str`.
+
+a [[patch]] to allow both versions by inspecting the types and en-/decoding on
+demand should work both for anarcat's and my case. i did not test the python3
+version, but i'm pretty sure it was already broken after the abovementioned
+patch.
+
+-- [[chrysn]]
--- /dev/null
+I suppose this isn't technically a bug, but whetever.
+
+I want symbolic links to be rendered as HTTP redirects. For example,
+if we do this,
+
+ touch foo.mkdwn
+ ln -s foo.mkdwn bar.mkdwn
+ git push baz.branchable.com
+
+then the following command should print 302
+
+ curl -o /dev/null -s -w "%{http_code}" http://baz.thomaslevine.com/bar/
+
+> An interesting idea, but it conflicts somewhat with wanting symlinks to be
+> treated as the referenced file when it's safe to do so, which would be
+> great for [[todo/git-annex support]], and also good to avoid duplication
+> for files in system-wide underlays.
+>
+> Also, I don't think this is possible without help from the web server
+> configuration: for instance, under Apache, I believe the only way to get
+> an HTTP 302 redirect is via Apache-specific `.htaccess` files or
+> system-level Apache configuration.
+>
+> In current ikiwiki, you can get a broadly similar effect by either
+> using \[[!meta redir=foo]] (which does a HTML `<meta>` redirect)
+> or reconfiguring the web server. --[[smcv]]
--- /dev/null
+[[!template id=gitbranch branch=chrysn/imgforpdf author="[[chrysn]]"]]
+
+when using the [[img plugin|plugins/img]] with an svg file, it is supposed to
+convert it into a png for display in all browsers, and because the typical use
+case is rendering small preview versions.
+
+this currently doesn't work (at least with graphicsmagick-libmagick-dev-compat
+1.3.18-1) due to the sequence imagemagick options are set, needs an extension
+to work for pdfs (or any other imagemagick compatibile file) too, and should
+have an additional parameter for page selection.
+
+i've provided a series of [[!taglink patch]]es in the chrysn/imgforpdf [[git]]
+branch.
+
+i'd prefer to go a step further, and not only convert pdf and svg files to png,
+but everything (with the possible exception of jpg files), as most other image
+formats can't be displayed in a browser anyway -- but i didn't in this patch
+series, as it would alter the file names of existing images, i don't know if
+that needs special care or breaks something i don't use; this way, my patches
+should be safe for inclusion.
+
+--[[chrysn]]
>>>>>
>>>>> --[[chrysn]]
->>>>>> [[!template id=gitbranch author="[[smcv]]" branch=smcv/ready/templatebody
- browse=http://git.pseudorandom.co.uk/smcv/ikiwiki.git/shortlog/refs/heads/ready/templatebody]]
->>>>>> [[!tag patch]]
->>>>>> Branch and directive renamed to `ready/templatebody` as chrysn suggested.
->>>>>> It's on-by-default now (or will be if that branch is merged).
->>>>>> Joey, any chance you could review this?
->>>>>>
->>>>>> There is one known buglet: `template_syntax.t` asserts that the entire
->>>>>> file is a valid HTML::Template, whereas it would ideally be doing the
->>>>>> same logic as IkiWiki itself. I don't think that's serious. --[[smcv]]
-
->>>>>>> Looking over this, I notice it adds a hash containing all scanned
->>>>>>> files. This seems to me to be potentially a scalability problem on
->>>>>>> rebuild of a site with many pages. Ikiwiki already keeps a lot
->>>>>>> of info in memory, and this adds to it, for what is a fairly
->>>>>>> minor reason. It seems to me there should be a way to avoid this. --[[Joey]]
-
->>>>>>>> Maybe. Are plugins expected to cope with scanning the same
->>>>>>>> page more than once? If so, it's just a tradeoff between
->>>>>>>> "spend more time scanning the template repeatedly" and
->>>>>>>> "spend more memory on avoiding it", and it would be OK to
->>>>>>>> omit that, or reduce it to a set of scanned *templates*
->>>>>>>> (in practice that would mean scanning each template twice
->>>>>>>> in a rebuild). --s
+----
+
+[[!template id=gitbranch author="[[smcv]]" branch=smcv/ready/templatebody
+ browse=http://git.pseudorandom.co.uk/smcv/ikiwiki.git/shortlog/refs/heads/ready/templatebody]]
+[[!tag patch]]
+Branch and directive renamed to `ready/templatebody` as chrysn suggested.
+It's on-by-default now (or will be if that branch is merged).
+Joey, any chance you could review this?
+
+There is one known buglet: `template_syntax.t` asserts that the entire
+file is a valid HTML::Template, whereas it would ideally be doing the
+same logic as IkiWiki itself. I don't think that's serious. --[[smcv]]
+
+> Looking over this, I notice it adds a hash containing all scanned
+> files. This seems to me to be potentially a scalability problem on
+> rebuild of a site with many pages. Ikiwiki already keeps a lot
+> of info in memory, and this adds to it, for what is a fairly
+> minor reason. It seems to me there should be a way to avoid this. --[[Joey]]
+
+>> Maybe. Are plugins expected to cope with scanning the same
+>> page more than once? If so, it's just a tradeoff between
+>> "spend more time scanning the template repeatedly" and
+>> "spend more memory on avoiding it", and it would be OK to
+>> omit that, or reduce it to a set of scanned *templates*
+>> (in practice that would mean scanning each template twice
+>> in a rebuild). --s
+>>> [Commit f7303db5](http://source.ikiwiki.branchable.com/?p=source.git;a=commitdiff;h=f7303db5)
+>>> suggests that scanning the same page more than once is problematic,
+>>> so that solution is probably not going to work.
+>>>
+>>> The best idea I've come up with so far is to track whether
+>>> we're in the scan or render phase. If we're in the scan
+>>> phase, I think we do need to keep track of which pages
+>>> we've scanned, so we don't do them again? (Or perhaps that's
+>>> unnecessary - commit f7303db5 removed a scan call that's in
+>>> the render phase.) If we're in the render phase, we can assume
+>>> that all changed pages have been scanned already, so we can
+>>> drop the contents of `%scanned` and rely on a single boolean
+>>> flag instead.
+>>>
+>>> `%scanned` is likely to be no larger than `%rendered`, which
+>>> we already track, and whose useful lifetime does not overlap
+>>> with `%scanned` now. I was tempted to merge them both and call
+>>> the result `%done_in_this_phase`, but that would lead to really
+>>> confusing situations if a bug led to `render` being called sooner
+>>> than it ought to be.
+>>>
+>>> My ulterior motive here is that I would like to formalize
+>>> the existence of different phases of wiki processing - at the
+>>> moment there are at least two phases, namely "it's too soon to
+>>> match pagespecs reliably" and "everything has been scanned,
+>>> you may use pagespecs now", but those phases don't have names,
+>>> so [[plugins/write]] doesn't describe them.
+>>>
+>>> I'm also considering adding warnings
+>>> if people try to match a pagespec before scanning has finished,
+>>> which can't possibly guarantee the right result, as discussed in
+>>> [[conditional_preprocess_during_scan]]. My `wip-too-soon` branch
+>>> is a start towards that; the docwiki builds successfully, but
+>>> the tests that use IkiWiki internals also need updating to
+>>> set `$phase = PHASE_RENDER` before they start preprocessing. --s
* **[ikiwiked gray-orange](https://github.com/AntPortal/ikiwiked/raw/master/theme/gray-orange/local.css)**, contributed by [Danny Castonguay](https://antportal.com/). Can be seen in action at [antportal.com/wiki](https://antportal.com/wiki/). Feel free to modify and contribute on [Github](https://github.com/AntPortal/ikiwiked)
<!-- Page links -->
- [1]: http://blankoworld.homelinux.com/demo/ikiwiki/blankoblues/src/local.css (Download Blankoblues CSS)
- [2]: http://blankoworld.homelinux.com/demo/ikiwiki/blankoblues/htdocs/ (Take a tour on Blankoblues Demo)
- [3]: http://blankoworld.homelinux.com/demo/ikiwiki/blankoblues/blankoblues.tar.gz (Download local.css and templates for Blankoblues theme)
- [4]: http://blankoworld.homelinux.com/demo/ikiwiki/contraste/src/local.css (Download Contraste CSS)
- [5]: http://blankoworld.homelinux.com/demo/ikiwiki/contraste/htdocs/ (Take a tour on Contraste Demo)
- [6]: http://blankoworld.homelinux.com/demo/ikiwiki/contraste/contraste.tar.gz (Download local.css and templates for Contraste theme)
+ [1]: http://olivier.dossmann.net/demo/ikiwiki/blankoblues/src/local.css (Download Blankoblues CSS)
+ [2]: http://olivier.dossmann.net/demo/ikiwiki/blankoblues/htdocs/ (Take a tour on Blankoblues Demo)
+ [3]: http://olivier.dossmann.net/demo/ikiwiki/blankoblues/blankoblues.tar.gz (Download local.css and templates for Blankoblues theme)
+ [4]: http://olivier.dossmann.net/demo/ikiwiki/contraste/src/local.css (Download Contraste CSS)
+ [5]: http://olivier.dossmann.net/demo/ikiwiki/contraste/htdocs/ (Take a tour on Contraste Demo)
+ [6]: http://olivier.dossmann.net/demo/ikiwiki/contraste/contraste.tar.gz (Download local.css and templates for Contraste theme)
--- /dev/null
+Github does not take .mdwn as Markdown files: https://github.com/github/markup/blob/b865add2e053f8cea3d7f4d9dcba001bdfd78994/lib/github/markups.rb#L1
+
+I'd like to use filename extensions complaint to GitHub. My question is after renaming all markdown files from *.mdwn to *.md how do I correct all the dependencies? Does simply committing the renamed files to the source repository suffice?
and can then use \[[!paste id=foo]].
Therefore, I've written an [*absorb* directive /
-plugin](http://schwinge.homeip.net/~thomas/tmp/absorb.pm), which is meant to
+plugin](http://nic-nac-project.de/~schwinge/ikiwiki/absorb.pm), which is meant to
absorb pages in order to get hold of their *cut* and *copy* directives'
contents. This does work as expected. But it also absorbs page fileA's *meta*
values, like a *meta title*, etc. How to avoid / solve this?
4
"""]]
-Note that if the highlight plugin is enabled, this directive can also be
+Note that if the [[!iki plugins/highlight desc=highlight]] plugin is enabled, this directive can also be
used to display syntax highlighted code. Many languages and formats are
supported. For example:
----
I guess patching [[/ikiwiki/directive/meta]] to document the fact this attribute is supported would be good. — [[Jon]]
+
+
+----
+
++1 the language attribute works, I see:
+
+ <meta name="language" content="en" />
+
+The problem is that it does not generate the lang attribute in `<html>` and that's what's required for [hyphenation](https://developer.mozilla.org/en-US/docs/Web/CSS/hyphens) so this would be welcome too!
+
+Also, being able to use the language variable in templates would be very useful for various css tweaks. — [Hugo](https://hroy.eu)
* [[CAS Libres|http://cas-libres.poivron.org]] - A French feminist radio program.
* [[Les Barricades|http://barricades.int.eu.org]] - A French socialist choir (CSS has been adapted from the one of [[Grésille|http://www.gresille.org]]).
* [DKØTU Amateur Radio Station](http://www.dk0tu.de), TU Berlin
+* [[Plan A|http://www.plan-a-muenchen.de/]] - A proposal for improvement of the urban public transport in Munich (by PRO BAHN, Bund Naturschutz and others)
+* [[Smuxi IRC Client|https://smuxi.im/]] - powerful IRC client for GNOME
Personal sites and blogs
========================
* [Z is for Zombies](http://blog.zouish.org/) — personal blog/site of Francesca Ciceri
* Julien Lefrique's [homepage](http://julien.lefrique.name/), hosted on [GitHub pages](https://github.com/jlefrique/jlefrique.github.com) with CGI disabled
* [Anarcat's homepage](http://anarcat.ath.cx/) - with a custom [[theme|theme_market]]
+* [Wouter's Blog](http://grep.be/blog/), with a custom CSS stylesheet based off the rest of his website.
+* [Julian Andres Klode's blog](http://jak-linux.org/)
+* [KheOps's blog](https://w.ceops.eu/words/)
+* [Stig Sandbeck Mathisen](http://fnord.no/) - Personal site and blog, with a bootstrap theme, and varnish frontend.
+
OpenID, and see how OpenID works for you. And let me know your feelings about
making such a switch. --[[Joey]]
-[[!poll 71 "Accept only OpenID for logins" 21 "Accept only password logins" 47 "Accept both"]]
+[[!poll 72 "Accept only OpenID for logins" 21 "Accept only password logins" 48 "Accept both"]]
+++ /dev/null
-ikiwiki 3.20130711 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
- * Deal with git behavior change in 1.7.2 and newer that broke support
- for commits with an empty commit message.
- * Pass --no-edit when used with git 1.7.8 and newer."""]]
\ No newline at end of file
--- /dev/null
+ikiwiki 3.20140227 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+ * Added useragent config setting. Closes: #[737121](http://bugs.debian.org/737121)
+ Thanks, Tuomas Jormola
+ * po: Add html\_lang\_code and html\_lang\_dir template variables
+ for the language code and direction of text.
+ Thanks, Mesar Hameed
+ * Allow up to 8 levels of nested directives, rather than previous 3
+ in directive infinite loop guard.
+ * git diffurl: Do not escape / in paths to changed files, in order to
+ interoperate with cgit (gitweb works either way)
+ Thanks, intrigeri.
+ * git: Explicity push master branch, as will be needed by git 2.0's
+ change to push.default=matching by default.
+ Thanks, smcv
+ * Deal with nasty issue with gettext clobbering $@ while printing
+ error message containing it.
+ Thanks, smcv
+ * Cleanup of the openid login widget, including replacing of hotlinked
+ images from openid providers with embedded, freely licensed artwork.
+ Thanks, smcv
+ * Improve templates testing.
+ Thanks, smcv
+ * python proxy: Avoid utf-8 related crash.
+ Thanks, Antoine Beaupré
+ * Special thanks to Simon McVittie for being the patchmeister for this
+ release."""]]
\ No newline at end of file
## Bugs
+* `thumbnailsize` doesn't actually work, they're always 96x96.
+ [[KathrynAndersen]] suggested a fix on the [[discussion]] page;
+ search for her name and look for a context diff.
+
+* The album index is limited to 10 images. kjs suggested a fix on
+ the [[discussion]] page: the plugin should pass `show => 0`
+ to `preprocess_inline`.
+
* There's currently a hard-coded list of extensions that are treated as
images: `png`, `gif`, `jpg`, `jpeg` or `mov` files. More image and video
types could be added in future.
----
+## design feedback from joeyh on an earlier version
+
You had wanted my feedback on the design of this. I have not looked at the
code or tried it yet, but here goes. --[[Joey]]
----
+## alternative "special extension" design (conclusion: "don't")
+
'''I think the "special extension" design is a dead-end, but here's what
happened when I tried to work out how it would work. --[[smcv]]'''
----
+## bug: unable to vary thumbnail size
+
Hi smcv, great plugin. I am an ikiwiki newbie but so far I've had success using your plugin.
I've integrated the jquery masonry plugin into the albumitem template and it works great.
But is there a way to create thumnails of different sizes? I've passed thumnailsize option
and value to album directive and while it does create the new thumbnail sizes it doesn't use them,
The 96x96 thumbnails still appear on the page no matter what I do. - jaime
+> [[KathrynAndersen]] fixed this, see below. --[[smcv]]
+
----
+## failed installation
+
Hi, the plugin looks great, but I am probably too dumb to use it ;( here is what I did:
created page gal.mdwn with just \[\[!album\]\] directive (no arguments) and subdirectory gal/ with images in form img_1234.jpg
>> Thanks for all the work you did on the plugin! --Lukas
----
-Hi smcv, we spoke on irc the other day. Passed `show => "0"` on line 126 in album.pm to remove the limit on the thumbnails shown on the album page. Setting it on the album directive didn't work. As mentioned above by Jaime setting the thumbnailsize doesn't catch either. Or rather if I git push after changing the album directive the generated thumbnails (the image files) are the correct size as set in the directive. The html however uses the default thumbnailsize as hardcoded in album.pm and has broken thumbnails as it links to a file with the default size in the filename.
+
+## bug + patch: not all images shown on album page
+
+Hi smcv, we spoke on irc the other day. Passed `show => "0"` on line 126 in album.pm to remove the limit on the thumbnails shown on the album page. Setting it on the album directive didn't work.
+
+--kjs
+
+> That sounds like a correct solution. I'll fix that in my branch when I work on
+> this again. --[[smcv]]
+
+----
+
+## bug: thumbnailsize doesn't work
+
+As mentioned above by Jaime setting the thumbnailsize doesn't catch either. Or rather if I git push after changing the album directive the generated thumbnails (the image files) are the correct size as set in the directive. The html however uses the default thumbnailsize as hardcoded in album.pm and has broken thumbnails as it links to a file with the default size in the filename.
+
+> [[KathrynAndersen]] fixed this, see below. --[[smcv]]
Issuing `ikiwiki --rebuild` knocks the system into another gear where the thumbnails show up correctly but this is only due to the html being the same as above (linking to hardcoded thumbnailsize) but the generated thumbnail images are now matching the hardcoded size ignoring the thumbnailsize attribute on the album directive.
For me this behaviour is way beyond my skills to sort out (I'm no coder). The albumplugin ikiwiki combo is very attractive to me and the plugin i soo close to working!
+--kjs
+
+----
+
+## wishlist + patch: make clicking on the large image go to the next
+
I've changed the behavior of the "slideshow" to show the next image when clicking the large image as downloading a full resolution image is a rare use case in a gallery of this type imho. The large clicktarget means you are likely to unnecessarily download large files otherwise. I can't quite follow the template, album.pm flow so I can't figure out how to put a "download full resolution" link on the viewer page which would be my next step. To achieve the next link i added ` link => ($nextpage or $album),` around line 454 in `my $img`
+--kjs
+
+> That seems reasonable. I'll consider that when I work on this
+> plugin again next. --[[smcv]]
+
+----
+
+## wishlist from kjs
+
My wishlist for the plugin would include:
- Reading exif info from the imagefile
-- Keeping the full resolution image files out of version control
-- Being able to create new albums by tag or bym anually picking images from other albums. Could be a simple comma separated list of viewer names, or even full urls, in the album directive.
+- ~~Keeping the full resolution image files out of version control~~ Solved this by simply creating a underlay for the images. Works out of the box for my non cgi workflow.
+- Being able to create new albums by tag or by manually picking images from other albums. Could be a simple comma separated list of viewer names, or even full urls, in the album directive.
+- A counter showing **current image/total number of images in album**. This would mean that you know how many images you have left to click through before you have seen all images in an album. This gives you enought info to decide weather to click through or go back/leave.
--kjs
+> I want the first two of those too, perhaps one day I'll get round to
+> implementing them.
+>
+> For the third, you can get the same practical effect using an inline
+> as documented in the main page. --[[smcv]]
+>> The downside to current behaviour is that clicking an inlined thumbnail will take you to the original album context. Previous/Next image will not match the thumbnails in the inline but the thumbnails in the album. This is a bit confusing for users and prevents using the image in multiple contexts without duplicating the image. To achieve what I'm looking for there would have to be several AlbumViewer pages for a single image. --kjs
+
----
+## suggested fix for thumbnail size bug
+
I've tracked down the "always showing the 96x96 thumbnails" bug!
The problem is in the pagetemplate function, which calls "thumbnail" to determine the name of the thumbnail image to use. As you know, the "img" method of generating thumbnails includes the size of the thumbnail as part of its name (to ensure that resizing thumbnails will create a new file of the correct size). The problem is... that in the pagetemplate function, the thumbnailsize is NOT passed in to the call to "thumbnail", so it always returns the default size, 96x96. Hence nothing that anyone can do will change the thumbnails to anything else. Oh, the different-sized thumbnail images ARE created, but they're never linked to.
-- [[KathrynAndersen]]
+> I haven't tried this change, but it seems sane. I'll apply it
+> when I next work on this plugin.
+>
+> (OOI: why not a unified diff? The VCS world seems to have
+> settled on those as universal, and I find them easier to
+> read.)
+>
+> --[[smcv]]
+
----
+## bug: inability to show more than 10 items
+
I've found another bug. The album plugin doesn't allow one to have more than 10 items in an album section. This is because it uses "inline" to display album sections, and the default for inline is to show only 10 items. So it only shows 10 items.
What would be good is if the album directive could have a "show" parameter which is passed on to preprocess_inline, so that users could decide how many items to show (including ALL of them, if they give show=0).
-- [[KathrynAndersen]]
+
+> My intention was that all items would always be shown, so I would always pass
+> `show => 0` to `preprocess_inline` (as kjs suggested above), but that must have
+> got lost somewhere. I'll apply it next time I work on this plugin.
+>
+> An optional `show` parameter would be a possible enhancement beyond that,
+> although I don't know how useful it would be; if it isn't passed, the
+> default should be 0 (unlimited). --[[smcv]]
--- /dev/null
+[[!template id=plugin name=purge core=0 author="[[users/ssm]]"]]
+
+IkiWiki plugin to send PURGE requests to remote http cache server (like Varnish Cache) when your content changes.
+
+PURGE requests are sent for the changed page, as well as all pages indirectly changed when ikiwiki rebuilds the web pages.
+
+# Download
+
+Download from [Github](https://github.com/ssm/ikiwiki-plugin-purge)
+
+# Configure ikiwiki
+
+ # purge_url (mandatory), the address of your cache server.
+ purge_url: http://example.com/
+
+ # purge_timeout (optional, default 5) timeout in seconds for a purge request.
+
+ # purge_method (optional, default "PURGE") HTTP method to use.
+
+# Configure your cache server
+
+For Varnish, you'll need to add a handler for the non-standard "PURGE" method, and preferrably an ACL which restricts who can send these requests to empty your cache.
+
+ acl origin_server {
+ "localhost";
+ "192.0.2.0"/24;
+ "2001:db8::"/64;
+ }
+
+ sub vcl_recv {
+ if (req.method == "PURGE") {
+ if (!client.ip ~ origin_server) {
+ return(synth(405,"Not allowed."));
+ }
+ return (purge);
+ }
+ }
+
[[!tag type/format]]
This plugin allows ikiwiki to process `.otl` outline files, as created by
-[vimoutliner](http://www.vimoutliner.org/). To use it, you need to have
+[vimoutliner](https://github.com/vimoutliner/vimoutliner). To use it, you need to have
vimoutliner installed, since it uses the `otl2html` program.
This is the [[SandBox]], a page anyone can edit to try out ikiwiki
(version [[!version ]]).
-hello world (right back at ya)
-asfddsaf sadfkjal;skdfj saldkfjasdf
-sdafljas;dlfk safdiuhsdf
+What about [[this page]]?
+hello world (right back at ya)
+test
> This is a blockquote.
>
<child />
</test>
-...Now why doesn't it work like that on my copy of ikiwiki? :(
+...Now why doesn't it work like that on my own copy of ikiwiki? :(
Räksmörgås.
The easiest way of installing an up-to-date ikiwiki on any version of Mac OS X is via
[pkgsrc](http://www.pkgsrc.org/).
+## From source:
+
7. [Bootstrap pkgsrc](http://www.netbsd.org/docs/pkgsrc/platforms.html#bootstrapping-pkgsrc)
7. Run `cd .../pkgsrc/www/ikiwiki && make install clean`
-{OK} As of 2013/09/14, the [version of ikiwiki in pkgsrc](http://pkgsrc.se/www/ikiwiki) is 3.20130904.1.
+## From binary packages:
+
+7. [install binary packages (OSX)](http://www.pkgsrc.org/#index1h1)
+
+{OK} As of 2014/03/19, the [version of ikiwiki in pkgsrc](http://pkgsrc.se/www/ikiwiki) is 3.20140227.
-----
Enrique Castilla
-[!] As of 2013/09/14, the [version of ikiwiki in MacPorts](http://www.macports.org/ports.php?by=name&substr=Ikiwiki) is 3.20110608.
+[!] As of 2014/03/19, the [version of ikiwiki in MacPorts](http://www.macports.org/ports.php?by=name&substr=Ikiwiki) is 3.20110608.
-----
--- /dev/null
+This recommended method (sc. install Ikiwiki using pkgsrc) is not compatible with homebrew and the packages installed via homebrew, and, therefore, not always a viable solution to installing Ikiwiki on Mac computers.
+
+> In what way is it "not compatible"? Have you tried it? I can't
+> think of any technical reason why having a working Homebrew
+> installation would prevent one from also having a working pkgsrc
+> installation, or vice versa. (MacPorts and Fink can certainly coexist
+> with each other and with other package managers on the same system.)
+>
+> We used to direct OS X ikiwiki users to MacPorts, but the version
+> there is almost three years old. pkgsrc's ikiwiki stays up to date
+> because I keep it that way. If someone packages ikiwiki for Homebrew
+> and reliably keeps the package updated, then we could discuss
+> whether pointing folks at Homebrew is better advice than what's
+> currently being given here. In the meantime, if you've tried and
+> failed to install ikiwiki from pkgsrc on OS X, please report your
+> problem in detail so it can be addressed in some way. --[[schmonz]]
--- /dev/null
+because of [[bugs/notifyemail_fails_with_some_openid_providers]], I have been struggling with finding ways of being notified of changes to pages I want to watch here.
+
+the workaround I found so far was to join the `#ikiwiki` channel on freenode, and set the following "hilight" in irssi:
+
+ /hilight -channels #ikiwiki -word tips/monitor_page_changes_through_IRC
+
+this will watch for any change to this page. -- [[anarcat]]
+
+hello anarcat, I'm editing your page! -- [[micah]]
> [[done]], with some changes --[[Joey]]
-Find the most recent version at
-<http://schwinge.homeip.net/~thomas/tmp/meta_forward.patch>.
-
I can't use `scrub(...)`, as that will strip out the forwarding HTML command.
How to deal with that?
--- /dev/null
+It would be great if IkiWiki could apply some sort of preprocessing to
+CSS. I'm just "thinking out loud" at the moment, but I might write
+a plugin.
+
+The simplest starting point would be concatenating a list of files:
+
+* The actiontabs and monochrome themes are not ready for use as-is;
+ the Makefile constructs the real stylesheet by concatenating the
+ anti-theme's CSS and the relevant theme's CSS. It would be better
+ if they could just drop a file in an underlay, and IkiWiki would
+ concatenate the anti-theme stylesheet and the theme's file.
+
+* The blueview theme is the same, but the theme's CSS also starts
+ with a couple of stylesheets from YUI. IkiWiki could maybe
+ concatenate the anti-theme stylesheet, the two YUI stylesheets
+ and the blueview-specific part? Or maybe that's too complicated.
+
+* The goldtype theme is the blueview theme with some overrides
+ added to the end. Again, IkiWiki could concatenate all the pieces.
+
+* The [[plugins/contrib/album]] plugin needs to append some
+ stuff to the stylesheet, making its installation more involved
+ than it ought to be. If it could append the pieces by putting them
+ in an underlay, installation would just be a matter of "add
+ the files".
+
+I'm not sure whether local.css should be concatenated too, or whether
+it should be separate.
+
+It would also be great if the same mechanism could be extended
+to compile CSS-like languages like [[!debpkg ruby-sass desc=SASS]]
+or [[!debpkg node-less desc=LESS]] down to CSS, but for dependency
+reasons, I don't think the themes shipped with IkiWiki should rely on that.
+
+If the compiled CSS ended up with a content-based filename (perhaps
+ikiwiki/compiled-HASH.css where HASH is the (possibly truncated) MD5 or SHA1
+hash of the content), that would mitigate stale CSS being served from cache
+(as long as the HTML has a short expiry, which is desirable anyway),
+and ikiwiki-hosting could maybe even do something like this to allow
+long-term caching of the files with content-based names:
+
+ <LocationMatch /ikiwiki/compiled-[a-f0-9]+\.css>
+ ExpiresByType text/css "now plus 1 year"
+ </LocationMatch>
+
+A similar mechanism could maybe be used to minify JavaScript.
+
+## vague syntax proposal: controlled by directive
+
+ \[[!css files="""
+ style.css
+ ikiwiki/plugin*.css
+ ikiwiki/theme*.css
+ local.css
+ """]]
+
+* *css* directive, placed in any page, concatenates the given files
+ and uses them as the stylesheet for that page and its subpages,
+ replacing `<TMPL_VAR BASEURL>style.css`
+
+* the files can be globs, which are sorted lexicographically within
+ a glob, and do not have to match anything (so it's OK if you don't
+ have anything that matches `plugin*.css`); "-" happens to sort
+ before ".", so theme-base.css would sort before theme.css,
+ which is nice to have
+
+* the default would be `style.css`, then `ikiwiki/plugin*.css`,
+ then `ikiwiki/theme*.css` and maybe `local.css`, as in the
+ example above
+
+* `style.css` would continue to be the anti-theme
+
+* themes would ship `ikiwiki/theme.css` instead of `style.css`,
+ resulting in concatenation
+
+* goldtype would ship `ikiwiki/theme-base.css` (which is a copy of
+ blueview, or a symlink to blueview if we can make symlinks safe)
+ and `ikiwiki/theme.css` (which is the goldtype additions)
+
+* [[plugins/contrib/album]] would put its templates and
+ `ikiwiki/plugin-album.css` in an underlay
+
+* any non-contrib plugin with complicated CSS requirements
+ could also move its CSS to an underlay
+
+I think this could be done entirely in a plugin, except for this
+change to `page.tmpl` to allow the `<style>`s to be overridden:
+
+ <TMPL_IF COMPILED_CSS>
+ <style type="text/css" href="<TMPL_VAR BASEURL><TMPL_VAR COMPILED_CSS>" />
+ <TMPL_ELSE>
+ <!-- ... what it does now ... -->
+ </TMPL_IF>
+
+The plugin could also optionally minify its output, and either pass input
+files through an external SASS/SCSS/LESS implementation according
+to their extension, or have a hook system to do so.
+
+People who want SASS/LESS would probably just do this in their top-level page:
+
+ \[[!css files="mywiki.less"]]
+
+and do the inclusion/concatenation logic via @import.
+
+Security consideration: the SASS/LESS compilers will read arbitrary local
+files, so if you use those languages, ability to upload the appropriate
+extension would have to be locked-down. Perhaps it's better to implement
+this without that feature initially.
+
+--[[smcv]]
+
+> Although I understand the need to improve CSS inclusion, I wonder why you are
+> proposing concatenating CSS rather than including them as several `<link
+> type="text/css" href="FILE.css" rel="stylesheet">` lines
+> in the header: unless I am missing something, I see this as far more simpler
+> than concatenating them.
+>
+> This would imply that a template variable `CSS` is added to the page
+> template, to be filled with those lines.
+>
+> Whatever solution is used, I agree that such a thing would be useful:
+> adding CSS (rather than replacing the existing one) should be easier.
+>
+> -- [[Louis|spalax]]
+
--- /dev/null
+[[!template id=gitbranch branch=smcv/ready/document-success-reason author="[[smcv]]"
+browse=http://git.pseudorandom.co.uk/smcv/ikiwiki.git/shortlog/refs/heads/ready/document-success-reason]]
+[[!tag patch]]
+
+Whenever I look at dependency calculation, for instance to solve
+[[bugs/editing gitbranch template is really slow]], it takes me a while to
+get my head round the concept of influences. The design documentation is
+in [[todo/dependency_types]], but that takes the form of a long discussion
+between [[Joey]] and [[Will]], so it's difficult to tell which of the
+attempts to define influences were incorrect or have been superseded.
+
+I think it would be valuable to have brief documentation
+as doc-comments in the source code. My branch adds some;
+please confirm whether I got it right? :-)
+
+It would also be great to have a definition of what
+should or shouldn't be counted as an influence, and which influences
+should count as static or dynamic, perhaps analogous to
+[git-annex's design pages](http://git-annex.branchable.com/design/)
+and linked from the `match_foo` section of [[plugins/write]]. I haven't
+written this myself because I'm somewhat stuck on the subtlety of what
+"indirectly influenced" means... --[[smcv]]
OK, so I'll have a look at replacing all email handling with *Email::Send*.
[[!tag patch]]
-*<http://schwinge.homeip.net/~thomas/tmp/ikiwiki-sendmail.patch>*
+*<http://nic-nac-project.de/~schwinge/ikiwiki/0001-Use-Email-Send-instead-of-Mail-Sendmail.patch>*
Remaining TODOs:
* Resolve TODOs as denoted inside the patch.
+ * Update for the last years of ikiwiki development, such as adapting the
+ [[plugins/notifyemail]] plugin.
+ * Is this
+ [[UTF-8-safe|bugs/password_reset_fails_with___34__Wide_character_in_subroutine_entry__34__]]?
* Is it worthwhile to use and depend on [[!cpan Return::Value]]
just for this bit of functionality?
* Debian news file.
* [[bugs/methodResponse in add__95__plugins]]
* [[bugs/preprocessing loop control too tight]]
* [[bugs/proxy.py utf8 troubles]]
+* [[bugs/pythonproxy-utf8 again]]
+* [[bugs/svg and pdf conversion fails]]
* [[bugs/Underscores in links don't appear]]
* [[bugs/unicode encoded urls and recentchanges]]
* [[bugs/wrong link in recentchanges when reverting an ikiwiki outside git root]]
--- /dev/null
+Stig Sandbeck Mathisen has a [web page somewhere](http://fnord.no).
+
+Somewhat fond of perl, ikiwiki and varnish, and wrote the [[plugins/contrib/purge]] plugin to glue them together.
sipb-www / ikiwiki.git / commitdiff
