Typo3 Probleme die ich einfach nicht gelöst bekomme

[Anton]

Morgen,

vorab schon mal sorry… hab SEHR viel geschrieben. Wäre trotzdem super wenn ihr mir helfen würdet.

Wie schon seid einigen Wochen bin ich nach wie vor mit Typo3 am kämpfen. Anfangs wollte ich alles gleich perfekt machen, sprich ich wollte gleich erreichen, dass die Webseite Barrierefrei wird und des weiteren sogar noch eine schöne Formatierung des Quellcodes erreichen. Aufgrund der Komplexität hab ich mich jetzt dafür entschieden, dass ich zunächst  was die reine Optik angeht meine händische Seite auf Typo3 nachbauen will. Im nächsten Schritt geht’s dann daran die Seite hinsichtlich der Barrierefreiheit und hinsichtlich der Formatierung des Quellcodes zu verbessern. Bei dem Nachbauen der Webseite bin ich immer wieder auf Probleme gestoßen. Besondere Probleme bereiten mir die folgenden fünf Fragen. Hier komme ich alleine und auch mit Google leider nicht weiter:

1.)
Über das Inhaltselement "Mail-Formular" habe ich meiner Webseite ein Kontaktformular hinzugefügt. Das Problem liegt nun in der Formatierung des Formulars. Die Elemente werden nicht sauber formatiert angezeigt. Außerdem enthält das Kontaktformular einen störenden Rahmen. Leider kann ich immer noch nicht so richtig die Funktion von css_styled_content nachvollziehen. css_styled_content ist anscheinend eine extension, mit deren Hilfe der Quellcode für die Inhaltselemente erzeugt sowie dessen CSS-Formatierung generiert wird. Da mein Mail Formular nicht richtig formatiert wird, liegt die Ursache wohl in css_styled_content. Demnach muß ich dann wohl zunächst in der Konfigurationsdatei (setup.txt) von css_styled_content nach dem Teil suchen, der für die Formatierung verantwortlich ist. Genau hier hackt es dann schon das erstemal. Da mir nicht so 100% klar ist, wann css_styled_content aufgerufen wird, ob es nur für die Erzeugung der CSS-Formatierung zuständig ist, oder ob es auch den HTML-Quellcode generiert, weiß ich nicht so wirklich wonach ich in setup.txt suchen muß, damit ich die Stelle finde, die für die Formatierung von meinem Kontaktformular verantwortlich ist. Naja, vielleicht könnt ihr mir den Zusammenhang nochmals ein bißchen erläutern. Angenommen ich habe die Stelle in der setup.txt gefunden die für die Formatierung des Kontaktformulars verantwortlich ist. Im meinem root-Template muß ich dann wohl dafür sorgen, dass das Formular ordentlich formatiert wird?

2.)
In meiner händischen Webseite existieren verschiedene Arten von Listen. Zunächst die Standardlisten und des weiteren Listen die Paragraphen enthalten. Die Listen die die Paragraphen enthalten sollen keine führenden Punkte besitzen. Demnach habe in der händischen erstellten Seite diesem Listentyp die Klasse "paragraphList" zugeordnet. Hier ist mir nicht so klar, wie ich die Umsetzung auf Typo3 durchführe. Diese Listen sind ja Bestandteile des Inhalts. Ich muß also auch einem Redakteur die Möglichkeit geben solch eine Liste anzulegen. Damit diese vom Redakteur angelegte Liste auch die richtige Formatierung enthält, muß Typo3 irgendwie dafür sorgen, dass beim generieren des Codes dieser Liste die Klasse "paragraphList" zugeordnet wird. Nur dann kann mein CSS die Liste entsprechend formatieren. Ich hab nun absolut keine Ahnung, wie ich erreichen kann, dass ein Redakteur über das RTE dieser Liste eine Klasse zuordnen kann.

3.)
Momentan habe ich die Überschriften h1, h2 und h3 nicht im RTE eingeblendet. Das liegt daran, dass der Titel der Internetpräsenz h1 zugeordnet ist. Dieser Titel ist im HTML-Template fest verankert. Der Seitentitel der aktuellen Seite wird ebenfalls automatisch gesetzt. Der entsprechende Wert wird aus dem Navigationsbaum ausgelesen. h3 schließlich ist ebenfalls nicht über den RTE festlegbar, da h3 auch automatisch gesetzt wird. h3 spiegelt die Überschrift des jeweiligen Inhaltselementes wieder. Nun ist es aber so, dass ich auf den meisten Seiten keine Überschrift für die Inhaltselemente vergeben habe. Demnach überlege ich gerade, ob es überhaupt sinnvoll ist, h3 für die Inhaltselemente zu reservieren, oder ob es besser wäre h3 im RTE zugänglich zu machen und außerdem dafür zu sorgen, dass eventuell doch gesetzte Überschriften von Inhaltselementen nicht angezeigt werden. Meine Vorstellung momentan ist folgende. Haben die Inhaltselemente meistens keine Überschriften, dann wird h3 auch sehr selten im Quelltext vorkommen. Wirkt es sich nachteilig auf die Google-Indexierung aus, wenn h3 selten bis gar nicht im Quelltext vorkommt. Es geht dann halt erst wieder mit h4 weiter. h3 fehlt fast komplett.

4.)
Im RTE gibt es die Möglichkeit das Symbol "Formatierung entfernen" einzublenden. Damit hat man dann die Möglichkeit die html-Formatierung bzw. die Word-Formatierung zu entfernen bzw. Bilder und HTML-Tags zu entfernen. Hier sind mir nicht alle Funktionen so ganz klar. Das mit der Word-Formatierung kann ich ja noch so halbwegs nachvollziehen: Eine Redakteur hat einen Texte auf Word vorbereitet. Per Copy&Paste fügt er ihn in den RTE ein. Damit das Speichern in der Datenbank funktioniert, müssen zunächst alle Word-Formatierungen entfernt werden. Anschließend muß der gesamte Text mit den vorhandenen Elementen in der Symbolleiste korrekt ausgezeichnet werden. Das versteh ich auch nicht so richtig: Dann könnte ich dem Redakteur doch gleich sagen, dass er die Texte direkt im RTE schreiben soll bzw. in einem Editor der keine Formatierung speichert. Ein ähnliches Verständnisproblem für den Button "HTML-Formatierung entfernen". Warum sollte man einen Text mit HTML-Formatierung in den RTE kopieren? Den Sinn der beiden letzen Buttons "html-Tags entfernen" und "Bilder entfernen" kann ich gar nicht nachvollziehen.

5.)
Wenn mir die ersten vier Fragen klar sind, muß ich nurnoch meine Startseite hinbekommen. Dann würde meine Typo3-Seite genauso, wie meine händisch erstellte, aussehen. Danach ginge es dann an die Barrierefreiheit und die schöne Formatierung des Quellcodes.

Meine händisch erstellte Startseite besitzt grob das folgende Aussehen:

Oben eine Überschrift. Unter der Überschrift befindet sich ein Foto. Rechts neben diesem Foto befindet sich, horizontal bezogen auf das Foto zentriert, die Beschreibung des Fotos. Diese Beschreibung umfasst drei Zeilen. Unter dem Foto befindet sich eine Aufzählungsliste.

Was die Umsetzung angeht stelle ich mir das folgendermaßen vor:

Die Überschrift der Seite (h2) wird automatisch aus der Seitenstruktur bezogen. Des weiteren enthält die Seite zwei Inhaltselemente. Das wären einmal "Bild mit Text" und einmal "Auszählungsliste".  Hier hört es dann leider schon auf mit meinem Überlegungen. Das Hauptproblem macht mir natürlich das Inhaltselement "Bild mit Text". Anscheinend muß ich ja css_styled_content entsprechend modifizieren, da solch eine Anordnung defaultmäßig nicht vorgesehen ist. Ich bin zwar ständig am überlegen wie ich das lösen könnte, finde aber leider keinen optimalen Weg. Das liegt wahrscheinlich auch daran, dass ich noch nicht so richtig verstanden hab wann css_styled_content überhaupt aufgerufen wird, und was es eigentlich genau macht.

Wie wäre das grundsätzliche Vorgehen um die Startseite zu bauen.

[suit]

Morgen,

vorab schon mal sorry… hab SEHR viel geschrieben. Wäre trotzdem super wenn ihr mir helfen würdet.

Wie schon seid einigen Wochen bin ich nach wie vor mit Typo3 am kämpfen.

TYPO3 ist sehr komplex, die Tiefen lernt man erst nach und nach - das kann uu. einige Monate dauern :)

Anfangs wollte ich alles gleich perfekt machen, sprich ich wollte gleich erreichen, dass die Webseite Barrierefrei wird und des weiteren sogar noch eine schöne Formatierung des Quellcodes erreichen.

Alles perfekt machen will jeder, aber spätestens nach dem 2. Versuch "alles perfekt zu machen" wirst du feststellen, dass es immer Verbesserungsmöglichkeiten gibt :)

Aufgrund der Komplexität hab ich mich jetzt dafür entschieden, dass ich zunächst  was die reine Optik angeht meine händische Seite auf Typo3 nachbauen will. Im nächsten Schritt geht’s dann daran die Seite hinsichtlich der Barrierefreiheit und hinsichtlich der Formatierung des Quellcodes zu verbessern.

Das ist hingegen schlauer als alles auf einmal

1.)
Im meinem root-Template muß ich dann wohl dafür sorgen, dass das Formular ordentlich formatiert wird?

Verwende die Extension th_mailformplus - da kann der Endbenutzer zwark eine Formulare zusammenklicken, aber man kann (X)HTML exakt wie gewünscht aus dem Template beziehen und sein eigenes CSS verwenden ohne css_styled_content umgraben zu müssen.

Ich hab nun absolut keine Ahnung, wie ich erreichen kann, dass ein Redakteur über das RTE dieser Liste eine Klasse zuordnen kann.

Das hat vermutlich etwas damit zu tun, dass das über TSConfig eingesetllt wird und nicht über TypoScript und du damit wahrscheinlich noch nichts zu tun hattest. Die Sache ist etwas Tricky, aber durchaus bewältigbar, wenn mans vestanden hat. Hier am Beispiel einer Tabellenzelle:

TSConfig:
RTE.default {
  contentCSS = fileadmin/template/css/rte.css
  classesTD = foo, bar
  proc.classesTD < .classesTD
}

im rte.css

td.foo {  
		background: #8080FF;  
}  
  
td.bar {  
		background: #FF8080;  
}  

3.)

Das Problem hat nichts mit TYPO3 zu tun, es kommt lediglich auf deine Texte und die Gliederung dieser drauf an - "diese h1 = Titel der Webpräsenz, h2 = Menüpunkt, h3 = Untertitel und Inhaltselemente"-Geschichte ist nur eine Faustregel - wenn es nicht in dein Schema passt, mach es anders.

4.)
Das versteh ich auch nicht so richtig: Dann könnte ich dem Redakteur doch gleich sagen, dass er die Texte direkt im RTE schreiben soll bzw. in einem Editor der keine Formatierung speichert.

Der Kunde, dem du das Erklärst, wird dich töten. Da schreibt die Sekretärin A den Text im Word (diktiert vom Chef), schickt ihn per Mail an Marketingtante B, die ihn an Assistent C weitergibt, der ihn dann von Student D ins TYPO3 einfügen lässt. Wenn du diese Funktion nicht benötigst, kannst du sie ausblenden - für den täglichen Geschäftsbetrieb ist sie aber idR sinnvoll.

Ein ähnliches Verständnisproblem für den Button "HTML-Formatierung entfernen". Warum sollte man einen Text mit HTML-Formatierung in den RTE kopieren? Den Sinn der beiden letzen Buttons "html-Tags entfernen" und "Bilder entfernen" kann ich gar nicht nachvollziehen.

Wie bereits oben erwähnt, Sinn hinter diesen Dingen steht, brauchst du nicht hinterfragen - es gibt diese durchaus. z.B. stellt die Geschäftsleitung neue AGB ins Intranet und diese sollten in die Website (getrenntes System) kopiert werden. Bilder entfernen kann dann Sinnvoll sein, wenn du z.B. Texte aus Foren/Boards oder Instant Messengern kopierst und die Smilies entfernen willst.

Lösung: wenn du der einzige bist, der damit arbeitet: Weg mit dem Button. Wenn du das Zeug an Kunden verkaufst, lass es drin, man weiß nie was die vorhaben.

5.)
Die Überschrift der Seite (h2) wird automatisch aus der Seitenstruktur bezogen. Des weiteren enthält die Seite zwei Inhaltselemente. Das wären einmal "Bild mit Text" und einmal "Auszählungsliste".  Hier hört es dann leider schon auf mit meinem Überlegungen. Das Hauptproblem macht mir natürlich das Inhaltselement "Bild mit Text". Anscheinend muß ich ja css_styled_content entsprechend modifizieren, da solch eine Anordnung defaultmäßig nicht vorgesehen ist. Ich bin zwar ständig am überlegen wie ich das lösen könnte, finde aber leider keinen optimalen Weg. Das liegt wahrscheinlich auch daran, dass ich noch nicht so richtig verstanden hab wann css_styled_content überhaupt aufgerufen wird, und was es eigentlich genau macht.

Wie wäre das grundsätzliche Vorgehen um die Startseite zu bauen.

Das von dir beschriebene vorgehen ist so ansich in Ordnung - das mit dem Modifizieren von css_styled_content ist, wenn mans begriffen hat, nicht mehr wirklich schwierig. TypoScript ist ein gigantisches PHP-Array, nur ist die schreibweise etwas anders.

Du kannst also auf deiner Startseite sämtliche Angaben überschreiben, ohne den Rest deiner Präsenz zu beeinflussen.

Wurzelseite (id 1, shortcut auf 2, hat die allgemeine Formatierung/Template usw)
  Startseite (id 2, hat anderes TypoScript, anderes CSS)
  Seite 1
  Seite 2

[Anton]

zu 1.)
Ist "th_mailformplus" grundsätzlich eher zu empfehlen als das Standard Kontaktformular, oder sollte man nachdem man das Modifizieren von css_styled_content beherscht wieder auf das Default Kontaktformular zurückgreifen?

zu 2.)
Ich habe folgendes in das TSConfig-Feld meiner root-Seite eingetragen:

RTE.default {
contentCSS = fileadmin/css/main.css
classesTD = paragraphList
   proc.classesTD < .classesTD
}

Die RTE-Extension habe ich auf "Typical" gestellt.

In der ersten Zeile gebe ich den Pfad zu meiner CSS-Datei an. Diese CSS-Datei enthält die Formatierung für die Klasse paragraphList. In der zweiten Zeile gebe ich den Namen der Klasse an die im RTE auswählbar sein soll. Dies dritte Zeile "proc.classesTD < .classesTD" kann ich nicht nachvollziehen. Kannst du mir sagen welchen Sinn sie hat?

Eigentlich würde ich die Auswahl "paragraphList" jetzt im RTE-Element Textstil erwarten. Das blöde ist, dass ich das nicht nachprüfen kann. Nachdem ich den Code in das TSConfig-Feld geschrieben habe ist das Element Textstil im RTE plötzlich deaktiviert.

In welchem RTE-Element sollte die Klasse "paragraphList" denn auftauchen? Wie von mir vermutet im RTE-Feld Textstil?

zu 3.)

Das Problem hat nichts mit TYPO3 zu tun, es kommt lediglich auf deine Texte und die Gliederung dieser drauf an - "diese h1 = Titel der Webpräsenz, h2 = Menüpunkt, h3 = Untertitel und Inhaltselemente"-Geschichte ist nur eine Faustregel - wenn es nicht in dein Schema passt, mach es anders.

Du schreibst "UNTERTITEL und Inhaltselemente". Untertitel sind doch was anderes als Inhaltselemente. Den Untertitel lege ich für das Seitenobjekt direkt fest, während ich die Überschriften der Inhaltselemente für die Inhaltsobjekte festlegte. Das Seitenobjekt setzt sich wiederrum aus den Inhaltsobjekten zusammen. Demnach müßte man h3 entweder dem UNTERTITEL oder dem Inhaltselement zuordnen. Hab ich da was falsch verstanden, oder müßte die Aussage "Untertitel ODER Inhaltselemente" statt "Untertitel UND Inhaltselemente" lauten?

Außerdem schreibst du "wenn es nicht in dein Schema passt, mach es anders.". Ich frage mich gerade wie ein Schema aussehen könnte, in welchem es sinnvoll ist h3 den Inhaltselementen zuzuordnen. Im allgemeinen hat ja jede html-Seite einen Überschrift. In meinem Fall nehme ich diese aus der Navigation und ordne ihr h2 zu. Angenommen in solch einer Seite befindet sich ein Text mit 30 Abschnitten. Jeder dieser Abschnitte hat eine Überschrift die in der Hierarchie direkt unter h2 folgt. Um das umzusetzen könnte ich entweder 30 Inhaltselemte vom Typ Text einfügen und jedem dieser Inhaltselemente die entsprechende Überschrift zuordnen. Das wäre natürlich super viel Aufwand. Alternativ könnte ich hingehen und nur ein Inhaltselement vom Typ Text erstellen. Ich würde h3 im RTE zulassen und dafür sorgen, die Inhaltselemente nicht hinsichtlich ihrer Überschrift berücksichtigt werden. Unter diesen Gesichtpunkten verstehe ich nicht wie der empfolene Weg, die Inhaltselemente bezüglich ihrer Überschrift zu berücksichtigen, in der Praxis einen Sinn macht? Der empfolene Weg sollte doch eigentich durchdacht sein. Demnach hab ich wohl irgendwas mißverstanden. Hast du hier vielleicht ein Beispiel durch welches ich den Sinn des empfohlenen Weges besser nachvollziehen kann?

zu 5.)

Das von dir beschriebene vorgehen ist so ansich in Ordnung - das mit dem Modifizieren von css_styled_content ist, wenn mans begriffen hat, nicht mehr wirklich schwierig. TypoScript ist ein gigantisches PHP-Array, nur ist die schreibweise etwas anders.

Du kannst also auf deiner Startseite sämtliche Angaben überschreiben, ohne den Rest deiner Präsenz zu beeinflussen.

Wurzelseite (id 1, shortcut auf 2, hat die allgemeine Formatierung/Template usw)
  Startseite (id 2, hat anderes TypoScript, anderes CSS)
  Seite 1
  Seite 2

Dann würde ich das jetzt so machen. Zunächstmal weiß ich ja, dass ich das Inhaltselement "Text mit Bild" nutzen möchte. Über das Backend setzte ich den Pfad zum Bild un die zugehörige Bildunterschrift. Das Bild lasse ich links positionieren. Denn Text lasse ich rechts um das Bild herumfließen. Das eigentliche Textfeld bleibt leer. mmm, wenn das Textfeld leer bleibt, dann brauch ich doch eigentlich nicht "Text mit Bild" sondern könnte doch stattdessen auch nur "Bild" benutzen. Die Beschreibung des Bildes kann ich ja über dessen Bildunterschrift festlegen. Demanch brauch ich das Textfeld nicht.

Naja wie auch immer. Egal ob ich mich jetzt für "Text mit Bild" oder für "Bild" entschieden habe, als nächstes lasse ich mir die Seite generieren und schaue mir den Quellcode an. Mit Firebug hab ich die Stelle im Code Ausfinding gemacht die für die Darstellung des Bildes mit seiner Beschreibung verantwortlich ist. Das ist der Kram mit den Definitionslisten. Das Bild wird ja defaultmäßig von css_styled_content irgendwie in eine verschchtelte Definitionsliste gepackt. Jetzt kommen die großen Schwierigkeiten:

Such ich jetzt einfach nach <dt> in der setup.txt? Falls ja, woher weiß ich welches der vielen <dt>s die ich finde das ist, das für die Erzeugung meines Quellcodes verantwortlich ist.

Angenommen ich hab die richtige Stelle in der setup.txt ausfindig gemacht. Dann geht es ja jetzt daran den Kram in dem Erweiterungstemplate meiner Startseite zu überschreiben. Ich wäre dieser super dankbar, wenn du mir hier vielleicht bespielhaft den TypoScript Code zeigen könntest, durch den das Layout das ich haben möchte erzeugt wird.

[suit]

zu 1.)
Ist "th_mailformplus" grundsätzlich eher zu empfehlen als das Standard Kontaktformular, oder sollte man nachdem man das Modifizieren von css_styled_content beherscht wieder auf das Default Kontaktformular zurückgreifen?

Ich verwende grundsätzlich mailformplus

zu 2.)

Dies dritte Zeile "proc.classesTD < .classesTD" kann ich nicht nachvollziehen. Kannst du mir sagen welchen Sinn sie hat?

Ja, sie kopiert zweiteres in ersteres um nicht alles doppelt schreiben zu müssen.

Eigentlich würde ich die Auswahl "paragraphList" jetzt im RTE-Element Textstil erwarten.

Nur für Tabellenzellen, für andere Elemente nicht.

In welchem RTE-Element sollte die Klasse "paragraphList" denn auftauchen? Wie von mir vermutet im RTE-Feld Textstil?

Versuchs mal mit den Eigenschaften einer Tabellenzelle.

zu 3.)
Hab ich da was falsch verstanden, oder müßte die Aussage "Untertitel ODER Inhaltselemente" statt "Untertitel UND Inhaltselemente" lauten?

ODER (OR) schließt UND (AND) nicht aus - es ist ja kein exklusives, logisches ODER (XOR) :)

Außerdem schreibst du "wenn es nicht in dein Schema passt, mach es anders.". Ich frage mich gerade wie ein Schema aussehen könnte, in welchem es sinnvoll ist h3 den Inhaltselementen zuzuordnen.

Ich weiß nicht wie deine Texte aussehen, da kann ich dir nicht helfen.

Im allgemeinen hat ja jede html-Seite einen Überschrift. In meinem Fall nehme ich diese aus der Navigation und ordne ihr h2 zu. Angenommen in solch einer Seite befindet sich ein Text mit 30 Abschnitten. Jeder dieser Abschnitte hat eine Überschrift die in der Hierarchie direkt unter h2 folgt. Um das umzusetzen könnte ich entweder 30 Inhaltselemte vom Typ Text einfügen und jedem dieser Inhaltselemente die entsprechende Überschrift zuordnen. Das wäre natürlich super viel Aufwand.

Sehe ich nicht so, wenn es 30 Abschnitte sind, warum nicht 30 Inhaltselemente? Was ist, wenn du die Reihenfolge der Abschnitte ändern willst? Oder nur einen Abschnitt bearbeiten willst? Einzelne Inhaltselemente sind genau für diesen Zweck äußerst cool.

Alternativ könnte ich hingehen und nur ein Inhaltselement vom Typ Text erstellen. Ich würde h3 im RTE zulassen und dafür sorgen, die Inhaltselemente nicht hinsichtlich ihrer Überschrift berücksichtigt werden.

Ja und keine automatisch vergegebenen IDs für die Abschnitte (zum Anspringen per Anker aus dem Inhaltsverzeichnis), jedes mal den kompletten Text bearbeiten wenn man doch nur 3 Zeilen haben will.

Der empfolene Weg sollte doch eigentich durchdacht sein. Demnach hab ich wohl irgendwas mißverstanden. Hast du hier vielleicht ein Beispiel durch welches ich den Sinn des empfohlenen Weges besser nachvollziehen kann?

http://suit.rebell.at/index.php?id=14 (Ja, Zeichencodierungsproblem - mein Fehler, grade keine Zeit/Lust das zu fixen :p)
user: suit
pass: rebell

Sämtliche h3-Elemente (mit Ausnahme "Inhaltsverzeichnis") sind überschriften von einzelnen Inhaltselementen und werden dafür genutzt ein automatisches Inhaltsverzeichnis zu erzeugen.

zu 5.)
Such ich jetzt einfach nach <dt> in der setup.txt? Falls ja, woher weiß ich welches der vielen <dt>s die ich finde das ist, das für die Erzeugung meines Quellcodes verantwortlich ist.

Das TypoScript in setup.txt ist ein Baum (ein mehrdimensionales Array) suche das dt-Element, welches in deinem Wunschinhaltselement (CType) genutzt wird. Zeile 462, # CType: textpic ist z.B. "Text mit Bild".

Angenommen ich hab die richtige Stelle in der setup.txt ausfindig gemacht. Dann geht es ja jetzt daran den Kram in dem Erweiterungstemplate meiner Startseite zu überschreiben.

Ja.

Ich wäre dieser super dankbar, wenn du mir hier vielleicht bespielhaft den TypoScript Code zeigen könntest, durch den das Layout das ich haben möchte erzeugt wird.

Angenommen du hast das hier gefunden und du willst lieber ein Klassenloses h3-Element stat dem div-Element

tt_content.textpic.20.text.10.stdWrap.dataWrap = <div class="csc-textpicHeader csc-textpicHeader-{field:imageorient}">|</div>

Ersetze es durch das hier:
tt_content.textpic.20.text.10.stdWrap.dataWrap = <h3>|</h3>

Vorkauen kann ich die die Sachen nicht - es wäre aber ggf. hilfreich, wenn du dich einfach damit beschäftigst und ausprobierst, welche Stelle worauf welchen Effekt hat.

Sieht dir z.B. mal den CType "bullet" an - das ist das Listeninhaltselement, hier wird einfach eine Funktion aus der Klasse tx_cssstyledcontent_pi1 aufgerufen. Anhand dieser Geschichte kannst du dir realtiv einfach abschauen, wie was passiert.

[Anton]

zu 1.)

Ich habe die Extension mailformplus installiert. In das Template habe ich folgends gepackt:

  
<form action="#" method="post">  
	<table>  
		<tr>  
			<td class="tableColumnOne">Nachname*:</td>  
			<td>  
				<input type="text" name="nachname" value=""/>  
			</td>  
		</tr>  
		<tr>  
			<td>Vorname*:</td>  
			<td>  
				<input type="text" name="vorname" value=""/>  
			</td>  
		</tr>  
		<tr>  
			<td>Firma:</td>  
			<td>  
				<input type="text" name="firma" value=""/>  
			</td>  
		</tr>  
		<tr>  
			<td>Straße + Hausnummer:</td>  
			<td>  
				<input type="text" name="strasse" value=""/>  
			</td>  
		</tr>  
		<tr>  
			<td>PLZ + Ort:</td>  
			<td>  
				<input type="text" name="ort" value=""/>  
			</td>  
		</tr>  
		<tr>  
			<td>Telefon:</td>  
			<td>  
				<input type="text" name="telefon" value=""/>  
			</td>  
		</tr>  
		<tr>  
			<td>E-Mail*:</td>  
			<td>  
				<input type="text" name="email" value=""/>  
			</td>  
		</tr>  
		<tr>  
			<td class="tableVerticalAlign">Anfrage*:</td>  
			<td>  
				<textarea class="tableTextbox" rows="12"  cols="60" name="text"></textarea>  
			</td>  
		</tr>  
		<tr>  
			<td>Formular:</td>  
			<td>  
				<input class="tableButtonDelete" type="reset" value="löschen"/>  
				<input class="tableButtonSend" type="submit" name="abschicken" value="absenden"/>  
			</td>  
		</tr>  
	</table>  
</form>  

Ich würde nun gerne noch folgendes einbauen. Leider finde ich in der mitgelieferten Anleitung nicht die Lösung für diese Probleme:

• Durch das Betätigen von "absenden" soll die E-Mail versand werden. Wie und wo kann ich denn die E-Mail festlegen an die die Anfrage gesand werden soll?

• die mit * gekennzeichneten Felder sollen zu Pflichtfeldern werden. Wie kann ich das umsetzen?

• Nach dem Absenden soll eine Bestätigungsseite, dass die E-Mail versand wurde, angezeigt werden. Wie ist das möglich?

Eine neue Frage habe ich auch noch. Wir hatten ja damals schonmal über die Webshoperweiterungen von Typo3 gesprochen. Das Thema ist jetzt wieder konkret. Ich benötige einen Webshop. Nun bin ich mir unsicher ob ich eine der beiden Typo3 Extensions verwenden soll, oder ob ich besser auf xt:commerce bzw. os:commerce ausweichen soll. Meine Anforderungen sind folgende. In Zukunft werde ich wahrscheinlich nie besonders große Webshops bauen müssen. Demnach die Frage an dich. Denkst du für kleinere Webshops werden die Typo3 Extensions ausreichen oder sollte ich in jedem fall auf xt:commerce bzw. os:commerce ausweichen? Falls du mir zu einem Typo3 Webshop raten solltest... welcher ist eher zu empfehlen: tt_products-Extension oder tt_commerce-Extension?

[suit]

Ich habe die Extension mailformplus installiert. In das Template habe ich folgends gepackt:

URGS! Warum denn diese Tabellengeschichte? :)

• Durch das Betätigen von "absenden" soll die E-Mail versand werden. Wie und wo kann ich denn die E-Mail festlegen an die die Anfrage gesand werden soll?

In den Plugin-Einstellungen (das Content-Element im Backend).

• die mit * gekennzeichneten Felder sollen zu Pflichtfeldern werden. Wie kann ich das umsetzen?

Ebenda

• Nach dem Absenden soll eine Bestätigungsseite, dass die E-Mail versand wurde, angezeigt werden. Wie ist das möglich?

Entweder über das Plugin (siehe oben) oder über ein Locallang-File, welches die Textinformation beinhaltet, welche dann mittels TypoScript gelesen wird (zweitere Variante bevorzuge ich).

Wenn der Shop nicht viele Sonderlösungen hat, ist commerce sicher ausreichend, tt_products ist imho eher uncool.

[Anton]

URGS! Warum denn diese Tabellengeschichte? :)

Hab mich da an die Beispiele in selfhtml gehalten. Dort setzen die Formulare eigentlich immer mit Tabellen um. Gibt es in selfhtml auch irgendein Artikel der beschreibt, wie man Formulare ohne Tabellen erstellt? Für einen Link wäre ich dankbar. Finde dazu nur Mist.

Unter Inhaltselement ==> Plugin ==> E-Mail Optionen habe ich bei Empfänger die E-Mail-Adresse des Empfängers eingetragen. Bei Redirect-Seite habe ich eine Seite angegeben die nach dem erfolgreichen Versand der E-Mail angezeigt werden soll. Des weiteren habe ich die Namen der Pflichtfelder Kommasepariert im Feld Pflichtfelder eingetragen. Trotzdem funktioniert keine der drei Sachen. Weder der Versand der E-Mail bzw. der anschließende Aufruf der Redirectseite noch eine Fehlermeldung wenn ich die Pflichtfelder nicht ausfülle. Ne Ahnung woran das liegen könnte?

»» Wenn der Shop nicht viele Sonderlösungen hat, ist commerce sicher ausreichend, tt_products ist imho eher uncool.

Zum Glück hab ich nochmal gefragt. Hätte mich fast für tt_products entschieden, da es hierzu mehr Dokumentationen und sogar ein Buch gibt. Nach deiner Aussprache für commerce habe ich ein bißchen weitergeforscht und folgendes gefunden: "Die typo3-Shopextension Commerce ist mittlerweile in der 0.9.8. erhältlich. Immer noch recht neu. Aber von den Möglichkeiten wird es tt_products wahrscheinlich mittelfristig den Rang ablaufen."

Im Prinzip habe ich mich für commerce entschieden. Das einzige was mir etwas Kopfzerbrechen bereitet ist die recht dürftige Dokumentation. Das einzige was ich bisher gefunden habe ist diese:

Tutorial commerce

Ist jetzt nicht super ausführlich. Ich will mal hoffen, dass ich nicht wegen fehlender Dokumentation in eine Sackgasse gerate. Kennst du vielleicht noch ein gutes Tutorial? Am besten ein sehr praxisbezogenes. Die in typo3.org hinterlegten sind meistens ziemlich kurz und auch nicht sonderlich verständlich. Das sie dann noch in Englisch sind gibt mir dann den Rest. Englisch ist im Prinzip nicht schlimm sollte aber dann wenigstens ein gutes Tutorial sein.

Du schreibst das du tt_products eher "UNCOOL" findest. Was ist denn so uncool daran bzw. was findest du besser an commerce?

[suit]

Hab mich da an die Beispiele in selfhtml gehalten. Dort setzen die Formulare eigentlich immer mit Tabellen um. Gibt es in selfhtml auch irgendein Artikel der beschreibt, wie man Formulare ohne Tabellen erstellt? Für einen Link wäre ich dankbar. Finde dazu nur Mist.

Da bin ich überfragt, aber im Archiv finden sich einige diskussionen (an denen auch ich beteiligt war) die sich mit tabellenlosen Formularen (und auch dem Für und Wider) auseinandersetzen.

Ne Ahnung woran das liegen könnte?

Nein, auf die Schnelle nicht - ggf. solltest du die dinge einzeln prüfen und dich Schritt-für-Schritt an die Lösung heranarbeiten.

Aber von den Möglichkeiten wird es tt_products wahrscheinlich mittelfristig den Rang ablaufen."

IMHO hat es/sie das schon.

Kennst du vielleicht noch ein gutes Tutorial?

Google hilft, afaik gibts einen Wiki-Artikel in irgend einem TYPO3-Wiki und es gibt auch eine Newsgroup dazu.

Du schreibst das du tt_products eher "UNCOOL" findest. Was ist denn so uncool daran bzw. was findest du besser an commerce?

Den Funktionsumfang - tt_products ist schon sehr minimal.

[Anton]

»» Ne Ahnung woran das liegen könnte?

Nein, auf die Schnelle nicht - ggf. solltest du die dinge einzeln prüfen und dich Schritt-für-Schritt an die Lösung heranarbeiten.

Lokalisiert habe ich den Fehler jetzt. Wenn ich statt meinem eigenen Template (myFormularTemplate.html) eines der mitgelieferten Templates (mailformplus_demo.html) verwende dann klappt es mit dem versenden der E-Mail. Demnach muß der Fehler wohl irgendwo in meinem Template liegen. Leider blicke ich in dem mitgelieferten Template nicht durch. Mit der mitgelieferten Dokumentation kann ich auch nicht besonders viel anfangen. Hast du vielleicht irgendeine Ahnung wo in meinem Template der Fehler liegen könnte? Hier nochmal der Quellcode. ###REL_URL### hab ich einfach mal reingepackt. Was dahinter steckt kann ich leider nicht nachvollziehen.

  
<form action="###REL_URL###" method="post">  
	<table>  
		<tr>  
			<td class="tableColumnOne">Nachname*:</td>  
			<td>  
				<input type="text" name="nachname" value=""/>  
			</td>  
		</tr>  
		<tr>  
			<td>Vorname*:</td>  
			<td>  
				<input type="text" name="vorname" value=""/>  
			</td>  
		</tr>  
		<tr>  
			<td>Firma:</td>  
			<td>  
				<input type="text" name="firma" value=""/>  
			</td>  
		</tr>  
		<tr>  
			<td>Straße + Hausnummer:</td>  
			<td>  
				<input type="text" name="strasse" value=""/>  
			</td>  
		</tr>  
		<tr>  
			<td>PLZ + Ort:</td>  
			<td>  
				<input type="text" name="ort" value=""/>  
			</td>  
		</tr>  
		<tr>  
			<td>Telefon:</td>  
			<td>  
				<input type="text" name="telefon" value=""/>  
			</td>  
		</tr>  
		<tr>  
			<td>E-Mail*:</td>  
			<td>  
				<input type="text" name="email" value=""/>  
			</td>  
		</tr>  
		<tr>  
			<td class="tableVerticalAlign">Anfrage*:</td>  
			<td>  
				<textarea class="tableTextbox" rows="12"  cols="60" name="text"></textarea>  
			</td>  
		</tr>  
		<tr>  
			<td>Formular:</td>  
			<td>  
				<input class="tableButtonDelete" type="reset" value="löschen"/>  
				<input class="tableButtonSend" type="submit" name="abschicken" value="absenden"/>  
			</td>  
		</tr>  
	</table>  
</form>  

[Anton]

Hab meine Template jetzt durch ein anderes ersetzt. In diesem Template verwende ich keine Tabelle mehr. Das Template sieht so aus:

  
<form>  
    <p><label>Vorname*:</label><input/></p>  
    <p><label>Nachname*:</label><input/></p>  
    <p><label>Firma:</label><input/></p>  
    <p><label>Straße + Hausnummer:</label><input/></p>  
    <p><label>PLZ + Ort:</label><input/></p>  
    <p><label>Telefon:</label><input/></p>  
    <p><label>E-Mail*:</label><input/></p>  
    <p><label>Anfrage*:</label><textarea/></textarea></p>  
    <p>  
        <input type="reset" value="löschen"/>  
	<input type="submit" value="absenden"/>  
    </p>  
</form>  

Auch mit diesem Template funktioniert das Versenden an die im Backend angegebene E-Mail Adresse nicht. Ich hab keine Ahnung warum.

[suit]

Auch mit diesem Template funktioniert das Versenden an die im Backend angegebene E-Mail Adresse nicht. Ich hab keine Ahnung warum.

Sieh dir das Originaltemplate an - das ist wesentlich umfangreicher, bei dem von dir geposteten Schnipsel fehlt etwa 90% des Codes.

Die Fehlerverarbeitung, die Bestätigungsmails ...

[Anton]

»» Auch mit diesem Template funktioniert das Versenden an die im Backend angegebene E-Mail Adresse nicht. Ich hab keine Ahnung warum.

Sieh dir das Originaltemplate an - das ist wesentlich umfangreicher, bei dem von dir geposteten Schnipsel fehlt etwa 90% des Codes.

Die Fehlerverarbeitung, die Bestätigungsmails ...

Leider kann ich das Prinzip das hinter dem Originaltemplate steckt nicht nachvollziehen. Auch nicht mit der Doku der Extension. Ich finde die Doku ziemlich kompliziert geschrieben. Hier wird ja überhaupt nicht das Grundprinzip erklärt. Ich habe eine Quellcodedatei (mailformplus_demo.html) die das Formular enthält (das kann ich ja noch nachvollziehen). Ansonsten sind in der Quellcodedatei super viele Marker enthalten. Irgendwie alles ziemlich verwirrend. Wir wird das Template eigentlich verarbeitet? Gibt es nicht ein Bespiel was nicht gleich über 300 Zeilen hat. So könnte ich zunächst an einem kleinen Beispiel das Grundprinzip verstehen.

[suit]

Wir wird das Template eigentlich verarbeitet? Gibt es nicht ein Bespiel was nicht gleich über 300 Zeilen hat. So könnte ich zunächst an einem kleinen Beispiel das Grundprinzip verstehen.

Das Template funktioniert genauso wie alle anderen marker-/subpartbasierenden Templates. Es besteht aus mehrere Subparts die das Formular sowie die Fehlermeldungen und die Antworttexte erzeugen. Wenn du dir alles Stück-für-Stück vornimmst, hast du es schnell durchdacht.

[Anton]

»» Wir wird das Template eigentlich verarbeitet? Gibt es nicht ein Beispiel was nicht gleich über 300 Zeilen hat. So könnte ich zunächst an einem kleinen Beispiel das Grundprinzip verstehen.

Das Template funktioniert genauso wie alle anderen marker-/subpartbasierenden Templates. Es besteht aus mehrere Subparts die das Formular sowie die Fehlermeldungen und die Antworttexte erzeugen. Wenn du dir alles Stück-für-Stück vornimmst, hast du es schnell durchdacht.

Ich weiß jetzt woran es gelegen hat, dass mein Forumular nicht verschickt wurde. Dafür waren diese beiden Zeilen verantwortlich:

  
<input type="hidden" name="id" value="###PID###" />  
<input type="hidden" name="submitted" value="1" />		  

Kannst du mir sagen, was diese beiden Zeilen bewirken bzw. warum ohne diese das Formular nicht korrekt verschickt wird?

Des weiteren würde mich noch interessieren, was diese beiden Zeilen bewirken. Leider komme ich mit der Doku hier nicht weiter:

  
<input type="hidden" name="L" value="###value_L###" />  
<input type="hidden" name="type" value="###value_type###" />  

[suit]

Kannst du mir sagen, was diese beiden Zeilen bewirken bzw. warum ohne diese das Formular nicht korrekt verschickt wird?

submitted wird ausgewertet um zu bestimmen, ob das Formular bereits abgeschickt wurde oder nicht - sprich ob eine weitere Seite angezeigt werden soll oder die Bestätigungseite usw. Man könnte zwar auch den Submit-Button auswerten oder ein anderes Feld, aber das ist halt so programmiert.

id ist natürlich die Seiten-ID aus der pages-Tabelle ohne diese würde auf index.php abgeschickt werden, die Zuordnung zur richtigen Seite wäre verloren.

Des weiteren würde mich noch interessieren, was diese beiden Zeilen bewirken. Leider komme ich mit der Doku hier nicht weiter:

<input type="hidden" name="L" value="###value_L###" />
<input type="hidden" name="type" value="###value_type###" />

  
L ist üblicherweise der Parameter für die Sprach- oder Länderversion einer TYPO3-Seite, natürlich ist jeder andere Parameter-Name auch möglich, allerdings ist L die Usance.  
  
Type bestimmt den Seitentyp einer Seite, solltest du mehrere haben - z.B. XML, HTML, XHTML, LaTeX, Plain Text - Vorgesehen ist seitens TYPO3 per default (css\_styled\_content) aber nur eine (X)HTML-Version sowie eine Druckversion dieser (wobei man diese nicht über Type sondern über ein entsprechendes CSS lösen sollte). Manche Extensions bringen eigene Seitentypen mit - z.B. liefert DirectMail einen Seitentyp für einen Textnewsletter mit.

[Anton]

»» Kannst du mir sagen, was diese beiden Zeilen bewirken bzw. warum ohne diese das Formular nicht korrekt verschickt wird?

submitted wird ausgewertet um zu bestimmen, ob das Formular bereits abgeschickt wurde oder nicht - sprich ob eine weitere Seite angezeigt werden soll oder die Bestätigungseite usw. Man könnte zwar auch den Submit-Button auswerten oder ein anderes Feld, aber das ist halt so programmiert.

id ist natürlich die Seiten-ID aus der pages-Tabelle ohne diese würde auf index.php abgeschickt werden, die Zuordnung zur richtigen Seite wäre verloren.

»» Des weiteren würde mich noch interessieren, was diese beiden Zeilen bewirken. Leider komme ich mit der Doku hier nicht weiter:
»»
»» ~~~html

»» <input type="hidden" name="L" value="###value_L###" />
»» <input type="hidden" name="type" value="###value_type###" />
»»

>   
> L ist üblicherweise der Parameter für die Sprach- oder Länderversion einer TYPO3-Seite, natürlich ist jeder andere Parameter-Name auch möglich, allerdings ist L die Usance.  
>   
> Type bestimmt den Seitentyp einer Seite, solltest du mehrere haben - z.B. XML, HTML, XHTML, LaTeX, Plain Text - Vorgesehen ist seitens TYPO3 per default (css\_styled\_content) aber nur eine (X)HTML-Version sowie eine Druckversion dieser (wobei man diese nicht über Type sondern über ein entsprechendes CSS lösen sollte). Manche Extensions bringen eigene Seitentypen mit - z.B. liefert DirectMail einen Seitentyp für einen Textnewsletter mit.  
  
mmm, steht das alles in der Doku von mailformplus oder hast du das woanders gelesen. Falls du es woanders gelesen hast wäre ich für einen Link auf die Quelle dankbar.

[suit]

»» »» Kannst du mir sagen, was diese beiden Zeilen bewirken bzw. warum ohne diese das Formular nicht korrekt verschickt wird?
»»
»» submitted wird ausgewertet um zu bestimmen, ob das Formular bereits abgeschickt wurde oder nicht - sprich ob eine weitere Seite angezeigt werden soll oder die Bestätigungseite usw. Man könnte zwar auch den Submit-Button auswerten oder ein anderes Feld, aber das ist halt so programmiert.
»»
»» id ist natürlich die Seiten-ID aus der pages-Tabelle ohne diese würde auf index.php abgeschickt werden, die Zuordnung zur richtigen Seite wäre verloren.
»»
»» »» Des weiteren würde mich noch interessieren, was diese beiden Zeilen bewirken. Leider komme ich mit der Doku hier nicht weiter:
»» »»
»» »» ~~~html

»» »» <input type="hidden" name="L" value="###value_L###" />
»» »» <input type="hidden" name="type" value="###value_type###" />
»» »»

> »»  
> »» L ist üblicherweise der Parameter für die Sprach- oder Länderversion einer TYPO3-Seite, natürlich ist jeder andere Parameter-Name auch möglich, allerdings ist L die Usance.  
> »»  
> »» Type bestimmt den Seitentyp einer Seite, solltest du mehrere haben - z.B. XML, HTML, XHTML, LaTeX, Plain Text - Vorgesehen ist seitens TYPO3 per default (css\_styled\_content) aber nur eine (X)HTML-Version sowie eine Druckversion dieser (wobei man diese nicht über Type sondern über ein entsprechendes CSS lösen sollte). Manche Extensions bringen eigene Seitentypen mit - z.B. liefert DirectMail einen Seitentyp für einen Textnewsletter mit.  
>   
> mmm, steht das alles in der Doku von mailformplus oder hast du das woanders gelesen. Falls du es woanders gelesen hast wäre ich für einen Link auf die Quelle dankbar.  
  
Das steht natürlich nicht in der mailformplus-Doku. Du wirst auch im Handbuch eines USB-Speicher-Sticks eine Spezifikation des UHCI/OHCI/EHCI finden.  
  
Quelle hab ich grade keine zur Hand, aber diese Aussagen wird dir jeder mit halbwegs Erfahrung in TYPO3 in diesem Zusammenhang bestätigen können.  
  
Informationen zum L-Paramterer wirst du ggf. mittels der Suchmaschine deiner Wahl finden "Mehrsprachigkeit TYPO3 linkVars L" oder ähnliches. Informationen zum Type-Parameter wirst du ggf. mit "typeNum TYPO3" finden - die Sache mit der ID sollte einleuchtend sein (ein Blick in die Tabelle "pages" sollte mehr als aussagekräftig sein). Die submitted-Geschichte steht sicher irgendwo im mailformplus-Quellcode oder in der Doku (die, wie üblich, schlecht und unzureichend ist) :)

[Anton]

So lansam finde ich Gefallen an mailformplus. Mein aktuelles Template sieht so aus:

  
<!-- ###TEMPLATE_FORM### -->  
###ERROR###  
<form>  
		<input type="hidden" name="id" value="###PID###" />  
		<input type="hidden" name="submitted" value="1" />  
		<input type="hidden" name="L" value="###value_L###" />  
		<input type="hidden" name="type" value="###value_type###" />  
		  
		<p><label>Vorname*:</label><input type="text" name="firstName"/></p>  
		<p><label>Nachname*:</label><input type="text" name="secondName"/></p>  
		<p><label>Firma:</label><input type="text" name="company"/></p>  
		<p><label>Straße + Hausnummer:</label><input type="text" name="street"/></p>  
		<p><label>PLZ + Ort:</label><input type="text" name="location"/></p>  
		<p><label>Telefon:</label><input type="text" name="phone"/></p>  
		<p><label>E-Mail*:</label><input type="text" name="email"/></p>  
		<p><label>Anfrage*:</label><textarea name="text"></textarea></p>  
		<p>  
			<input type="reset" value="löschen"/>  
			<input type="submit" value="absenden"/>  
		</p>  
</form>  
<!-- ###TEMPLATE_FORM### -->  
  
<!-- ###TEMPLATE_SUBMITTED_OK### -->  
<p>Wir haben Ihre E-Mail erhalten und bedanken uns für Ihr Interesse.</p>  
<!-- ###TEMPLATE_SUBMITTED_OK### -->  
  
<!-- ###TEMPLATE_EMAIL_RECEIVER### -->  
Anfrage über das Kontaktformular  
  
Vorname: ###firstName####  
Nachname: ###secondName###  
Firma: ###company###  
Straße + Hausnummer: ###street###  
Telefon: ###phone###  
E-Mail: ###email###  
Anfrage: ###text###  
<!-- ###TEMPLATE_EMAIL_RECEIVER### -->  
  
<!-- ###TEMPLATE_EMAIL_RECEIVER_HTML### -->  
<h1>Anfrage über das Kontaktformular</h1>  
<table>  
  <tr><th>Parameter</th><th>Wert</th></tr>  
  <tr><td>Vorname:</td><td>###firstName####</td></tr>  
  <tr><td>Nachname:</td><td>###secondName###</td>  
  </tr><tr><td>Firma:</td><td>###company###</td></tr>  
  <tr><td>Straße:</td><td>###street###</td></tr>  
  <tr><td>Telefon:</td><td>###phone###</td></tr>  
  <tr><td>E-Mail:</td><td>###email###</td></tr>  
  <tr><td>Text:</td><td>###text###</td></tr>  
</table>  
<!-- ###TEMPLATE_EMAIL_RECEIVER_HTML### -->  
  
<!-- ###TEMPLATE_ERROR### begin -->  
  
<!-- ###ERROR_START### begin this is used for the global error marker ###ERROR### -->  
<strong>  
<h4>Die folgenden Felder sind Pflichtfelder und müssen ausgefüllt werden: </h4>  
<ul>  
<!-- ###ERROR_START### end -->  
  
<!-- ###ERROR_firstName### begin -->  
<li>Vorname</li>  
<!-- ###ERROR_firstName### end -->  
  
<!-- ###ERROR_secondName### begin -->  
<li>Nachname</li>  
<!-- ###ERROR_secondName### end -->  
  
<!-- ###ERROR_email### begin -->  
<li>E-Mail</li>  
<!-- ###ERROR_email### end -->  
  
<!-- ###ERROR_text### begin -->  
<li>Anfrage</li>  
<!-- ###ERROR_text### end -->  
  
<!-- ###ERROR_END### begin this is used for the global error marker ###ERROR### -->  
</ul>  
<p>Bitte berichtigen Sie diese Fehler und senden das Formualar erneut.</p>  
</strong>  
<!-- ###ERROR_END### end -->  
  
<!-- ###TEMPLATE_ERROR### end -->  

Eine paar Fragen hätte ich noch dazu:

Das was innerhalb der Subparts <!-- ###TEMPLATE_EMAIL_RECEIVER_HTML### --> steht wird ja genutzt um, falls der E-Mail-Client HTML-Ausgabe unterstützt, die E-Mail entsprechend mit HTML zu formatieren. Wie mache ich das hier mit Formatierungen? Soll ich hierzu CSS verwenden oder das irgendwie anders formatieren. Wenn ich CSS verwende kann ich die CSS Formatierung wohl nicht in eine externe Datei auslagern, sondern muß alles in direkt in den HTML-Code packen?

Sollte der Fall eintreten, dass der E-mail Client kein HTML unterstützt, so kommt ja <!-- ###TEMPLATE_EMAIL_RECEIVER### --> zum tragen. Was mich hier stört, ist das hinter dem Parameter und dem eigentlichen Value keine Leerzeichen vorhanden sind. Wenn ich hier Tabs einfüge, damit die Values alle untereinander stehen so wird das leider nicht in die E-Mail übernommen.

Vorname:   <TAB> ###firstName####
Nachname:  <TAB> ###secondName###

Im Beispieltemplate "mailformplus_demo.html" sind im oberen Bereich die beiden folgenden Elemente enthalten:

####################################

TypoScript settings for saving submitted data into a DB table of your choice

####################################
...
...

und

######################################

here we overwrite the default configuration for

file uploads defined in saveDB. for one

specific field

######################################
...
...

Diese beiden Elemente  habe ich in meinem Template komplett rausgeschmissen. Ich kann nicht so ganz nachvollziehen was in diesen beiden Bereichen überhaupt umgesetzt wird bzw. wofür sie notwendig sind?

Dann noch eine Frage zu ###ADDITIONAL_MULTIPAGE###. Das muss man anscheinend immer dann zwischen die Form Tags packen, wenn man eine multipage-form verwendet. Diesbezüglich die Frage: Was ist überhaupt eine mulitpage-form und was genau bewirkt der Marker ###ADDITIONAL_MULTIPAGE###?

Jetzt endgültig die letzte Frage zu mailformplus. Im Beispiel enthält das form-Tag diese beiden Parameter: action="###REL_URL###" und enctype="multipart/form-data". Hier verstehe ich nicht was hinter ###REL_URL### und multipart/form-data steckt und warum deren Angabe notwendig ist?

[suit]

So lansam finde ich Gefallen an mailformplus. Mein aktuelles Template sieht so aus:

Sieht schon besser aus, als dein erstes Template - immerhin sind nun die relevanten Dinge drin.

Diese beiden Elemente  habe ich in meinem Template komplett rausgeschmissen. Ich kann nicht so ganz nachvollziehen was in diesen beiden Bereichen überhaupt umgesetzt wird bzw. wofür sie notwendig sind?

Damit kannst du die Daten z.B. in die fe_user-Tabelle schreiben oder benutzerdefinierte Routinen für den Fileupload einbauen. Ersteres ist z.B. Praktisch, wenn du Mailformplus für eine Newsletteranmeldung (Double Opt-In ist dann aber afaik nicht ohne weitere Extensions möglich) verwendest.

Was ist überhaupt eine mulitpage-form und was genau bewirkt der Marker ###ADDITIONAL_MULTIPAGE###?

multi      = viel, mehrere
page       = Seite
form       = Formular
additional = zusätzlich

Was wirds wohl sein? ;)

Jetzt endgültig die letzte Frage zu mailformplus. Im Beispiel enthält das form-Tag diese beiden Parameter: action="###REL_URL###" und enctype="multipart/form-data". Hier verstehe ich nicht was hinter ###REL_URL### und multipart/form-data steckt und warum deren Angabe notwendig ist?

Sieh dir den generierten Quelltext an, dann weißt du, was ###REL_URL### macht - wenn du es dann noch nicht verstanden hast, lies die Formular-Dokumentation in SELFHTML :) zum Thema multipart/form-data kannst du das W3C befragen.

[Anton]

Nun muß ich doch noch was fragen :-):

Sollten nicht alle Pflichtfelder aufgefüllt sein, so bekommt man eine entsprechende Fehlermeldung. Natürlich will ich erreichen, dass die anderen Eingabefelder nicht alle wieder zurückgesetzt werden. Das habe ich umgesetzt, indem ich bei value den Marker hinzugefügt habe. Das Problem ist das anschließend der Reset-Button nichtmehr funktioniert, da die Werte in den Markern nun die Default-Werte sind. Am Beispiel hab ich verucht mir die Lösung abzugucken. Das Problem ist das das Beispiel diesbezüglich nicht funktioniert. So wollte ich es lösen:

  
plugin.tx_thmailformplus_pi1{  
	fieldConf.email.defaultValue.value = [e-mail]  
}  
  
<!-- ###TEMPLATE_FORM### -->  
###ERROR###  
<form>  
		<input type="hidden" name="id" value="###PID###" />  
		<input type="hidden" name="submitted" value="1" />  
		<input type="hidden" name="L" value="###value_L###" />  
		<input type="hidden" name="type" value="###value_type###" />  
		  
                ...  
                ...  
                ...  
		<p><label>E-Mail*:</label><input type="text" name="email" value="###value_email###"/></p>  
                ...  
                ...  
                ...  

Klappt aber leider nicht. Der defaultwert für email wird nicht am Anfang angezeigt.

Wenn ich später nachdem ich vergessen habe ein Pflichtfeld auszufüllen auf den Button reset Klicke zeigt dies ebenfalls keine Wirkung. Der Wert der vom Nutzer eingegeben wurde bleibt in E-Mail erhalten. Eigentlich sollte aber der Defaultwert "[e-mail]" bei E-Mail eingefügt werden. Ne Ahnung wo hier mein Fehler ist?

Im Backend im Feld "Name des Absenders" habe ich "Webseite Anton Kontaktformular" eingegeben. Wenn ich mir nun in einem E-Mail Clienten den Absender anschaue steht da folgendes:

[e-mail];[e-mail];[e-mail];

Wie bekomme ich denn das "@dd20503.kasserver.com;" weg?

[Anton]

Die zweite Frage hat sich erledigt. Ich darf als Absender natürlich nur eine E-Mail angeben. Da hätte ich auch direkt drauf kommen können.

Hab den Code von eben bezüglich des Betreffs der E-Mail noch ein wenig angepasst. Leider funktioniert das ebensowenig wie die Sache mit dem default-Wert.

  
plugin.tx_thmailformplus_pi1{  
    fieldConf.email.defaultValue.value = [e-mail]  
    default.email_subject = TEXT  
    default.email_subject.value = Anfrage von Herr/Frau ###value_secondName###  
}  

[suit]

Wenn ich später nachdem ich vergessen habe ein Pflichtfeld auszufüllen auf den Button reset Klicke zeigt dies ebenfalls keine Wirkung. Der Wert der vom Nutzer eingegeben wurde bleibt in E-Mail erhalten. Eigentlich sollte aber der Defaultwert "[e-mail]" bei E-Mail eingefügt werden. Ne Ahnung wo hier mein Fehler ist?

Der Reset setzt auf die Werte zurück, die beim Laden des HTML-Dokuments im value-Attribut standen - wenn du das Formular bereits abgeschickt hast, mit einer leeren Adresse, ist der Defaultwert ein Leerstring.

Warum willst du das Feld überhaupt vorbelegen? Und warum willst du einen Reset-Button verwenden?

[Anton]

Der Reset setzt auf die Werte zurück, die beim Laden des HTML-Dokuments im value-Attribut standen - wenn du das Formular bereits abgeschickt hast, mit einer leeren Adresse, ist der Defaultwert ein Leerstring.

Ich würde gerne erreichen, dass der Default-Wert immer ein Leerstring ist, auch wenn ich das Formular bereits abschickt habe. Nur so kann der Button-Reset funktionieren. Andererseits muß ich auch gewährleisten, dass, falls das Formular bereits abgeschickt wurde (mit einem fehlenden Pflichtfeld), die Werte aus der vorherigen Nutzereingabe übernommen werden. Sonst muß der Nutzer ja nochmal alles neu eingeben. In dieser Hinsicht dürfen die Default-Werte also wiederrum nicht ein Leerstring sein. Damit haben wir einen typischen Teufelskreis.

Warum willst du das Feld überhaupt vorbelegen?

Folgendes Szenario zu diesem Quelltext:

  
plugin.tx_thmailformplus_pi1{  
	fieldConf.email.defaultValue.value = [e-mail]  
	default.email_subject = TEXT  
    default.email_subject.value = Hallo Welt  
}  
  
<!-- ###TEMPLATE_FORM### -->  
###ERROR###  
<form>  
    ...  
    <p><label>E-Mail*:</label><input type="text" name="email" value="###value_email###"/></p>  
    ...		  

Marry Buffet möchte mich gerne über meine genialles Kontaktformular erreichen. Dazu tippt sie eine sehr lange Anfrage in das Textarea.

Nun füllt sie zunächst alle Felder aus. Sie vergisst allerdings das Pflichtfeld Vorname auszufüllen. Nach einem Klick auf den Button senden wird sie vom Browser darum gebeten das Feld Vorname auszufüllen, und dann erneut auf den Button absenden zu klicken. Würde ich nun nicht mit vorbelegten Eingabefeldern bzw. Textareas arbeiten, müßte sie alles noch einmal neu eingeben u.a. auch die sehr lange Anfrage im Textarea. Das wäre für sie mit Sicherheit sehr nervig. U.u. würde sie mir dann vielleicht doch keine Anfrage schicken, weil sie zu faul ist alles nochmal einzugeben.

Und warum willst du einen Reset-Button verwenden?

Der Grund warum ich einen Reset-Button verwenden will ist folgender. Es kann ja immer mal vorkommen, aus welchem Grund auch immer, dass die Person die mich über das Kontaktfromular erreichen will alle Daten die sie bisher eingegeben hat komplett verwerfen will. Hierzu wäre dann der Reset-Button sinnvoll. Selbst wenn sowas recht selten vorkommt. Einen wirklichen Nachteil hätte das vorhandensein solch eines Buttons doch eigenlich nicht. Deshalb würde ich ihn gerne einbauen. Wurde das Formular noch nicht abgesendet funktioniert dieser Reset-Button ja auch einwandfrei, das die Default-Values ja noch leer sind. Wurde das Formualr allerdings bereits einam mit einem fehlenden Pflichtfeld abgesendet, so funktioniert der Reset-Button nichtmehr so wie er soll, da die Default-Values ja nun nichtmehr leer sind.

mmm das einfachste wäre wohl auf den Reset-Button zu verzichten? Er wird wohl sowieso selten bis garnicht genutzt werden. Was meinst du?

In technischer Hinsicht würde mich allerings schon interssieren, wie man diese Problem lösen könnte?

[suit]

In dieser Hinsicht dürfen die Default-Werte also wiederrum nicht ein Leerstring sein. Damit haben wir einen typischen Teufelskreis.

Das bringt mich zu zwei Schlüssen: "geht nicht" und "Krücke mit JavaScript, die beim Klick auf den Reset-Button den Feldinhalt entfernt"

»» Warum willst du das Feld überhaupt vorbelegen?
Folgendes Szenario zu diesem Quelltext:

Du hast meine Frage nicht beantwortet - warum willst dieses Feld (E-Mail vorbelegen und durch einen Leerstring ersetzen können?). Das typische verhalten eines Affenformulars sollte doch völlig ausreichen.

U.u. würde sie mir dann vielleicht doch keine Anfrage schicken, weil sie zu faul ist alles nochmal einzugeben.

Ja ist klar, da Spricht aber nix dagegen - nur warum zur hölle soll eine E-Mail-Adresse vorbelegt sein, die soll der Benutzer gefälligst 1x selbst eingeben und dann bleibt sie bei jedem Absenden des Formulars erhalten - deine Adresse hat in dem Formular nix verloren - wäre nur eine Spam-Maschine.

mmm das einfachste wäre wohl auf den Reset-Button zu verzichten? Er wird wohl sowieso selten bis garnicht genutzt werden. Was meinst du?

Bei mir hat sich bisher noch nie jemand über einen nicht vorhandenen Reset-Button beschwert - zumindest nicht bei einem herkömmlichen Kontaktformular.

In technischer Hinsicht würde mich allerings schon interssieren, wie man diese Problem lösen könnte?

Siehe oben "gar nicht" - du kannst nur eine JavaScript-Krücke einbauen :)

[Anton]

Siehe oben "gar nicht" - du kannst nur eine JavaScript-Krücke einbauen :)

Der Reset-Button bleibt drausen. Wenn du JavaScript nur erwähnst wird mir schon ganz übel ;-)

[Anton]

»» Wenn der Shop nicht viele Sonderlösungen hat, ist commerce sicher ausreichend, tt_products ist imho eher uncool.

Hab mich heute mit der Einarbeitung in "commerce" beschäftigt. Dazu habe ich dieses Tutorial durchgearbeitet:

Tutorial commerce

Hut ab, dass ist wirklich super geschrieben. Hat eigentlich alles soweit auf Anhieb geklappt.

Zunächst wurden die Produkte die ich unter der Produktkategorie "Produktkatalog" angelegt hatte auch im Frontend angezeigt. Nun hab ich ein bißchen rumgespielt (u.a. die Produktkategorie gelöscht und wieder angelegt, im Constants Editor allerdings auch die ID auf die der neuen Kategorie angepasst). Plötzlich werden die Produkte nichtmehr im Frontend sondern nurnoch im Backend angezeigt. Ich versuche jetzt schon fast ne Stunde diesen Fehler zu finden. Leider vergeblich. Irgend eine Ahnung wie ich diesen Fehler lokalisieren kann?

Ich muß dazu sagen, dass ich nur die 21 Schritte im Tutorial durchgearbeitet habe. Danach gehts ja dann mit der Manipulation der Templates (TypoScript) weiter, so dass man den Shop ganz genau auf seine Befürfnisse anpassen kann.

Zu diesen eigenen Befürfnissen zähle ich momentan folgendes Punkte:

• alles ins deutsche übersetzen
• das Layout des Shop entsprechend anpassen (das Auswahlmenü der einzelnen Produktgruppen soll beispielsweise nicht als Liste oben in der Seite angezeigt werden)

Ich habe leider absolut keinen Plan wie ich bezüglich der Anpassungen loslege. Es wäre nett wenn du mir diesbezüglich einen Denkanstoss geben könntest, dann wüßte ich zumindest so halbweg wie ich das angehe. Kann ich diese Anpassungen im Backend vornehmen. Ist es nur möglich dies über eine Eingriff ins TypoScript durchzuführen. Falls es nur über das TypoScript möglich ist, geht das dann wieder wie immer über das überschreiben der setup.txt von commerce?

[suit]

Irgend eine Ahnung wie ich diesen Fehler lokalisieren kann?

Geh' die Checkliste der Installationsanleitung durch, enferne Stück-für-Stück die Konfiguration.

Falls es nur über das TypoScript möglich ist, geht das dann wieder wie immer über das überschreiben der setup.txt von commerce?

Natürlich - wie bei jeder halbwegs brauchbaren TYPO3-Extension.

Das vorgehen ist immer gleich: Brich' die Probleme auf kleinere Teilprobleme runter, analysiere das Problem, löse es.

Bisher bist du auch zurecht gekommen - commerce ist halt nur eine Nummer Größer, d.h. mehr zu bewältigende Aufgaben die sich auf jeweils mehrere Teilaufgaben herunterbrechen lassen.

[johannes293]

1.)

Da mir nicht so 100% klar ist, wann css_styled_content aufgerufen wird, ob es nur für die Erzeugung der CSS-Formatierung zuständig ist, oder ob es auch den HTML-Quellcode generiert, weiß ich nicht so wirklich wonach ich in setup.txt suchen muß, damit ich die Stelle finde, die für die Formatierung von meinem Kontaktformular verantwortlich ist. Naja, vielleicht könnt ihr mir den Zusammenhang nochmals ein bißchen erläutern. Angenommen ich habe die Stelle in der setup.txt gefunden die für die Formatierung des Kontaktformulars verantwortlich ist. Im meinem root-Template muß ich dann wohl dafür sorgen, dass das Formular ordentlich formatiert wird?
die richtige Stelle zu finden, ist nicht so schwer: Schau dir den generierten Quelltext an und suche dann diesen Wrapper-String (ohne uid oder pid :])in der setup.txt

nicht so richtig verstanden hab wann css_styled_content überhaupt aufgerufen wird, und was es eigentlich genau macht.

Das TypoScript Syntax and In-depth Study - Dokument hat mir da geholfen, schau dir insbesondere What is TypoScript? an:
TypoScript is a syntax for defining information in a hierarchical structure using simple ASCII text content. [...] it just contains information.
[...]
In scope of its use you can also understand TypoScript as a non-strict way to enter information into a multidimensional array. In fact when TypoScript is parsed that means it is transformed into a PHP array![...]

Zu den anderen Themen kann ich dir nicht helfen, mit dem RTE-Editor habe ich mich noch nicht auseinandergesetzt, und auch aus der css-styled-content-setup-datei habe ich einfach einmal alle Marker einftfernt, die baue ich nach wenn ich sie brauche..

[suit]

TypoScript is a syntax for defining information in a hierarchical structure using simple ASCII text content. [...] it just contains information.
[...]
In scope of its use you can also understand TypoScript as a non-strict way to enter information into a multidimensional array. In fact when TypoScript is parsed that means it is transformed into a PHP array![...]

Wie ich bereits sagte - sobald man das begriffen hat, machts meistens "Klick!" :) Der Haken daran ist, man muss wissen wie mehrdimensionale Arrays in PHP funktioniern, ohne dieses Wissen ist auch die Information wertlos.

[Anton]

Noch ein paar Dinge zu den fünf Fragen die ich ursprünglich gestellt habe:

zu 1.)
Diese Frage hat sich erledigt. Das Kontaktformular setze ich jetzt mit mailformplus um. Das klappt wunderbar.

zu 2.)
Hier gibt es noch Probleme. Diesen Code habe ich in das TS-Config Feld meiner root-Seite eingetragen:

RTE.default {
contentCSS = fileadmin/css/main.css
   classesParagraph = paragraphList
   proc.classesParagraph < .classesParagraph
}

Problem 1:
Durch das Einfügen der Zeile „contentCSS = fileadmin/css/main.css“ wird das RTE-Element „Textstil“ grundsätzlich nurnoch ausgegraut dargestellt. Meine Vorstellung wäre allerdings folgende. Ich füge einen Absatz im RTE ein, anschließend habe ich die Möglichkeit über das RTE-Element „Textstil“ meinem Absatz die Klasse paragraphList zuzuweisen. Leider funktioniert das nicht so, da das RTE-Element „Textstil“ grundsätzlich ausgeraut ist. Eine Ahnung woran das liegen könnte?

Problem 2:
Um zu testen, ob meine selbst definierte Klasse paragraphList angezeigt wird hab ich einfach mal die Zeile „contentCSS = fileadmin/css/main.css“ enternt, die dafür verantwortlich ist, dass „Textstil“ nurnoch ausgeraut dargestellt wird. Nun hätte ich eigentlich erwartet, dass meine Klasse pargraphList zusätzlich zu „Detail“, „Name der Person“ und „Wichtig“ im RTE-Element Textstill angezeigt wird. Leider ist es aber so, das meine eigene Klasse nicht angezeigt wird.

Problem 3:
In meinem Fall würde ich ja gerne für eine Liste eine Klasse vergeben. Also hab ich mich in der TSConfig Quick Reference auf die Suche nach dem richtigen Namen gemacht. Leider finde ich nirgends etwas was ich für eine Liste nutzen könnte. Erwartet hätte ich z.B. classesUL damit ich folgendes schreiben könnte:

RTE.default {
contentCSS = fileadmin/css/main.css
   classesUL = paragraphList
   proc.classesUL < .classesUL
}

Weißt du was der richtige Name für Listen ist und wo ich diesen finden kann?

zu 3.)
Diese Frage hat sich, wie die erste, auch erledigt. Ich verwende jetzt h3 für Inhaltselemente. Zum einen deshalb, weil ich so z.B. verschiedene Abschnitte leichter umsortieren kann, weil alle Inhaltselemente eine eigene ID erhalten und somit als Anker einfach angesprungen werden können und zum andern weil es dann beispielsweise automatisiert möglich ist ein Inhaltsverzeichnis am Anfang der Seite zu erstellen.

zu 4.)
Diese Frage hat sich ebenfalls erledigt.

zu 5.)
Ohne Modifikation in der setup.txt meines extension-Templates der Startseite generiert Typo3 diesen Quellcode.

  
<div class="csc-textpic csc-textpic-left csc-textpic-above">  
  <div class="csc-textpic-imagewrap">  
    <dl class="csc-textpic-image csc-textpic-lastcol"  
        style="width:600px;">  
      <dt>  
        <img src="typo3temp/pics/2aa680c0ed.jpg"  
             width="600"  
             height="796"  
             alt="" />  
      </dt>  
      <dd class="csc-textpic-caption">  
        Bildunterschrift  
      </dd>  
    </dl>  
  </div>  
</div>  
<div class="csc-textpic-clear"><!-- -->  
</div>  

In das Setup-Element des extension-Templates der Startseite packe ich diesen TypoScript-Code:

tt_content.image.20.layout.2.value = ###IMAGES######TEXT###
tt_content.image.20.imageStdWrapNoWidth.wrap >
tt_content.image.20.rendering.dl.oneImageStdWrap.dataWrap >
tt_content.image.20.rendering.dl.imgTagStdWrap.wrap >
tt_content.image.20.rendering.dl.caption.wrap = <div id="imageText"><p>|</p></div>

Dadurch generiert mir Typo3 jetzt diesen  Quellcode:

  
<img src="typo3temp/pics/2aa680c0ed.jpg" width="600" height="796" alt="" />  
<div id="imageText">  
  <p>Bildunterschrift</p>  
</div>  

Das zugehörige CSS in meiner CSS-Datei sieht so aus:

#imageStartseite {
width: 125px;
height: 160px;
float: left;
padding: 30px 20px 30px 0px;
}

#imageText {
padding: 80px 0px 0px 0px;
}

#imageText p {
margin: 0px 0px 0px 0px;
}

Ich muss also eigentlich nur noch erreichen, dass <img> um die id id=“imageStartseite“ erweitert wird. Hier weiß ich leider nicht wie ich das hinbekommen kann. Hast du hier vielleicht einen Tipp?

[suit]

zu 2.)
Leider funktioniert das nicht so, da das RTE-Element „Textstil“ grundsätzlich ausgeraut ist. Eine Ahnung woran das liegen könnte?

Du hast keine Tabellenzelle ausgewählt - ich sagte bereits, dass mein Beispiel NUR bei Tabellenzellen funktioniert - übernimm es 1:1 und es wird funktionieren :)

main.css (oder wie auch immer das Ding heisst) sollte aber eine Kopie für den RTE sein und ausschließlich jenes CSS beinhalten (siehe mein Beispiel,das enthält alles nötige).

Leider ist es aber so, das meine eigene Klasse nicht angezeigt wird.

Der Parser untersucht TSConfig UND das CSS für den RTE, wenn im CSS für den RTE eine Klasse nicht vorhanden ist, wird sie im Drop-Down nicht angezeigt.

Problem 3:
Weißt du was der richtige Name für Listen ist und wo ich diesen finden kann?

Auch der RTE ist eine Extension und besitzt eine Vorgabekonfiguration in Form von TypoScript bzw. TSConfig.

zu 5.)
Ohne Modifikation in der setup.txt meines extension-Templates der Startseite generiert Typo3 diesen Quellcode.

Ich muss also eigentlich nur noch erreichen, dass <img> um die id id=“imageStartseite“ erweitert wird. Hier weiß ich leider nicht wie ich das hinbekommen kann. Hast du hier vielleicht einen Tipp?

Erstens: Warum? Was hindert dich, dem <body />-Element der Startseite eine ID zu verpassen und daran die alternative Darstellung aufzuhängen?

Alternativ: gruppiere die Beschreibung und das Bild in einem gemeinsamen Element und verpasse diesem eine ID (oder auch nicht, nutzte das <body />-Element):

  
<body>  
  <div id="bildstartseite">  
   <img />  
   <p>caption</p>  
</body>

<body id="startseite">  
  <div>  
   <img />  
   <p>caption</p>  
</body>

[Anton]

Du hast keine Tabellenzelle ausgewählt - ich sagte bereits, dass mein Beispiel NUR bei Tabellenzellen funktioniert - übernimm es 1:1 und es wird funktionieren :)

Dein Beispiel funktioniert jetzt. Ich hatte die CSS-Datei in einem Verzeichnis templateS liegen. Im TSConfig habe ich allerdings template hingeschrieben. Hatte das S beim Ordner template zuviel.

Nachdem dein Beispiel nun funktioniert würde ich gerne für Listen eine Klasse paragraphList zur Verfügung stellen. Dazu erweitere ich dein Beispiel so:

  
RTE.default {  
  contentCSS = fileadmin/template/css/rte.css  
  classesTD = foo, bar  
  proc.classesTD < .classesTD  
  ??? = paragraphList  
  proc.??? < .???  
}  

Zusätzlich packe ich die neue Klasse "paragraphList" in die CSS-Datei rte.css.

Auch der RTE ist eine Extension und besitzt eine Vorgabekonfiguration in Form von TypoScript bzw. TSConfig.

Genau in dieser Vorgabekonfiguration (TS-Config-Referenz) habe ich nach dem richtigen Namen für Listen gesucht. Ich finde leider nichts Passendes. Den Namen „classesTD“, den du für Tabellenzellen in deinem Beispiel verwendet hast, habe ich gefunden. Wie kann ich denn den richtigen Namen für Listen finden?

Was hindert dich, dem <body />-Element der Startseite eine ID zu verpassen und daran die alternative Darstellung aufzuhängen?

Mich hindert nichts daran ;-). Naja höchstens das ich nicht weiß wie ich body das Attribut per TypoScript hinzufüge.  Füge ich id=“Startseite“ am besten im root-Template über TypoScript hinzu? Wie sieht denn das TypoScript aus, um body „id=Startseite“ hinzuzufügen?

[suit]

Wie kann ich denn den richtigen Namen für Listen finden?

Durch genauere Suche :) - dir sollte zumindest "classesParagraph" untergekommen sein oder "classesCharacter" für generisches hinzufügen.

Mich hindert nichts daran ;-). Naja höchstens das ich nicht weiß wie ich body das Attribut per TypoScript hinzufüge.  Füge ich id=“Startseite“ am besten im root-Template über TypoScript hinzu? Wie sieht denn das TypoScript aus, um body „id=Startseite“ hinzuzufügen?

Du könntest nach "body typo3" in der Suchmaschine deiner Wahl suchen - die ersten paar Treffer scheinen mir sehr vielversprechend zu sein.

[Han Solo]

Bin ab jetzt mit dem Pseudonym "Han Solo" unterwegs... nur zur Info.

»» Wie kann ich denn den richtigen Namen für Listen finden?
Durch genauere Suche :) - dir sollte zumindest "classesParagraph" untergekommen sein oder "classesCharacter" für generisches hinzufügen.

Das hab ich jetzt eingebaut:

RTE.default {
hidePStyleItems = h1, h2, h3, pre
contentCSS = fileadmin/template/css/rte.css
   classesTD = foo, bar
  proc.classesTD < .classesTD
  classesParagraph = test
  proc.classesParagraph < .classesParagraph
}

die Klasse test habe ich so in die rte.css hinzugefügt:

  
.test {  
		background: #FF8080;  
}  

Die Klasse test will einfach nicht im RTE erscheinen. Ich bin echt am verzweifeln. Noch irgendwelche Tipps?

»» Mich hindert nichts daran ;-). Naja höchstens das ich nicht weiß wie ich body das Attribut per TypoScript hinzufüge.  Füge ich id=“Startseite“ am besten im root-Template über TypoScript hinzu? Wie sieht denn das TypoScript aus, um body „id=Startseite“ hinzuzufügen?

Du könntest nach "body typo3" in der Suchmaschine deiner Wahl suchen - die ersten paar Treffer scheinen mir sehr vielversprechend zu sein.

Das klappt jetzt. Hab es so gelöst indem ich in das Template der Startseite folgendes geschrieben habe:

  
page.bodyTag = <body id="hello">  

mmm, ob das die beste Lösung ist weiß ich nicht... zumindest funktioniert es.

[suit]

Die Klasse test will einfach nicht im RTE erscheinen. Ich bin echt am verzweifeln. Noch irgendwelche Tipps?

Schon mal p.test {} versucht? Ansonsten müsste ich nachsehen, auswendig weiß ich das aktuell auch nicht.

page.bodyTag = <body id="hello">
mmm, ob das die beste Lösung ist weiß ich nicht... zumindest funktioniert es.

Die Alternative ist, auf der Startseite ein zusätzliches Stylesheet einzubinden.

[Han Solo]

»» Die Klasse test will einfach nicht im RTE erscheinen. Ich bin echt am verzweifeln. Noch irgendwelche Tipps?

Schon mal p.test {} versucht? Ansonsten müsste ich nachsehen, auswendig weiß ich das aktuell auch nicht.

Genau daran hat es gelegen. Jetzt ist der Groschen bei mir auch endlich gefallen. Hab zum Testen mal sowas gebaut:

RTE.default {
hidePStyleItems = h1, h2, h3, pre
contentCSS = fileadmin/template/css/rte.css
   classesTD = foo, bar
  proc.classesTD < .classesTD
  classesParagraph = test
  proc.classesParagraph < .classesParagraph
  classesCharacter = test2
  proc.classesCharacter < .classesCharacter
}

und dieses CSS dafür genutzt:

  
td.foo {  
                background: #8080FF;  
}  
  
td.bar {  
                background: #FF8080;  
}  
  
p.test {  
		background: #FF8080;  
}  
  
ul.test2 {  
		background: #FF8080;  
}  
  
li.test2 {  
		background: #FF8080;  
}  

Deine beiden haben ja vorher schon funktioniert. Zu den anderen will ich kurz was sagen. Die Klasse test erscheint im RTE jetzt nur bei Absätzen. Die Klasse test2 erscheint im RTE sowohl bei ul, also bei der kompletten Liste, als auch bei einem einzelnen Listenpunkt (li). Endlich hab ich das Prinzip verstanden.

»» page.bodyTag = <body id="hello">
»» mmm, ob das die beste Lösung ist weiß ich nicht... zumindest funktioniert es.

Die Alternative ist, auf der Startseite ein zusätzliches Stylesheet einzubinden.

Du meinst im extension Template der Startseite per TypoScript main.css z.B. durch startseite.css zu ersetzen, und in startseite.css dann halt die benötigten Anweisungen packen. mmm, dass finde ich aber aufwändiger als das andere...

Durch dich habe ich in letzter Zeit ja eine ganze Menge gelernt was Typo3 angeht. Leider sind bezüglch Typo3 sehr viele falsche Dinge im Netz zu finden. Auch die Bücher die ich mir bisher angeschaut habe gefallen mir nicht besonders gut. Entweder beschreiben sie wie man mit dem Backend arbeitet und gehen viel zu wenig ins Detail, oder sie setzen voraus das man schon ziemlich viel Erfahrung mit Typo3 hat. Demnach wird in diesen "Expertenbüchern" kaum auf das Grundprizinp eingegangen. Mit Grundprinzip meine ich folgende Punkte:

• Die HTML-Designvorlage erstellen
• Grundstruktur mit Hilfe der Desingvorlage generieren lassen
• Inhalte hinzufügen
• RTE Konfiguration
• Eigene Klassen in den RTE packen
• Mailformplus einsetzen
• Validierung erreichen
• Barierefreie Gestaltung
• Formatierung des Quellcodes verbessern (Anpassen von css_styled_content)

Genau diese Punkte könnte man super an einem Praxisbeipiel erläutern. Ich überlege mir ersthaft ein Tutorial zu schreiben das dies beschreibt. Denkst du das wäre sinnig und würde auch entsprechend genutzt werden? Will mir halt nicht die Arbeit machen und später braucht es keiner. Falls Du das für sinnig hälst, wäre es natürlich super wenn du es später mal korrekturlesen bzw. vielleicht sogar ergänzen könntest. Keine Angst beovor ich dir was zum korrekturlesen gebe würden bestimmt noch zwei Monate vergehen. Was hälst du von dieser Idee?

PS: Du hattest mal erwähnt, dass du auch so ein Tutorial schreiben willst bzw. das du schon dabei bist. Wenn du schon dran bist würde ich dir gerne meine Hilfe anbieten... für die EINFACHEN Sachen ;-).

[suit]

Du meinst im extension Template der Startseite per TypoScript main.css z.B. durch startseite.css zu ersetzen, und in startseite.css dann halt die benötigten Anweisungen packen. mmm, dass finde ich aber aufwändiger als das andere...

Nein, ich meine im Extension-Template der Startseite ein zustätzliches css-file einfügen.

alle Seiten:

• main.css

Startseite

• main.css
• home.css

Die Formatierung der Startseite wird ja im Allgemeinen sehr ähnlich sein, darum kannst du durchaus dein main.css verwenden und nur die ergänzungen im zusätzlichen CSS durchführen.

Natürlich können die Seiten auch völlig verschieden aussehen - dann kannst du 2 separate Files verwenden.

Leider sind bezüglch Typo3 sehr viele falsche Dinge im Netz zu finden.

Ich erinnere mich, das irgendwann mal gesagt zu haben :)

Wenn du eine TYPO3-Lösung für ein Problem im Netz findest, besteht sie idR. aus 10 Zeilen Code/TypoScript. Eine Zeile davon ist relevant für das Problem. 3 Zeilen haben keine Auswirkung und 6 Zeilen graben Löcher an anderen Stellen :)

Demnach wird in diesen "Expertenbüchern" kaum auf das Grundprizinp eingegangen. Mit Grundprinzip meine ich folgende Punkte:

Dafür gibts bereits eins auf der TYPO3-Website. Das Tutorial ist aber schlecht, unter anderem weil es hoffnungslos überaltert ist (bezieht sich teilweise auf prä TYPO3 3.8).

Denkst du das wäre sinnig und würde auch entsprechend genutzt werden?

Ich denke ja. Ggf. könnte man die typo3.org-Leute dazu bringen, ihr altes Tut zu ersetzten :)

PS: Du hattest mal erwähnt, dass du auch so ein Tutorial schreiben willst bzw. das du schon dabei bist. Wenn du schon dran bist würde ich dir gerne meine Hilfe anbieten... für die EINFACHEN Sachen ;-).

Gerne - allerdings muss dafür meine Seite erst halbwegs fertig werden - sonst wirds schwierig, die Inhalte überhaupt zu publizieren.

Ich tendiere momentan aber zur einer losen Artikelsammlung, die sich im einzelnen mit den von dir genannten Punkten beschäftigen. Ein durchgängiges, strukturiertes Tutorial ist momentan noch in weiter Ferne.

[Han Solo]

Nein, ich meine im Extension-Template der Startseite ein zustätzliches css-file einfügen.

Genau so mach ich das *Hände reib*. Dann brauche ich nicht das unnötige  id="Startseite" im Body-Tag.

Ich denke ja. Ggf. könnte man die typo3.org-Leute dazu bringen, ihr altes Tut zu ersetzten :)

Naja, aber nur wenn ich ein englisches schreibe. Ich hatte eigentlich vor eines in deutsch zu schreiben. Ein deutsches würde bei mir genauso schlecht wie das das momentan auf typo3.org zu bekommen ist.

»» PS: Du hattest mal erwähnt, dass du auch so ein Tutorial schreiben willst bzw. das du schon dabei bist. Wenn du schon dran bist würde ich dir gerne meine Hilfe anbieten... für die EINFACHEN Sachen ;-).

Gerne - allerdings muss dafür meine Seite erst halbwegs fertig werden - sonst wirds schwierig, die Inhalte überhaupt zu publizieren.

Ich tendiere momentan aber zur einer losen Artikelsammlung, die sich im einzelnen mit den von dir genannten Punkten beschäftigen. Ein durchgängiges, strukturiertes Tutorial ist momentan noch in weiter Ferne.

Willst du eigentlich ein englisches oder ein deutsches Tutorial schreiben?

Ich denke, ich werde in der nächsten Woche mal ein etwas detaillierteres Konzept für so ein Tutorial entwerfen. Nächste Woche hab ich nämlich Zeit, da ich in den Urlaub fahre... naja vorausgesetzt meine Freundin läst mich auch im Urlaub ein kleines bißchen über Typo3 nachdenken ;-). Das grobe Konzept was ich nächste Woche erarbeite könnte ich dir dann übernächste Woche mal zusenden. So könnte ich Fehler vermeiden. Nachdem das Grundkonzept steht könnten ich nach und nach die einzelnen Kapitel in die Tat umsetzen. Wäre dieser Vorschlag akzeptabel für dich?

Meine Seite habe ich jetzt fast fertig mit Typo3 nachgebaut. Das einzige was noch nicht so wie die händische Seite aussieht ist die Startseite. Der Quellcode unten (ein der wenigen Quellcodekomponeten meiner händischen Seite die mir noch nicht gefallen) der relevanten Stelle in der Startseite sieht vom Grundprinzip her so aus:

  
<div id="content">  
    <h2>Startseite</h2>  
    <img id="foto" src="test.jpg"/>  
    <div id="beschreibungFoto">  
        <p>Beschreibung Foto Zeile 1</p>  
	<p>Beschreibung Foto Zeile 2</p>  
	<p>Beschreibung Foto Zeile 3</p>  
    </div>  
    <h3 class="clear">Hobbys</h3>  
    <ul>  
        <li>Hobby 1</li>  
	<li>Hobby 2</li>  
	<li>Hobby 3</li>  
    </ul>  
</div>  

und so das relevante CSS:

  
#foto {  
	width: 125px;  
	height: 160px;  
	float: left;  
	padding: 30px 20px 30px 0px;  
}  
  
#beschreibungFoto {  
	padding: 80px 0px 0px 0px;  
}  
  
#beschreibungFoto p {  
	margin: 0px 0px 0px 0px;  
}  
  
.clear {  
	clear: both;  
}  

Ich will das ganze jetzt auch in Typo3 umsetzen. Vorher müßte ich allerdings erstmal sicher gehen, ob dies händische Lösung oben überhaupt die optimale ist. Ich glaube nämlich das ich das ziemlich schlecht gelöst habe weiss aber keine gute Alternative. Es geht halt um das vormals schon beschriebene Layout mit dem Bild auf der linken Seite. Rechts neben dem Bild die Bildbeschreibung die über drei Zeilen geht und die vertikal bezugnehmend auf dei Höhe des Bildes zentriert ist. Unter dem Bild dann eine Aufzählungsliste. Hälst du die Lösung oben für optimal oder würdest du etwas anderes empfehlen?

[suit]

Willst du eigentlich ein englisches oder ein deutsches Tutorial schreiben?

Österreichisches Deutsch :p

Ich denke, ich werde in der nächsten Woche mal ein etwas detaillierteres Konzept für so ein Tutorial entwerfen. Nächste Woche hab ich nämlich Zeit, da ich in den Urlaub fahre... naja vorausgesetzt meine Freundin läst mich auch im Urlaub ein kleines bißchen über Typo3 nachdenken ;-). Das grobe Konzept was ich nächste Woche erarbeite könnte ich dir dann übernächste Woche mal zusenden. So könnte ich Fehler vermeiden. Nachdem das Grundkonzept steht könnten ich nach und nach die einzelnen Kapitel in die Tat umsetzen. Wäre dieser Vorschlag akzeptabel für dich?

Wie gesagt, ich würde mit einer losen Sammlung beginnen und diese dann allfällig, später mal zu einem "Werk" zusammenfügen.

Hälst du die Lösung oben für optimal oder würdest du etwas anderes empfehlen?

Ich würde Bild und Text (wenn sie denn zusammengehören) gruppieren - dann sparst du dir auch die seltsame Klasse "clear"

[Han Solo]

»»  Hälst du die Lösung oben für optimal oder würdest du etwas anderes empfehlen?

Ich würde Bild und Text (wenn sie denn zusammengehören) gruppieren - dann sparst du dir auch die seltsame Klasse "clear"

Hab mal nach Gruppieren in selfhtml gesucht. Habe nur <fieldset> gefunden. Ich dachte, dass ist nur für Formulare. Meist du das oder etwas anderes. Hast du vielleicht ein Link zu einem Beiispiel?

[suit]

Hab mal nach Gruppieren in selfhtml gesucht. Habe nur <fieldset> gefunden. Ich dachte, dass ist nur für Formulare. Meist du das oder etwas anderes. Hast du vielleicht ein Link zu einem Beiispiel?

Du kannst beliebige Elemente mit einem beliebigen Element gruppieren.

Formularelemente gruppiert man sinnigerweise mit einem fieldset-Element.
Tabellenkopfzeilen gruppiert man mit einem <thead />-Element
Beliebige Elemente lassen sich auch mit dem generischen Container <div /> gruppieren.

[Han Solo]

Du kannst beliebige Elemente mit einem beliebigen Element gruppieren.

Formularelemente gruppiert man sinnigerweise mit einem fieldset-Element.
Tabellenkopfzeilen gruppiert man mit einem <thead />-Element
Beliebige Elemente lassen sich auch mit dem generischen Container <div /> gruppieren.

Meinst du das so:

  
<div id="content">  
    <h2>Startseite</h2>  
  
    <div>  
        <img id="foto" src="test.jpg"/>  
        <div id="beschreibungFoto">  
            <p>Beschreibung Foto Zeile 1</p>  
            <p>Beschreibung Foto Zeile 2</p>  
            <p>Beschreibung Foto Zeile 3</p>  
        </div>  
    </div>  
  
    <h3>Hobbys</h3>  
    <ul>  
        <li>Hobby 1</li>  
        <li>Hobby 2</li>  
        <li>Hobby 3</li>  
    </ul>  
</div>  

Die Klasse "clear" bei h3 habe ich entfernt. Foto und Beschreibung habe ich mit DIV gruppiert. Leider weiß ich trotzdem nicht wie ich jetzt die gewünschte Anordnung hinbekomme. Steh total auf dem Schlauch.

[suit]

Die Klasse "clear" bei h3 habe ich entfernt. Foto und Beschreibung habe ich mit DIV gruppiert. Leider weiß ich trotzdem nicht wie ich jetzt die gewünschte Anordnung hinbekomme. Steh total auf dem Schlauch.

Und ich hab' eine Ahnung wie dein Layout aussieht?

[Han Solo]

»» Die Klasse "clear" bei h3 habe ich entfernt. Foto und Beschreibung habe ich mit DIV gruppiert. Leider weiß ich trotzdem nicht wie ich jetzt die gewünschte Anordnung hinbekomme. Steh total auf dem Schlauch.

Und ich hab' eine Ahnung wie dein Layout aussieht?

Hatte ich doch beschrieben. Links das Bild. Rechts daneben der Text der über drei Zeilen geht (vertikal ausgehend von der Höhe des Bildes zentriert). Unter dem Bild die Liste. Die Elemente (das Bild ist test.jpg, die Beschreibung neben dem Bild sind "Beschreibung Foto Zeile 1-3", die Liste unter dem Bild ist der Kram mit den Hobbys) sind ja alle in diesem Markup enthalten:

  
<div id="content">  
    <h2>Startseite</h2>  
  
    <div>  
        <img id="foto" src="test.jpg"/>  
        <div id="beschreibungFoto">  
            <p>Beschreibung Foto Zeile 1</p>  
            <p>Beschreibung Foto Zeile 2</p>  
            <p>Beschreibung Foto Zeile 3</p>  
        </div>  
    </div>  
  
    <h3>Hobbys</h3>  
    <ul>  
        <li>Hobby 1</li>  
        <li>Hobby 2</li>  
        <li>Hobby 3</li>  
    </ul>  
</div>  

Ich bekomme die gewünschte Anordnung leider nur hin, indem ich h3 die Klasse clear zuweise. Du sagtest ja, dass es auch ohne clear geht indem ich das Foto (test.jpg) und dessen Beschreibung ("Beschreibung Foto Zeile 1-3") mit einem DIV Gruppiere. Genau das habe ich gemacht. Leider kann ich trotzdem noch nicht nachvollziehen wie ich das jetzt mit CSS optimal so anordne wie oben beschrieben. Vielleicht ist mein Markup ja auch noch falsch?

[suit]

Vielleicht ist mein Markup ja auch noch falsch?

Wenn ich richtig verstanden habe, was du willst, müsste dein Markup in Ordnung sein - du brauchst nur ein Element, welches den Textfluss wiederherstellt. Das machst du am Besten per CSS mit einem Pseudo-Elemenent (:after und content). Der IE machts ohnehin falsch, also passts dort dann auch.

[Han Solo]

»» Vielleicht ist mein Markup ja auch noch falsch?

Wenn ich richtig verstanden habe, was du willst, müsste dein Markup in Ordnung sein - du brauchst nur ein Element, welches den Textfluss wiederherstellt. Das machst du am Besten per CSS mit einem Pseudo-Elemenent (:after und content). Der IE machts ohnehin falsch, also passts dort dann auch.

:-( ich versteh leider nicht wie du das meinst. Eine kleines Beispiel wäre super hilfreich.

[suit]

:-( ich versteh leider nicht wie du das meinst. Eine kleines Beispiel wäre super hilfreich.

clearfix