Standard-Mailform

Minimales Setup für Standard-Mailformular sollte mitbringen:

  • Reply-To an Websitebesucher
  • fester From-Name…
  • …und From-Email (sonst ggf. falsch automatisiert ermittelt)

Konfiguration könnte somit etwa aussehen wie folgt:

 Name | *replyto_name=input
 E-Mail | *replyto_email=input
 Nachricht | *Nachricht=textarea
 
 | from_name=hidden | example.com
 | from_email=hidden | info@example.com
 | formtype_mail=submit | Absenden
 | html_enabled=hidden
 | subject=hidden | example.com Mailformular

Mit getText in generischen Markern auf tt_content zugreifen

Heute benötigte ich innerhalb eines generischen Markers von tt_news Zugriff auf das Content-Element, in dem die Meldung angezeigt wird (also die Plugin-Einbindung). Warum man sowas braucht? Naja, Projekte entwickeln sich manchmal kreativ… 😉

Generische Marker werden im Zuge des Renderings der einzelnen Newsmeldungen ausgewertet, d.h. der Zugriff über field etc. ist jeweils auf den tt_news-Datensatz, nicht auf das Inhaltselement. Der Datensatz selbst hat auch keine Verknüpfung zum Inhaltselement. 🙁

Die Kollegen der marit.ag haben vor Längerem den Artikel „Datenbankfelder dynamisch per stdWrap.data auslesen“ verfasst. Damit ließe sich (via „getText“) auf beliebige Datensätze dynamisch zugreifen wie folgt:

genericmarkers {
        ceheader >
        ceheader = TEXT
        ceheader {
            // @see http://blog.marit.ag/2009/12/15/datenbankfelder-stdwrap-data/
            dataWrap = DB:tt_content:{field:pid}:header
            wrap3 = {|}
            insertData=1
        }
}

Es bleibt aber die Problematik, dass wir die uid des tt_content-Datensatzes dennoch nicht kennen. Hilfe bringt aber der Inhalt von TSFE: dort gibt es einen Wert currentRecord:

This is set to the [table]:[uid] of the record delivered in the $data-array

Somit lässt sich der Ansatz erweitern, indem im dataWrap der Teilstring „[table]:[uid]“ dynamisch ersetzt wird:

genericmarkers {
        ceheader >
        ceheader = TEXT
        ceheader {
            // @see http://blog.marit.ag/2009/12/15/datenbankfelder-stdwrap-data/
            //dataWrap = DB:tt_content:{cObj:TSFE:parentRecordNumber}:header
            // {TSFE:currentRecord} liefert etwas in der Art "tt_content:1234"
            dataWrap = DB:{TSFE:currentRecord}:header
            wrap3 = {|}
            insertData=1
        }
}

Quellen

Suggest-Wizard mit PAGE_TSCONFIG_*-Werten

Wird bei Relationen die Auswahl (zu) groß, ist oftmals die Einschränkung via TCA und PAGE_TSCONFIG_*-Werten in den addWhere-Klauseln sinnvoll. Zusammen mit dem Suggest-Wizard wäre damit die Datenmenge für den Redakteur handhabbar. Leider stoßen wir hier aber auf ein Problem, wie Frank im Kommentar zu Steffen Blogartikel „Using the new TCA wizard „suggest“ for autocompletion in BE fields of TYPO3 4.3“ schon anmerkt:

Just found out, that suggest doesn’t work with „foreign_table_where“-conditions with markers like „###PAGE_TSCONFIG_IDLIST###“. Only the explicit csv-list works in that case.

Aber warum? Schaut man sich die Klasse t3lib_TCEforms_Suggest an, so sieht man, dass lediglich zwei Marker ersetzt werden: THIS_UID, CURRENT_PID. Mit einer einfachen Änderung ließe sich dies ergänzen um die PAGE_TSCONFIG_*-Werte. Gibt es einen Grund, weshalb das seit TYPO3 4.3 noch niemand gemacht hat?

Workaround

Ersetzen dieser Codezeilen der Klasse t3lib_TCEforms_Suggest

if (isset($config['addWhere'])) {
	$config['addWhere'] = strtr(
		' ' . $config['addWhere'],
		array(
			'###THIS_UID###' => intval($uid),
			'###CURRENT_PID###' => intval($pageId),
		)
	);
}

durch

if (isset($config['addWhere'])) {
	$config['addWhere'] = strtr(' ' . $config['addWhere'], 
		array(
			'###THIS_UID###' => intval($uid),
			'###CURRENT_PID###' => intval($pageId),
			'###PAGE_TSCONFIG_ID###' => intval($TSconfig['TCEFORM.'][$table . '.'][$field . '.']['PAGE_TSCONFIG_ID']),
			'###PAGE_TSCONFIG_IDLIST###' => $GLOBALS['TYPO3_DB']->cleanIntList($TSconfig['TCEFORM.'][$table . '.'][$field . '.']['PAGE_TSCONFIG_IDLIST']),
			'###PAGE_TSCONFIG_STR###' => $GLOBALS['TYPO3_DB']->quoteStr($TSconfig['TCEFORM.'][$table . '.'][$field . '.']['PAGE_TSCONFIG_STR'], $fieldConfig['foreign_table']), 
		)
	);
}

Update

Ein Feature-Request wurde inzwischen erstellt und ein Patch eingereicht. Dieser darf gerne einem Review unterzogen werden 🙂

Links

realURL: optimierte Multi-Domain-Konfiguration

Ausgangssituation

In einem Projekt waren in einer TYPO3-Instanz über den Seitenbaum mehrere Marken in verschiedenen Ländern mit jeweils eigenen (Teil-)Seitenbaum abgebildet. Die einzelnen Websites waren inhaltlich-strukturell sehr ähnlich, und es waren viele spezifische Plugins im Einsatz. Insgesamt entstand so für die rund 100 Einstiegseiten eine (via realURL-Autoconfiguration erzeugte) rund 4,5 MB große Konfiguration. Die war uns ein Dorn im Auge.

Weiterlesen»

Extensionmanager: Fatal error: Call to a member function getUid() on a non-object

Gestern war es wieder einmal so weit: leises Fluchen war zu hören. Grund hierfür war, dass der Extensionmanager einer frischen TYPO3-Installation keine Extension installieren wollte, sondern seinen Dienst mit einer Fehlermeldung abbrach:

Fatal error: Call to a member function getUid() on a non-object in /var/www/test/typo3/6.1.5/typo3/sysext/extensionmanager/Classes/Utility/Repository/Helper.php on line 251

Recht schnell war verständlich, dass hier auf ein nicht vorhandenes Repository versucht wird zuzugreifen. Aber warum? Bei einer frischen Installation sollte das doch funktionieren? Und es tut doch normal auch… Wir wollten es wissen. Was geht hier (manchmal) schief?

Wir setzten schnell eine frische Test-Installation auf – alles passt. Dann gab so eine Idee: „Ach, ähm, ich musste die Datenbankstruktur gestern nochmal neu anlegen“. Also löschten wir alle Tabellen aus der Datenbank und legten diese via Install Tool -> Database Analyser -> COMPARE neu an. Und siehe da, der Extensionmanager versagt seinen Dienst mit obiger Meldung 🙂

Weiterlesen»