6.3.11 (2021-07-17)

Overview of merged pull requests

FEATURE: I18n.translate() now accept $source to contain dots instead of only a path to the translation file 

What I did translateByExplicitlyPassedOrderedArguments() and I18n.translate() now accept $source argument to contain dots instead of only a path to the translation file.

When we use translations we use for example the shorthand `php {I18n.translate('Muensmedia.DistributionPackage:NodeTypes.Content.Todo.Container:ui.label')} ` when we want to pass arguments we had to use `php ${I18n.translate('progress', null, {solved: this.checkedElementsCount, total: this.checkboxCount}, 'NodeTypes/Content/Todo/Container', 'Muensmedia.DistributionPackage')} ` As you can see, you have to pass the path to the translation file instead of the well known dot-notation.

This commit enables you to use also the well known dot-notation for the source argument: `php ${I18n.translate('progress', null, {solved: this.checkedElementsCount, total: this.checkboxCount}, 'NodeTypes.Content.Todo.Container', 'Muensmedia.DistributionPackage')} `

How I did it In the method translateByShortHandString() we already replace dots with slashes, so I just copied this behavior to the method translateByExplicitlyPassedOrderedArguments() https://github.com/neos/flow-development-collection/blob/5b7b57523ab1a3b05105227e0a5266ece2777038/Neos.Flow/Classes/I18n/EelHelper/TranslationHelper.php#L140

How to verify it

Packages: Flow

TASK: Add minimal dependencies build 

This should make sure that our minimum dependency requirements actually lead to a working installation. If this build fails, we need to raise some dependencies minimum version.

BUGFIX: Change empty check on target collection to `valid()` in resource:copy 

$targetCollection->getObjects() method returns a generator, which will always return false in an empty() check. This makes it impossible to use resource:copy as this always fails with a The target collection “tmpNewCollection” is not empty. error.

The problem is mentioned here: https://github.com/neos/flow-development-collection/issues/2510

What I did Change !empty() against a ->valid() check

How to verify it Use resource:copy to copy assets to an empty Storage.

~~[ ] Tests have been created, run and adjusted as needed~~ (not needed)
[x] The PR is created against the lowest maintained branch

This replaced PR https://github.com/neos/flow-development-collection/pull/2512

Packages: Flow

TASK: Revert #2052 - Add TTL to tags in RedisBackend 

This resolves the issues with the redis backend that came up after the changes in #2052, which unfortunately are worse than the benefits. We’d still like to get the TTL for tags in, but likely need to refrain from having them consistent/in sync.

See https://github.com/neos/flow-development-collection/issues/2483

Packages: Cache Flow

BUGFIX: retrieve package by case insensitive packageKey 

What I did

The PackageManager::getPackage($packageKey) method should throw an exception or return the found package. There is a case, such that getPackage returns null. In recent php versions, this causes a php error because the return value of the api public function getPackage($packageKey): PackageInterface is not met:

` Exception in line 514 of /var/www/Data/Temporary/Development/Cache/Code/Flow_Object_Classes/Neos_Flow_ResourceManagement_Streams_ResourceStreamWrapper.php: Return value of Neos\\Flow\\Package\\PackageManager::getPackage() must implement interface Neos\\Flow\\Package\\PackageInterface, null returned - See also: 202106101712258f223a.txt `

In older flow versions (4.0 and up), this might also be a problem, because the method actually can return null instead of throwing an exception.

Problem analysis

The problem occures, because the check, if an exception should be thrown by isPackageAvailable(), ignores the case during the check, whereas the actual return statement return $this->packages[$packageKey]; needs the correct case.

How I did it

I’m using $this->getCaseSensitivePackageKey($packageKey) to retrieve the key in the correct case, such that $this->packages returns the correct package.

How to verify it

A call like $packageManager->getPackage(‘Neos.some.package.with.wrong.case’) should throw a php error in recent versions.

Packages: Flow

TASK: Fix documentation for firewall option “rejectAll”

The rejectAll option needs to be set as boolean. See: https://github.com/neos/flow-development-collection/blob/6.3/Neos.Flow/Classes/Security/Authorization/FilterFirewall.php#L53

Packages: Flow

BUGFIX: Avoid open_basedir restriction with realpath 

## Bug

I encountered the following error in the setup (/setup/index?step=1):

(Plesk / PHP7.4 / Flow7.1)

!`image <https://user-images.githubusercontent.com/85400359/121085865-b51c5000-c7e2-11eb-81f8-602eb0c51167.png>`_

### The error source: ` $realPhpBinary = realpath(PHP_BINARY); `

My web hoster doesn’t allow me to change the open_basedir to include “/usr/local/php74/bin/php”.

## Fix

But using: php -r “echo realpath(PHP_BINARY);” in exec() will work and bypass open_basedir.

### implemented:

` exec(PHP_BINARY . ' -r "echo realpath(PHP_BINARY);"', $output); $realPhpBinary = $output[0]; ` Tested with: (Plesk / PHP7.4 / Flow7.1)

### similar exec use:: exec() is also used in a similar manner on line 844:

`exec($phpBinaryPathAndFilename . ' -r "echo realpath(PHP_BINARY);"', $output, $result);`

### realpath? … using realpath was introduced with #2032

## Recap

This change brings up the compatibility for some ISPs(web hosting)

By getting the realPhpBinary see #2032: $realPhpBinary = realpath(PHP_BINARY); a Neos\Flow\Error\Exception is thrown with the Code: 1355480641 Warning: realpath(): open_basedir restriction in effect. File(/usr/local/php74/bin/php) is not within the allowed path(s) on the most(rather all) web hosting platforms(f.x. Plesk).

By using system commands to get the realpath inside exec() this behavior can be avoided.

Packages: Flow

BUGFIX: Avoid bool return value in restoreFlashMessageContainerFromSession()

It can happen, that getData(…) returns a boolean, leading to an error due to the return type declaration.

BUGFIX: Ensure cache backends are prepared before usage 

If the flushByTag or findIdentifiersByTag methods of the TaggableMultiBackend are used before backend initialization by other methods, the backends have to be prepared. Otherwise, $this->backends is an empty array and no cache entries are flushed.

What I did I added the $this->prepareBackends() calls in the two methods.

How to verify it - Configure the TaggableMultiBackend for the Neos_Fusion_Content cache - Change a node property in the Neos backend - Reload the page

Before this change, the change of the node property was saved to the db, but the cache was not flushed. Thus, the incorrect property value was shown in the Neos backend after a page reload.

Packages: Cache

Added all new types introduced since PHP7.1 to not being qualified 

Since PHP 7.1 iterable, object and mixed are new allowed PHP types, which are not allowed to be “qualified”.

But having a method returning one of those (and having a corresponding type-hint) did lead to a proxy method, annotated with \type, which will lead to a PHP Fatal error: Type declaration ‘type’ must be unqualified in …

This resolves #2498

List of types taken from here: https://www.php.net/manual/de/language.types.declarations.php

(and yes, this commit includes one type, which is part of PHP8.0 which is not (yet?) supported by Flow 6.3, but I guess it will not harm anyone and definitely makes live easier in upwards versions.

TASK: Update psalm-baseline 

TASK: Disallow installing guzzlehttp/psr7 2.0 

It is incompatible with versions < 1.7 due to the replaced stream_for method. The ~2.0 dependency was added before the actual 2.0 release and this breaking change was added later, making it incompatible. If 2.0+ is needed, you need to upgrade to Flow 7.1

Packages: Factories Flow