doc/todo/Allow_TITLE_to_include_part_of_the_path_in_addition_to_the_basename.mdwn

   1 I need to display part of my pages' path in the `<title>` meta HTML
   2 header instead of their basename ; e.g. for /abs/path/to/basename, I'd
   3 like to set it to path/to/basename.
   4
   5 Of course, one might consider it's my own problem, as I could
   6 workaround this in my templates, and replace, in the `<title>` meta
   7 HTML header, `<TMPL_VAR TITLE>` with a `TMPL_LOOP` on `PARENTLINKS`,
   8 but...
   9
  10 - it's ugly (call it a semantic hijacking if you want) ; a side-effect
  11   of this ugliness is :
  12 - it defeats any further plugin's (e.g. [[plugins/meta]])
  13   attempt to override the default title with a nicer one ;
  14 - all parents appear : there is no way to specify how deep to go up in
  15   the parents tree.
  16
  17 So I really want to avoid this ugly workaround.
  18
  19 Looking at `Render.pm`, the second solution I thought of was :
  20
  21 - add a `parents_in_page_title` configuration option (default=0, i.e.
  22   the current behaviour) ;
  23 - modify `Render.pm` to insert as much parents as possible (up to
  24   `N=parents_in_page_title`), separated by '/', in the `title`
  25   template parameter, before the actual page basename ; I personally
  26   would use N=2.
  27
  28 The only problems I can see with this approach are :
  29
  30 - it requires modification of the core, which may not be desirable
  31 - the resulting title would be unconditionally overridden by the meta
  32   plugin, and I can think of no clean solution to make this
  33   configurable without hacking [[plugins/meta]], which I'd rather not
  34   to ; I don't care, but once you add a ad-hoc feature to the core,
  35   you can be sure someone will want a more generic version in less than
  36   three months ;)
  37
  38 I'm not too convinced writing a plugin for such a small feature isn't
  39 overdoing it, so I'm tempted to implement this solution in the
  40 simplest way : the generated title would be the default and could be
  41 overridden later by plugins.
  42
  43 Joey, what do you think ?
  44
  45 (Before starting to write any single line of code, I need to know how
  46 much you are on the "if you can do it as a plugin, don't ever modify
  47 the core" side... :)
  48
  49 > My general philosophy is that the core should be flexible enough to allow
  50 > plugins to do arbitrary useful stuff. And there are some things in-core
  51 > that I'd like to get out (such as backlinks processing), but that cannot
  52 > currently be moved out efficiently. KISS is also part of my pholisophy.
  53 >
  54 > So no, I don't like adding new options to the core that few users will
  55 > want to use.
  56
  57 In case you're on the hardcore side, I would probably write
  58 a dedicated plugin, called `genealogictitle` or whatever, and :
  59
  60 - use the pagetemplate hook to modify the `title` template parameter,
  61   and maybe set `title_overridden`, as does the meta plugin
  62 - add a `genealogictitle_depth` configuration option to tell how many
  63   parents to display
  64 - maybe add a `genealogictitle_overrides_meta` or whatever to decide
  65   whether a title overridden by [[plugins/meta]] should be overridden
  66   by genealogictitle ; but anyway, I've not found, in the plugins
  67   documentation, any hint about the order in which the plugins are
  68   called for a given hook, so the "choose the strongest between meta
  69   and genealogictitle" thing might just be more complicated... (no,
  70   I did not Read The Nice Source, yet).
  71
  72 -- intrigeri
  73
  74 > Plugin sounds reasonable. --[[Joey]]
  75
  76 >> Well, it seems I once more designed a solution before clearly
  77 >> defining my problem... What I really need is more generic, can be
  78 >> done as a plugin, and deserves its own [[todo|pedigree_plugin]], so
  79 >> I'm tagging this one wontfix^W [[done]]. I'm sorry. -- intrigeri