Page logic files can use application classes in function parameters, constructor calls and static method calls. PHP needs the class’s namespace to resolve its name correctly.

¶Why a missing import mentions GT\AppLogic

WebEngine gives classless logic files a generated namespace so several files can define functions such as go() without colliding. For example, page/index.php uses a namespace ending in page\index_php.

If we use AnotherThing without importing it, PHP looks for it relative to that generated namespace. The resulting error might mention:

GT\AppLogic\page\index_php\AnotherThing

When the name appears in a logic function parameter, the service container can throw ServiceNotFoundException. A constructor or static method call can instead produce PHP’s Class not found error. Both can have the same cause: a missing class import.

This applies to shared files such as _common.php and nested page logic too. The generated namespace is an implementation detail; we do not need to create an application class inside it.

¶Import the class

If AnotherThing is declared in the App namespace, import it at the top of the logic file:

use App\AnotherThing;

function go(AnotherThing $anotherThing):void {
	$anotherThing->run();
}

The import also applies to new AnotherThing() and static calls within the file. Use the namespace where the class is actually declared, which may differ from App.

Alternatively, use the fully qualified name:

function go(\App\AnotherThing $anotherThing):void {
	$anotherThing->run();
}

¶If the class is already imported

Check that:

• the class name and namespace are spelt correctly
• the import is in the logic file that uses the class; imports in _common.php do not apply to other files
• the class file is in the expected location for its namespace
• Composer’s autoloader includes any external package that supplies the class

See application classes for the project’s namespace and directory conventions, and Service Container for dependency injection.

¶Development guidance

In development mode, WebEngine adds a friendly explanation, a suggested action and a link to this page when it recognises this error. The original exception message and trace remain available. The explanation describes a likely cause, so it is still useful to check spelling and autoloading before changing the imports.

The built-in HTML error response displays the guidance automatically. JSON fallback responses include it in a separate context object. Custom error pages can display it using the bindings described in errors and logging. The extra guidance is omitted when app.production is enabled.