Wenn man in dem Seitentitel z.B. HTML-Auszeichnungen nutzen möchte (wie tief- und hochgestellte Zeichen), ist das problematisch, da die HTML-Tags auch in dem Titel des Browsers auftauchen. Als Lösung kann man HTML-Tags im Subtitle verwenden, diesen zum Rendern des Menüs verwenden, der Seitentitel ist dann HTML frei. In einem TMENU braucht man folgende Zeile, der Rest ist wie gehabt:
1 = TMENU
1 {
NO = 1
NO.wrapItemAndSub =
Bei der Benutzung des rgaccordion wird der ausfahrende Content beim zusammengeklappten Akkordeon weiter oben und hinter dem anderen Content angezeigt. Dieser Fehler passiert im IE, wenn man innerhalb des Inhalts, das mit dem Akkordeon auf- und zugeklappt wird, die CSS Anweisung position: relative; verwendet.
Problem: man hat in einen Ordner neue Artikel (tt_news) eingegeben und wundert sich, warum diese nicht auf der Seite erscheinen. Der Cache muss erstmal gelöscht werden. Diesen Vorgang kann man aber automatisieren, dazu folgende Zeile in die PageTSconfig der Storage-Seite reinschreiben:
TCEMAIN.clearCacheCmd = all
Ich brauchte in meinem Fall eine unique ID, um darüber bestimmte Funktionen auszulösen. Eine zufällig generierte ID wäre nicht möglich, weil ich sie zweimal gebraucht hätte, daher als Lösung die ID des übergeordneten Content Elements.
10 = TEXT
10.data = register:tx_templavoila_pi1.parentRec.uid
Der Grund dafür ist einfach. Die Extension is_styleswitcher nutzt eine einfache (selbstgebastelte) JavaScript Funktion, um die Stylesheets zu aktivieren. Dabei wird einfach davon ausgegangen, dass der Tag link nur im Zusammenhang mit Stylesheets bentuzt werden kann. Ein Irrtum. Die Extension metatags nutzt den link-Tag mit der Attribut rev (statt rel), um den Urheber der Seite im Header einzufügen. Und dann knallts beim Ausführen des JavaScript Schnipsels.
Diese Zeile:
if(a.getAttribute(„rel“).indexOf(„style“) != -1 && a.getAttribute(„title“)) {
Wenn man z.B. bei einem FCE für zweispaltigen Content den Header des Elements selbst als Überschrift rendern möchte, muss man ein Feld dafür definieren, was aber im BE nicht angezeigt wird und dann in das DS folgendes reinschreiben/ergänzen: Header
input_h |
10.stdWrap.required = 1
]]>
Die Zeile mit register setzt den Wert aus dem Header-Feld ein und es wird in ein h1-Tag gewrappt, aber nur dann, wenn das Feld auch befüllt ist.
Einen kleinen Nachteil hat der Code schon, falls ein Überschriftentyp ausgewählt ist (wie z.B. Layout 2), dann wird es ignoriert. Es wird immer der h1-Tag verwendet.
Habe in einem Forum gefunden, wie man rg_accordion mit TemplaVoila verwenden kann: http://www.typo3.net/forum/
Eigentlich ganz einfach, wenn mans weiß:
Den Datensatz mit der DS bearbeiten, dort suchen, wo Content Elemente verwendet werden und folgendes einfügen: 10.conf.tt_content < plugin.tx_rgaccordion1
Das reicht schon. Wenn man natürlich noch FCEs verwendet für zweispaltige Layouts oder ähnliches, dann muss man den gleichen Schnipsel in alle FCEs einbauen. Und dann beim Neu-Mappen aufpassen, dass man die bearbeitete DS nicht überschreibt.
Ich komme im Moment nicht zum Schreiben, weil ich grade am Programmieren bin, an einem sehr tollen Plugin, das mindestens genauso viel kann, wie sr_feuser_register. Die Idee dahinter ist eigentlich sehr genial – die Extension läßt sich über TypoScript komplett konfigurieren. So wie bei Direct Mail gibt es die Möglichkeit Templates zu definieren und diese dann in einzelnen Content Elementen zu verwenden. Durch die Konfiguration lassen sich beim Anlegen der Benutzer alle möglichen Werte und Relationen abbilden, Werte generieren (aus Eingabedaten), Dateiupload ist möglich, genauso wie komplexe Validierungsvorgänge. So kann man dem Benutzer beim Anmelden bestimmte Gruppen wählen lassen, um dann eine Standardbenutzergruppe hinzuzufügen und diese dann zusätzlich in einem bestimmten anderen Feld zu speichern – alles eine Frage der Konfiguration. Da die eierlegende Wollmilchsau noch keine Gedanken lesen kann und die Konfiguration schon tricky ist, gibt es auch eine Art Konfigurationswizard.
Heute ein interessantes Problem entdeckt.
Mit einem TYPO3-Mailform-Element lassen sich Formulare erzeugen. Dabei gibt man über einen Wizard- oder in einem Konfigurationsfeld die Felder an, die im Formular dargestellt werden sollen. Mit einem Sternchen vor dem Feld gibt man an, ob das Feld ein Pflichfeld ist. Wenn man das Formular dann absendet, wird ein Alert-Fenster angezeigt, mit der Meldung welche Felder noch ausgefüllt werden sollten.
Mein Formular sah in der Konfiguration etwa so aus:
Name *| *Name=input
Straße * | *Strasse=input
PLZ , Ort * | *PLZ_Ort=input
E-Mail *| *EMail=input
Telefon* | *Telefon=input
Beim Absenden stand in dem Fenster: „Bitte füllen Sie folgende Felder aus: Name *, Straße *, PLZ, EMail“. Das Feld heißt doch „PLZ, Ort“. Außerdem fehlen die Sternchen nach dem PLZ und E-Mail, und wo bleibt Telefon.
Mit einem Kollegen betrachteten wir die Funktion onSubmit im Formular genauer: Es wird die Funktion validateForm aufgerufen mit dem Namen des Formulars und eine kommaseparierten Liste von Feldern, die Pflicht sind. Dabei kommt jedes Feld zweimal vor – als Feld-Name und Label. In der Funktion wird die Liste aufgeteilt und Feld-Name und Label ausgewertet.
Dadurch, dass „PLZ, Ort“ ein Feldname ist, bringt das diese Rechnung total durcheinander und PLZ wird als Feldbezeichnung gewertet, „Ort *“ als Name des nächsten Feldes. Deswegen fehlen die Sternchen und die Rechnung geht nicht auf und das letze Feld fehlt.
Lösung: eigentlich keine, kein Komma im Label benutzen, sondern / oder so.
Neueste Kommentare