Files
michaelschiemer/docs/FORPROCESSOR-ISSUE-ANALYSIS.md
Michael Schiemer 5050c7d73a docs: consolidate documentation into organized structure
- Move 12 markdown files from root to docs/ subdirectories
- Organize documentation by category:
  • docs/troubleshooting/ (1 file)  - Technical troubleshooting guides
  • docs/deployment/      (4 files) - Deployment and security documentation
  • docs/guides/          (3 files) - Feature-specific guides
  • docs/planning/        (4 files) - Planning and improvement proposals

Root directory cleanup:
- Reduced from 16 to 4 markdown files in root
- Only essential project files remain:
  • CLAUDE.md (AI instructions)
  • README.md (Main project readme)
  • CLEANUP_PLAN.md (Current cleanup plan)
  • SRC_STRUCTURE_IMPROVEMENTS.md (Structure improvements)

This improves:
 Documentation discoverability
 Logical organization by purpose
 Clean root directory
 Better maintainability
2025-10-05 11:05:04 +02:00

3.6 KiB

ForProcessor Issue Analysis & Fix

Problem-Beschreibung

Das Template System hat aktuell Smart Caching komplett deaktiviert aufgrund eines ForProcessor-Problems. Dies führt zu massiven Performance-Einbußen.

Root Cause Analysis

1. Smart Caching ist deaktiviert

Location: src/Framework/View/Engine.php:62-67

public function render(RenderContext $context): string
{
    // FORCE DIRECT RENDERING - Bypass all caching to fix ForProcessor issue
    error_log("=== ENGINE::RENDER FORCED DIRECT === Template: " . $context->template);

    // Always use renderDirect to ensure DOM processing pipeline runs
    return $this->renderDirect($context);  // ⚠️ BYPASSES CACHE MANAGER!

    // Dead code below - never executed:
    $templateContext = new TemplateContext(...);
    return $this->cacheManager->render($templateContext, function () use ($context) {
        return $this->renderDirect($context);
    });
}

Impact: Jeder Template-Render umgeht den Cache-Manager komplett → keine Performance-Optimierung!

2. ForProcessor ist überladen mit Debug-Logs

Location: src/Framework/View/Processors/ForProcessor.php

Probleme:

  • 125+ error_log() Aufrufe in der Datei
  • Massives Debug-Logging bei jedem <for>-Loop
  • Logs über innerHTML, DOM structure, sibling nodes
  • Performance-Killer durch String-Operationen für Logging

Beispiele (Zeilen 30-78):

error_log("🚀🚀🚀 FORPROCESSOR CALLED FOR TEMPLATE: " . $context->template);
error_log("🚀🚀🚀 ForProcessor: Current DOM content (first 500 chars): " . substr($htmlContent, 0, 500));
error_log("🚀🚀🚀 ForProcessor: DOM contains '<for': " . (strpos($htmlContent, '<for') !== false ? 'YES' : 'NO'));
// ... 100+ weitere Debug-Logs

3. Eigentliches ForProcessor-Problem

Das ursprüngliche Problem war vermutlich:

  • DOM-Parser behandelt <for> Tags als self-closing
  • innerHTML ist manchmal leer
  • collectSiblingContent() versucht das zu fixen (Zeile 366-423)
  • Komplexe Logic für TR/TABLE Element-Extraktion

Core Issue: DOM-Parser versteht <for> nicht als Container-Element.

Lösungsansatz

Phase 1: Debug-Logs entfernen

  • Alle error_log() und file_put_contents() Debug-Statements entfernen
  • Performance-Messung statt Debug-Logging
  • Clean Code ohne Entwickler-Artifacts

Phase 2: ForProcessor stabilisieren

  • innerHTML-Check vereinfachen
  • collectSiblingContent() robuster machen
  • Besseres Error Handling ohne Logs

Phase 3: Smart Caching re-aktivieren

  • render() Methode in Engine.php reparieren
  • Cache-Manager korrekt verwenden
  • ForProcessor cache-safe machen

Phase 4: Testing & Validation

  • ForProcessor mit verschiedenen Templates testen
  • Cache-Hit-Rate messen
  • Performance-Verbesserung validieren

Erwartete Performance-Verbesserung

Vor dem Fix:

  • Kein Caching → jeder Request rendert alles neu
  • Debug-Logs → I/O Overhead pro Request
  • Geschätzt: 50-200ms pro Template-Render

Nach dem Fix:

  • Smart Caching aktiv → Cache-Hits vermeiden Re-Rendering
  • Keine Debug-Logs → kein I/O Overhead
  • Geschätzt: 1-5ms für gecachte Templates (95%+ schneller!)

Implementation Plan

  1. ForProcessor aufräumen: Debug-Logs entfernen
  2. Engine.php reparieren: Cache-Manager reaktivieren
  3. ForProcessor testen: Mit realen Templates validieren
  4. Performance messen: Vorher/Nachher Comparison

Next Steps

  • Problem analysiert
  • ForProcessor Debug-Logs entfernen
  • Engine.php Cache-Bypass entfernen
  • ForProcessor Logic vereinfachen
  • Integration Tests erstellen
  • Performance Benchmarks durchführen