mahara-contributors team mailing list archive

[Aaron Wells <1327921@xxxxxxxxxxxxxxxxxx>]

Tagged with "compatibility-breaking", because it breaks backwards
compatibility (for those few sites that are using plugin configs set in
the config.php file).

We'll need to remember to put a note about this in the 1.10.0 upgrade
instructions.

** Changed in: mahara
     Assignee: (unassigned) => Aaron Wells (u-aaronw)

** Changed in: mahara
       Status: New => Fix Committed

** Tags added: nominatedfeature

** Tags removed: nominatedfeature
** Tags added: compatibility-breaking

-- 
You received this bug notification because you are a member of Mahara
Contributors, which is subscribed to Mahara.
Matching subscriptions: Subscription for all Mahara Contributors -- please ask on #mahara-dev or mahara.org forum before editing or unsubscribing it!
https://bugs.launchpad.net/bugs/1327921

Title:
  Plugin config params in config.php throw a strict standards notice:
  "Creating default obect from empty value"

Status in Mahara ePortfolio:
  Fix Committed

Bug description:
  In bug 1196781, Mahara 1.9, we added the ability to set plugin
  configuration parameters in config.php. The syntax I suggested for
  this is a chain of nested objects, e.g:

   $cfg->plugin->search->elasticsearch->host = 'localhost';

  However this throws a PHP strict standards notice, e.g. "Creating
  default object from empty value in config.php on line 90". And in PHP
  5.4, which more and more people are using, strict standards notices
  are included in E_ALL, which is the default for many servers.
  Resultantly, any users who are using plugin config params in
  config.php are likely to get this notice clogging up their logs. We
  disable E_STRICT notices in error.php, but config.php is loaded and
  evaluated before error.php

  You can of course manually initialize each object in the chain, but
  that's not very concise.

   $cfg->plugin = new stdClass();
   $cfg->plugin->search = (isset($cfg->plugin->search) ? $cfg->plugin->search : new stdClass());
   $cfg->plugin->search->elasticsearch = new stdClass();
   $cfg->plugin->search->elasticsearch->host = 'localhost';

  And it's a bit awkward for our deployment process, which previously
  was able to store the configs in a database as a set of (key, value)
  pairs and then just churn those into PHP statements of the sort
  "\$cfg->{$key} = {$value};". If we needed to initialize each object as
  well, that would be a lot trickier.

  So the current workaround we're using is just to put an @ before it:

   @$cfg->plugin->search->elasticsearch->host = 'localhost';

  Anyway, after giving this some thought, I think the best way to go is
  to replace the "->"'s with underscores _. So this becomes:

  $cfg->plugin_search_elasticsearch_host = 'localhost'.

  This has these ramifications:

  1. After loading up config.php we'll need to locate all the configs
  that start with "plugin_" and parse them into proper plugin configs.

  2. The parsing will follow this regular expression:
  \^plugin_([a-z]+)_([a-z]+)_(.+)$\. The first capture group is the
  plugin type, the second capture group is the plugin name, and the
  third capture group is the config field within that plugin.

  3. Core config parameters are consequently forbidden from beginning
  with "plugin_".

To manage notifications about this bug go to:
https://bugs.launchpad.net/mahara/+bug/1327921/+subscriptions