Some weeks ago I started to upgrade multiple outdated Hrun installations from 2014 to the actual Greebo release. As long as a dokuwiki installation works it is usually a no-brainer. Now I'm finished nearly - some things still have to be fixed. Beside the change to PHP7 in the background, the effort of the upgrade overall was higher than expected. To be honest my use cases are more often different than a wiki.

Dokuwiki comes with a plugin system to extend its functionality and some plugins are bundled with it. In general I use as less as possible plugins and highly recommend to be very careful by selecting a plugin. Especially avoid the usage of third party plugins! Once a plugin is used by a lot of content it is hard to get rid of it later on.

If a third party plugin doesn't work properly after an upgrade, it breaks things and it could be a very high effort to solve this!

The reasons are simple:

• the continuous maintenance is not always guarantied, so perhaps it will no longer work with newer releases of dokuwiki (examples: folded, styler)
• the number of third party plugins and even templates published at dokuwiki's website have exceeded a useful level
• even if a simple plugin seems to provide a required, useful functionality - there are bugs which are not fixed, the download link (include updates) doesn't work, the documentation lacks (example: ifauth)

There is a core team of developers which maintains a set of plugins actively. These plugins are usually update safe, but this isn't guaranteed. Good examples are the wrap and the BlogTNG plugins. On the other side the farmer plugin raises complexity and limits flexibility - even if it works - against the old way by manually configure a farm. See below.

Now, I don't want to give recommendations for one or another plugin. The point here is that there are a lot of very similar plugins. The differences are very, very little quite often. I suggest to made the choice along the popularity indicator of the Extension Manager.

A lot of syntax plugins without parameters can be replaced through  entities.local.conf !

Unfortunately there is no indicator if a plugin will be maintained over the time. But a higher popularity increases the chance for long term support.

Templates can be considered similar to plugins. In both cases quantity rules over quality - less would be more here!

The by default bundled template dokuwiki (since “Adora Belle” 2012) is highly configurable and can be a good base for an individual template. But I don't think it is a good idea always to create a “new” template which differs very less. Much less if the most changes can be done through  userstyle.css . Personally there is to much space wasted, unneeded information provided and the displayed colors are doesn't correspond nicely enough.

To fit my needs I created some patches which adds some config options to change the look & feel. Thus I cover different of my use cases. With dokuwiki's usual release circle of 1 year, it should be acceptable to apply them after an upgrade. With additional css overwrites the appearance is difficult enough to me.

With a dokuwiki farm it is possible to run multiple websites with one core instance - the farmer and its animals. This really great feature appeared round about 2009. At this time it have to be setup by hand, meanwhile there exist the farmer plugin. But I'm not satisfied how the plugin works by default. The facts ^(Why?):

1. The farmer acts as a master, thus it have to much control over the animals. A change in the configuration of the farmer is adopted by the animals.
2. The farmer is IMHO not really required, it could (should) be implemented as first animal. From an administrators POV every animal should be independent.
3. The  .htaccess  based setup seems to have precedence over a DNS based setup - even if it works (with some caveats)
4. The options of the farmer plugin inside the Configuration Manager are pretty useless - it just a waste of (visual) space.

• deactivating a plugin in the farmer deactivates it for ALL animals too (the plugin have to be activated for each animal again)
• the farmer is like a single website, a single installation for one wiki - in comparison the animals looks like a foreign matter
• I wouldn't use a  .htaccess  setup, better change the root cause to be able to do a DNS based setup
  • The initial configuration requires that the farmer - even if not used (but required for administration purposes through the farmer plugin) - have to have a different DNS name than the first animal

Now, these are some main points. If you think more about it, it would grow to an article inside this article. As a conclusion it is a better choice to setup a farm manual. Even because the setup through the farmer plugin isn't really intuitive (yet). Anyway …

If you use the farmer plugin, check out the files in  lib/plugins/farmer/includes/  for “hidden” config options!

Update! After I tried to remove the plugin I ran into trouble. It was a big effort to identify the cause, but at least the plugin removed options from the animals  local.php :

1.  $conf['useacl'] = 1; 
2.  $conf['superuser'] 
3.  $conf['breadcrumbs'] 
4.  $conf['start'] 
5.  $conf['useheading'] 

And may be more which I didn't recognize at first. Thus a rollback to a manual farm setup is critical. I highly recommend to make backups of all animals  conf  folder before an installation of the plugin.

First of all: dokuwiki is great! Still! Kudos to the developers.

I use dokuwiki for a long time now - with all “my” content I'm trapped to stay with it. But I see that the functionality and my requirements are drifting apart. It is not my intention to open another construction side - but I think about an individual fork. Maybe not really a fork, more to build a patch set which I will apply over new releases of dokuwiki. Not sure yet, lets see what will be in the future.

• Dokuwiki: plugin isauth
• Dokuwiki: Template tweaks
• Dokuwiki: CAPTCHA patch
• Dokuwiki: plugin ifauth patch