Aktuell aktualisiere ich eine ziemlich alte Extension. In einem Bereich dieser Extension werden alle Termine gelistet, auch die inaktiven. Diese sind über eine updateAction bearbeitbar. Normalerweise resultiert eine ``` updateAction(FooObjekt $fooObjekt)``` eines inaktiven Datensatzes in einer Exception. Früher habe ich das total umständlich umgangen, indem ich bei der editAction $fooObjekt nicht als Objekt sondern als Array abbildete und erst in der updateAction wieder in ein Objekt wandelte. Die Validierung habe ich dann über einen Validator vorgenommen, den in in initializeActionMethodValidators() im Controller eingebunden habe. Soviel zur Vorgeschichte. Nun möchte ich in Typo3 13.4 (Composer) nur noch dann im Controller initiierten Validatoren einbinden, wenn sie Laufzeitparameter benötigen. Alle anderen Validatoren sollen im Model definiert werden. Das funktioniert auch prima und ist zudem super für die Datenintegrität. ABER… Jetzt arbeite ich durchweg mit Objekten. Mein alter Ansatz mit dem Array ist a) inkonsistent und b) bedeutet ich muss für den Updatevorgang einen eigenen Validator schreiben. Der von mir bevorzugte Ansatz nur Objekte zu verwenden bedeutet jedoch, dass auch versteckte Datensätze an ```updateAction(FooObjekt``` $fooObjekt) übergeben werden müssen. Wie löst ihr das? Ich habe folgendes probiert: ### 1. QuerySettings im Controller setzen ```php public function initializeAction(): void { if ($this->actionMethodName == 'updateAction') { $settings = GeneralUtility::makeInstance(Typo3QuerySettings::class); $settings->setIgnoreEnableFields(true) ->setEnableFieldsToBeIgnored(['disabled']); $this->fooRepository->setDefaultQuerySettings($settings); } } ``` Aber das greift ja nur für die Repository Instanz die im Controller initiert wird und nicht die die Typo3 für den Request benutzt. Fiel mir dann ein, als ich es umgesetzt hatte... Naja, egal, hat ja nur einen Moment gedauert. ### 2. Middleware Ok, dieser Versuch war einfach nur ein Proof-Of-Concept, funktioniert aber...grundsätzlich. Nach dem Absenden prüft die Middleware ob in der persisted Instanz „hidden“ wahr ist und setzt es ggf. auf falsch. Dadurch wird das Objekt von den Mechanismen im Controller gefunden und die Validierung funktioniert auch. Danach werden im Controller die Parameter zur Sichtbarkeit vom aktuellen Request übernommen. Das funktioniert auch tadellos, ist aber aufgrund der offensichtlichen Dateninkonsistenz zur Laufzeit nicht für den Produktiveinsatz geeignet. D.h. wenn es mal zu einer Exception kommt o.ä. kommt könnte der Datensatz in einem Sichbarkeites-Zustand sein der nicht gewünscht ist. Ja, jetzt sitz ich hier und überlege wie ich das lösen kann. Eine Suche im Netz war nicht erfolgreich, ChatGPT hat mir mal wieder irgendwelche „fake“ Funktionalitäten vorgegaukelt die es nicht gibt. **Also, wie löst ihr das?**

Deswegen hatte ich ja vorgeschlagen, dass Du für die Actions bei denen das Objekt "versteckbar" sein soll Deine Implementierung verwendest. Also im Repo in der InitializeObject wie von mir oben beschrieben. und dann in dem Controller so: ```php public function initializeAction(): void { if ($this->actionMethodName != 'updateAction') { $settings = GeneralUtility::makeInstance(Typo3QuerySettings::class); $settings->setIgnoreEnableFields(false); $this->fooRepository->setDefaultQuerySettings($settings); } } ```

Bearbeiten von versteckten Datensätzen im Frontend

Matthew Colton

Aktuell aktualisiere ich eine ziemlich alte Extension. In einem Bereich dieser Extension werden alle Termine gelistet, auch die inaktiven. Diese sind über eine updateAction bearbeitbar. Normalerweise resultiert eine updateAction(FooObjekt $fooObjekt) eines inaktiven Datensatzes in einer Exception.
Früher habe ich das total umständlich umgangen, indem ich bei der editAction $fooObjekt nicht als Objekt sondern als Array abbildete und erst in der updateAction wieder in ein Objekt wandelte. Die Validierung habe ich dann über einen Validator vorgenommen, den in in initializeActionMethodValidators() im Controller eingebunden habe.
Soviel zur Vorgeschichte. Nun möchte ich in Typo3 13.4 (Composer) nur noch dann im Controller initiierten Validatoren einbinden, wenn sie Laufzeitparameter benötigen. Alle anderen Validatoren sollen im Model definiert werden. Das funktioniert auch prima und ist zudem super für die Datenintegrität. ABER… Jetzt arbeite ich durchweg mit Objekten. Mein alter Ansatz mit dem Array ist a) inkonsistent und b) bedeutet ich muss für den Updatevorgang einen eigenen Validator schreiben. Der von mir bevorzugte Ansatz nur Objekte zu verwenden bedeutet jedoch, dass auch versteckte Datensätze an updateAction(FooObjekt $fooObjekt) übergeben werden müssen. Wie löst ihr das? Ich habe folgendes probiert:

1. QuerySettings im Controller setzen

public function initializeAction(): void
{
    if ($this->actionMethodName == 'updateAction') {
        $settings = GeneralUtility::makeInstance(Typo3QuerySettings::class);
        $settings->setIgnoreEnableFields(true)
            ->setEnableFieldsToBeIgnored(['disabled']);
        $this->fooRepository->setDefaultQuerySettings($settings);
    }
}

Aber das greift ja nur für die Repository Instanz die im Controller initiert wird und nicht die die Typo3 für den Request benutzt. Fiel mir dann ein, als ich es umgesetzt hatte... Naja, egal, hat ja nur einen Moment gedauert.

2. Middleware

Ok, dieser Versuch war einfach nur ein Proof-Of-Concept, funktioniert aber...grundsätzlich. Nach dem Absenden prüft die Middleware ob in der persisted Instanz „hidden“ wahr ist und setzt es ggf. auf falsch. Dadurch wird das Objekt von den Mechanismen im Controller gefunden und die Validierung funktioniert auch. Danach werden im Controller die Parameter zur Sichtbarkeit vom aktuellen Request übernommen. Das funktioniert auch tadellos, ist aber aufgrund der offensichtlichen Dateninkonsistenz zur Laufzeit nicht für den Produktiveinsatz geeignet. D.h. wenn es mal zu einer Exception kommt o.ä. kommt könnte der Datensatz in einem Sichbarkeites-Zustand sein der nicht gewünscht ist.

Ja, jetzt sitz ich hier und überlege wie ich das lösen kann. Eine Suche im Netz war nicht erfolgreich, ChatGPT hat mir mal wieder irgendwelche „fake“ Funktionalitäten vorgegaukelt die es nicht gibt.

Also, wie löst ihr das?

Matthew Colton

Hier ist vollständigkeitshalber die Middleware:

<?php

declare(strict_types=1);

namespace FOO\Bar\Middleware;

use FOO\Bar\Domain\Model\EventDate;
use FOO\Bar\Domain\Repository\EventDateRepository;
use Psr\Http\Message\ServerRequestInterface;
use Psr\Http\Server\RequestHandlerInterface;
use Psr\Http\Server\MiddlewareInterface;
use Psr\Http\Message\ResponseInterface;
use TYPO3\CMS\Core\Utility\GeneralUtility;
use TYPO3\CMS\Extbase\Persistence\Generic\PersistenceManager;

class EventDateManipulateHiddenMiddleware implements MiddlewareInterface
{
    public function __construct(
        private readonly EventDateRepository $eventDateRepository,
        private readonly PersistenceManager $persistenceManager
    ) {}

    public function process(
        ServerRequestInterface $request, 
        RequestHandlerInterface $handler
    ): ResponseInterface {
        $queryParams = $request->getQueryParams();
        if (isset($queryParams['tx_foobar_admin']) &&
            $queryParams['tx_foobar_admin']['action'] === 'update' &&
            $queryParams['tx_foobar_admin']['controller'] === 'EventDate'
        ) {
            $parsedBody = $request->getParsedBody();
            // In $parsedBody['tx_foobar_admin']['eventDate'] stehen die 
            // aktualisierten Daten, wir brauchen aber nur die ID des 
            // Objekts, welches aktualisiert werden soll.
            $uid = (int)$parsedBody['tx_foobar_admin']['eventDate']['__identity'];
            // Nachfolgend wird das alte, persistierte Objekt geladen. Falls
            // es versteckt ist, wird es wieder sichtbar gemacht und persistiert.
            // Im Controller wird wiederum der Zustand übernommen der mit übergeben
            // wurde und somit passt es wieder in die Logik.
            $eventDate = $this->eventDateRepository->findByUidEvenIfHidden($uid);
            if ($eventDate instanceof EventDate && $eventDate->getHidden() === true) {
                $eventDate->setHidden(false);
                $this->eventDateRepository->update($eventDate);
                $this->persistenceManager->persistAll();
            }
        }
        return $handler->handle($request);
    }
}

Mogens Fiebrandt

Du könntest versuchen die initializeObject Methode des Repos zu verwenden.

class MyRepository extends Repository{
    
    public function initializeObject() {
        /** @var $defaultQuerySettings \TYPO3\CMS\Extbase\Persistence\Generic\Typo3QuerySettings */
        $defaultQuerySettings = $this->createQuery()->getQuerySettings();
        $defaultQuerySettings->setIgnoreEnableFields(true)
            ->setEnableFieldsToBeIgnored(['disabled']);
        $this->setDefaultQuerySettings($defaultQuerySettings);
    }

}

Jetzt sollte das Repo bei jedem Zugriff das Feld ignorieren. Aber Du könntest dann ja Deinen Ansatz nehmen und das disabled Feld wieder aktivieren im Controller wenn (Action != updateAction) ist.
Nicht ganz sicher, ob das funktioniert. Aber einen Versuch wäre es wert. Viel Glück dabei.

Matthew Colton

Mogens Fiebrandt Danke für deinen Vorschlag. Das Problem hierbei ist, dass das Objekt nicht immer "versteckbar" sein soll, sondern nur bei bestimmten Actions, deshalb habe ich das nicht in initializeObject umgesetzt.

Matthew Colton

Eine weitere Idee wäre via EventListener:
https://docs.typo3.org/m/typo3/reference-coreapi/main/en-us/ApiOverview/Events/Events/Extbase/Persistence/ModifyQueryBeforeFetchingObjectDataEvent.html#modifyquerybeforefetchingobjectdataevent

Mogens Fiebrandt

Deswegen hatte ich ja vorgeschlagen, dass Du für die Actions bei denen das Objekt "versteckbar" sein soll Deine Implementierung verwendest.

Also im Repo in der InitializeObject wie von mir oben beschrieben. und dann in dem Controller so:

public function initializeAction(): void
{
    if ($this->actionMethodName != 'updateAction') {
        $settings = GeneralUtility::makeInstance(Typo3QuerySettings::class);
        $settings->setIgnoreEnableFields(false);
        $this->fooRepository->setDefaultQuerySettings($settings);
    }
}

Matthew Colton

Das habe ich bereits umgekehrt probiert, d.h. im Controller setIgnoreEnableFields(true) setzen , aber das hat nicht funktioniert. Hast du das tatsächlich bereits so ausprobiert wie von dir beschrieben oder ist das einfach eine Idee?

Mogens Fiebrandt

Ich habe kein Projekt mit den Anforderungen und müsste mir mühsam erstmal einen Testcase zusammenbauen. Also nein - das habe ich nicht ausprobiert. Hatte ich oben aber auch schon erwähnt. 😉

Aber Du hast doch ein Projekt in dem Du das testen kannst. Du musst doch nur die beiden Methoden kurz implementieren und dann siehst Du, ob es geht. Das dauert doch maximal 5-10 min.

Theoretisch musst Du ja erstmal nur die Methode im Repo implementieren und schauen, ob Du dann Objekte, die disabled sind, updaten kannst. Wenn das geht, dann kannst Du die Methode im Controller nachziehen und verhindern, dass in den anderen Actions Objekte, die disabled sind, geladen werden. (Bsp. in der ListAction oder so).

Matthew Colton

Nein, das funktioniert leider nicht. Offensichtlich werden die defaultQuerySettings des Repositorys von Typo3 beim Laden des Objekts nicht verwendet. Erst wenn im Controller eine Methode des Repositorys aufgerufen wird werden diese berücksichtigt.
Was allerdings funktioniert ist ein EventListener:

<?php

declare(strict_types=1);

namespace FOO\Bar\Extbase\EventListener;

use FOO\Bar\Domain\Model\EventDate;
use TYPO3\CMS\Core\Attribute\AsEventListener;
use TYPO3\CMS\Extbase\Event\Persistence\ModifyQueryBeforeFetchingObjectDataEvent;

#[AsEventListener(
    identifier: 'foo/disable-enable-fields-for-event-date-update',
)]
final readonly class DisableEnableFieldsForEventDateUpdate
{

    public function __invoke(ModifyQueryBeforeFetchingObjectDataEvent $event): void
    {
        if (!isset($GLOBALS['TYPO3_REQUEST'])) {
            return;
        }
        $incorrectType = $event->getQuery()->getType() !== EventDate::class;
        $request = $GLOBALS['TYPO3_REQUEST']->getQueryParams();
        $missingParameters = !isset($request['tx_foo_admin']['action']) || !isset($request['tx_foo_admin']['controller']);
        
        if (
            $incorrectType 
            || $missingParameters 
            || $request['tx_foo_admin']['action'] !== 'update' 
            || $request['tx_foo_admin']['controller'] !== 'EventDate'
        ) {
            return;
        }
        $querySettings = $event->getQuery()->getQuerySettings();
        $querySettings->setIgnoreEnableFields(true)->setEnableFieldsToBeIgnored(['disabled']);
    }
}

Leider steht das ServerRequest Objekt nicht direkt über das ModifyQueryBeforeFetchingObjectDataEvent Objekt zur Verfügung und muss über $GLOBALS['TYPO3_REQUEST'] geholt werden. Aber es geht und ist auch laufzeitsicher im Vergleich zu meiner Lösung via Middleware.
Was meint ihr, ist das die beste Lösung?

Nachtrag: Damit die Lösung bei der Verwendung von Commands keine PHP Warnung rausschmeißt weil $GLOBALS['TYPO3_REQUEST'] nicht existiert, muss geprüft werden ob diese vorhanden ist. Das habe ich nun hinzugefügt.

Unterstütze das Forum

Hilf mit, den Community Hub für TYPO3 werbefrei zu halten und die Betriebskosten zu decken. Werde Official Community Hub Supporter für nur 5 Euro im Monat (zzgl. USt) und erhalte ein exklusives Supporter-Badge. Jeder Beitrag zählt!

Jetzt Supporter werden

Impressum - Datenschutz - Kontakt - Netiquette - RSS