Michael Schiemer
5050c7d73a
- 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
107 lines
3.6 KiB
Markdown
107 lines
3.6 KiB
Markdown
# 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`
|
|
|
|
```php
|
|
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):
|
|
```php
|
|
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
|
|
|
|
- [x] Problem analysiert
|
|
- [ ] ForProcessor Debug-Logs entfernen
|
|
- [ ] Engine.php Cache-Bypass entfernen
|
|
- [ ] ForProcessor Logic vereinfachen
|
|
- [ ] Integration Tests erstellen
|
|
- [ ] Performance Benchmarks durchführen
|