Dokuwiki: Separate local and core code

[ndarilek]

I currently have DokuWiki running in a Docker container. This works very well in most circumstances, but the upgrade/rollback story is more painful than it needs to be.

For instance, I build a Docker container containing DokuWiki and everything works well. However, if I install a new plugin, it gets placed in lib/plugins alongside plugins shipped with the core installation. If that container shuts down, the plugin is lost. If I make the lib/plugins directory a volume, Docker's way of sharing directories between versions of a container, core plugins are kept alongside user-installed ones. If I generate a new image with a new version, then load the volumes from the old image, I'll have all new code but older core plugins. This may be the same for templates and other data, I haven't done anything with templates. Currently I store all of Doku in a directory outside of the container, but that sidesteps most of Docker's benefit.

It would be nice if plugins, templates, etc. were installed to one or more directories specifically set aside for local modifications. So lib/plugins/local, for instance, would only contain plugins I installed, and lib/plugins could contain those shipped with the installation. Better yet would be local/lib/plugins, so I could treat all of local/ as a volume. Upgrading Doku would then just be a matter of building a new container, pointing a few volumes at the old config/plugins/templates, and everything would just work. If it didn't, I could roll back by loading the old image. Maybe add lib/ directories to data/ so data/ could be treated as a directory holding all user data/modifications for a Doku install (aside from configuration, that is.)

[splitbrain]

This might be achievable by the config cascade already. Basically you would do a farm setup. The farmer is inside the container, the animal(s) are in the volume.

[ndarilek]

Hmm, possibly, though it'd still be nice to separate these in a default
install so you could, for instance, replace farms and animals with
containers.

Where do animals place their plugins? I only see examples of separate
configuration/data.

[michitux]

I think the proper solution for this problem is to install plugins and
templates when you build the container. Installing a plugin or template is
even simpler than installing DokuWiki, you only need to extract a directory
(or clone a git repository) in lib/plugins. Apart from that I think a farm
setup would make sense, you could create the needed inc/preload.php-file
when you build the container and then have a completely separated
configuration and data directory.

[splitbrain]

@michitux I think the question is. can animals install their own plugins? I think we talked about this a while ago, but I'm not sure if that has ever been supported.

[michitux]

2014-07-09 10:39 GMT+02:00 Andreas Gohr [email protected]:

@michitux https://github.com/michitux I think the question is. can
animals install their own plugins? I think we talked about this a while
ago, but I'm not sure if that has ever been supported.

No, this has never been supported and the plugin path (lib/plugins/) is
hardcoded in many plugins so this is nothing that we can easily change in
DokuWiki. It might be a nice feature but I think in the context of Docker
containers the solution that I proposed is the best one.

[ndarilek]

Unfortunately, including plugins in the image breaks the idea of
shipping a generic wiki which users can instantiate and build out as
wanted. It also vastly complicates the image build process.

Anyhow, if it can't be done due to plugin writers using /lib/plugins as
a literal then I'll close the issue. I recognize that many of these
types of apps were built before containerization/12-factor, and it isn't
realistic to expect that they can be changed to fit those ideals.

Thanks for pointing me to farms. That may help a bit with the upgrade
process.

[michitux]

A different solution would be to add the bundled extensions to the extension repository so they can be updated using the extension manager. However that would create new problems as we would either need to ensure that the bundled extension are compatible with more than one DokuWiki version or we would need to make sure that the extension manager only installs the plugin version that matches the DokuWiki version.

[splitbrain]

Because people keep asking for an official docker image in #1896 I outline what I think is needed here again:

• config can be separated by config cascade :heavy_check_mark:
• data can be separated by config setting :heavy_check_mark:
• plugins can not be separated :x:
• templates can not be separated :x:

Solving the latter two needs:

• maybe introducing them in the config cascade (alternative: have a secondary place by default)
• some changes to the internal auto loading of plugins (we need to check multiple places
  
  
  
  • autoloaded in inc/load.php
  
  
  • load_plugin() in inc/plugins.php
  
  
  • maybe there's something in the parser/renderer stuff, but I think it should be covered by the above
  
  
• we can only have one PLUGIN_INCLUDE define, I think it should always point to the user's plugins
• plugins expect to be able to access their resources via /lib/plugins//
  
  
  
  • this can probably be solved by some clever rewriting
  
  
  • or by having the bundled plugins know they are different
  
  
• adjust the extension manager to be able to cope with different locations
  
  
  
  • basically display/enable bundled plugins only
  
  
  • install to user dir
  
  

I would suggest to split stuff into /lib/plugins/ and /lib/plugins.bundled/. So most stuff keeps the same for user installed plugins. Then it may be possible to solve all this by just adjusting the code of the bundled plugins.

All of the above applies for templates as well of course.

[DidierHoarau]

Hi,

First of all, thank for the great work. I know it can be complex and time consuming. This wiki is really great.

I would just have 1 comment: this change would make creating Docker images (official or not) easier but wouldn't it be also a good thing for "normal" installation? It would then make it easier to upgrade those installation as well, right?

Thanks.

[glensc]

somewhat workable solution exists:

mv lib/plugins lib/plugins.bundled
mkdir lib/plugins
(cd lib/plugins && ln -s ../plugins.bundled/* .)

then the plugins get updated with image update. problem arises only if plugins are added/removed in dokuwiki-core.

[splitbrain]

@glensc good idea, the container startup script could take care of maintaining the correct symlinks.

[mat-m]

@glensc : I would do the opposite:
Say your wiki persistent data is:

/var/dokuwiki-persist/conf/{*.local.php;*.auth*.php}
/var/dokuwiki-persist/data/
/var/dokuwiki-persist/lib/tpl/*
/var/dokuwiki-persist/lib/plugins/*

Mount /var/dokuwiki/persist in the container as /var/doku-data and let the entrypoint script symlinks all the endpoints of the list in the standard image.
The only constraint is you need to rename plugins and themes that you overload on your own.
Did I missed something ?

[kolbyjack]

I've built a docker image based on @glensc's suggestion, and generated images for frusterick-manners, greebo, and hogfather, to test upgrading (older releases didn't work with the php version available in alpine). It seems to work well for me, it's available here and the images are here