In meinem Beispiel soll das Zugriffs-Ablaufdatum automatisch gesetzt werden, abhängig von einem Datum in einem anderen Feld. Beispiel: DatumsfeldX: 20.09.2025 --> Zugriff Ablaufdatum (endtime): 17.09.2025 Geht so was überhaupt mit Content blocks, und weiß jemand ggf. wie das umzusetzen ist?

@"Johannes Laxander"#p6867 Ja, so etwas ist möglich – allerdings nicht direkt über Content Blocks selbst, sondern über einen kleinen DataHandler Hook beim Speichern des Datensatzes. Damit stellst du sicher, dass der Wert **immer serverseitig** gesetzt wird (egal ob im Backend, via Import oder CLI), und nicht nur in der Eingabemaske. Ein Beispiel für `tt_content` mit einem eigenen Content Element könnte so aussehen (erfolgreich getestet): ```php

@"Eric Harrer"#p6927 Super Eric, das werde ich so mal umsetzen und gebe dann wieder Feedback.

@"Eric Harrer"#p6927 So, ich habe deinen Code eingebunden und `\VendorName\Sitepackage\` an mein Sitepackage angepasst. Leider erhalte ich diesen Fehler: `Class "khpy\khpy03sitepackage\Hooks\DatamapAutoEndtime" not found` Schreib-/Tippfehler konnte ich nicht finden (was aber nicht unbedingt auch so sein muss). Der Fehler tritt beim Speichern bzw. Löschen auf!? (extension:setup und Cache löschen habe ich natürlich gemacht!)

@"Johannes Laxander"#p6942 also wenn die Klasse nicht gefunden werden kann, vermute ich schon einen Schreib- oder Tippfehler im Namespace. Mein Beispiel hat auf jeden Fall in TYPO3 v13 mit dem darin genannten Namespace funktioniert. Prüfe das bitte noch mal systematisch ab. Die Datei muss in deinem Sitepackage unter folgendem Pfad liegen: ``` Classes/Hooks/DatamapAutoEndtime.php ``` Evtl. liegt es auch daran, dass in der `composer.json` deines Sitepackages der folgende Zusatz fehlt: ```json "autoload": { "psr-4": { "Khpy\\Khpy03sitepackage\\": "Classes/" } } ``` Erst mit diesem Zusatz greift das Autoloading für Klassen deines Sitepackages. Möglicherweise hilft zusätzlich die Ausführung des folgenden CLI Commands wie [hier](https://docs.typo3.org/m/typo3/reference-coreapi/main/en-us/ApiOverview/Autoloading/Index.html#autoloading-troubleshooting) beschrieben: ```bash composer dumpautoload ```

@"Eric Harrer"#p6945 Danke Eric für deine Hinweise. Der Zusatz für's Autoloading ist vorhanden, und die Datei `DatamapAutoEndtime.php` liegt im Verzeichnis `Classes/Hooks/`. In der autoload_psr4.php ist der Eintrag `Khpy\\khpy03sitepackage\\' => array($vendorDir . '/khpy/khpy03sitepackage/Classes'),` zu finden. In der `autoload_classmap.php` ist kein Eintrag im Zusammenhang mit dem Sitepackage zu finden. Was mich aufgrund meiner Unwissenheit irritiert ist, warum in der ext_localconf.php `\VendorName\Sitepackage\Hooks\DatamapAutoEndtime::class; `angegeben wird, und nicht `\VendorName\Sitepackage\Classes\Hooks\DatamapAutoEndtime::class;`?

@"Eric Harrer"#p6945 Wer lange genug sucht, der findet! In der ext_localconf.php war "khpy03sitepackage" mit einem großen "S" geschrieben, was ich hartnäckig übersehen habe! :( Woher kommt eigentlich der Eintrag in der autoload_psr4.php? Aus der ext_localconf.php? Trotzdem wird `endtime` noch nicht gesetzt. Der Grund dafür liegt vermutlich in meiner vereinfachten Aufgabenbeschreibung bzw. im vereinfachten Beispiel. Das Ablaufdatum betrifft nämlich nicht das eigentliche Contentelement, sondern Elemente einer Collection dieses CEs. CType: Khpy_lastminute-offers --> Fremdtabelle (Collection): lastminute_offers: [field:offer_enddate] --> [field:endtime] Deine Lösung Eric, geht ja davon aus, dass `endtime` im CE `Khpy_lastminute-offers` gesetzt wird. Das habe ich erst jetzt bemerkt, als ich weiter nach der Ursache gesucht habe, warum das nicht im Element `lastminute_offers` gesetzt wird. Ich war davor zu sehr im Focus auf technische Probleme. Sorry Eric, wenn dich mein Beispiel in die falsche Richtung geführt hat.

@"Johannes Laxander"#p6954 stelle hier bitte mal die Content-Block YAML-Konfiguration des betroffenen Elements ein, damit man deinen Anwendungsfall 1:1 mit den von dir verwendeten Identifikatoren/Strukturen nachvollziehen kann. Der Hook ist am Ende wahrscheinlich der gleich aber die Bedingungen für die `tt_conten.endtime`-Modifikation sind andere. Anhand deines konkreten Elements würde ich das mal praktisch durchspielen.

@"Eric Harrer"#p6955 mach ich gerne Eric ... Ist aber nicht vollständig, weil umfangreich. Die wichtigen Konfigurationen sind aber enthalten. ``` name: khpy/lastminute-offers typeName: khpy_lastminute-offers title: 'Last Minute Offers' # description: labels.xlf group: default prefixFields: false prefixType: full basics: #- TYPO3/Links #- TYPO3/Appearance #- TYPO3/Header #- offerSubheader fields: # Header - identifier: header type: Text label: 'Überschrift zu den Last Minute Angeboten' useExistingField: true # Collection - identifier: 'lastminute_offers' type: Collection label: 'Last Minute Angebote' labelField: - offer_startdate - header - yacht_type minitems: 1 appearance: levelLinksPosition: both #collapseAll: null fields: # Palette: Angebotsart - identifier: palette_offer type: Palette label: 'Bareboat Last-Minute-Angebot' description: 'Welche Art Last-Minute-Angebot soll angelegt werden?' fields: - identifier: 'offer_type' type: Select label: 'Angebotsart' description: '1) Yachtcharter Partner (Yacht). - 2) KH+P Event (Selbstfahrer-Yacht). - 3) Partnerangebot mit Pauschalrabatt (Beispiel: Messerabatt).' renderType: selectSingle items: - label: 'Yachtcharter Partner (Yacht)' value: 1 - label: 'KH+P Event (Selbstfahrer-Yacht)' value: 2 - label: 'Partnerangebot mit Pauschalrabatt' value: 3 minitems: 1 default: 1 onChange: reload # Palette: Charter-Zeitraum, Ablauf - identifier: palette_dates type: Palette label: 'Angebots-/Charter-Zeitraum' description: Charterdauer oder Angebotsgültigkeit (von/bis) und Ablaufdatum fields: # Startdatum - identifier: 'offer_startdate' type: DateTime label: 'Startdatum' description: 'Datum, an dem die Charter beginnt bzw. ab dem das Angebot gültig ist.' format: date required: true displayCond: OR: - 'FIELD:offer_type:=:1' - 'FIELD:offer_type:=:2' - 'FIELD:offer_type:=:3' # Enddatum - identifier: 'offer_enddate' type: DateTime label: 'Enddatum' description: 'Datum, bis zu dem die Charter geht bzw. bis zu dem das Angebot gültig ist.' format: date required: true displayCond: OR: - 'FIELD:offer_type:=:1' - 'FIELD:offer_type:=:2' - 'FIELD:offer_type:=:3' - identifier: 'offer_expirydate' type: DateTime format: date label: 'Ablaufdatum: Zugriff bis' description: 'Datum, ab dem das Angebot nicht mehr angezeigt wird. Standard: 3 Tage vor Charterbeginn.' #useExistingField: true # ab/an - identifier: 'header' type: Text label: 'ab/an' description: 'Ausgangs- und Zielhafen' required: true useExistingField: true displayCond: OR: - 'FIELD:offer_type:=:1' - 'FIELD:offer_type:=:2' # Angebotstitel - identifier: 'subheader' type: Text label: 'Angebotstitel' description: 'Überschrift für das Pauschalangebot.' required: true useExistingField: true displayCond: 'FIELD:offer_type:=:3' # Palette: Yachttyp & Yachtname - Kabinen, Toiletten - identifier: palette_yacht type: Palette label: 'Yacht' description: 'Angaben zur Yacht' fields: - identifier: 'yacht_type' type: Text label: 'Yachttyp' description: 'Beispiel: Bavaria Cruiser 45' required: true displayCond: OR: - 'FIELD:offer_type:=:1' - 'FIELD:offer_type:=:2' - identifier: 'yacht_name' type: Text label: 'Yachtname' description: 'Beispiel: Vihor (2013)' required: true displayCond: 'FIELD:offer_type:=:1' - identifier: 'number_of_berth' type: Text label: 'Anzahl Kojen' description: 'Beispiel: 8 + 1' required: true displayCond: OR: - 'FIELD:offer_type:=:1' - 'FIELD:offer_type:=:2' ```

@"Johannes Laxander"#p6956 Ich habe heute Nacht eine Weile mit deinem Use-Case experimentiert und eine funktionierende Lösung gefunden. So sieht der Hook nun aus: ```php

Content Blocks: Kann ein Feld mit einem berechnenden Wert gesetzt werden?

Johannes Laxander

Eric Harrer WOW!!! 🤩 Vielen Dank Eric, da hast du dich mächtig ins Zeug gelegt, damit habe ich nun wirklich nicht gerechnet. Tolle Hilfe!

Ich hab von deinem Zip-File in meinem Projekt eine zweite Extension angelegt "khpy03sitepackage2" und natürlich auch alle Bezeichner "khpy03sitepackage" durch "khpy03sitepackage2" in den Dateien ersetzt. Ich wollte deine Test-Extension einfach mal native wie von dir erstellt ausprobieren.

Aber irgendwie bin ich wohl zu doof das hinzukriegen, oder verstehe manche Zusammenhänge noch nicht nicht wirklich. Jedenfalls funktioniert das extension:setup --extension=khpy03sitepackage2 nicht. Dieser Fehler wird ausgeworfen:
Uncaught TYPO3 Exception Expected to find class "Khpy\Khpy03sitepackage2\Hooks\DatamapAutoEndtime" in file "/var/www/html/packages/khpy03sitepackage2/Classes/Hooks/DatamapAutoEndtime.php" while importing services from resource "../Classes/*", but it was not found! Check the namespace prefix used with the resource. thrown in file /var/www/html/vendor/symfony/dependency-injection/Loader/FileLoader.php in line 365
Wo hakt es bei mir?

Eric Harrer

Johannes Laxander auch hier wurde vermutlich irgendwo etwas vergessen oder ein Tippfehler gemacht. Ich habe den Namespace in der Test-Extension Datei-übergreifend zu Khpy\Khpy03sitepackage2 geändert und es funktioniert trotzdem.

Hier ein mal der Unterschied beider Extensions (aus diff -ru a/ b/ > patch.diff) für dich zum systematischen Abgleich aller relevanter Stellen für eine Namensänderung:

diff --color -ru a/Classes/Hooks/DatamapAutoEndtime.php b/Classes/Hooks/DatamapAutoEndtime.php
--- a/Classes/Hooks/DatamapAutoEndtime.php	2025-09-18 00:32:42
+++ b/Classes/Hooks/DatamapAutoEndtime.php	2025-09-19 08:52:36
@@ -2,7 +2,7 @@
 
 declare(strict_types=1);
 
-namespace Khpy\Khpy03sitepackage\Hooks;
+namespace Khpy\Khpy03sitepackage2\Hooks;
 
 use Doctrine\DBAL\Exception;
 use TYPO3\CMS\Core\Database\Connection;
diff --color -ru a/Configuration/Services.yaml b/Configuration/Services.yaml
--- a/Configuration/Services.yaml	2025-09-17 22:26:32
+++ b/Configuration/Services.yaml	2025-09-19 08:52:36
@@ -3,6 +3,6 @@
     autowire: true
     autoconfigure: true
     public: false
-  Khpy\Khpy03sitepackage\:
+  Khpy\Khpy03sitepackage2\:
     resource: '../Classes/*'
     exclude: '../Classes/Domain/Model/*'
diff --color -ru a/composer.json b/composer.json
--- a/composer.json	2025-09-19 09:01:34
+++ b/composer.json	2025-09-19 09:01:30
@@ -1,5 +1,5 @@
 {
-    "name": "khpy/khpy03sitepackage",
+    "name": "khpy/khpy03sitepackage2",
     "description": "DatamapAutoEndtime test extension",
     "type": "typo3-cms-extension",
     "license": [
@@ -10,12 +10,12 @@
     },
     "autoload": {
         "psr-4": {
-            "Khpy\\Khpy03sitepackage\\": "Classes/"
+            "Khpy\\Khpy03sitepackage2\\": "Classes/"
         }
     },
     "extra": {
         "typo3/cms": {
-            "extension-key": "khpy03sitepackage"
+            "extension-key": "khpy03sitepackage2"
         }
     }
 }
diff --color -ru a/ext_localconf.php b/ext_localconf.php
--- a/ext_localconf.php	2025-09-17 22:28:26
+++ b/ext_localconf.php	2025-09-19 08:52:36
@@ -19,7 +19,7 @@
  * https://docs.typo3.org/m/typo3/reference-coreapi/main/en-us/ExtensionArchitecture/FileStructure/ExtLocalconf.html
  */
 
-use Khpy\Khpy03sitepackage\Hooks\DatamapAutoEndtime;
+use Khpy\Khpy03sitepackage2\Hooks\DatamapAutoEndtime;
 
 defined('TYPO3') or die();

Hier ist es wichtig exakt zu arbeiten. Es kommt auf jedes Zeichen an.

Johannes Laxander

Eric Harrer Danke Eric. War am WE "ausgebremst", werde mir alles noch einmal genau ansehen und gebe hier wieder Rückmeldung.

Johannes Laxander

Hat ein Weilchen gedauert, bis ich an dem Thema wieder weitermachen konnte. Danke @Eric Harrer, dass du dir so viele Mühe machst, mir bei dieser Aufgabe zu helfen. Die gute Nachricht: dein Beispiel funktioniert jetzt auch bei mir!
Nur leider ist es nicht die Lösung, die ich eigentlich brauche. In deinem Beispiel setzt du das enddate auf der obersten Ebene für den CType "lastminute_offers", abhängig vom höchsten enddate der referenzierten Offers (IRRE). Das ist eine tolle Idee und kann im Prinzip ja auch so bleiben. Was mir aber fehlt, ist das Berechnen von enddateauf Ebene der referenzierten Offers. Denn das Ablaufdatum soll für das einzelne Angebot automatisch gesetzt werden.

Ich habe mir den Code angesehen, bin mir aber nicht klar darüber, wie ich auf den aktuellen Datensatz des referenzierten Angebots zugreifen kann. In offerUids speicherst du alle Uids der IRRE-Datensätze, und mit der foreach-Schleife gehst du zwar durch alle IRRE-Datensätze durch, aber das bringt mich ja nicht auf den aktuellen IRRE-Datensatz. Da hakt es bei mir.

Wie adressiere ich die Felder für den aktuell bearbeiteten IRRE-Datensatz?

Eric Harrer

Johannes Laxander
cool, dass es nun bei dir funktioniert. Schade allerdings, dass es doch nicht die Lösung ist, die du eigentlich gebraucht hattest. Hier wäre es hilfreich gewesen, die Anforderung im Vorfeld etwas klarer zu formulieren – dann hätte ich zielgerichteter an deinem konkreten Anwendungsfall gearbeitet und dir wäre vermutlich schneller geholfen gewesen. 🙂

Aktuell fehlt mir die Zeit für längere Ausarbeitungen, aber hier mal der Grundgedanke: Auch für Datensätze anderer Tabellen wird meines Wissens nach der Hook angesteuert. Momentan beschränken wir die Logik auf tt_content-Datensätze mit CType khpy_lastminute-offers. Für diese findet dann eine Auswertung und Anpassung des fieldArray statt.

Vermutlich besteht die Lösung in deinem Fall darin, den Hook auf lastminute_offers-Datensätze zu begrenzen und die Logik in diesem Kontext anzupassen. Dann betrachtest du nur noch den jeweils aktuellen Kind-Datensatz und musst dich nicht mehr um den Elterndatensatz samt aller Kinder kümmern – was den Code sogar einfacher machen dürfte.

Edit:
Ich sehe gerade deine Aussage:

Deine Lösung Eric, geht ja davon aus, dass endtime im CE Khpy_lastminute-offers gesetzt wird. Das habe ich erst jetzt bemerkt, als ich weiter nach der Ursache gesucht habe, warum das nicht im Element lastminute_offers gesetzt wird. Ich war davor zu sehr im Focus auf technische Probleme.
Sorry Eric, wenn dich mein Beispiel in die falsche Richtung geführt hat.

Das hattest du also bereits angedeutet – das war mir beim ersten Lesen entgangen. Mit dem Tipp, die Logik direkt auf lastminute_offers-Datensätze anzuwenden, und dem bestehenden Code solltest du die Anpassung jetzt aber hinbekommen.

Johannes Laxander

Eric Harrer Aktuell fehlt mir die Zeit für längere Ausarbeitungen, aber hier mal der Grundgedanke: Auch für Datensätze anderer Tabellen wird meines Wissens nach der Hook angesteuert. Momentan beschränken wir die Logik auf tt_content-Datensätze mit CType khpy_lastminute-offers. Für diese findet dann eine Auswertung und Anpassung des fieldArray statt.

Also das erwarte ich wirklich nicht, du hast mir eh schon viel geholfen. Und der Hinweis auf das fieldArray war für mich der "Dosenöffner". Hätte ich deinen Kommentar am Code-Anfang @param array<string,mixed> $fieldArray Eingehende Werte des Datensatzes aufmerksamer gelesen, hätte ich die Frage gar nicht mehr stellen müssen!

Ich habe deinen Code daraufhin entsprechend angepasst, und bekomme das Ablaufdatum wie gewünscht. Super coole Sache und ganz großen Dank für Deine Hilfe!

Johannes Laxander

Gerade ist mir noch aufgefallen, dass die endtime um zwei Stunden abweicht. Statt z.B. 29.09.2025 00:00 ist die endtime auf 29.09.2025 02:00 eingestellt. Ich denke, das hat mit der timezone zu tun. Für PHP ist die aber schon richtig auf "Europe/Berlin" eingestellt. Woher kommt die Abweichung?

Eric Harrer

Johannes Laxander hier scheint strtotime verantwortlich zu sein. Es sieht so aus als würden wir UTC mit der lokalen Zeitzone auf diese Weise vermischen.

Probiere es evtl. mal mit folgender Alternative, die von ChatGPT vorgeschlagen wurde (noch ungetestet):

$offerEnddateTimestamp = is_numeric($offerEnddateValue)
    ? (int)$offerEnddateValue
    : (new DateTimeImmutable((string)$offerEnddateValue, new DateTimeZone(\date_default_timezone_get())))
        ->setTimezone(new DateTimeZone('UTC'))
        ->getTimestamp();

Johannes Laxander

Hier ist mein angepasster Code - eigentlich ganz einfach, wenn man weiß wie es geht! 😅

<?php

declare(strict_types=1);

namespace Khpy\Khpy03sitepackage2\Hooks;

use Doctrine\DBAL\Exception;
use TYPO3\CMS\Core\Database\Connection;
use TYPO3\CMS\Core\Database\ConnectionPool;
use TYPO3\CMS\Core\DataHandling\DataHandler;
use TYPO3\CMS\Core\Utility\GeneralUtility;

final class DatamapAutoEndtime
{
    /**
     * Setzt das Zugriffs-Ablaufdatum (endtime) automatisch,
     * ausgehend vom Enddatum des Angebots (offer_enddate).
     *
     * @param array<string,mixed> $fieldArray Eingehende Werte des Datensatzes
     * @throws Exception
     */
    public function processDatamap_preProcessFieldArray(
        array &$fieldArray,
        string $table,
        ?string $id,
        DataHandler $dataHandler
    ): void {
        if ($table !== 'lastminute_offers') {
            return;
        }

        // Enddatum des Angebots auslesen:
        // = Ausgangswert für die Berechnung des Auslaufdatums
        $offerEnddateValue = $fieldArray['offer_enddate'] ?? null;
        if (!$offerEnddateValue) {
            return;
        }
        // Datum in Timestamp umwandeln
        $offerEnddateTimestamp = is_numeric($offerEnddateValue)
            ? (int)$offerEnddateValue
            : strtotime((string)$offerEnddateValue);

        // Auslaufdatum 3 Tage vorher berechnen
        $calculatedEndtime = $offerEnddateTimestamp - 3 * 24 * 60 * 60;

        // Auslaufdatum ins Record-Feld schreiben
        $fieldArray['endtime'] = $calculatedEndtime;
    }
}

Ich denke,

use TYPO3\CMS\Core\Database\Connection;
use TYPO3\CMS\Core\Database\ConnectionPool;
use TYPO3\CMS\Core\Utility\GeneralUtility;

kann ich jetzt auch weglassen, oder?

Eric Harrer

Johannes Laxander

kann ich jetzt auch weglassen, oder?

Das kannst du ganz leicht selbst prüfen, wenn du eine IDE nutzt, die überflüssige use-Statements erkennt und bereinigt. In PhpStorm funktioniert das beispielsweise sehr gut: unnötige Statements werden ausgegraut dargestellt:

Mit der Funktion Optimize Imports lassen sich solche Zeilen sogar automatisch per Shortcut entfernen:

Außerdem ist mir in deinem Code aufgefallen, dass du die datamap aktuell nicht mehr berücksichtigst. Das führt dazu, dass Änderungen erst beim zweiten Speichern greifen, wenn sie direkt vor dem Speichern gemacht wurden. Ich würde das wie im bisherigen Code wieder mit einbauen, damit es redaktionell intuitiver bleibt.

Johannes Laxander

Super, danke für deine beiden Tipps @Eric Harrer !

Johannes Laxander

Eric Harrer Probiere es evtl. mal mit folgender Alternative, die von ChatGPT vorgeschlagen wurde (noch ungetestet):

Das hat leider zu einem Fehler geführt: DateTimeImmutable not found

Ich habe es dann auch mit ChatGPT versucht. Diese Lösung wurde mir vorgeschlagen:

<?php
// Zeitzone setzen (am Anfang des Skripts)
date_default_timezone_set('Europe/Berlin');

// Beispiel: 1. Oktober 2025, 00:00 Uhr
$ts = strtotime("2025-10-01 00:00:00");
echo $ts; // richtiger Unix-Timestamp für 00:00 Uhr in Berlin
echo PHP_EOL . date("Y-m-d H:i:s", $ts);

Alternativ:

<?php
$dt = new DateTime("2025-10-01 00:00:00", new DateTimeZone("Europe/Berlin"));
$ts = $dt->getTimestamp();

echo $ts;
echo PHP_EOL . $dt->format("Y-m-d H:i:s");

Erklärung:

strtotime() selbst berücksichtigt keine Zeitzone im String. Es nutzt immer die aktuell gesetzte PHP-Default-Zone.
Daher entweder globale Zeitzone setzen (date_default_timezone_set), oder gezielt mit DateTime/DateTimeZone arbeiten.

Ich habe am Anfang des Skripts die globale Zeitzone gesetzt, und es funktioniert! 🙂

Warum die Einstellung timezone: Europe/Berlin in meiner DDEV config.yaml nicht greift, weiß ich nicht.

« Vorherige Seite

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