Beiträge der Kategorie TYPO3

IE6 Darstellungsfehler beim rgaccordion

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.

Geschrieben in TYPO3 | Kommentare deaktiviert für IE6 Darstellungsfehler beim rgaccordion

Cache beim Ändern löschen

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

Geschrieben in TYPO3 | Kommentare deaktiviert für Cache beim Ändern löschen

TemplaVoila: ID des Content Datensatzes nutzen

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

Geschrieben in TYPO3 | Kommentare deaktiviert für TemplaVoila: ID des Content Datensatzes nutzen

is_styleswitcher klappt nicht mit metatags Extension

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”)) {

ändern in diese:

if(a.getAttribute(“rel”) && a.getAttribute(“rel”).indexOf(“style”) != -1 && a.getAttribute(“title”)) {

Geschrieben in TYPO3 | Kommentare deaktiviert für is_styleswitcher klappt nicht mit metatags Extension

TemplaVoila FCE Header rendern

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.

Accordion und TemplaVoila

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.

Geschrieben in TYPO3 | Kommentare deaktiviert für Accordion und TemplaVoila

Registrierungsextension

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.

Komma in Mailform-Label

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.

Letzen Login anzeigen

Das hier ist ein Konzept, das ich umgesetzt habe, den Quellcode darf/möchte ich (noch) nicht veröffentlichen.
Aufgabenstellung: im Extranet dem Benutzer das Datum seines letzen Logins anzeigen. Problem: Sobald sich ein Benutzer in Typo einloggt, wird automatisch das Datum neu gesetzt, so dass der Benutzer immer den Zeitpunkt vor ein paar Minuten zu sehen bekommt.
Egal wie der Benutzer sich einloggt – newloginbox oder felogin (neu als Systemextension in 4.2), das Einloggen und das Setzen des Wertes findet immer auf Core-Ebene statt. Die felogin bietet zwar eine Möglichkeit für einen Hook an, da ist das Setzen des Wertes aber schon passiert und auf den alten Wert kann man nicht mehr zugreifen.
Um das Problem zu lösen, braucht man in der fe_users Tabelle zwei weitere Felder – ein Backup-Feld für lastlogin und ein Feld mit dem tatsächlichen letzen Login, nennen wir sie mal ll_bkp und real_ll.
Bei Login-Vorgang passiert folgendes: Ganz am Anfang auf Core-Ebene wird der Benutzer eingeloggt, der Wert lastlogin wird gesetzt. Wenn die Extension aufgerufen wird, wird aus dem Backup (der ist noch der alte) der Wert ins Real-Last-Login übertragen, und das Backup mit dem neuen lastlogin-Wert (der aktuelle Zeitpunkt) überschrieben. Warum braucht man das Backup-Feld? Weil man keine Möglichkeit hat, das lastlogin vor dem Überschreiben irgendwie zu sichern. Und das macht man “manuell” in der Extension.
Natürlich muss sich der Benutzer mindestens zweimal einloggen, damit im real_ll ein vernünftiger Wert steht (ist aber auch so logisch).
Wann kann man das einbauen? Man kann den Hook in der newloginbox oder felogin nutzen, um den eben beschriebenen Kopiervorgang auszuführen. Das wird dann beim Einloggen einmal ausgeführt. Das mit dem Hook klappt leider nicht, wenn die Login-Seite die Eigenschaft gesetzt hat, beim Einloggen ausgeblendet zu werden und stattdessen die Logout-Seite angezeigt wird. Da kommt es nach dem Einloggen gar nicht erst zur Ausführung des felogin/newloginbox Codes und des dazugehörigen Hooks.
Da besteht die Möglichkeit, die Extension auf jeder Seite einzubinden und die Werte nur dann zu kopieren, wenn ein Benutzer eingeloggt ist und das Backup sich vom lastlogin-Wert unterscheidet. Sobald man es einmal kopiert hat, ist es nicht mehr der Fall. Die Werte, die man zum Vergleichen benötigt stehen praktischerweise direkt im GLOBALS Objekt, das beim Einloggen mit allen in der Datenbank verfügbaren Daten des Benutzerdatensatzes geladen wird.

Flexforms (Part 1)

Bei der Entwicklung von eigenen Extensions arbeite ich im BE fast nur noch mit Flexforms – es ist wirklich toll, dass man damit fast alles an Eingaben realisieren kann. Ich wollte mal ein paar sinnvolle Schnipsel zusammenstellen, wie man bestimmte Sachen definiert, ansonsten muss man in tt_news nachschauen (wunderbares Beispiel) und in anderen Extensions, wenn man was bestimmtest benötigt.
Wenn man den Kickstarter nutzt, dann wird gleich das richtige Grundgerüst definiert, aber hier ist es nochmal:




1






Die Sheets werden in Typo3 in Form von Reitern dargestellt. Ein Sheet kann einen beliebigen Namen haben (würd ich behaupten), der Kickstarter erzeugt eines, das sDEF heißt. Darin befindet sich ein Element namens ROOT und darin wird in TCEforms der Inhalt des Sheets definiert.




LLL:EXT:np_content_slideshow/locallang_db.xml:ff.settings

array






Innerhalb des el-Elements (ist vom Typ Array) können nun unterschiedliche Felder definiert werden. Der Name dieser Felder ist beliebig (darf keine Leer- und Sonderzeichen enthalten), darüber kann der Wert der Felder im Plugin in der PHP-Klasse ausgelesen werden.
Hier ist z.B. eine Checkbox:



1


check




Der Wert heißt “random” und kann im BE (MVC-Style) wie folgt ausgelesen werden:

$random = intval($this->configurations->get(‘random’));

Ich habe mit das irgendwie so angewöhnt, die Locallang-Wert mit ff. zu versehen, damit man erkennt, dass es in den Flexforms verwendet wird.
Reicht für heute 🙂

Geschrieben in TYPO3 | Kommentare deaktiviert für Flexforms (Part 1)