Maho Core Mocks

Purpose and Scope

This document describes the mock class definitions provided in the mock/maho-phpstan-plugin/ directory. These minimal class definitions allow PHPStan to perform static analysis on Maho/Magento codebases without requiring a full Maho installation. The mocks define class signatures, method declarations, and return types that PHPStan needs to understand Maho's core API.

For information about the mock definitions for Laminas framework libraries, see Laminas Framework Mocks. For details on how the type inference system uses these mocks to resolve dynamic class names, see MageCoreConfig.

Overview of Mock Requirements

PHPStan requires type information about classes that appear in the codebase being analyzed. When analyzing Maho application code, PHPStan encounters references to core Maho classes like Mage, Varien_Object, and configuration classes. Without these class definitions present, PHPStan would report numerous "class not found" errors.

The mock files provide lightweight stubs that define:

• Class existence and structure
• Method signatures and parameters
• Return type declarations
• Interface implementations
• Constants used by Maho bootstrap

These mocks contain no implementation logic—only enough information for PHPStan to understand the API surface.

Sources: .phpstan.dist.neon9-11

Mock File Structure

Diagram: Mock File Organization and Loading

The plugin provides two mock files that are loaded via the PHPStan scanFiles configuration parameter:

File	Classes Defined	Purpose
mock/maho-phpstan-plugin/Mage.php	Mage, Mage_Core_Model_App, Mage_Core_Model_Config, Varien_Object	Core Maho API including factory methods and configuration
mock/maho-phpstan-plugin/DataObject.php	Maho\DataObject	Modern namespaced replacement for Varien_Object

Sources: mock/maho-phpstan-plugin/Mage.php1-119 mock/maho-phpstan-plugin/DataObject.php1-17 .phpstan.dist.neon9-11

Bootstrap Constant

The BP constant is defined at mock/maho-phpstan-plugin/Mage.php6 to represent Maho's base path. In actual Maho installations, this constant is defined during bootstrap and contains the absolute filesystem path to the Maho root directory. The mock defines it as an empty string to satisfy PHPStan's requirement that constants exist.

Sources: mock/maho-phpstan-plugin/Mage.php3-6

Mage Factory Class

Diagram: Mage Class API Surface

The Mage class mock (mock/maho-phpstan-plugin/Mage.php11-30) defines the static factory hub used throughout Maho codebases. While the real Mage class contains dozens of methods, the mock only defines two:

app() Method

Declared at mock/maho-phpstan-plugin/Mage.php19-21 this method returns a Mage_Core_Model_App instance. The return type annotation at mock/maho-phpstan-plugin/Mage.php17 provides PHPStan with the information needed to understand the returned object type.

Parameters:

• $code: Store/website code (optional)
• $type: Scope type - 'store', 'website', or 'default'
• $options: Configuration array or string

init() Method

Declared at mock/maho-phpstan-plugin/Mage.php27-29 this method initializes the Maho application. The mock declares it with a void return type.

Factory Methods Not Mocked

The mock intentionally does not include factory methods like:

• getModel()
• getSingleton()
• helper()
• getResourceModel()

These methods are handled dynamically by MageTypeExtension (see MageTypeExtension), which resolves their return types based on the string alias parameter. The mock only needs to define methods that have concrete, static return types.

Sources: mock/maho-phpstan-plugin/Mage.php11-30

Application and Configuration Classes

Diagram: Configuration Class Method Mapping

Mage_Core_Model_App

The application class mock at mock/maho-phpstan-plugin/Mage.php35-45 defines a single method:

Returns Mage_Core_Model_Config as documented at mock/maho-phpstan-plugin/Mage.php40

Mage_Core_Model_Config

The configuration class mock at mock/maho-phpstan-plugin/Mage.php50-105 defines six class name resolution methods. These methods are critical because they represent the actual Maho API that the MageCoreConfig service wraps to convert string aliases to fully qualified class names.

Method	Return Type	Lines	Purpose
getNodeClassName(string $path)	string	56-59	Resolve class from XML path
getBlockClassName(string $blockType)	string	65-68	Resolve block alias to class
getHelperClassName(string $helperAlias)	string	73-77	Resolve helper alias to class
getModelClassName(string $modelAlias)	string	83-86	Resolve model alias to class
getResourceModelClassName(string $modelAlias)	string|false	92-95	Resolve resource model, returns false if not found
getResourceHelperClassName(string $moduleAlias)	string|false	101-104	Resolve resource helper, returns false if not found

Note that getResourceModelClassName() and getResourceHelperClassName() return string|false (not just string) because these methods can fail to find a match in actual Maho configurations.

The MageCoreConfig service (see MageCoreConfig) obtains converter functions by invoking these methods on the real Maho configuration instance.

Sources: mock/maho-phpstan-plugin/Mage.php35-105

Data Object Classes

Diagram: Data Object Mock Definitions

Varien_Object

The legacy data object class is defined at mock/maho-phpstan-plugin/Mage.php111-118 This class is the foundation of Maho's data container pattern and is extended by hundreds of classes throughout the framework.

The mock declares:

• Interface implementations: ArrayAccess<string, mixed> and JsonSerializable at mock/maho-phpstan-plugin/Mage.php111
• ArrayAccess methods: offsetExists(), offsetGet(), offsetSet(), offsetUnset() at lines 113-116
• Serialization method: jsonSerialize() at mock/maho-phpstan-plugin/Mage.php117

The generic type ArrayAccess<string, mixed> annotation at mock/maho-phpstan-plugin/Mage.php109 informs PHPStan that array access operations use string keys and return mixed values.

The mock bodies are empty because PHPStan only needs the signatures. The actual implementation logic is not required for static analysis.

Maho\DataObject

The modern namespaced replacement is defined at mock/maho-phpstan-plugin/DataObject.php9-16:

This class is structurally identical to Varien_Object but exists in the Maho namespace (declared at mock/maho-phpstan-plugin/DataObject.php3). The interface implementations and generic type annotation are at mock/maho-phpstan-plugin/DataObject.php7

Magic Method Handling

Both data object classes support magic getter/setter methods (e.g., getName(), setName()) through their __call() implementation in the real Maho codebase. The mock files do not declare these methods because:

1. There are infinite possible method names based on data keys
2. The VarienObjectReflectionExtension (see Magic Method Support) dynamically provides these method signatures during analysis

Sources: mock/maho-phpstan-plugin/Mage.php108-118 mock/maho-phpstan-plugin/DataObject.php1-17

Integration with PHPStan Configuration

Diagram: Mock File Loading and Usage Flow

The mock files are loaded into PHPStan's analysis context via the scanFiles configuration parameter at .phpstan.dist.neon9-11:

When PHPStan initializes, it:

1. Parses the mock files and extracts class definitions
2. Registers these classes in its reflection system
3. Makes them available for type resolution during analysis

This allows the plugin's extensions to:

• MageCoreConfig: Access methods like getModelClassName() and getHelperClassName() when creating converter functions
• MageInvalidTypeRule: Use class_exists() to validate that resolved class names correspond to actual class definitions
• VarienObjectReflectionExtension: Check if a class extends Varien_Object or Maho\DataObject to determine whether to provide magic method support

The mock definitions must be loaded via scanFiles rather than through autoloading because:

• They override classes that exist in actual Maho installations
• PHPStan needs them available before analyzing any user code
• The scanFiles mechanism ensures they're loaded during bootstrap

Sources: .phpstan.dist.neon9-11

Mock Limitations and Design Decisions

The mock files are intentionally minimal and incomplete compared to real Maho classes:

What's Mocked	What's NOT Mocked	Rationale
Class existence and structure	Method implementations	PHPStan only needs signatures
Method return types	Factory methods like getModel()	Handled by MageTypeExtension dynamically
Interface declarations	Magic methods like __call()	Handled by VarienObjectReflectionExtension
Required constants (e.g., BP)	All methods from real classes	Only analyzing, not executing

This design minimizes maintenance burden while providing sufficient type information for PHPStan's analysis. When the plugin detects method calls not present in the mocks, the dynamic type extensions provide the necessary type information on-demand.

Sources: mock/maho-phpstan-plugin/Mage.php1-119 mock/maho-phpstan-plugin/DataObject.php1-17