This construct used to work, and pretty much the Zend Config is built around that accessing NULL as array yields no notices:

$ php --version
PHP 7.4.6 (cli) (built: May 29 2020 01:44:57) ( NTS )
$ php -r '$a=null; $a["bla"];'
PHP Notice:  Trying to access array offset on value of type null in Command line code on line 1

• https://www.php.net/manual/en/migration74.incompatible.php:

Array-style access of non-arrays ¶

Trying to use values of type null, bool, int, float or resource as an array (such as $null["key"]) will now generate a notice.

rfc:

• https://wiki.php.net/rfc/notice-for-non-valid-array-container

| Q | A |-------------- | ------ | QA | yes

Description

Port of https://github.com/zendframework/zend-config/pull/66

Fixes #1

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.

Originally posted by @eguvenc at https://github.com/zendframework/zend-config/pull/52

Welcome to Renovate! This is an onboarding PR to help you understand and configure settings before regular Pull Requests begin.

🚦 To activate Renovate, merge this Pull Request. To disable Renovate, simply close this Pull Request unmerged.

Detected Package Files

• composer.json (composer)
• .github/workflows/auto-close.yml (github-actions)
• .github/workflows/continuous-integration.yml (github-actions)
• .github/workflows/docs-build.yml (github-actions)
• .github/workflows/release-on-milestone-closed.yml (github-actions)

Configuration Summary

Based on the default config's presets, Renovate will:

• Start dependency updates only once this onboarding PR is merged
• Enable Renovate Dependency Dashboard creation.
• Ignore node_modules, bower_components, vendor and various test/tests directories.
• Automerge patch and minor upgrades if they pass tests.
• If automerging, push the new commit directly to the base branch (no PR).
• Wait for branch tests to pass or fail before creating the PR.
• Rebase existing PRs any time the base branch has been updated.
• Separate major versions of dependencies into individual branches/PRs.
• Do not separate patch and minor upgrades into separate PRs for the same dependency.
• Raise PR when vulnerability alerts are detected.
• Evaluate schedules according to timezone UTC.
• Append Signed-off-by: to signoff Git commits.
• Apply label renovate to PRs.
• Group all minor and patch updates together.
• Default configuration for repositories in the Laminas organisation

🔡 Would you like to change the way Renovate is upgrading your dependencies? Simply edit the renovate.json in this branch with your custom config and the list of Pull Requests in the "What to Expect" section below will be updated the next time Renovate runs.

What to Expect

With your current configuration, Renovate will create 4 Pull Requests:

❓ Got questions? Check out Renovate's Docs, particularly the Getting Started section. If you need any further assistance then you can also request help here.

Read more information about the use of Renovate Bot within Laminas.

Feature Request

| Q | A |------------ | ------ | QA | yes

Summary

As decided during the Technical-Steering-Committee Meeting on August 3rd, 2020, Laminas wants to implement vimeo/psalm in all packages.

Implementing psalm is quite easy.

Required

• [ ] Create a psalm.xml in the project root
• [ ] Copy and paste the contents from this psalm.xml.dist
• [ ] Run $ composer require --dev vimeo/psalm
• [ ] Run $ vendor/bin/psalm --set-baseline=psalm-baseline.xml
• [ ] Add a composer script static-analysis with the command psalm --shepherd --stats
• [ ] Add a new line to script: in .travis.yml: - if [[ $TEST_COVERAGE == 'true' ]]; then composer static-analysis ; fi
• [ ] Remove phpstan from the project (phpstan.neon.dist, .travis.yml entry, composer.json require-dev and scripts)

Optional

• [ ] Fix as many psalm errors as possible.

| Q | A |-------------- | ------ | Documentation | yes | Bugfix | no | BC Break | no | New Feature | yes | RFC | no | QA | yes

Description

Adds a typedMode flag to the INI Reader to support the built-in INI_SCANNER_TYPED flag on parse_ini_file(). This allows integer, boolean, and null values to be returned as the appropriate types, rather than all being returned as strings.

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?

Originally posted by @akomm at https://github.com/zendframework/zend-config/issues/7

• [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

Originally posted by @eguvenc at https://github.com/zendframework/zend-config/issues/50

This patch provides PHP 8.1 support, via the following changes:

• Adds ~8.1.0 to the list of allowed PHP versions
• Bumps laminas-stdlib minimum supported version to 3.6
• Bumps PHPUnit to 9.5.5
• Adds CI configuration to ignore platform PHP when installing under 8.1
• Adds #[ReturnTypeWillChange] annotations to methods of Config implementing internal interfaces
• Updates the unit test suite to work under PHPUnit 9.5

Release Notes for 3.5.1

3.5.x bugfix release (patch)

3.5.1

• Total issues resolved: 0
• Total pull requests resolved: 1
• Total contributors: 1

Bug

• 17: Merge release 3.4.1 into 3.5.x thanks to @github-actions[bot]

Release Notes for 3.4.1

3.4.1

• Total issues resolved: 0
• Total pull requests resolved: 1
• Total contributors: 1

Bug

• 13: Fix returned value of Laminas\Config\Processor\Queue#process() to comply with interface declaration thanks to @7-zete-7