laminas / laminas-zendframework-bridge Goto Github PK

View Code? Open in Web Editor NEW

1.2K 29.0 21.0 599 KB

Alias legacy ZF class names to Laminas Project equivalents.

License: BSD 3-Clause "New" or "Revised" License

PHP 100.00%

laminas migration zendframework mezzio expressive laminas-api-tools apigility security-only

laminas-zendframework-bridge's Issues

ClassLoader type

Hello,

Got a bug on another repository : Rareloop/lumberjack-core#35

Is this from here or from this repo ?

`ConfigPostProcessor::replaceDependencyAliases` does not prevent infinite loop

Bug Report

Q	A
Version(s)	1.1.1

Summary

I recently ran into an infinite loop due to the fact that there was an alias pointing to itself.
I know, thats due to invalid configuration but as a consumer, I'd like to get an information that the configuration might be invalid rather than running into an infinite loop.

I think, we can fix this when using early continue in here:

laminas-zendframework-bridge/src/ConfigPostProcessor.php

Line 294 in 466d07d

$newAlias = $this->replacements->replace($alias);

If the alias does not differ, we dont need to execute while, e.g.

Current behavior

Infinite loop until memory_limit is reached.

How to reproduce

$config = [
	'dependencies' => [
		'aliases' => [
			'foo' => 'foo',
		],
	],
];

Expected behavior

Exception that the configuration might be invalid.

Support for zend-stratigility v2

We need to add autoloader override for zend-stratigility v2 functions.

Migration from ZendFramework on old PHP

Some projects that use ZendFramework still support old php versions.
For example PHPOffice / PHPWord >= php 5.3

BC Break Report

Summary

laminas-zendframework-bridge require >= 5.6 and is required even in old tags just rewrited to laminas (great job btw), tags used by older php versions

Previous behavior

Old php 5.3 - 5.5 projects use old tags of ZendFramework, whichout additional dependencies.

Current behavior

After switch to Laminas, every tag in every laminas repo require this project,

 - laminas/laminas-escaper 2.2.0 requires laminas/laminas-zendframework-bridge ^1.0 -> satisfiable by laminas/laminas-zendframework-bridge[1.0.0].

...

  - laminas/laminas-zendframework-bridge 1.0.0 requires php ^5.6 || ^7.0 -> your PHP version (5.3.29) does not satisfy that requirement.
  - Installation request for laminas/laminas-escaper ^2.2 -> satisfiable by laminas/laminas-escaper[2.2.0, 2.2.1, 2.2.10, 2.2.2, 2.2.3, 2.2.4, 2.2.5, 2.2.6, 2.2.7, 2.2.8, 2.2.9, 2.3.0, 2.3.1, 2.3.2, 2.3.3, 2.3.4, 2.3.5, 2.3.6, 2.3.7, 2.3.8, 2.3.9, 2.4.0, 2.4.1, 2.4.10, 2.4.11, 2.4.12, 2.4.13, 2.4.2, 2.4.3, 2.4.4, 2.4.5, 2.4.6, 2.4.7, 2.4.8, 2.4.9, 2.5.0, 2.5.1, 2.5.2, 2.6.0, 2.6.1].

https://travis-ci.org/PHPOffice/PHPWord/builds/632169932?utm_medium=notification&utm_source=github_status

How to fix

Change requirements in composer to php >=5.3

The bridge does not seem to work in all cases

Bug Report

Q	A
Version(s)	1.0.1

Summary

We got many reports that ocramius/proxy-manager 2.2 (which was using zendframeword/zend-code) breaks when using the laminas/laminas-code replacement. See symfony/symfony#35934 and doctrine/DoctrineMigrationsBundle#300 for instance.
It looks like the bridge is not foolproof.

laminas.dev website is down

https://docs.laminas.dev/laminas-zendframework-bridge/
https://discourse.laminas.dev/

Make autoloader a bit faster

laminas-zendframework-bridge/src/Autoloader.php

Line 22 in 0d159d8

spl_autoload_register(function ($class) use ($namespaces) {

You can make anonymous function as static one, and it will load a little bit faster.

Append rewrite delegator classes

Bug Report

Q	A
Version(s)	1.0.2

Summary

In delegators classes are not rewritten with Laminas namespace.

In 1.0.1 it works well.

Current behavior

I connect bridge module to my app modules for rewriting zend classes.

In delegators I used \Zend\ServiceManager\Proxy\LazyServiceFactory

[
    'service_manager' => [
        'delegators' => [
            Buzzer::class => [
                LazyServiceFactory::class,
            ],
        ],
    ]
]

But it throws with error in createDelegatorFromName of ServiceManager

foreach ($this->delegators[$name] as $index => $delegatorFactory) {
    $delegatorFactory = $this->delegators[$name][$index];
    if ($delegatorFactory === Proxy\LazyServiceFactory::class) { 
          $delegatorFactory = $this->createLazyServiceDelegatorFactory();
    }

    if (is_string($delegatorFactory) && class_exists($delegatorFactory)) {
        $delegatorFactory = new $delegatorFactory(); // here throws with error
    }
   ...

Also fixed by adding code below to ConfigPostProcessor

private function replaceDependencyDelegators(array $config)
{
    if (empty($config['delegators'])) {
        return $config;
    }

    foreach ($config['delegators'] as $key => $factory) {
        $factory = is_string($factory[0]) ? $this->replacements->replace($factory[0]) : $factory[0];
        $config['delegators'][$key][0] = $factory;
    }

    return $config;
}

and

private function replaceDependencyConfiguration(array $config)
{
    $aliases = isset($config['aliases']) ? $this->replaceDependencyAliases($config['aliases']) : [];
    if ($aliases) {
        $config['aliases'] = $aliases;
    }

    $config = $this->replaceDependencyInvokables($config);
    $config = $this->replaceDependencyFactories($config);
    $config = $this->replaceDependencyDelegators($config);

    return $config;
}

Expected behavior

\Zend\ServiceManager\Proxy\LazyServiceFactory to be rewritten to \Laminas\ServiceManager\Proxy\LazyServiceFactory

Psalm integration

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.

Migrate the code instead

I see the implementation basically replaces "Zend" with "Laminas" in namespace. This step introduces possible conflict of 2 classes, one with Laminas, one with Zend. It also adds extra work with eventual migration.

Why not migrate the namespace when laminas packages are used already?

I work on a tool that instantly migrates PHP code - Rector. It can do this migration as well:

# configure rector.yaml
services:
    Rector\Rector\Namespace_\RenameNamespaceRector:
        Zend: Laminas

# run
vendor/bin/rector process src/SomeOldZendCode

Result

-use Zend\Something;
+use Laminas\Something;

 class SomeController
 {
     public function run()
     {
-        return new Zend\Response;
+        return new Laminas\Response;
     }
 }

`ConfigPostProcessor` replaces dependency service and therefore removes factory mapping

Bug Report

Q	A
Version(s)	1.0.1

Summary

Hey guys, I am experiencing an issue with mezzio-only projects where the ConfigPostProcessor provided from this project replaces keys and values in the project configuration and by doing that, destroying the factory mapping for a zendframework service.

I've tried this with an mvc application but it seems that there are no such config replacements (because I could not reproduce this in there)?

Current behavior

The ConfigPostProcessor changes the factory mapping for the servicemanager as follows:

RAW configuration:

[
    'factories' => [
        'Zend\Form\Factory' => 'SomeZendFormFactoryFactory',
    ],
]

Post processed configuration:

[
    'factories' => [
        'Laminas\Form\Factory' => 'SomeZendFormFactoryFactory',
    ],
]

Now, the non-migrated module wants to retrieve the service from the servicemanager.
The servicemanager searches for the factory for Zend\Form\Factory as provided, but the post processed configuration does not know the Zend\Form\Factory factory anymore.

How to reproduce

I've created two repositories to provide an example on how the bug occurs:

Project (would be enough to check this out):
https://github.com/boesing/mezzio-project

Module which is not yet migrated to laminas:
https://github.com/boesing/zend-form-module

Run composer serve in the mezzio-project project and call http://localhost:8080. The error will occur.

Expected behavior

The proper laminas service should be instantiated. However, as this is a mapping issue for the service manager, I am not sure if this can be solved that easy. I guess there should be a dedicated replacement for all service- and pluginmanager configurations to solve that issue. Or probably you guys have another idea.

Unable to use with PHP 7.4 preload

The current behaviour doesn't allow to use the new PHP 7.4 preload.
It's useful for laminas-mvc application to preload all laminas-* classes, but right now the autoloader can't register the aliases because the laminas classes are already loaded.

I don't know how to solve it, but probably it can be useful to have a function where we can provide a list of classes (maybe from composer's autoload_classmap.php) and trying to register all aliases from Zend to Laminas. This function can be called in the application bootstrap.
Honestly I don't know if this solution can be useful because the application should register all aliases, even if they are not used.

Append rewritten aliases

Feature Request

Q	A
New Feature	yes
RFC	yes
BC Break	no

Summary

The project I'm trying to move from ZF to Laminas often uses interface names as an alias in ServiceManager config, and sometimes it's a Zend\...Interface::class key. But in this case when I start switching to Laminas\... interfaces in my code there's no such alias key (because alias keys are kept unchanged).

My proposal is to append rewritten alias keys with same value to the list of aliases (keeping the original). This allows the config to work with both Zend and Laminas classes transparently. If the rewritten key already exists then we should keep it as is.

Incompatibility with composer 2.2.0RC1

Bug Report

Q	A
Version(s)	1.4.0

Summary

composer/composer#10349
With composer 2.2.0, the autoloading is already provided for plugins during installation of dependencies.
Due to this fact, vendor/autoload.php might be missing and thus, the autoloader will crash.

Current behavior

Exception trace:
  at /Users/max/git/hardware/core-api/vendor/laminas/laminas-zendframework-bridge/src/Autoloader.php:75
 Laminas\ZendFrameworkBridge\Autoloader::getClassLoader() at /Users/max/git/hardware/core-api/vendor/laminas/laminas-zendframework-bridge/src/Autoloader.php:47
 Laminas\ZendFrameworkBridge\Autoloader::load() at /Users/max/git/hardware/core-api/vendor/laminas/laminas-zendframework-bridge/src/autoload.php:3
 require() at /Users/max/git/tools/composer/vendor/composer/composer/src/Composer/Autoload/AutoloadGenerator.php:1422
 Composer\Autoload\composerRequire() at /Users/max/git/tools/composer/vendor/composer/composer/src/Composer/Plugin/PluginManager.php:244
 Composer\Plugin\PluginManager->registerPackage() at /Users/max/git/tools/composer/vendor/composer/composer/src/Composer/Installer/PluginInstaller.php:79
 Composer\Installer\PluginInstaller->Composer\Installer\{closure}() at /Users/max/git/tools/composer/vendor/react/promise/src/FulfilledPromise.php:28
 React\Promise\FulfilledPromise->then() at /Users/max/git/tools/composer/vendor/react/promise/src/Promise.php:134
 React\Promise\Promise::React\Promise\{closure}() at /Users/max/git/tools/composer/vendor/react/promise/src/Promise.php:168
 React\Promise\Promise->settle() at /Users/max/git/tools/composer/vendor/react/promise/src/Promise.php:231
 React\Promise\Promise::React\Promise\{closure}() at /Users/max/git/tools/composer/vendor/react/promise/src/FulfilledPromise.php:42
 React\Promise\FulfilledPromise->done() at /Users/max/git/tools/composer/vendor/react/promise/src/Promise.php:135
 React\Promise\Promise::React\Promise\{closure}() at /Users/max/git/tools/composer/vendor/react/promise/src/Promise.php:168
 React\Promise\Promise->settle() at /Users/max/git/tools/composer/vendor/react/promise/src/Promise.php:231
 React\Promise\Promise::React\Promise\{closure}() at /Users/max/git/tools/composer/vendor/react/promise/src/FulfilledPromise.php:42
 React\Promise\FulfilledPromise->done() at /Users/max/git/tools/composer/vendor/react/promise/src/Promise.php:66
 React\Promise\Promise::React\Promise\{closure}() at /Users/max/git/tools/composer/vendor/react/promise/src/Promise.php:168
 React\Promise\Promise->settle() at /Users/max/git/tools/composer/vendor/react/promise/src/Promise.php:231
 React\Promise\Promise::React\Promise\{closure}() at /Users/max/git/tools/composer/vendor/react/promise/src/FulfilledPromise.php:42
 React\Promise\FulfilledPromise->done() at /Users/max/git/tools/composer/vendor/react/promise/src/Promise.php:135
 React\Promise\Promise::React\Promise\{closure}() at /Users/max/git/tools/composer/vendor/react/promise/src/Promise.php:168
 React\Promise\Promise->settle() at /Users/max/git/tools/composer/vendor/react/promise/src/Promise.php:231
 React\Promise\Promise::React\Promise\{closure}() at /Users/max/git/tools/composer/vendor/react/promise/src/FulfilledPromise.php:42
 React\Promise\FulfilledPromise->done() at /Users/max/git/tools/composer/vendor/react/promise/src/Promise.php:135
 React\Promise\Promise::React\Promise\{closure}() at /Users/max/git/tools/composer/vendor/react/promise/src/Promise.php:168
 React\Promise\Promise->settle() at /Users/max/git/tools/composer/vendor/react/promise/src/Promise.php:231
 React\Promise\Promise::React\Promise\{closure}() at /Users/max/git/tools/composer/vendor/react/promise/src/FulfilledPromise.php:42
 React\Promise\FulfilledPromise->done() at /Users/max/git/tools/composer/vendor/react/promise/src/Promise.php:135
 React\Promise\Promise::React\Promise\{closure}() at /Users/max/git/tools/composer/vendor/react/promise/src/Promise.php:168
 React\Promise\Promise->settle() at /Users/max/git/tools/composer/vendor/react/promise/src/Promise.php:231
 React\Promise\Promise::React\Promise\{closure}() at n/a:n/a
 call_user_func() at /Users/max/git/tools/composer/vendor/composer/composer/src/Composer/Util/ProcessExecutor.php:343
 Composer\Util\ProcessExecutor->countActiveJobs() at /Users/max/git/tools/composer/vendor/composer/composer/src/Composer/Util/Loop.php:98
 Composer\Util\Loop->wait() at /Users/max/git/tools/composer/vendor/composer/composer/src/Composer/Installer/InstallationManager.php:497
 Composer\Installer\InstallationManager->waitOnPromises() at /Users/max/git/tools/composer/vendor/composer/composer/src/Composer/Installer/InstallationManager.php:470
 Composer\Installer\InstallationManager->executeBatch() at /Users/max/git/tools/composer/vendor/composer/composer/src/Composer/Installer/InstallationManager.php:390
 Composer\Installer\InstallationManager->downloadAndExecuteBatch() at /Users/max/git/tools/composer/vendor/composer/composer/src/Composer/Installer/InstallationManager.php:282
 Composer\Installer\InstallationManager->execute() at /Users/max/git/tools/composer/vendor/composer/composer/src/Composer/Installer.php:752
 Composer\Installer->doInstall() at /Users/max/git/tools/composer/vendor/composer/composer/src/Composer/Installer.php:281
 Composer\Installer->run() at /Users/max/git/tools/composer/vendor/composer/composer/src/Composer/Command/InstallCommand.php:141
 Composer\Command\InstallCommand->execute() at /Users/max/git/tools/composer/vendor/symfony/console/Command/Command.php:298
 Symfony\Component\Console\Command\Command->run() at /Users/max/git/tools/composer/vendor/symfony/console/Application.php:1005
 Symfony\Component\Console\Application->doRunCommand() at /Users/max/git/tools/composer/vendor/symfony/console/Application.php:299
 Symfony\Component\Console\Application->doRun() at /Users/max/git/tools/composer/vendor/composer/composer/src/Composer/Console/Application.php:332
 Composer\Console\Application->doRun() at /Users/max/git/tools/composer/vendor/symfony/console/Application.php:171
 Symfony\Component\Console\Application->run() at /Users/max/git/tools/composer/vendor/composer/composer/src/Composer/Console/Application.php:128
 Composer\Console\Application->run() at /Users/max/git/tools/composer/vendor/composer/composer/bin/composer:74

install [--prefer-source] [--prefer-dist] [--prefer-install PREFER-INSTALL] [--dry-run] [--dev] [--no-suggest] [--no-dev] [--no-autoloader] [--no-scripts] [--no-progress] [--no-install] [-v|vv|vvv|--verbose] [-o|--optimize-autoloader] [-a|--classmap-authoritative] [--apcu-autoloader] [--apcu-autoloader-prefix APCU-AUTOLOADER-PREFIX] [--ignore-platform-req IGNORE-PLATFORM-REQ] [--ignore-platform-reqs] [--] [<packages>...]

How to reproduce

Not really to reproduce but loading the autoload.php while vendor/autoload.php is not available should be testable.

Expected behavior

Autoloader::load should not throw an exception in case that vendor/autoload.php is missing. Maybe some kind of NoopAutoloader might be something. This would only be necessary during composer install of a project which does not initially have a vendor/autoload.php.

Abstract factories and lazy services "class_map" are not replaced with 1.0.2

Bug Report

Q	A
Version(s)	1.0.2

Summary

Same behavior as in laminas-zendframework-bridge#60
With the changes made in 1.0.2, we only handled factories, invokables and aliases in the replacement.

Current behavior

abstract_factories definition and lazy_services definition are not replaced.

How to reproduce

Use those configurations for testing purposes:

<?php

use Zend\ServiceManager\AbstractFactory\ConfigAbstractFactory;
use Zend\ServiceManager\Factory\InvokableFactory;

return [
    'service_manager' => [
        'factories' => [
            'MyService' => InvokableFactory::class,
        ],
        'abstract_factories' => [
            ConfigAbstractFactory::class,
        ],
    ],

    'dependencies' => [
        'factories' => [
            'MyService' => InvokableFactory::class,
        ],
        'abstract_factories' => [
            ConfigAbstractFactory::class,
        ],
    ],
];

<?php

use Zend\ServiceManager\Factory\InvokableFactory;
use Zend\ServiceManager\Proxy\LazyServiceFactory;

return [
    'dependencies' => [
        'factories' => [
            'Zend\Db\Adapter\Adapter' => 'Zend\ServiceManager\AbstractFactory\ReflectionBasedAbstractFactory',
        ],
        'lazy_services' => [
            // Mapping services to their class names is required
            // since the ServiceManager is not a declarative DIC.
            'class_map' => [
                'Zend\Db\Adapter\Adapter' => 'Zend\Db\Adapter\Adapter',
            ],
        ],
        'delegators' => [
            'Zend\Db\Adapter\Adapter' => [
                LazyServiceFactory::class,
            ],
        ],
    ],
];

Expected behavior

<?php

use Laminas\ServiceManager\AbstractFactory\ConfigAbstractFactory;
use Laminas\ServiceManager\Factory\InvokableFactory;

return [
    'service_manager' => [
        'factories' => [
            'MyService' => InvokableFactory::class,
        ],
        'abstract_factories' => [
            ConfigAbstractFactory::class,
        ],
    ],

    'dependencies' => [
        'factories' => [
            'MyService' => InvokableFactory::class,
        ],
        'abstract_factories' => [
            ConfigAbstractFactory::class,
        ],
    ],
];

<?php

use Laminas\ServiceManager\Factory\InvokableFactory;
use Laminas\ServiceManager\Proxy\LazyServiceFactory;

return [
    'dependencies' => [
        'factories' => [
            'Laminas\Db\Adapter\Adapter' => 'Laminas\ServiceManager\AbstractFactory\ReflectionBasedAbstractFactory',
        ],
        'lazy_services' => [
            // Mapping services to their class names is required
            // since the ServiceManager is not a declarative DIC.
            'class_map' => [
                'Laminas\Db\Adapter\Adapter' => 'Laminas\Db\Adapter\Adapter',
            ],
        ],
        'delegators' => [
            'Laminas\Db\Adapter\Adapter' => [
                LazyServiceFactory::class,
            ],
        ],
    ],
];

Bridge does not work with zend i18

Bug Report

TypeError : Argument 1 passed to Laminas\View\Helper\HeadTitle::setTranslator() must be an instance of Laminas\I18n\Translator\TranslatorInterface or null, instance of Zend\Mvc\I18n\Translator given

modules.config.php
...
'Zend\Db',
'Zend\Filter',
'Zend\Hydrator',
'Zend\InputFilter',
'Zend\Paginator',
'Zend\Router',
'Zend\Validator',
'ZF\Apigility',
'ZF\ApiProblem',
'ZF\Configuration',
'ZF\OAuth2',
'ZF\MvcAuth',
'ZF\Hal',
'ZF\ContentNegotiation',
'ZF\ContentValidation',
'ZF\Rest',
'ZF\Rpc',
'ZF\Versioning',
'Zend\I18n',
'Zend\Mvc\I18n',
....

Composer versions:
"zendframework/zend-mvc": "~3.1",
"zendframework/zend-cache": "^2.7.1",
"zendframework/zend-mvc-i18n": "^1.1",

Tool should not rename classes using "Zend" or "ZF" in them

Bug Report

Q	A
Version(s)	1.0+

Summary

Given a class name such as Some\Vendor\Zend\Form\ZendFormFactory, the bridge rewrites this to Some\Vendor\Zend\Form\LaminasFormFactory. This can be problematic for 3rd party libraries and/or generated code.

Current behavior

Rewrites Some\Vendor\Zend\Form\ZendFormFactory to Some\Vendor\Zend\Form\LaminasFormFactory

How to reproduce

$replacements = new Laminas\ZendFrameworkBridge\Replacements();
echo $replacements->replace(Some\Vendor\Zend\Form\ZendFormFactory::class);

Expected behavior

"Some\Vendor\Zend\Form\ZendFormFactory"

Dependency Dashboard

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Repository problems

These problems occurred while renovating this repository. View logs.

WARN: Use matchDepNames instead of matchPackageNames

Awaiting Schedule

These updates are awaiting their schedule. Click on a checkbox to get an update now.

Lock file maintenance

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

Detected dependencies

composer

composer.json

php ~8.1.0 || ~8.2.0 || ~8.3.0

phpunit/phpunit ^10.4

psalm/plugin-phpunit ^0.18.0

squizlabs/php_codesniffer ^3.7.1

vimeo/psalm ^5.16.0

github-actions

.github/workflows/continuous-integration.yml

.github/workflows/release-on-milestone-closed.yml

Check this box to trigger a request for Renovate to run again on this repository

README does not mention which ZF versions are supported

Bug Report

As a user transitioning away from an old ZF Framework codebase, I need to know which versions of ZF are supported by this bridge.

Q	A
Version(s)	1.1.1

Summary

as already done in https://github.com/laminas/laminas-migration it would be helpful to know which major versions of the zend framework are/can be 'bridged' with this component.

a description like in https://github.com/laminas/laminas-migration would be sufficient.

Performance Issue with 1.6.0

BC Break Report

Q	A
Version	1.6.0

Summary

The zendframework-bridge is a dependency of other libraries we use, e.g. API Tool, Laminas Cache, Laminas Form, and after doing a composer update from 1.5.0. to 1.6.0, performance of our application has taken a significant hit.
Each request to the application takes around 1 second longer and phpunit tests run time has increased significantly.

Previous behavior

Application performance was good
PHPUnit tests completed < 2 mins

Current behavior

Application performance has degraded significantly, with requests taking an extra second to process
PHPUnit tests complete in 10 mins.

How to reproduce

The best way to reproduce is to run the unit tests.
The unit tests that uses Laminas Test's AbstractControllerTestCase->dispatch() show a significant reduction on time to complete.
Downgrading to zendframework-bridge 1.5.0 allows the unit tests to complete in the expected time.

I will look into providing a working example of the issue, but it will be next week before I can do this.
As this is a widely used library, and seems to cause a performance reduction and not a break, I think others may be experiencing poorer performance by their applications, I wanted to get this issue raised as soon as possible

Developer tools do not work for BjyAuthorize anymore

BC Break Report

laminas-zendframework-bridge breaks https://github.com/kokspflanze/BjyAuthorize in a way that the templates for laminas-development-tools are not registered correctly anymore.

Q	A
Version	1.0.3

Summary

The module rewrites zend-developer-tools/toolbar/bjy-authorize-role which should probably not be rewritten.

Previous behavior

laminas-developer-tools shows the role of the user currently signed in.

Current behavior

Role is not shown, instead a warning is generated:

Warning: include(/var/www/config/autoload/../view/laminas-developer-tools/toolbar/bjy-authorize-role.phtml): failed to open stream: No such file or directory in /var/www/vendor/laminas/laminas-view/src/Renderer/PhpRenderer.php on line 50

Behind the scenes laminas-zendframework-bridge seems to have rewritten the the following config of the above mentioned module:

    'view_manager' => [
        'template_map' => [
            'error/403' => __DIR__ . '/../view/error/403.phtml',
            'zend-developer-tools/toolbar/bjy-authorize-role'
                => __DIR__ . '/../view/zend-developer-tools/toolbar/bjy-authorize-role.phtml',
        ],
    ],
    'zenddevelopertools' => [
        'toolbar' => [
            'entries' => [
                'bjy_authorize_role_collector' => 'zend-developer-tools/toolbar/bjy-authorize-role',
            ],
        ],
    ],

How to solve

I admit that the module BjyAuthorize ist quite outdated, nevertheless some people like me might still use it for legacy reasons. Therefore, I suggest to add a NEVER REWRITE statement in replacements.php as you did for zend-developer-tools/toolbar/doctrine as well.

Development mode response times have increased 10x after migration.

Bug Report

Q	A
Version(s)	1.1.0

Summary

Development mode response times have increased 10x after migration.

Current behavior

We have a large Apigility deployment (17 APIs, 100s of services). Using Zend/Apigility packages the average response time in development mode (config not cached) is around 70 ms. Once migrated to Laminas packages (using the official migration path) we are seeing response times around 700ms with the exact same codebase. With development mode disabled we see the usual response times but this still has a significant impact on our development experience.

How to reproduce

The culprit seems to be Laminas\ZendFrameworkBridge\ConfigPostProcessor please see attached a stack trace where 73% of the request time is spent on this method.

I am not sure why we even need this package to do autoloading for us since all classes and references have already been renamed in the migration. The package is not a direct dependency but a dependency of all the laminas packages so we can't remove it.

Expected behavior

Response time is not impacted.

Unaccaptable performance hit

Bug Report

Q	A
Version(s)	all

Summary

The bridge prepend autoloader runs on all autoloaded classes regardless of what package they are from. The implementation is not very efficient and adds unacceptable overhead of 4ms for a regular Symfony request of 200ms. The problem imho is that a lot of laminas components always include this bridge, even though the README of this component states differently:

This package should be installed only if you are also using the composer plugin that installs Laminas packages to replace ZF/Apigility/Expressive packages.

Current behavior

Expensive logic detecing class aliasing is run on every class regardless if it starts with Zend or not.

How to reproduce

Run a Profiler on any script with for example laminas/laminas-event-manager 3.3.1 as a composer dependency, for example any Symfony that includes friendsofphp/proxy-manager-lts. Here from Tideways:

Expected behavior

At the very least let the autoloader early exit with if (strpos($class, 'Zend') !== 0) { return; }.

But better would be not to enable this autoloader automatically via "autoload": {"files": key.

In addition this package should not be included in other laminas packages by default such as laminas/laminas-eventmanager: https://github.com/laminas/laminas-eventmanager/blob/3.4.x/composer.json#L27

"ZendForm" getting replaced in 3rd party module

Bug Report

Q	A
Version(s)	1.5.0, current commit (`581d11f`) as of this report

Summary

We have an internal module called KrumediaZendFormBinder which is getting renamed to KrumediaLaminasFormBinder which leads to a NotFound exception.

Current behavior

The phrase "ZendForm" is getting replaced in 3rd party modules.

How to reproduce

This is a failing test case which could be added to ReplacementsTest.php

yield 'MyZendForm' => [
    'MyZendFormBinder\Controller\Plugin\BinderPlugin',
    'MyZendFormBinder\Controller\Plugin\BinderPlugin',
];

Expected behavior

The ZendframeworkBridge does not touch 3rd party module names.

Potential fix

A potential fix could be adding

    'aZendForm' => 'aZendForm',
    'bZendForm' => 'bZendForm',
    'cZendForm' => 'cZendForm',
    'dZendForm' => 'dZendForm',
    'eZendForm' => 'eZendForm',
    'fZendForm' => 'fZendForm',
    'gZendForm' => 'gZendForm',
    'hZendForm' => 'hZendForm',
    'iZendForm' => 'iZendForm',
    'jZendForm' => 'jZendForm',
    'kZendForm' => 'kZendForm',
    'lZendForm' => 'lZendForm',
    'mZendForm' => 'mZendForm',
    'nZendForm' => 'nZendForm',
    'oZendForm' => 'oZendForm',
    'pZendForm' => 'pZendForm',
    'qZendForm' => 'qZendForm',
    'rZendForm' => 'rZendForm',
    'sZendForm' => 'sZendForm',
    'tZendForm' => 'tZendForm',
    'uZendForm' => 'uZendForm',
    'vZendForm' => 'vZendForm',
    'wZendForm' => 'wZendForm',
    'xZendForm' => 'xZendForm',
    'yZendForm' => 'yZendForm',
    'zZendForm' => 'zZendForm',

to the replacements.php rules. A similar batch is already in there for 'aZend' => 'aZend' etc.

Though I don't know if there is a case where SomethingZendForm actually needs to be replaced with SomethingLaminasForm.

I'd gladly send a PR with this fix (and test) if it results in the intended behavior.

Getting "failed to open stream: No such file or directory in /autoload.php on line 5" when loading package

Bug Report

Q	A
Version(s)	2.12

Summary

I am seeing the following error message when using a stock install via Composer. Here's my composer file.

{
    "name": "test-app",
    "type": "project",
    "require": {
        "laminas/laminas-feed": "^2.12"
    }
}

And here is my PHP file that autoloads the Composer dependencies:

<?php

require_once '../vendor/autoload.php';

echo "Hello";

I'm seeing this issue in craftcms/cms#6773, but posting it here as it seems to be occurring due to the laminas/laminas-feed package.

Current behavior

Instead of echoing "Hello", the browser outputs the following:

Warning: require_once(//composer/autoload_real.php): failed to open stream: No such file or directory in /autoload.php on line 5

Fatal error: require_once(): Failed opening required '//composer/autoload_real.php' (include_path='.:/opt/sp/php7.3/lib/php') in /autoload.php on line 5

How to reproduce

This is a bit tricky because it works locally, but doesn't on a Digital Ocean server. However:

Setup a basic composer.json
Install laminas/laminas-feed
Autoload deps

Expected behavior

The dependency should load correctly and echo my "Hello" text.

About zend.

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

Sorry, but i don't can access forum... all zend packages now are called "laminas" ? my questions is about my long change framework to zend structure...

again, sorry for this issue.

Mark component feature-complete

Feature Request

Q	A
New Feature	yes
RFC	yes/no
BC Break	yes/no

Summary

Per a decision by the Technical Steering Committee, we should mark this component as feature complete, and accepting only security fixes, when performing the next minor release.