summaryrefslogtreecommitdiff
path: root/doc/bugs
diff options
context:
space:
mode:
Diffstat (limited to 'doc/bugs')
-rw-r--r--doc/bugs/Comments_dissapeared.mdwn5
-rw-r--r--doc/bugs/bzr_2.0_breaks_bzr_plugin.mdwn87
-rw-r--r--doc/bugs/some_but_not_all_meta_fields_are_stored_escaped.mdwn39
-rw-r--r--doc/bugs/stray___60____47__p__62___tags.mdwn2
4 files changed, 133 insertions, 0 deletions
diff --git a/doc/bugs/Comments_dissapeared.mdwn b/doc/bugs/Comments_dissapeared.mdwn
index ac297028c..7ff1a012f 100644
--- a/doc/bugs/Comments_dissapeared.mdwn
+++ b/doc/bugs/Comments_dissapeared.mdwn
@@ -28,3 +28,8 @@ It worked just fine with this configuration. I swear I have not modified it. :)
> So I suspect you have simply not rebuilt your wiki after making some
> change that fixed the comments, and so only newer pages are getting them.
> --[[Joey]]
+
+I have tried rebuilding on my squeeze system and still comments don't appear. Any clues how to debug this?
+<http://natalian.org/comments/>
+
+I was worried is was due to a time skew problem I was experiencing on my VPS in the last month, though the time is right now and still comments do not appear on blog posts like <http://natalian.org/archives/2010/03/25/BBC_News_complaints/>
diff --git a/doc/bugs/bzr_2.0_breaks_bzr_plugin.mdwn b/doc/bugs/bzr_2.0_breaks_bzr_plugin.mdwn
new file mode 100644
index 000000000..39500af20
--- /dev/null
+++ b/doc/bugs/bzr_2.0_breaks_bzr_plugin.mdwn
@@ -0,0 +1,87 @@
+Version 2.0 of bzr seems to break the bzr plugin.
+
+I traced this to the bzr_log method in the plugin, and patching that seems to fix it. The plugin just needs to parse the input little bit differently.
+--liw
+
+> Patch applied, [[done]] (but, it would be good if it could be tested with
+> an older bzr, and it's a pity bzr's human-targeted log has to be parsed,
+> I assume there is no machine-targeted version?) --[[Joey]]
+
+ From fb897114124e627fd3acf5af8e784c9a77419a81 Mon Sep 17 00:00:00 2001
+ From: Lars Wirzenius <liw@liw.fi>
+ Date: Sun, 4 Apr 2010 21:05:07 +1200
+ Subject: [PATCH] Fix bzr plugin to work with bzr 2.0.
+
+ The output of "bzr log" seems to have changed a bit, so we change the
+ parsing accordingly. This has not been tested with earlier versions of
+ bzr.
+
+ Several problems seemed to occur, all in the bzr_log subroutine:
+
+ 1. The @infos list would contain an empty hash, which would confuse the
+ rest of the program.
+ 2. This was because bzr_log would push an empty anonymous hash to the
+ list whenever it thought a new record would start.
+ 3. However, a new record marker (now?) also happens at th end of bzr log
+ output.
+ 4. Now we collect the record to a hash that gets pushed to the list only
+ if it is not empty.
+ 5. Also, sometimes bzr log outputs "revno: 1234 [merge]", so we catch only
+ the revision number.
+ 6. Finally, there may be non-headers at the of the output, so we ignore
+ those.
+ ---
+ IkiWiki/Plugin/bzr.pm | 23 ++++++++++++++++-------
+ 1 files changed, 16 insertions(+), 7 deletions(-)
+
+ diff --git a/IkiWiki/Plugin/bzr.pm b/IkiWiki/Plugin/bzr.pm
+ index 1ffdc23..e813331 100644
+ --- a/IkiWiki/Plugin/bzr.pm
+ +++ b/IkiWiki/Plugin/bzr.pm
+ @@ -73,28 +73,37 @@ sub bzr_log ($) {
+ my @infos = ();
+ my $key = undef;
+
+ + my $hash = {};
+ while (<$out>) {
+ my $line = $_;
+ my ($value);
+ if ($line =~ /^message:/) {
+ $key = "message";
+ - $infos[$#infos]{$key} = "";
+ + $$hash{$key} = "";
+ }
+ elsif ($line =~ /^(modified|added|renamed|renamed and modified|removed):/) {
+ $key = "files";
+ - unless (defined($infos[$#infos]{$key})) { $infos[$#infos]{$key} = ""; }
+ + unless (defined($$hash{$key})) { $$hash{$key} = ""; }
+ }
+ elsif (defined($key) and $line =~ /^ (.*)/) {
+ - $infos[$#infos]{$key} .= "$1\n";
+ + $$hash{$key} .= "$1\n";
+ }
+ elsif ($line eq "------------------------------------------------------------\n") {
+ + if (keys %$hash) {
+ + push (@infos, $hash);
+ + }
+ + $hash = {};
+ $key = undef;
+ - push (@infos, {});
+ }
+ - else {
+ + elsif ($line =~ /: /) {
+ chomp $line;
+ - ($key, $value) = split /: +/, $line, 2;
+ - $infos[$#infos]{$key} = $value;
+ + if ($line =~ /^revno: (\d+)/) {
+ + $key = "revno";
+ + $value = $1;
+ + } else {
+ + ($key, $value) = split /: +/, $line, 2;
+ + }
+ + $$hash{$key} = $value;
+ }
+ }
+ close $out;
+ --
+ 1.7.0
diff --git a/doc/bugs/some_but_not_all_meta_fields_are_stored_escaped.mdwn b/doc/bugs/some_but_not_all_meta_fields_are_stored_escaped.mdwn
new file mode 100644
index 000000000..8e1ca42e0
--- /dev/null
+++ b/doc/bugs/some_but_not_all_meta_fields_are_stored_escaped.mdwn
@@ -0,0 +1,39 @@
+[[!template id=gitbranch branch=smcv/unescaped-meta author="[[Simon_McVittie|smcv]]"]]
+[[!tag patch]]
+(Warning: this branch has not been tested thoroughly.)
+
+While discussing the [[plugins/meta]] plugin on IRC, Joey pointed out that
+it stores most meta fields unescaped, but 'title', 'guid' and 'description'
+are special-cased and stored escaped (with numeric XML/HTML entities). This
+is to avoid emitting markup in the `<title>` of a HTML page, or in an RSS/Atom
+feed, neither of which are subject to the [[plugins/htmlscrubber]].
+
+However, having the meta fields "partially escaped" like this is somewhat
+error-prone. Joey suggested that perhaps everything should be stored
+unescaped, and the escaping should be done on output; this branch
+implements that.
+
+Points of extra subtlety:
+
+* The title given to the [[plugins/search]] plugin was previously HTML;
+ now it's plain text, potentially containing markup characters. I suspect
+ that that's what Xapian wants anyway (which is why I didn't change it),
+ but I could be wrong...
+
+* Page descriptions in the HTML `<head>` were previously double-escaped:
+ the description was stored escaped with numeric entities, then that was
+ output with a second layer of escaping! In this branch, I just emit
+ the page description escaped once, as was presumably the intention.
+
+* It's safe to apply this change to a wiki and neglect to rebuild it
+ (assuming I implemented it correctly!), but until the wiki is rebuilt,
+ titles, descriptions and GUIDs for unchanged pages will appear
+ double-escaped on any page that inlines them in `quick=yes` mode, and
+ is rebuilt for some other reason. The failure mode is too much escaping
+ rather than too little, so it shouldn't be a security problem.
+
+* Reverting this change, if applied, is more dangerous; until the wiki is
+ rebuilt, any titles, descriptions and GUIDs on unchanged pages that
+ contained markup could appear unescaped on any page that inlines them
+ in `quick=yes` mode, and is rebuilt for some other reason. The failure
+ mode here would be too little escaping, i.e. cross-site scripting.
diff --git a/doc/bugs/stray___60____47__p__62___tags.mdwn b/doc/bugs/stray___60____47__p__62___tags.mdwn
index 6e508ffda..99d6fe09f 100644
--- a/doc/bugs/stray___60____47__p__62___tags.mdwn
+++ b/doc/bugs/stray___60____47__p__62___tags.mdwn
@@ -13,3 +13,5 @@ I believe that this snippet in `IkiWiki.pm` might be the reason for the imbalanc
}
The fact that HTML in a `\[[!meta title]]` is added but then escaped might indicate that some other bug is involved.
+
+> [[done]] --[[Joey]]