Class not found Error when booting a custom package

After upgrading from Flow 3.0.x to 4.0.x I’m getting a queer problem with custom packages that call a RequestHandler when beeing booted.

The Front-End of my Application is partly using ExtJs Widgets and does the data-communication with RPC (ExtDirect). So one of my custom packages is derived from the former TYPO3/ExtDirect package which has been abandoned long ago but which worked perfectly until Flow 3.0.x.

The package built exactly as described in the docs.

  1. ./flow package:create (PackageName = Welu.ExtJs).
  2. add Package.php to the root Folder (Welu.ExtJs/Classes/Welu/ExtJs/Package.php)
  3. add RequestHandler Class to a Dedicated Folder (Welu.ExtJs/Classes/Welu/ExtJs/ExtDirect/RequestHandler.php) and set the namespace accordingly.
  4. add RequestHandler call to the boot function of the Package.php class.
<?php namespace Welu\ExtJs use Neos\Flow\Package\Package as BasePackage; /** * The Custom Package * * @license GNU Lesser General Public License, version 3 or later */ class Package extends BasePackage { /** * Invokes custom PHP code directly after the package manager has been initialized. * * @param \Neos\Flow\Core\Bootstrap $bootstrap The current bootstrap * @return void */ public function boot(\Neos\Flow\Core\Bootstrap $bootstrap) { $bootstrap->registerRequestHandler(new ExtDirect\RequestHandler($bootstrap)); } } When trying to boot the Application (e.g. with ./flow from the command linde) I get the following error. PHP Fatal error: Uncaught Error: Class 'Welu\ExtJs\ExtDirect\RequestHandler' not found in /Library/WebServer/Documents/FLOW/flow-neos-4/Quickstart/Packages/Application/Welu.ExtJs/Classes/Package.php:39 Stack trace: #0 /Library/WebServer/Documents/FLOW/flow-neos-4/Quickstart/Packages/Framework/Neos.Flow/Classes/Package/PackageManager.php(145): Welu\ExtJs\Package->boot(Object(Neos\Flow\Core\Bootstrap)) #1 /Library/WebServer/Documents/FLOW/flow-neos-4/Quickstart/Packages/Framework/Neos.Flow/Classes/Core/Booting/Scripts.php(193): Neos\Flow\Package\PackageManager->initialize(Object(Neos\Flow\Core\Bootstrap)) #2 /Library/WebServer/Documents/FLOW/flow-neos-4/Quickstart/Packages/Framework/Neos.Flow/Classes/Core/Bootstrap.php(106): Neos\Flow\Core\Booting\Scripts::initializePackageManagement(Object(Neos\Flow\Core\Bootstrap)) #3 /Library/WebServer/Documents/FLOW/flow-neos-4/Quickstart/Packages/Framework/Neos.Flow/Scripts/flow.php(61): Neos\Flow\Core\Bootstrap->run() #4 /Library/WebServer/Documents/FLOW/flow-neos-4/Quickstart/flow(18): r in /Library/WebServer/Documents/FLOW/flow-neos-4/Quickstart/Packages/Application/Welu.ExtJs/Classes/Package.php on line 39 Fatal error: Uncaught Error: Class 'Welu\ExtJs\ExtDirect\RequestHandler' not found in /Library/WebServer/Documents/FLOW/flow-neos-4/Quickstart/Packages/Application/Welu.ExtJs/Classes/Package.php on line 39 Error: Class 'Welu\ExtJs\ExtDirect\RequestHandler' not found in /Library/WebServer/Documents/FLOW/flow-neos-4/Quickstart/Packages/Application/Welu.ExtJs/Classes/Package.php on line 39 Call Stack: 0.0005 354792 1. {main}() /Library/WebServer/Documents/FLOW/flow-neos-4/Quickstart/flow:0 0.0055 372176 2. require('/Library/WebServer/Documents/FLOW/flow-neos-4/Quickstart/Packages/Framework/Neos.Flow/Scripts/flow.php') /Library/WebServer/Documents/FLOW/flow-neos-4/Quickstart/flow:18 0.0158 857776 3. Neos\Flow\Core\Bootstrap->run() /Library/WebServer/Documents/FLOW/flow-neos-4/Quickstart/Packages/Framework/Neos.Flow/Scripts/flow.php:61 0.0193 1072712 4. Neos\Flow\Core\Booting\Scripts::initializePackageManagement() /Library/WebServer/Documents/FLOW/flow-neos-4/Quickstart/Packages/Framework/Neos.Flow/Classes/Core/Bootstrap.php:106 0.0238 1251304 5. Neos\Flow\Package\PackageManager->initialize() /Library/WebServer/Documents/FLOW/flow-neos-4/Quickstart/Packages/Framework/Neos.Flow/Classes/Core/Booting/Scripts.php:193 0.0313 1696168 6. Welu\ExtJs\Package->boot() /Library/WebServer/Documents/FLOW/flow-neos-4/Quickstart/Packages/Framework/Neos.Flow/Classes/Package/PackageManager.php:145

Hi Regine,

Creating packages using package:create will use PSR-4 instead of PSR-0 auto loading now. Meaning you have to put your classes in /Classes instead of /Classes/Vendor/Name/. It can be changed back in composer.json if preferred.

Hi Aske,

unfortunately the way you mentioned is not enough as the psr-4 autoloading does only work if a package is not “mentioned” in the composer.json of the flow application. As my custom packages are not “hosted” in a composer repository (neither me nor my customers want that), the only way I found to get the psr-4 autoloader working was to put the following lines into the composer.json of my flow-app.

“repositories”: [
“type”: “path”,
“url”: “.//<vendor-name.package-name>”

… whereas the repository-folder must not be the package folder (…/Packages/Application/…) of the custom-package but has to be a folder elsewhere on the local system. Second, the composer.json of the custom-package itself must not contain any require to packages already required by the flow-app as a composer update would install them into the custom package as well. (My custom packages do not contain any composer require) After doing a composer upgrade the custom package is then symlinked into the …/Packages/Application/… folder and everything works as expected.

So to put a long story short it would be very helpful if you changed the documentation accordingly (may be there’s an even better way to get private packages integrated into a flow app). As no one else had that problem up to now it seems, that working with really individual packages is not common in the community.



Hello again,

Fortunately that is not true, there is a simpler and easier way. Custom packages don’t need to be hosted remotely, nor available on Packagist, nor mentioned in your root composer.json. They can work just fine just being available on the filesystem, usually in the form of a root git repository.

Here’s an example repository curtesy of @dimaip showing how to do it
Notice the site package is part of the git repository and not mentioned in the root composer.json manifest
The site package still needs to have it’s own composer.json
There’s no difference for site packages, application packages and plugin packages except for which folder they are in which matches a composer type, but not restricted to.

Since Flow 3.2, you’ll need to run ./flow package:rescan when adding new packages or updating composer.json in a package.

Hope that helps and will make it easier for you in the future.