TYPO3 MailForm Validierungs-Probleme wegen Komma

19. September 2011 in TYPO3 von Leo

Vor kurzem bin ich wieder über das Problem gestolpert. Hat man in der standard TYPO3 MailForm Kommas in den Labels angegeben, z.b. “Name, Vorname”, so funktioniert die ganze MailForm nicht mehr da die Validierung scheitert.
Grund dafür ist das JavaScript, welches durch das Komma ins stolpern kommt.

Die einzige mir bekannte Lösung ist entweder auf eine andere Extension umzusteigen, oder einfach keine Kommas zu nutzen.

Hier findet ihr auch noch kurz etwas dazu: Klick

TYPO3: Eigene Extension lokalisieren

16. August 2011 in TYPO3 von Leo

Um die eigene Extension Mehrsprachig zu machen und trotzdem so flexibel wie möglich zu halten, nutzt man die locallang. Früher handelte es sich hier um ein simples PHP-File mit einem Array, heute ist es ein XML-File mit einer besseren struktur und Übersicht, wo es auch keine Zeichensatz Probleme gibt.

Um für die eigene Extension eine locallang nutzen zu können, gehen wir folgendermassen vor:

Als erstes legen wir die locallang.xml an. Meist direkt im Extension Verzeichnis zu finden, sprich typo3conf/ext/meineExtension/locallang.xml. Falls wir jedoch mehrere pi’s in unserer Extension haben, können wir in jedem pi eine eigene locallang Anlegen welche dann jeweils genutzt wird.

In unsere so eben erstelle locallang.xml Datei kopieren wir nun folgenden XML-Code:

<?xml version="1.0" encoding="utf-8" standalone="yes" ?>
<T3locallang>
	<meta type="array">
		<type>module</type>
		<description>language Labels</description>
	</meta>
	<data type="array">
		<languageKey index="default" type="array">
			<label index="captchaErrorMessage">Captcha incorrect!</label>
		</languageKey>

		<languageKey index="de" type="array">
			<label index="captchaErrorMessage">Captcha nicht korrekt!</label>
		</languageKey>
	</data>
</T3locallang>

Hier haben wir 2 Sprachen. Die default Sprache (englisch) und “de” für Deutsch. Die Übersetzungen werden als Phrasen gemacht, welche jeweils in labels abgespeichert werden. Die labels erhalten einen namen (index=”") und werden im languageKey Array eingefügt. Oben anhand des Beispiels zu sehen.

In unserer PHP-Class der Extension (falls mehrere muss es in jeder gemacht werden), müssen noch folgende Variabeln angegeben werden, was falls ihr mit dem Extension Kickstarter arbeitet eigentlich erledigt sein sollte. Direkt in der Class gebt ihr folgendes an:

public $scriptRelPath = 'class.ux_tx_tipafriend.php'; // Path to this script relative to the extension dir.
public $extKey = 'x4etipafriendrecap'; // The extension key.

So kann TYPO3 die korrekte localconf holen. Wäre unsere Datei in einem pi Verzeichnis, wäre der $scriptRelPath demnach z.B. pi1/class.ux_tx_tipafriend.php.

Damit die Sprachen nun noch geladen werden, müssen in der Main-Funktion noch folgendes gemacht werden:
Zuerst muss die conf in $this->conf geschrieben werden:

$this->conf = $conf;

Danach (muss danach sein!) muss die locallang selbst noch geladen werden:

$this->pi_loadLL();

Fertig!

Um jetzt auf die Phrasen zuzugreifen, nutzen wir folgende Zeile:

$error = $this->pi_getLL('captchaErrorMessage');

Fluid: Select mit zusätzlicher Option

30. Juni 2011 in TYPO3 von Leo

Lange war ich auf der Suche nach einer einfachen Möglichkeit in einem Fluid Select eine default Option anzufügen, sprich eine Option wie “Produkt auswählen” oder ähnlich. Schlussendlich war die beste lösung einen ViewHelper für das Select zu erstellen.
Dabei bin ich erstmals auf folgenden Artikel gestossen: Fluid: Select in Formularen mit weiteren Optionen. Leider führte dies zu einer Fehlermeldung, und ausserdem waren in meinem Fall noch ein paar Anpassungen nötig.

Hier nun eine kurze Anleitung:
Als erstes erstellen wir einen neuen ViewHelper mit dem Namen SelectViewHelper.php unter typo3conf/ext/meineExt/Classes/ViewHelpers/. In diesen fügen wir nun folgenden Code ein:

class Tx_MeineExt_ViewHelpers_SelectViewHelper extends Tx_Fluid_ViewHelpers_Form_SelectViewHelper {

    public function initializeArguments() {
        parent::initializeArguments();
        $this->registerArgument('additionalOptions', 'array', 'Associative array with values to prepend', FALSE);
    }

    protected function getOptions() {
        $options = parent::getOptions();
        $additionalOptions = array();
        foreach ($this->arguments['additionalOptions'] as $key => $value) {
            $additionalOptions[$key] = $value;
        }
        $return = $additionalOptions + $options;
        return $return;
    }

}

Hierbei noch den Namen der Klasse abändern und “meineExt” durch den eigenen Extension namen ersetzen.

Nun bearbeiten wir unser Fluid Template wo das Custom Select hin soll. Dort fügen wir zuoberst folgende Zeile ein:

{namespace meineExt=Tx_meineExt_ViewHelpers}

Der namespace kann eigentlich beliebig heissen, wie man es halt gerne hätte.

Und fügen dann an einer beliebigen Stelle darunter unser Select ein:

<meineExt:select additionalOptions="{- : '-- Produkt wählen --'}" sortByOptionLabel="name" name="products" property="products" options="{allProducts}" optionValueField="uid" optionLabelField="name" />

Der Parameter additionalOptions ist also für unseres Zusätzliche Feld, dort kann ein beliebiger Wert angegeben werden.

Wichtig: In meinem Fall wurde in der getOptions Methode in unserer ViewHelper Klasse keine array_merge verwendet, wie im Original Code, da die Array-Keys noch gebraucht wurden.

TYPO3: Felder über PageTS entfernen

21. Juni 2011 in TYPO3 von Leo

Um für Kunden welche Backend-Zugriff für ihre TYPO3 Installation den Umgang mit TYPO3 möglichst einfach und Benutzerfreundlich zu gestalten, wird alles unnötige – was sie halt nicht benötigen – entfernt. So auch bei den Feldern. Verschiedene Plugins wie z.B. tt_news sind sehr Umfangreich und bieten Felder an die der Kunde nicht benötigt. Da es teilweise sehr viele Felder hat, könnte dies den Benutzer nur verwirren, als dass sie ihm was nutzen. Eine möglichkeit diese Felder zu entfernen, ist über die Zugriffsliste. Man bearbeitet eine Gruppe und kann dort bei den Rechten die Zugriffsliste einschränken, somit werden die ausgeschlossenen Felder ausgeblendet.
Was wenn jedoch einige Felder auf verschiedenen Seiten (oder z.B. SysFoldern mit Datensätzen für Plugins) benötigt werden und auf anderen wiederum nicht?

Eine simple Methode ist das auslagern des pageTS in eine oder mehrere Dateien. Diese Dateien können wir im pageTS einbinden.
Und so gehts:

Wir erstellen eine Datei im fileadmin Ordner, wo genau ist egal. Am besten nehmen wir die Endung .ts, auch wenn es sich eigentlich um eine Textdatei handelt, so wissen wir was es ist.
In dieser Datei können wir für jedes Feld das wir nicht haben wollen folgende Zeile einfügen:

TCEFORM.tt_news.author.disabled = 1

Somit wird das Autoren-Feld von tt_news nicht mehr angezeigt. Dies kann für alle Spalten in einer Tabelle gemacht werden, am besten öffnet man noch phpMyAdmin (oder ähnlich) und kopiert dort die Namen der Spalten.
Um ein Feld zu erlauben wird demnach einfach eine “0″ gesetzt.

Damit das ganze seine Wirkung zeigen kann, muss es noch im pageTS eingebunden werden:

<INCLUDE_TYPOSCRIPT: source="FILE:fileadmin/ts/setup/tt_news-fields.ts">

Fertig! Um Felder je nach Ort zu erlauben / verbieten, erstellt man am besten 2 Dateien (für zum erlauben / verbieten) und bindet diese je nach dem ein wo halt die Felder erlaubt oder verboten werden sollen.

pageTS: Seiten TypoScript, zu finden beim bearbeiten einer Hauptseite unter dem Tab “Resources” (Ressourcen).

TYPO3: Problem mit Image-Links nach Update auf 4.5

in TYPO3 von Leo

Nach dem Update auf TYPO3 funktionierten die Image-Links nicht mehr, sofern mehrere Bilder in einem Inhaltselement waren, welche je Einzeln verlinkt werden sollten. Angegeben werden die Links undereinander (je eine Zeile) in einem Textfeld, und sollten dann gesplittet werden. Kurze Zeit später bin ich auf folgendes gestossen: [Klick], welches mich auf die richtige Spur brachte.
Jedoch war es in meinem Fall die Extension SlimBox die das Problem verursacht. Also bearbeitete ich kurz das TypoScript-Setup der genannten Extension, und fügte folgende 2 Zeilen ein:

tt_content.image.20.1.imageLinkWrap.enable.ifEmpty.typolink.parameter.listNum.splitChar = 10
tt_content.image.20.1.imageLinkWrap.typolink.parameter.override.listNum.splitChar = 10

Danach funktionierte alles wieder wunderbar.

Womöglich funktioniert es auch lediglich mit einem Update der SlimBox. Auf der Seite welche dieses Problem existierte war noch eine alte Version installiert (2.1.0), zurzeit ist Version 3.1.0 die aktuellste.

TYPO3: DirectMail – Probleme mit Logfile

17. Juni 2011 in TYPO3 von Leo

In einer TYPO3 Installation hatten wir das Problem, dass wieso auch immer plötzlich DirectMail keine Schreibrechte mehr auf sein eigenes Logfile hatte, weshalb es nicht mehr möglich war Newsletter zu Versenden. Wir erhielten lediglich die Meldung

logfile cannot be written. Quiting directmail sending!

Nach kurzer Zeit war das Problem aber behoben. Es musste lediglich dem Logfile eine Berechtigung von 777 gegeben werden. Zu finden ist das File im typo3temp Verzeichnis unter dem Namen “tx_directmail_dmailer_log.txt”.

Danach funktionierte der Versand wieder bestens.

HTML Select mit Fluid erstellen

31. Mai 2011 in TYPO3 von Leo

Mithilfe von Fluid kann aus einem Array welches wir mit Extbase erstellt haben, ein einfaches HTML Select erstellt werden. Dies funktioniert so:

<f:form.select name="person" property="person" options="{allPersons}"
optionValueField="firstname" optionLabelField="firstname"/>

Kurz erklärt: Wir erstellen aus dem Array “allPersons” (mit geschweiften Klammern als Array gekennzeichnet) die Optionen für das Select. Das OptionValueField ist der Wert der Option welcher schlussendlich als value=”" im Option Tag stehen wird. Mit optionLabelField wird das Label des Option Tags gegeben, also was bei der Auswahl angezeigt wird.

Mit dem “name” und “property” Tag bestimmen wir schlussendlich noch wie das Select heisst, und in welcher Variable die Auswahl gespeichert wird, also im property = person. Diesen Wert würden wir dann mit getter/setter weiterverarbeiten erhalten.

Subqueries in TYPO3 mit TypoScript

20. Januar 2011 in TYPO3 von Leo

In TYPO3 lassen sich per TypoScripts normale Subqueries bilden, wie man sie aus MySQL kennt. Das ganze lernte ich im Zusammenhang mit einem RSS Feed, welchen ich für einen Kunden erstellte. So musste ich mit einer ID welche ich zu beginn über eine Variable von RealURL erhielt in grossen mm_Tables nach nach weiteren ID’s suchen, mit welchen ich dann zum Ziel kam.

Für solche grosse Sprünge in Tabellen nutzten wir dann Subqueries, sozusagen Queries in Queries, welche bis ins unendliche verschachtelt werden können (Achtung Ladezeiten!).

elementxy = CONTENT
elementxy {
        # Die Tabelle die durchsucht wird
        table = tx_extension_unsere_tabelle
        select {
            andWhere {
                # Optional: Eine Variable welche wir mitbekommen (get)
                data = GP:tx_extension_pi1|showUid
                insertData = 1
                wrap = uid IN (SELECT uid_local FROM tx_extension_unsere_tabelle_auth_mm WHERE uid_foreign IN (SELECT uid_foreign FROM tx_extension_unsere_tabelle_head_mm WHERE uid_local = |))
            }
            # Der Sysfolder mit den Datensätzen
            pidInList = 1234
            orderBy = crdate DESC
            max = 15
        }

        renderObj = COA
        renderObj {
            # Das Feld welches vom SELECT ausgewählt wird
            field = title
            # Das Resultat wird gewrappt
            wrap = <item>|</item>
       }
}

Was wird also gemacht?
Zuerst geben wir die Tabelle an welche wir mit dem normalen SELECT auswählen, also SELECT … FROM . Welche Spalte wir ins SELECT werfen wird weiter unten im renderObj.field bestimmt, unser normales SELECT würde also so aussehen:

SELECT title FROM tx_extension_unsere_tabelle ...

Das ist natürlich noch nicht alles. Nach dem normalen SELECT geht es weiter mit dem andWhere aus unserem TypoScript Code. Dieses andWhere Statement hängt eigentlich nur ein WHERE an unseren bisherigen Code und wird dann mit dem Rest was im andWhere steht weitergeführt. Deshalb steht im andWhere auch nicht noch ein SELECT oder ähnlich am Anfang.

Nachdem unser Query mit den Subqueries gebildet wurde, wird mit pidInList die ID unseres Sysfolders angegeben, also der Sysfolder wo die Datensätze gespeichert sind, welche wir hier benötigen. OrderBy und Max sind normale SQL Statements, welche sicherlich jedem bekannt sind.

Danach wird unser Resultat gerendert und in den Wrap geschrieben (dort wo die Pipe “|” ist), wir können das ganze noch z.B. mit HTML Code wrappen.

TYPO3: Immer HTML E-Mails bei Newsletter Anmeldung (sr_email_subscribe)

20. Dezember 2010 in TYPO3 von Leo

Da HTML E-Mails eigentlich mittlerweile sowieso der Standard sind und es nur mehr Aufwand ist einen Newsletter in zwei Formaten zu versenden, gibt es eine sehr simple Möglichkeit immer HTML E-Mails in TYPO3 zu aktivieren, wenn man die Newsletter Anmeldungs Extension sr_email_subscribe (oder irgend eine andere welche auf tt_address aufbaut) nutzt.

Um also HTML E-Mails als Standard zu setzen, gehen wir in unsere Datenbank und suchen die Tabelle “tt_address”. Dort wechseln wir zur Struktur und bearbeiten die Spalte “module_sys_dmail_html”. Dort setzen wir einen Benutzerdefinierten Standardwert, nämlich “1″.

Nun muss lediglich noch im HTML Template die Auswahl entfernt werden sowie im TypoScript das Feld aus den Required Fields nehmen.

TYPO3: Facebook Like Button per TypoScript

8. November 2010 in TYPO3 von Leo

Mittlerweile findet man den Facebook “Like”-Button ja überall. Dazu gibt es auch passende Extensions im TYPO3 Ext Repository, mit welchen man den Like Button sehr einfach einbauen kann. Jedoch waren diese Extensions nur sehr schwer anpassbar (HTML musste im PHP Code angepasst werden) und man muss sie als Plugin manuell auf jeder Seite platzieren – mühsam!
Deshalb fragte ich mich ob es auch eine bessere Variante gibt – sicher, per TypoScript!
Kurz in Google nach einer Variante gesucht und dabei gleich auf folgendes gestossen, klick. Alles in allem kein schlechtes TypoScript Snippet, jedoch nicht geeignet für mich geeignet, was ich nach einer weile feststellen musste, da ich tt_news im Einsatz habe. Wird nun in der SINGLE-Ansicht ein solcher Button platziert, wird jeweils nur die Seite “geliked”, nicht die News mit der ID. Dies durfte so natürlich nicht sein, da der User so immer auf eine falsche Seite mit einer Warnung kommen würde.

Also habe ich den Code etwas angepasst:

lib.facebook = COA
lib.facebook {
	10 = TEXT
	10.typolink.parameter.data = getIndpEnv:REQUEST_URI
	10.typolink.returnLast = url
	10.dataWrap = http://meinedomain.ch|
	10.rawUrlEncode = 1

	wrap = <iframe src="http://www.facebook.com/plugins/like.php?href=|&layout=button_count&show_faces=true&width=450&action=like&colorscheme=light&height=21" scrolling="no" frameborder="0" style="border:none; overflow:hidden; width:450px; height:21px;" allowTransparency="true"></iframe>
}

Es muss noch die baseURL oben angepasst werden. Eigentlich wäre es auch möglich direkt die baseURL zu holen, jedoch habe ich dies im obigen Code nicht gemacht da meine baseURL mit einem Slash (“/”) endet, was schlussendlich einen Doppel-Slash verursachen würde.
Wer die baseURL verwenden möchte ersetzt die Zeile mit folgendem:

10.dataWrap = {TSFE:baseUrl}|

Viel Spass!