fix: add false parameter to class_exists() guards to prevent autoloader collisions

[yanick29]

Zusammenfassung (DE)

Dieser PR fügt den Parameter false zu allen class_exists()-Guard-Aufrufen in includes/ hinzu, um Autoloader-Kollisionen mit Drittanbieter-Plugins zu verhindern.

Problem

Wenn OES Core zusammen mit Plugins wie WooCommerce eingesetzt wird, die eigene PHP-Autoloader registrieren (Action Scheduler, Jetpack Autoloader), führen class_exists('ClassName')-Aufrufe ohne false dazu, dass diese Autoloader unbeabsichtigt ausgelöst werden. Kurze, unqualifizierte Klassennamen wie 'Config', 'Container' oder 'Page' werden von externen Autoloadern fälschlicherweise als eigene Klassen erkannt und geladen. Das führt zu Fatal Errors.

Beobachtete Fehler

1. Cannot declare class Action_Scheduler\Migration\Config — OES ruft class_exists('Config') auf → der Action Scheduler Autoloader matcht Config als Migration-Klasse → lädt migration/Config.php → beim zweiten Aufruf wird die Klasse doppelt deklariert → Fatal Error.

2. Class "OES\Admin\Container" not found — OES ruft class_exists('Container') auf → der Jetpack Autoloader lädt seine eigene \Container-Klasse → der Guard gibt true zurück → OES überspringt die eigene Klassendeklaration → späterer Code versucht OES\Admin\Container zu instanziieren → Fatal Error.

Fix

class_exists('X') → class_exists('X', false) bei allen Guard-Aufrufen. Der Parameter false weist PHP an, nur im Speicher zu prüfen ob die Klasse existiert, ohne Autoloader auszulösen.

• 128 Guard-Aufrufe geändert in 87 Dateien
• 27 Runtime-Dispatch-Aufrufe unverändert (diese prüfen absichtlich auf externe Klassen wie IntlDateFormatter)

Warum gegen development?

Dieser PR basiert auf dem development-Branch (OES 3.0.0 Vorbereitung), da dort die aktive Entwicklung stattfindet und der Bug auch in der neuen Version noch vorhanden ist.

---

Summary (EN)

This PR adds the false parameter to all class_exists() guard calls in includes/ to prevent autoloader collisions with third-party plugins.

Problem

When OES Core is used alongside plugins that register PHP autoloaders (e.g. WooCommerce with Action Scheduler and Jetpack Autoloader), class_exists('ClassName') calls without false trigger all registered autoloaders as a side effect. Short, unqualified class names like 'Config', 'Container', or 'Page' are incorrectly matched by external autoloaders, which then load classes from the wrong namespace, causing fatal errors.

Errors observed

1. Cannot declare class Action_Scheduler\Migration\Config, because the name is already in use — OES calls class_exists('Config') → Action Scheduler autoloader matches Config as a migration class → loads migration/Config.php → on a second call, PHP attempts to redeclare it → fatal error.

2. Class "OES\Admin\Container" not found — OES calls class_exists('Container') → Jetpack Autoloader loads its own global \Container class → guard returns true → OES skips declaring OES\Admin\Container → later code tries to instantiate it → fatal error.

Fix

Added false as the second argument to all class_exists() guard calls:

// Before (triggers autoloaders):
if (!class_exists('Config')) oes_include('admin/tools/config/class-config.php');

// After (no autoloader triggered):
if (!class_exists('Config', false)) oes_include('admin/tools/config/class-config.php');

Scope

• 128 guard calls changed across 87 files in includes/
• 27 runtime dispatch calls left unchanged (these intentionally check for external class availability)

Three guard patterns affected

1. Before class declaration: if (!class_exists('X')) { class X ... }
2. Before oes_include(): if (!class_exists('Config')) oes_include(...)
3. Exit guard: if (class_exists('Schema')) exit;

Environment tested

• WordPress 7.0
• OES Core 2.4.x and development branch (3.0.0)
• WooCommerce 10.7.0
• PHP 8.3

After applying this fix, OES Core and WooCommerce run side by side without fatal errors.