By default the INI reader is processing sections. It is not possible to merge sections, which is the default behavior of parse_ini_file().

This PR introduces the protected property $processSections with a public getter and setter. It enables users to tell the reader not to process sections by setting $processSections to false. The default behavior of the reader does not change.

• [x] Are you creating a new feature? Yes
  • [x] Why is the new feature needed? What purpose does it serve? See description above
  • [x] How will users use the new feature? See docs/book/reader.md in the INI section
  • [x] Base your feature on the develop branch, and submit against that branch. Check
  • [x] Add only one feature per pull request; split multiple features over multiple pull requests Check
  • [x] Add tests for the new feature. Check
  • [x] Add documentation for the new feature. Check
  • [x] Add a CHANGELOG.md entry for the new feature.

In case we extend the Config class we would like to have the same type of the subnodes as the parent node.

Relates to #55 / #56

• [x] Is this related to quality assurance?

as per zendframework/zendframework#7660

also entails these changes:

• bump minimum php version to 5.6
• bump minimum phpunit version to 4.8
• add composer scripts entries
• fix coveralls configuration
• fix travis.yml env variables to not be affected by travis-ci/travis-ci#1444
• remove obsolete phpunit bootstrap

This adds resolution to typical notice seen:

Indirect modification of overloaded element of Zend\Config\Config has no effect

Example:

        $config = new Config($this->all, true);

        $closure = function (&$property, $value) {
            if ($property === null) {
                return;
            }

            $property = $value;
        };

        // updates $config['db']['pass'] value to 'secret'
        $closure($config['db']['pass'], 'secret');
        // $config['db']['pass2'] is not present and will not be created
        $closure($config['db']['pass2'], 'secret');

This requires PHP 5.3.4 :

Update: This problem was fixed in PHP 5.3.4 and ArrayAccess now works as expected:

Starting with PHP 5.3.4, the prototype checks were relaxed and it's possible for implementations of this method to return by reference. This makes indirect modifications to the overloaded array dimensions of ArrayAccess objects possible.

• https://stackoverflow.com/a/2881533/2314626

This patch updates the Constant processor to allow processing class constants, including the ::class pseudo-constant; additionally, it ensures that both the Token and Constant processors can apply to Config keys as well as the values by calling their enableKeyProcessing() methods.

To allow this to work, I've changed the visibility of Token::doProcess() from private to protected, to allow overriding the method within the Constant class. I've also added the new test case ZendTest\Config\Processor\Constant to cover the behavior.

Essentially, this allows the following to work (assuming the provided classes and constants exist):

{
    "Acme\\Component::CONFIG_KEY": {
        "host": "Acme\\Component::CONFIG_HOST",
        "dependencies": {
	    "Acme\\Foo::class": "Acme\\FooFactory::class",
        }
    }
}

Via:

$config = new Config(Factory::fromFile('config.json'), true);
$processor = new Processor\Constant();
$processor->enableKeyProcessing();
$processor->process($config);

• composer.json entry for zend-servicemanager using dev-develop as 2.7.0.
• Updated AbstractConfigFactory to follow new interface definition.
• Updated ReaderPluginManager and WriterPluginManager to follow changes in AbstractPluginManager; they aggregate invokables and merge them with incoming configuration before passing on to the parent constructor.
• Updated Factory to pass an empty service manager instance to plugin managers when lazy loading them.

• [x] I was not able to find an open or closed issue matching what I'm seeing.
• [x] This is not a question.

I'm trying to extend Zend\Config\Config and supply default config. I also add some extra methods.

Code to reproduce the issue

<?php

namespace Zend\Config\Issue;

use Zend\Config\Config;

/**
 * Class Simple
 * @package Zend\Config\Issue
 */
class Simple extends Config
{
    /** @var int */
    private static $callsCount = 0;

    /**
     * Simple constructor.
     */
    public function __construct()
    {
        self::$callsCount++;
        echo __METHOD__ . " - Number of calls: " . self::$callsCount . PHP_EOL;

        $default = [

            'something' => [
                0 => 'I am an array',
                1 => '\Zend\Config\Config::__construct() will try to create new instance of itself',
                2 => 'And that\'s fine',
                3 => 'As long as it does "new self" instead of "new static"',
                4 => 'because static means this extending class'
            ],
            'something_else' => 'this is fine'
        ];

        // Call parent constructor \Zend\Config\Config::__construct()
        parent::__construct($default);
    }


}

Expected results

Definitely not infinite loop.

Actual results

Infinite loop - class Simple is calling Zend\Config\Config::__construct() and Zend\Config\Config will try to create new instance of itself using "new static()", which will in turn call extending class Simple ..... If you run code I provided, you will get following output:

Zend\Config\Issue\Simple::__construct - Number of calls: 1
Zend\Config\Issue\Simple::__construct - Number of calls: 2
Zend\Config\Issue\Simple::__construct - Number of calls: 3
Zend\Config\Issue\Simple::__construct - Number of calls: 4
Zend\Config\Issue\Simple::__construct - Number of calls: 5
Zend\Config\Issue\Simple::__construct - Number of calls: 6
Zend\Config\Issue\Simple::__construct - Number of calls: 7
Zend\Config\Issue\Simple::__construct - Number of calls: 8
(...)

As proposed in #5.

I thought about adding an option to toggle the autoload usage, but I could not find any reason why you would want to set it. If you want it to be added, let me know.

I did not add a trailing slash to resolved ::class-literals, because:

• The rendered output does not include any namespacing.
• Even if the rendered output is included in another namespace, PHP does not transfer the context to the included file.

Close #4 Close #5

Similar to the use_bracket_array_syntax-option, I would propose to add a use_class_contant-option.

If enabled, string keys and values should be checked for being a known full qualified class- or-interface name, using class_exists and interface_exists.

Additional option use_class_constant_autoload might be added, to set whether autoload should be used.

It only works if the names are defined in the main file, were included/required from another script or a registered autoloader can resolve them.

I'v tried it on some packages, which use this writer and it worked well without breaking anything.

Possible issues:

Writing config in a different context than reading it (e. G. different autoloader configs). But since it is an option you don't have to use it. Depending on usage context you can localy enable this option for development and disable for deployment.

@weierophinney

Good morning,

Could it be possible to make us able to setup the separator to use for the Java propertie configuration file reader? Right now, the colon sign is hardcoded, making us unable to change it by equal sign which should be also supported. You should also maybe considere a new option allowing to remove leading and trailing whitespaces from resulting key/value pairs.

For now, we have not other choice than doing https://github.com/i-MSCP/imscp/commit/69df56265aea1a95d947ed708a8839c0dc7c13aa and then:

namespace iMSCP;

use iMSCP\Config\Reader\JavaProperties;
use iMSCP\Config\StandaloneReaderPluginManager;
use Zend\Config\Config;
use Zend\Config\Factory;

// Load default settings, that is, those that are overridable by administrator through GUI
$config = new Config(include_once 'default_settings.php', true);

// Load and merge settings from master i-MSCP configuration file.
// We need set our own JavaProperties configuration file reader as
// the one provided by ZF doesn't handle equal sign as separator
Factory::setReaderPluginManager(new StandaloneReaderPluginManager());
Factory::registerReader('conf', JavaProperties::class);
$config->merge(new Config(Factory::fromFile(CONFIG_FILE_PATH)));

Regarding the above code, maybe that the standalone reader plugin manager should also accept custom definitions because right now, we need provide our own.

Finally, could you provide a writer implementation for that configuration file type?

Thank you.

Provide a narrative description of what you are trying to accomplish:

• [x] Are you fixing a bug?
  • [ ] Details in the issue #55
  • [ ] Infinite loop
  • [ ] Using self will not cause extending class to be called

No tests are supplied because existing tests cover this change.

This feature will allow getenv function to be run from static files like yaml.

Using Zend\Config\Processor\Env

This example illustrates the basic usage of Zend\Config\Processor\Env:

putenv('AMQP_PASSWORD=guest');

use Zend\Config\Config;
use Zend\Config\Factory;
use Zend\Config\Processor\Env as EnvProcessor;

$config = new Config([
            'host' => '127.0.0.1',
            'port' => 5672,
            'username' => 'guest',
            'password' => 'env(AMQP_PASSWORD)',
            'vhost' => '/',
        ], true);

$processor = new EnvProcessor;
$processor->process($config);
$config->setReadOnly();

echo $config->amqp->password;

This example returns the output: guest.

• [x] I was not able to find an open or closed issue matching what I'm seeing.
• [x] This is not a question. (Questions should be asked on chat (Signup here) or our forums.)

Code to reproduce the issue

# amqp.yaml
# 
amqp:
    host: 127.0.0.1
    port: 5672
    username: 'env(AMQP_USERNAME)'
    password: 'env(AMQP_PASSWORD)'
    vhost: /

namespace Zend\Config\Processor;

use Zend\Config\Config;
use Zend\Config\Exception;
use Zend\Config\Processor\Token;
use Zend\Config\Processor\ProcessorInterface;

class Env extends Token implements ProcessorInterface
{
    protected function doProcess($value, array $replacements)
    {
        if (! is_string($value)) {
            return parent::doProcess($value, $replacements);
        }

        if (false === strpos($value, 'env(')) {
            return parent::doProcess($value, $replacements);
        }

        $value = $this->parseEnvRecursive($value);

        return $value;
    }

    /**
     * Parse env variables
     * 
     * @param mixed $input input
     * @return string
     */
    protected function parseEnvRecursive($input)
    {
        $regex = '/env\((.*?)\)/';
        if (is_array($input)) {
            $input = getenv($input[1]);
        }
        return preg_replace_callback($regex, array($this, 'parseEnvRecursive'), $input);
    }
}

require 'vendor/autoload.php';

use Symfony\Component\Yaml\Yaml as SymfonyYaml;
use Zend\Config\Config;
use Zend\Config\Factory;
use Zend\Config\Processor;
use Zend\Config\Reader\Yaml as YamlConfig;

Factory::registerReader('yaml', new YamlConfig([SymfonyYaml::class, 'parse']));

putenv('AMQP_USERNAME=guest');

$config = Factory::fromFile(dirname(__FILE__).'/config/amqp.yaml');

$config = new Config($config, true);
$processor = new Processor\Env();
$processor->process($config);
$config->setReadOnly();

echo $config->amqp->username; // guest

Expected results

// guest

I came to the following question/thoughts by chance, when I'v started implement a writer capable to write array configuration into multiple files. It splits configuration by criteria, currently hard-coded by key, later by strategy defined, into different files and join them in a stub-file, which includes the config from separate files.

I use it for example in zfcampus/zf-configuration, to reduce the configuration file size and split top level keys into separate files. This way I can find things much quicker, if further module-separation is not possible/logical.

Now everything works fine, but I'v noticed, that the API defined by WriterInterface does not make much sense in my new writer, because toString() would only return the stub-file contents.

This made me think about two possibilities: Either my implementation of WriterInterface is misusing this interface and it is actually something else, that should internally use Writers, but is itself not a writer or the current spec for Writer in zend-config is to concrete.

My conclusion so far is:

• The job of my WriterInterface implementation is really to write the configuration, not something do something else. How it writers, in a single or multiple files, or even maybe not in a file, does not make it something else, than a writer.
• Actually the current WriterInterface is rather something like a FileWriterInterface. A configuration should actually be writable to indefinite type of targets.

Example how it seem logical to me, but if I'm wrong with my thought somewhere, correct me:

interface WriterInterface
{
    /**
     * Write configuration
     * 
     * @param mixed $config
     */
    public function write($config);
}

interface FileWriterInterface extends WriterInterface
{
    /**
     * Write a config object to a file.
     *
     * @param  string  $filename
     * @param  mixed   $config
     * @param  bool $exclusiveLock
     * @return void
     */
    public function toFile($filename, $config, $exclusiveLock = true);

    /**
     * Write a config object to a string.
     *
     * @param  mixed $config
     * @return string
     */
    public function toString($config);
}

Whether Interfaces like the FileWriterInterface are actually needed then is another question. What do you think about it?