www.dvnlp.de

Bugsink: https://bugsink.cytrus.de/issues/issue/814d6871-2a08-46e4-b5df-cc9c67f1cbd0/event/last/

Typ: NEW issue

Projekt: www-dvnlp-de

Bugsink Alert

TYPO3\CMS\Extbase\Property\Exception\TargetNotFoundException: Object of type Qb\DvnlpIntranet\Domain\Model\Member with identity "5186" not found.

Automatisch erstellt durch n8n

KI-Analyse:

Analyse des Fehlers: TargetNotFoundException für Member-Objekt mit UID 5186¶

1. Ursache identifizieren¶

Die TargetNotFoundException wird von Extbase geworfen, wenn ein Repository versucht, ein Domain-Objekt anhand einer gegebenen UID (hier: 5186) zu laden, dieses jedoch nicht in der Datenbank existiert oder nicht zugänglich ist.

Mögliche Gründe:¶

• Datenbank-Inkonsistenz:
  • Der Datensatz mit UID 5186 in der Tabelle tx_dvnlpintranet_domain_model_member (oder einer verknüpften Tabelle) existiert nicht (gelöscht, nie angelegt, falsche UID).
  • Die Tabelle oder der Datensatz ist nicht für die aktuelle Sprache/PID verfügbar (z. B. bei sys_language_uid oder pid-Restriktionen).
• Fehlende Berechtigungen:
  • Der Frontend-User hat keine Leseberechtigung für den Datensatz (z. B. durch fe_groups-Restriktion).
• Falsche Konfiguration:
  • Das Repository oder der Query ist falsch konfiguriert (z. B. falsche storagePid, enableFields nicht berücksichtigt).
  • Der Datensatz wurde manuell gelöscht, aber Referenzen (z. B. in Plugins, Menüs oder anderen Tabellen) blieben bestehen.
• Cache-Problem:
  • Der TYPO3-Cache enthält veraltete Referenzen (z. B. nach einem Import/Update).

Konkreter Auslöser im Stacktrace:¶

Der Fehler tritt im Frontend-Kontext auf, vermutlich bei der Verarbeitung eines Extbase-Plugins (z. B. ein Member-Listing oder Detail-View). Die Exception wird in der Middleware-Chain abgefangen, was darauf hindeutet, dass der Fehler während der Request-Verarbeitung auftritt.

2. Fix beschreiben (konkret)¶

Schritt 1: Prüfen, ob der Datensatz existiert¶

• Datenbank-Check:

  SELECT * FROM tx_dvnlpintranet_domain_model_member WHERE uid = 5186;
  

  • Falls kein Ergebnis: Datensatz wurde gelöscht oder nie angelegt.
  • Falls Ergebnis vorhanden: Prüfen, ob deleted=0, hidden=0, und die pid/sys_language_uid zum aktuellen Kontext passt.

Schritt 2: Referenzen bereinigen¶

• TYPO3 Backend:
  • Im List-Modul nach dem Datensatz suchen (UID 5186).
  • Falls gelöscht: Alle Referenzen (z. B. in Plugins, Menüs, oder anderen Tabellen) manuell anpassen oder löschen.
• Extbase-Repository:
  • Im Repository (MemberRepository) prüfen, ob der Query korrekt ist:

    public function findByUid($uid) {
        $query = $this->createQuery();
        $query->getQuerySettings()->setIgnoreEnableFields(true); // Nur für Debug!
        $query->matching($query->equals('uid', $uid));
        return $query->execute()->getFirst();
    }
    

    • Falls der Datensatz existiert, aber nicht geladen wird: enableFields prüfen (z. B. hidden, starttime, endtime).

Schritt 3: Fehlerbehandlung im Code¶

• Graceful Degradation:
  • Im Controller oder Service, der den Member lädt, eine Fallback-Logik einbauen:

    try {
        $member = $this->memberRepository->findByUid(5186);
    } catch (\TYPO3\CMS\Extbase\Property\Exception\TargetNotFoundException $e) {
        // Loggen oder 404-Seite anzeigen
        $this->logger->error('Member not found', ['uid' => 5186]);
        $this->redirect('notFoundAction');
    }
    

• Cache leeren:
  • TYPO3-Cache leeren (flush cache im Backend oder via CLI: typo3 cache:flush).

Schritt 4: Konfiguration prüfen¶

• TypoScript:
  • Prüfen, ob die storagePid korrekt gesetzt ist:

    plugin.tx_dvnlpintranet {
        persistence {
            storagePid = 123  // PID der Member-Datensätze
        }
    }
    

• TCA/Extbase-Konfiguration:
  • Prüfen, ob das Feld uid im TCA als readOnly oder exclude markiert ist (sollte nicht der Fall sein).

3. Betroffene TYPO3 Extension¶

• Extension-Name: dvnlp_intranet
  • Domain-Modell: Qb\DvnlpIntranet\Domain\Model\Member
  • Repository: Qb\DvnlpIntranet\Domain\Repository\MemberRepository
• Hinweis: Die Extension scheint ein Intranet-System mit Member-Verwaltung zu sein.

4. Confidence (0-100%)¶

• 90% – Die Ursache ist mit hoher Wahrscheinlichkeit ein nicht existierender oder nicht zugänglicher Datensatz (UID 5186).
• 10% Unsicherheit:
  • Es könnte ein Cache-Problem vorliegen (z. B. veraltete Referenzen).
  • Seltenere Ursachen: Falsche storagePid, fehlende Berechtigungen, oder ein Bug in der Extension.

Zusammenfassung der nächsten Schritte¶

1. Datenbank prüfen (existiert UID 5186?).
2. Referenzen bereinigen (z. B. Plugins, Menüs).
3. Fehlerbehandlung im Code anpassen (Graceful Degradation).
4. Cache leeren und Konfiguration prüfen.
5. Logging einbauen, um ähnliche Fehler zukünftig schneller zu identifizieren.

Falls der Datensatz absichtlich gelöscht wurde, sollten alle Referenzen darauf entfernt werden. Falls er versehentlich gelöscht wurde, kann er aus einem Backup wiederhergestellt werden.