The DokuWiki Taratasy Template offers a rather nice design, which i wanted to use for my new Wiki. This Wiki will be based upon the currently stable DokuWiki 2015-08-10a (aka “Detritus”) release. The Taratasy templates site currently shows the compatibility to the DokuWiki “Detritus” release as “unknown”, see the following screenshot:

Installing the Taratasy templates in an otherwise working DokuWiki 2015-08-10a instance lead to the rather broken appearance shown in the following example screenshot:

The colors and fonts are way off, the navigation bar at the head and bottom of the page as well as the tools menu are broken. Thus, my immediate suspicion for the root cause of the issues was in the direction of the CSS definitions provided by the Taratasy template.

Digging through the webserver and PHP logs as well as double checking the webservers rewrite rules showed no noticable indication of a problem with the DokuWiki instance itself. Switching to another template like e.g. Arctic also showed that the DokuWiki 2015-08-10a instance itself worked flawlessly. So this was not a general issue with my setup of the current DokuWiki release. The other way around, using the Taratasy template with an older DokuWiki 2014-09-29d (aka “Hrun”) release, also worked as expected and without any issues. So the problem was narrowed down to some change introduced between those two DokuWiki releases.

With the suspicion about the CSS definitions mentioned above, i tried to make some changes in the Taratasy templates style.ini file. Those changes immediately effected the layout of the re-rendered page. On the other hand, making some changes in the Taratasy templates style.local.ini file had no effect on the subsequently re-rendered page.

Browsing the commit history of the DokuWiki GitHub repository for the 2015-08-10a release and searching for commits with a reference to style.local.ini, i stubled upon the commit 656e584. The associated changes finally removed a feature which had already been marked as deprecated in previous DokuWiki releases. This feature was to include user defined CSS formatting definitions through the file style.local.ini in a templates main directory and merge these definitions with the ones from the templates style.ini file into the final CSS definitions. For several DokuWiki releases the user defined CSS formatting definitions are now supposed to be placed in the file DOKU_CONF.“tpl/$tpl/style.ini” instead.

With the source of the issue now known, my quick'n'dirty solution was to merge the CSS definitions from the templates style.local.ini into the templates style.ini and afterwards drop the now redundant style.local.ini. This was just easier to accomplish given my particular DokuWiki directory setup. Another solution would have been to create a directory DOKU_CONF/tpl/taratasy/ and move the style.local.ini into it as DOKU_CONF/tpl/taratasy/style.ini.

The modified template sources can be found in my Taratasy repository on GitHub

In conclusion, the following image shows an example screenshot of the same DokuWiki 2015-08-10a instance as above after the patch to the Taratasy template has been applied:

Essentially “.patch” files are – with regard to their content – not different from “.diff” files. Still, throughout this blog and all of my other documentation i like to and also have grown accustomed to using the “.diff” filename suffix in cases where i want to focus on the semantics of a pure comparison. On the other hand, in cases where i want to focus on the semantics of actually applying a patch to a certain source file, the “.patch” filename suffix is used. I guess it's more of a personal quirk, rather than a well funded scientific theory.

Unfortunately in the stock DokuWiki distribution there is a little deficiency in displaying the appropriate diff file icon not only for “.diff” files, but for “.patch” files also. Here is an example screenshot of what this looks like:

Note the plain white paper sheet icon in front of the filename “sblim-wbemcli-1.6.3_debug.patch”, which is the default file icon in case of an unknown filename suffix.

This behaviour basically exists, because the “.patch” filename suffix has no appropriate icon in the “<dokuwiki-path>/lib/images/fileicons/” directory:

$ find <dokuwiki-path>/lib/images/ -type f -name "patch.*" -ls | wc -l
0

See also the DokuWiki documentation on MIME configuration.

This can be quickly fixed though. By just creating appropriate directory enties for the “.patch” filename suffix via symbolic links to the file icons for the “.diff” filename suffix:

$ ln -s <dokuwiki-path>/lib/images/fileicons/diff.png <dokuwiki-path>/lib/images/fileicons/patch.png
$ ln -s <dokuwiki-path>/lib/images/fileicons/32x32/diff.png <dokuwiki-path>/lib/images/fileicons/32x32/patch.png
$ find <dokuwiki-path>/lib/images/ -name "patch.*" -ls
 ... lrwxrwxrwx   ...   <dokuwiki-path>/lib/images/fileicons/patch.png -> <dokuwiki-path>/lib/images/fileicons/diff.png
 ... lrwxrwxrwx   ...   <dokuwiki-path>/lib/images/fileicons/32x32/patch.png -> <dokuwiki-path>/lib/images/fileicons/32x32/diff.png
$ touch <dokuwiki-path>/conf/local.php

The final “touch” command is necessary, since the icons are part of the DokuWiki cache and the application logic has to be notified to rebuild the now invalid cache.

After reloading the respective DokuWiki page in the browser, note the now “Diff”-labeled paper sheet icon in front of the filename “sblim-wbemcli-1.6.3_debug.patch”:

This may be just a small change in the display of the DokuWiki page, but in my humble opinion it makes things much more pleasant to look at.

How to add a Google+1 Button to a DokuWiki (“Angua” release or later) based blog using the BlogTNG plugin and the mnml-blog template? Here's how:

• Download the Google +1 plugin and install it. With the DokuWiki release “Angua” or later, the requirement for the external jQuery plugin is not necessary any more. An internally packaged jQuery is part of the DokuWiki standard distribution since that release.

• Edit the plugin to not register for the external jQuery events any more:

  plugins/googleplusone/action.php

      ...
      function register(&$controller) {
          /* $controller->register_hook( 'JQUERY_READY', 'BEFORE', $this, '_addjs' ); */
          $controller->register_hook( 'TPL_METAHEADER_OUTPUT', 'BEFORE', $this, '_addscript' );
      }
      ...

• Edit the mnml-blog template to insert the Google+1 Button into the lower right corner, just above the footer defined by blogtng_footer:

  • entry.php for individual blog posts:

    entry.php

    --- entry.php.orig      2012-05-29 23:08:09.000000000 +0200
    +++ entry.php   2012-05-30 00:40:10.000000000 +0200
    @@ -42,6 +42,9 @@
                           //skip header
                           true); ?>
         <div class="clearer"></div>
    +    <div class="sharethis">
    +    <?php global $ID; echo "  <g:plusone href=\"" . wl($this->entry['page'],'',true,'&') . (!empty($anchor) ? '#'.$anchor : '') . "\" size=\"medium\" count=\"true\"></g:plusone>\n";?>
    +    </div>
         <div class="blogtng_footer">
             <div class="level1">
                 <?php $entry->tpl_created("%Y-%m-%d @ %H:%M"); ?> |

  • list.php for the overview of blog posts:

    list.php

    --- list.php.orig       2012-05-29 23:08:12.000000000 +0200
    +++ list.php    2012-05-30 00:11:03.000000000 +0200
    @@ -45,5 +45,8 @@
                           true);
     ?>
         <div class="clearer"></div>
    +    <div class="sharethis">
    +    <?php global $ID; echo "  <g:plusone href=\"" . wl($this->entry['page'],'',true,'&') . (!empty($anchor) ? '#'.$anchor : '') . "\" size=\"medium\" count=\"true\"></g:plusone>\n";?>
    +    </div>
         <div class="blogtng_footer">
             <div class="level1">

• Add a Stylesheet for the sharethis Class:

  tpl/mnml-blog/user/screen.css

  .sharethis{
      text-align:right;
      padding:0;
      margin:0;
  }

After the above changes you should now see a Google+1 Button in the lower right corner of each blog post.