doc/bugs/misctemplate_does_not_respect_the_current_page___40__if_any__41__.mdwn

   1 I really like the new approach to having only one main template "page.tmpl". For instance, it improves previews during edits.
   2 But it causes some nasty bugs for plugins that use the pagetemplate hook. It is especially visible with the [[plugins/sidebar]] plugin.
   3
   4 ## Some examples
   5
   6 ### A first example
   7
   8 * activate sidebars globally and cgi
   9 * create "/sidebar.mdwn" with "[<span></span>[foo]]" inside
  10 * create "/foo.mdwn" with "hello!" inside
  11 * create "/bar.mdwn"
  12 * run ikiwiki
  13 * with the web browser, go to the page "bar"
  14 * notice the sidebar, click on "foo"
  15 * notice the page "foo" is now displayed (hello!)
  16 * return the the page "bar" and click "edit"
  17 * notice the sidebar is still here, click on the "foo"
  18 * -> Problem: 404, the browser goes to "/bar/foo"
  19 * -> Was expected: the browser goes to "/foo"
  20
  21 > You must have a locally modified `page.tmpl` that omits the "TMPL_IF DYNAMIC"
  22 > that adds a `<base>` tag. That is needed to make all links displayed by
  23 > cgis work reliably. Not just in this page editing case.
  24 > The [[version_3.20100515]] announcment mentions that you need to
  25 > update old `page.tmpl` files to include that on upgrade. --[[Joey]]
  26
  27 >> I followed the anouncment. I also disabled my custom page.tmpl to confirm the bug. I even produced a step-by-step example to reproduce the bug.
  28 >> In fact, the base tag work for the page links (the content part) but did not works for the sidebar links (the sidebar part) since the sidebar links are generated in the context of the root page.
  29 >> In the examble above:
  30 >>
  31 >> * base="http://www.example.com/bar" relative_link_in_bar=''something" -> absolute_link_in_bar = "http://www.example.com/bar/something" (that is fine)
  32 >> * base="http://www.example.com/bar" relative_link_in_sidebar="foo" (because generated in the context of the root page) -> absolute_link_in_sidebar = "http://www.example.com/bar/foo" (that is not fine)
  33 >>
  34 >> The fix commited work for previewing, but not in other cases : links are still broken. Please juste follow the example step-by-step to reproduce it (I just retried it with a "fixed" version: Debian 3.20100610). If you cannot reproduce, please say it explicitely instead of guessing about my innability to read changelogs. -- [[JeanPrivat]]
  35
  36 >>> Sorry if my not seeing the bug offended you. [[Fixed|done]] --[[Joey]]
  37
  38 >>>> Thanks! --[[JeanPrivat]] (I'm not offended)
  39
  40 ### A second example
  41
  42 * create "/bar/sidebar.mdwn" with "world"
  43 * run ikiwiki
  44 * with the web browser, go to the page "bar"
  45 * notice the sidebar displays "world"
  46 * click "edit"
  47 * -> Problem: the sidebar now shows the foo link (it is the root sidebar!)
  48 * -> Was expecte : the sidebar displays "world"
  49
  50 > I think it's a misconception to think that the page editing page is the same
  51 > as the page it's editing. If you were deleting that page, would you expect
  52 > the "are you sure" confirmation page to display the page's sidebar?
  53 > --[[Joey]]
  54
  55 >> It is a very good point and could be argued:
  56 >>
  57 >> * for dynamic page, is the root context more legitimate than the current page context?
  58 >> * when clicking the Edit link, does the user expect to remain in the "same page"?
  59 >>
  60 >> But, as far as something sensible is displayed and that the links work. I'm OK with any choice. -- [[JeanPrivat]]
  61
  62 ### A last example
  63
  64 * with the web browser edit the page "bar"
  65 * type <code>[<span></span>[!sidebar content="goodby"]]</code>
  66 * click preview
  67 * -> Problem: the sidebar still displays the foo link
  68 * -> Was expected: the sidebar display "goodby"
  69
  70 > In the specific case of previewing, it is indeed a bug that the
  71 > right sidebar is not displayed. And replacing the regular sidebar
  72 > with the one from the previewed page is probably the best we can do..
  73 > displaying 2 sidebars would be confusing, and the `page.tmpl` can
  74 > put the sidebar anywhere so we can't just display the preview sidebar
  75 > next to the rest of the page preview. --[[Joey]]
  76
  77 >> The behavior is fine for me. However, some nitpicking (fell free to ingore) :
  78 >>
  79 >> * If the sidebar is replaced (making the previewing in-place), for consitency, should not the previewed content also shown in-place ? i.e. above the form part
  80 >> * there is no way to come back (without saving or canceling) to the root context (e.g. displaying the root sidebar) i.e. some sort of unpreviewing.
  81 >>
  82 >> -- [[JeanPrivat]]
  83
  84 ## Some superficial hacking
  85
  86 With the following workaround hacks, I manage to solve the 3 examples shown above:
  87
  88 1- edit IkiWiki/Plugin/editpage.pm and call showform with additional page and destpage parameters:
  89 <pre>showform($form, \@buttons, $session, $q, forcebaseurl => $baseurl, page => $page, destpage => $page);</pre>
  90
  91 2- edit /usr/share/perl5/IkiWiki.pm and modify the misctemplate function to use the given page and destpage:
  92 <pre>my %params=@_;
  93 shift->(page => $params{page}, destpage => $params{destpage}, template => $template);</pre>
  94
  95 I do not guarantee (I do not even expect) that it is the proper way to solve
  96 this bug but it may help developers to find and solve the real problem.
  97
  98 > Oh, it's pretty reasonable. I don't think it breaks anything. :)
  99 > I modified it a bit, and explicitly made it *not* "fix" the second example.
 100 > --[[Joey]]
 101 >> I removed the done tag (I suspect it is the way to reopen bugs) -- [[JeanPrivat]]