Seit Version 4.0.0 der Extension MailformPlus (th_mailformplus) verfügt das Mail-Form Plugin über Funktionen zur Spam-Abwehr. Das ist zwar gut, führt aber in manchen Fällen leider zu Problemen...
Eine dieser neuen Funktionen ist das Abgleichen des HTTP Referer ($_SERVER['HTTP_REFERER']) mit einer per TypoScript definierten Liste von zulässigen Referers. Diese Liste wird standardmäßig (und automatisch) um den eigenen Server ($_SERVER['HTTP_HOST']) erweitert. Sinn und Zweck dieser Funktion ist es zu verhindern, dass jemand über einen anderen Server unser Mail-Formular missbraucht, um Spam zu verschicken. Dazu schickt der Spammer GET- oder POST-Requests (also abgesendete Formulare, mit seinem Content = Müll) von seinem Server an unsere Seite mit dem Formular. Würde der Referer nicht geprüft, schickt das Formular nun fleißig Mails über unseren Server und Mailadresse raus. Richtig problematisch wird es, wenn das Formular so konfiguriert ist, dass der Kunde eine Bestätigungsmail erhält! Dann geht der ganze Müll (abhängig von den Formular-Feldern die in der Mail verarbeitet werden) raus an die angegebene Email Adresse. Im anderen Fall, wird nur die Datenbank und das Postfach des Admin zugemüllt.
Das spricht natürlich dafür, die Standardkonfiguration so zu lassen wie es ist. Allerdings, wie ja schon geschrieben gibt's hier ab und an Probleme... Und zwar dann, wenn ein richtiger Kunde das Formular ausfüllt und aus irgendwelchen Gründen keinen Referer hat. Das kann z.B. durch bestimmte Netzwerk-Konfigurationen, Browser Plugins die den Referer löschen oder an den Firewall-Einstellungen liegen. Der nicht vorhandene Referer wird mit der Liste der zulässigen verglichen, was natürlich zu keiner Übereinstimmung führt. In Folge dessen, wird weder eine Mail an den User noch an den Admin gesendet. War es eine "dringende" Kontaktanfrage, hat man den potenziellen Neukunden unter Umständen verloren... blöd!
Dieses Verhalten kann man über TypoScript abstellen. Das geht so:
plugin.tx_thmailformplus_pi1.doNotCheckReferer = 1
Ich würde das Risiko nicht eingehen, einen Neukunden zu verlieren. Auf der anderen Seite ist es etwas Riskant die Prüfung des Referer abzustellen. Daher muss man einfach sehr genau beobachten was da vor sich geht ;).
Ach ja, es gibt noch 2 weitere Einstellungen um die Problematik etwas zu entschärfen. Zum einen kann man die Zahl der Email die an eine Email-Adresse gesendet werden begrenzen.
plugin.tx_thmailformplus_pi1.limitMailsToUser = 1
Und, zum andern könnte man ein Captcha einbauen - z.B. freeCap CAPTCHA (sr_freecap) oder reCAPTCHA (jm_recaptcha). Das hält zumindest die meisten Maschinen davon ab Spam zu verschicken. Auf der anderen Seite sind diese Captchas nicht sonderlich userfreundlich.
Tja... wie man's macht... isses falsch ;)! Was denkt Ihr?
Dienstag, 23. September 2008
Samstag, 13. September 2008
Direct Mail - Wo sind denn die CSS Styles hin?!
Das hab ich mich nach dem ersten Testversand meines Newsletters auch gefragt... Als ich mir die Seite ganz normal im Frontend anzeigen ließ, war noch alles in Ordnung - die Styles waren da und alles perfekt formatiert. Doch nach dem Versenden, sah das anders aus. Wo vorher noch CSS Styles im <head> Bereich des Newsletters zu finden waren... ist jetzt nur noch ein leeres <style></style> Tag vorhanden! Was um Himmels Willen ist da nun passiert?!
Die Antwort ist eigentlich ganz einfach - aber langsam... mich hat‘s auch einige graue Haare gekostet ;). In meinem Fall kam noch hinzu, dass ich über TypoScript sämtlichen Header-Code deaktiviert hatte um es dann selber, wiederrum über TypoScript, zu setzen. Das gibt mir die Möglichkeit genau zu steuern was da in den Header kommt. Das kann ich bei einem Newsletter nur empfehlen. Denn nur so, hat man die vollständige Kontrolle über den Header und es kann nicht mehr vorkommen, dass z.B. durch die Installation eines neuen Plugins irgendwelcher Header-Code - meist CSS oder JavaScript - plötzlich hinzukommt und unser Newsletter-Layout zerschießt. Wie das geht, seht Ihr hier:
# disable all header code
config.disableAllHeaderCode = 1
# define page element
page = PAGE
page.typeNum = 0
# set header code
page.10 = TEXT
page.10.value (
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>...</title>
<style>
body {...}
p {...}
</style>
</head>
<body bgcolor="ffffff" text="#000000">
)
# set page content - in this case with templavoila
page.20 = USER
page.20.userFunc = tx_templavoila_pi1->main_page
# close body and html tag
# include tracking-pixel
page.30 = TEXT
page.30.value (
<img src="typo3conf/ext/direct_mail/res/gfx/dmailerping.gif" width="1" height="1" dmailerping="1" />
</body>
</html>
)
So, zurück zum eigentlichen Problem. Ist doch echt komisch, dass die Styles aus dem <style> Tag nach dem Versand einfach verschwunden sind obwohl ich es manuell hinzugefügt hatte. Google hat mir dazu einiges ausgespuckt. Doch alles was ich in den Foren lesen konnte war "es liegt an den Mail-Clients (Outlook, gmx, ...) ... die schneiden CSS manchmal einfach weg". Kann das sein? Ich meine NEIN. Habs auch getestet, mit sämtlichen Clients. Die Styles waren einfach weg. Das muss also irgendwie beim versenden passieren. Vielleicht gibt's ja nen TypoScript Parameter für Direct Mail, mit dem man dieses Verhalten steuern kann? ... Leider auch nicht. Dann fiel mir aber auf, dass sämtliche HTML-Kommentare aus dem Code entfernt wurden... na, dämmers scho ;)? Üblicherweise kommentiert man CSS-Styles im HTML-Code aus, damit ältere Browser die kein CSS unterstützen das nicht fälschlicherweise als Text mit ausgeben (im obigen Beispiel hab ich bewusst drauf verzichtet ;)). Also... ausprobieren... und siehe da... meine Styles sind wieder da... und alles ist gut! So einfach kann‘s manchmal sein.
Das Wegschneiden von HTML-Kommentaren ist eigentlich sinnvoll, denn es sind unnötige Bytes die hier in der Gegend rum geschickt werden - das allerdings auskommentierte Styles weggeschnitten werden... halte ich für einen Bug. Allerdings konnte ich die entsprechende Stelle im Code - auch nach langem Suchen - nicht finden... was mich ehrlich gesagt schon ein bisschen wurmt!
Jetzt noch mal kurz was zum Thema Newsletter und CSS im Allgemeinen. Bekanntlich verhalten sich die vielen Mail-Clients (online u. offline) höchst unterschiedlich was die Darstellung von CSS angeht. Daher ist es wichtig Formatierungen auf ein Minimum zu reduzieren. Beim Newsletter-Design (bei Webseiten bin ich ähnlicher Meinung) gilt: Weniger ist Mehr! Ihr erspart Euch jede Menge Ärger, wenn Ihr das das Design schlicht und mit wenigen Formatierungen gestaltet. Es gibt eine ausgezeichnete Übersicht welche Email-Clients was unterstützen - das sollte an dieser Stelle weiterhelfen. Und nachdem wir den CSS-Code damit sehr klein halten, halte ich es für sinnvoll den Code wie im obigen Beispiel direkt in den HTML-Code mit aufzunehmen und nicht über eine extern Datei einzubinden. Es hat den Vorteil, dass die korrekte Darstellung des Newsletters so nicht von der Verfügbarkeit Eures Servers abhängt. Und wie oben beschrieben... bloß nicht auskommentieren! Ich sehe das auch nicht als kritisch an. Die Clients die das <style> Tag nicht unterstützen kann man meiner Ansicht nach vernachlässigen - wenn es überhaupt noch welche gibt ist diese Zahl sehr gering (das sieht man selbst bei SELFHTML so).
Na dann… viel Erfolg beim Newsletterversand!
Die Antwort ist eigentlich ganz einfach - aber langsam... mich hat‘s auch einige graue Haare gekostet ;). In meinem Fall kam noch hinzu, dass ich über TypoScript sämtlichen Header-Code deaktiviert hatte um es dann selber, wiederrum über TypoScript, zu setzen. Das gibt mir die Möglichkeit genau zu steuern was da in den Header kommt. Das kann ich bei einem Newsletter nur empfehlen. Denn nur so, hat man die vollständige Kontrolle über den Header und es kann nicht mehr vorkommen, dass z.B. durch die Installation eines neuen Plugins irgendwelcher Header-Code - meist CSS oder JavaScript - plötzlich hinzukommt und unser Newsletter-Layout zerschießt. Wie das geht, seht Ihr hier:
# disable all header code
config.disableAllHeaderCode = 1
# define page element
page = PAGE
page.typeNum = 0
# set header code
page.10 = TEXT
page.10.value (
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>...</title>
<style>
body {...}
p {...}
</style>
</head>
<body bgcolor="ffffff" text="#000000">
)
# set page content - in this case with templavoila
page.20 = USER
page.20.userFunc = tx_templavoila_pi1->main_page
# close body and html tag
# include tracking-pixel
page.30 = TEXT
page.30.value (
<img src="typo3conf/ext/direct_mail/res/gfx/dmailerping.gif" width="1" height="1" dmailerping="1" />
</body>
</html>
)
So, zurück zum eigentlichen Problem. Ist doch echt komisch, dass die Styles aus dem <style> Tag nach dem Versand einfach verschwunden sind obwohl ich es manuell hinzugefügt hatte. Google hat mir dazu einiges ausgespuckt. Doch alles was ich in den Foren lesen konnte war "es liegt an den Mail-Clients (Outlook, gmx, ...) ... die schneiden CSS manchmal einfach weg". Kann das sein? Ich meine NEIN. Habs auch getestet, mit sämtlichen Clients. Die Styles waren einfach weg. Das muss also irgendwie beim versenden passieren. Vielleicht gibt's ja nen TypoScript Parameter für Direct Mail, mit dem man dieses Verhalten steuern kann? ... Leider auch nicht. Dann fiel mir aber auf, dass sämtliche HTML-Kommentare aus dem Code entfernt wurden... na, dämmers scho ;)? Üblicherweise kommentiert man CSS-Styles im HTML-Code aus, damit ältere Browser die kein CSS unterstützen das nicht fälschlicherweise als Text mit ausgeben (im obigen Beispiel hab ich bewusst drauf verzichtet ;)). Also... ausprobieren... und siehe da... meine Styles sind wieder da... und alles ist gut! So einfach kann‘s manchmal sein.
Das Wegschneiden von HTML-Kommentaren ist eigentlich sinnvoll, denn es sind unnötige Bytes die hier in der Gegend rum geschickt werden - das allerdings auskommentierte Styles weggeschnitten werden... halte ich für einen Bug. Allerdings konnte ich die entsprechende Stelle im Code - auch nach langem Suchen - nicht finden... was mich ehrlich gesagt schon ein bisschen wurmt!
Jetzt noch mal kurz was zum Thema Newsletter und CSS im Allgemeinen. Bekanntlich verhalten sich die vielen Mail-Clients (online u. offline) höchst unterschiedlich was die Darstellung von CSS angeht. Daher ist es wichtig Formatierungen auf ein Minimum zu reduzieren. Beim Newsletter-Design (bei Webseiten bin ich ähnlicher Meinung) gilt: Weniger ist Mehr! Ihr erspart Euch jede Menge Ärger, wenn Ihr das das Design schlicht und mit wenigen Formatierungen gestaltet. Es gibt eine ausgezeichnete Übersicht welche Email-Clients was unterstützen - das sollte an dieser Stelle weiterhelfen. Und nachdem wir den CSS-Code damit sehr klein halten, halte ich es für sinnvoll den Code wie im obigen Beispiel direkt in den HTML-Code mit aufzunehmen und nicht über eine extern Datei einzubinden. Es hat den Vorteil, dass die korrekte Darstellung des Newsletters so nicht von der Verfügbarkeit Eures Servers abhängt. Und wie oben beschrieben... bloß nicht auskommentieren! Ich sehe das auch nicht als kritisch an. Die Clients die das <style> Tag nicht unterstützen kann man meiner Ansicht nach vernachlässigen - wenn es überhaupt noch welche gibt ist diese Zahl sehr gering (das sieht man selbst bei SELFHTML so).
Na dann… viel Erfolg beim Newsletterversand!
Dienstag, 22. Juli 2008
Hardcore SEO beim SEOktoberfest
Party und SEO beim SEOktoberfest mit QuadsZilla, Marcus, und Rsnake. Das ist mit Sicherheit das top SEO-Event, dass es so bisher noch nicht gegeben hat. Hier erfährst Du, wie man im Internet richtig Geld verdienen kann. Und die Jungs wissen wirklich wie das geht! Und dazu, wird noch richtig gefeiert - und auch das können die Jungs richtig gut ;)! Zunächst gehts zum Oktoberfest um danach noch mal richtig in den Münchner Clubs abfeiern zu können. Tische sind reserviert und VIP Zugang zu den Clubs ist auch schon sichergestellt - Marcus kennt sich da ja bestens aus ;)! Aus der "Wissens-Sicht" ist noch wichtig zu erwähnen, dass die Runde auf ca. 20 Personen begrenzt ist - es gibt daher auch nur 10 freie Plätze. D.h. man hat durch die kleine Gruppe auch wirklich die Möglichkeit mit allen zu reden und so richtig viel mit nach Hause zu nehmen. Natürlich bekommt man das nicht für Umme - Teilnahme kostet 5000 €. Aber wie schon gschrieben, bekommt man dafür erstklassiges SEO Wissen. Und richtig eingesetzt, kann man die 5000 € schnell wieder reinholen. Alle Infos zum Event gibts hier: SEOktoberfest.
Unter allen Bloggern die darüber berichten, wird ein Platz verlost... darauf hoffe ich... slso, drückt mir die Daumen ;)!
Sehe gerade, Marcus hat auf seinem Blog ne deutsche Version gschrieben... SEOktoberfest - deutsche Version.
Hab noch vergessen, dass es oben drauf noch eine einjährige Mitgliedschaft im SEO Blackhat Forum gibt. Das kostet sonst auch $ 100 / Monat.
Unter allen Bloggern die darüber berichten, wird ein Platz verlost... darauf hoffe ich... slso, drückt mir die Daumen ;)!
Sehe gerade, Marcus hat auf seinem Blog ne deutsche Version gschrieben... SEOktoberfest - deutsche Version.
Hab noch vergessen, dass es oben drauf noch eine einjährige Mitgliedschaft im SEO Blackhat Forum gibt. Das kostet sonst auch $ 100 / Monat.
Dienstag, 8. Juli 2008
Kluges TypoScript Template Management
Mit wachsender Website wird auch das TypoScript Template zunehmend Größer. Liegt einfach daran, dass man im Eifer des Gefechts jede menge "Bugfixes" hinzufügt die das TS Template nach und nach immer mehr aufblähen. Wer kennt das nicht? Und irgendwann stellt man fest, dass man sich darin nicht mehr auskennt... blöd!
Mit einigen Kniffen bzw. einem überlegten Management der Templates lässt sich dieses Problem von vornherein vermeiden. Und wie sieht das Ganze aus?
Man muss sich zunächst davon verabschieden alle TypoScript Einstellungen in einem einzigen Template (nämlich im Root Template) unterbringen zu wollen. Grundsätzlich benötigt man für jede Website einige "Standardkomponenten". Dazu gehört z.B.:
Hier werden alle Templates abgelegt
Diese Einzeltemplates bindet man dann im entsprechenden Root-Template der Website ein. Hierfür gibt es einen separaten Beriech im TS-Template und zwar "Include basis template". Dazu muss man zuvor auf "Click here to edit whole template record" klicken. Damit hat man die Möglichkeit beliebige (und beliebig viele) Templates, die auf irgendeiner Seite im Seitenbaum abgelegt sind, hinzuzufügen.
Wird gerne mal übersehn...
Hier werden die Templates aus dem Sys-Ordner hinzugefügt
Eigentlich ganz einfach... ;) Ich leg mir gerne noch ein zusätzliches Test TS Template an, indem ich Änderungen zunächst ausprobieren kann. Manchmal muss man ja ein bisschen experimentieren. Sind die Tests abgeschlossen, übernehm ich die Änderungen in das von mir dafür vorgesehene TS Template.
Dieses "System" hat ein Schwäche... Ihr werdet feststellen, dass die Entscheidung "in welches Template pack ich denn jetzt die Änderungen?" manchmal etwas schwer fällt ;). Der große Vorteil dabei ist, dass man sich automatisch etwas mehr Gedanken über seine Template Struktur machen muss... wodurch man sich wesentlich besser zurechtfindet - auch bei großen Sites!
Mit einigen Kniffen bzw. einem überlegten Management der Templates lässt sich dieses Problem von vornherein vermeiden. Und wie sieht das Ganze aus?
Man muss sich zunächst davon verabschieden alle TypoScript Einstellungen in einem einzigen Template (nämlich im Root Template) unterbringen zu wollen. Grundsätzlich benötigt man für jede Website einige "Standardkomponenten". Dazu gehört z.B.:
- die Navigation: sämtliche Navi-Elemente die mit TypoScript erzeugt werden
- Basiseinstellungen: Im Prinzip sämtliche "config." Einstellungen (Sprache, Doctype, BaseURL, Header, Meta-Tags, ...)
- Irgendwelche Default Styles (css)
- Konfiguration der Plugins (RealURL, News, ...)
Hier werden alle Templates abgelegt
Wird gerne mal übersehn...
Hier werden die Templates aus dem Sys-Ordner hinzugefügtEigentlich ganz einfach... ;) Ich leg mir gerne noch ein zusätzliches Test TS Template an, indem ich Änderungen zunächst ausprobieren kann. Manchmal muss man ja ein bisschen experimentieren. Sind die Tests abgeschlossen, übernehm ich die Änderungen in das von mir dafür vorgesehene TS Template.
Dieses "System" hat ein Schwäche... Ihr werdet feststellen, dass die Entscheidung "in welches Template pack ich denn jetzt die Änderungen?" manchmal etwas schwer fällt ;). Der große Vorteil dabei ist, dass man sich automatisch etwas mehr Gedanken über seine Template Struktur machen muss... wodurch man sich wesentlich besser zurechtfindet - auch bei großen Sites!
Freitag, 4. Juli 2008
Snippet Archiv für TYPO3 gestartet
Gerade auf t3n gelesen, dass ein Snippet Archiv für TYPO3 Code-Schnipsel gestartet wurde. Hier hat man die Möglichkeit Code-Schnipsel, gerade für häufig auftretende Problemstellungen, zu finden und natürlich auch einzustellen. Darüber hinaus gibt's die Möglichkeit die eingestellten Schnipsel zu bewerten und zu kommentieren. Tags können natürlich auch vergeben und entsprechend gesucht werden.
Hab mir das mal schnell angeschaut... Optisch ist es noch nicht so ansprechend - muss es eigentlich auch gar nicht sein. Ansonsten ist es intuitiv zu bedienen und die ersten Snippets sind auch schon eingestellt. Was ich noch vermisse, ist die Möglichkeit beim erstellen eines Snippet noch ein Screenshot hochzuladen. Gerade bei Layout Geschichten fände ich das sehr sinnvoll. Da sieht auf einen Blick was das Code-Schnipsel so tut und muss es nicht erst im Detail analysieren. Aber das wird bestimmt noch.
Ich kann mir schon vorstellen, dass das Ganze gut angenommen wird - eine entsprechende Beteiligung vorausgesetzt. Die Idee finde ich auf jeden Fall echt klasse! Und wie so oft frag ich mich... "das da noch keiner früher drauf gekommen ist?" ;)
Weiterführende Links:
Hab mir das mal schnell angeschaut... Optisch ist es noch nicht so ansprechend - muss es eigentlich auch gar nicht sein. Ansonsten ist es intuitiv zu bedienen und die ersten Snippets sind auch schon eingestellt. Was ich noch vermisse, ist die Möglichkeit beim erstellen eines Snippet noch ein Screenshot hochzuladen. Gerade bei Layout Geschichten fände ich das sehr sinnvoll. Da sieht auf einen Blick was das Code-Schnipsel so tut und muss es nicht erst im Detail analysieren. Aber das wird bestimmt noch.
Ich kann mir schon vorstellen, dass das Ganze gut angenommen wird - eine entsprechende Beteiligung vorausgesetzt. Die Idee finde ich auf jeden Fall echt klasse! Und wie so oft frag ich mich... "das da noch keiner früher drauf gekommen ist?" ;)
Weiterführende Links:
Freitag, 20. Juni 2008
Schlanke Websites: Ladezeiten verkürzen, Code/Content Verhältnis verbessern
Grundsätzlich sollte man immer versuchen Webseiten so "schlank" wie nur möglich zu halten. Das bedeutet, dass der reine Code (HTML, JavaScript und CSS) auf ein Minimum reduziert werden muss. Abgesehen davon, dass diese Maßnahme die Ladezeiten zum Teil deutlich verinngern kann hat es noch weitere Vorteile. Zum einen verringert sich dadurch die Serverauslastung - je mehr Traffic eine Seite hat, desto deutlicher wird man diesen Effekt merken. Und zum anderen verbessert sich das Verhältnis zwischen Code und Content - das sog. Code/Content Verhältnis. Das spielt vor allem aus SEO-Sicht eine nicht zu unterschätzende Wirkung. Durch weniger Code gewinnt der Website-Content an Bedeutung (und die darin enthaltenen Keywords auch ;)). Und mal ehrlich... wie würdet Ihr, aus der Sicht einer Suchmaschine, eine Seite beurteilen die jede menge Code aber kaum Text enthält? Eben! Kurz: Schlanke Seiten wirken sich positiv auf die Nutzererfahrung bzw. Usability und das Ranking in Suchmaschinen aus. Worauf also noch warten?
Damit will ich eine Beitragsreihe ins Leben rufen die in mehreren Schritten zeigt wie man dem oben gestecktem Ziel näher kommen kann. Da ich bis jetzt noch nicht genau weiß, was mir dazu alles einfällt bzw. was ich mit aufnehme, gibt es an dieser Stelle zunächst mal keine Übersicht ;). Ich beginne einfach mit dem ersten Thema und wir sehen mal was noch so alles kommt...
Schlanke Seiten Tipp 1: JavaScript und CSS auslagern
Die Ausgabe von TYPO3 beinhaltet zum Teil sehr viel JavaScript und CSS Code. Das hängt vor allem mit den installierten Extensions zusammen. Mit wenigen Zeilen TypoScript Code kann man dieses unschöne Verhalten jedoch abstellen.
# remove JavaScript to external files
config.removeDefaultJS = external
# remove CSS to external files
config.inlineStyle2TempFile = 1
Diese Zeilen können hier raus kopiert und direkt in das Haupt-TypoScript-Template der Website eingebunden werden.
Darüber hinaus ist es sinnvoll "_CSS_DEFAULT_STYLE" sämtlicher Plugins - sofern man die standard CSS Ausgabe nicht braucht - zu löschen. Normalerweise übernehm ich alles was ich brauche in ein eigenes CSS und deaktivier danach die Standardausgabe. Das hält die Dateien schlanker und verhindert, dass irgendeine Einstellung "im Hintergrund" zu Fehlern führt.
Immer dran denken: Aufräumen heißt die Devise - also weg mit allem was man nicht unbedingt braucht!
Um die Standardausgabe zu unterbinden folgende Zeilen in das Haupt-TypoScript-Template einfügen:
# clear default CSS styles - only if using plugin css_styled_content plugin.tx_cssstyledcontent._CSS_DEFAULT_STYLE >
# clear default CSS styles of Plugin tx_veguestbook_pi1 plugin.tx_veguestbook_pi1._CSS_DEFAULT_STYLE >
Die erste Zeile benötigt man beim Einsatz von CSS Styled Content. Die zweite zeigt wie man für ein anderes Plugin (hier tx_veguestbook_pi1 - Plugin für Kommentare) die Standard CSS Ausgabe unterbindet.
Dann könnte man noch den TYPO3 Header entfernen der standardmäßig im bereich mit ausgegeben wird... davon halte ich jedoch nichts! Immerhin kann man TYPO3 kostenlos nutzen - da sollte man das auch sehen können. Das ist meine persönliche Meinung und deshalb gibt den Tipp auch nicht ;).
Das soll's fürs Erste mal gewesen sein...
Noch eine Anmerkung an dieser Stelle: Eine Auswirkung meiner früheren Tätigkeit als Programmieren ist, dass ich besonders auf sauberen Code achte (meistens zumindest ;)). Dazu gehört auch, dass man deutsch/englische Programmierung vermeidet. Nachdem TYPO3 und sämtliche Dokumentationen in englischer Sprache sind, sind auch meine Code Beispiele hier im Blog englisch. Früher oder später muss man sich ja im Umgang mit TYPO3 sowieso an das Englisch gewöhnen ;).
Damit will ich eine Beitragsreihe ins Leben rufen die in mehreren Schritten zeigt wie man dem oben gestecktem Ziel näher kommen kann. Da ich bis jetzt noch nicht genau weiß, was mir dazu alles einfällt bzw. was ich mit aufnehme, gibt es an dieser Stelle zunächst mal keine Übersicht ;). Ich beginne einfach mit dem ersten Thema und wir sehen mal was noch so alles kommt...
Schlanke Seiten Tipp 1: JavaScript und CSS auslagern
Die Ausgabe von TYPO3 beinhaltet zum Teil sehr viel JavaScript und CSS Code. Das hängt vor allem mit den installierten Extensions zusammen. Mit wenigen Zeilen TypoScript Code kann man dieses unschöne Verhalten jedoch abstellen.
# remove JavaScript to external files
config.removeDefaultJS = external
# remove CSS to external files
config.inlineStyle2TempFile = 1
Diese Zeilen können hier raus kopiert und direkt in das Haupt-TypoScript-Template der Website eingebunden werden.
Darüber hinaus ist es sinnvoll "_CSS_DEFAULT_STYLE" sämtlicher Plugins - sofern man die standard CSS Ausgabe nicht braucht - zu löschen. Normalerweise übernehm ich alles was ich brauche in ein eigenes CSS und deaktivier danach die Standardausgabe. Das hält die Dateien schlanker und verhindert, dass irgendeine Einstellung "im Hintergrund" zu Fehlern führt.
Immer dran denken: Aufräumen heißt die Devise - also weg mit allem was man nicht unbedingt braucht!
Um die Standardausgabe zu unterbinden folgende Zeilen in das Haupt-TypoScript-Template einfügen:
# clear default CSS styles - only if using plugin css_styled_content plugin.tx_cssstyledcontent._CSS_DEFAULT_STYLE >
# clear default CSS styles of Plugin tx_veguestbook_pi1 plugin.tx_veguestbook_pi1._CSS_DEFAULT_STYLE >
Die erste Zeile benötigt man beim Einsatz von CSS Styled Content. Die zweite zeigt wie man für ein anderes Plugin (hier tx_veguestbook_pi1 - Plugin für Kommentare) die Standard CSS Ausgabe unterbindet.
Dann könnte man noch den TYPO3 Header entfernen der standardmäßig im bereich mit ausgegeben wird... davon halte ich jedoch nichts! Immerhin kann man TYPO3 kostenlos nutzen - da sollte man das auch sehen können. Das ist meine persönliche Meinung und deshalb gibt den Tipp auch nicht ;).
Das soll's fürs Erste mal gewesen sein...
Noch eine Anmerkung an dieser Stelle: Eine Auswirkung meiner früheren Tätigkeit als Programmieren ist, dass ich besonders auf sauberen Code achte (meistens zumindest ;)). Dazu gehört auch, dass man deutsch/englische Programmierung vermeidet. Nachdem TYPO3 und sämtliche Dokumentationen in englischer Sprache sind, sind auch meine Code Beispiele hier im Blog englisch. Früher oder später muss man sich ja im Umgang mit TYPO3 sowieso an das Englisch gewöhnen ;).
Sonntag, 15. Juni 2008
TYPO3 + 1und1 = "500 Internal Server Error" im Frontend?
Auf einem "1&1 Homepage Business" Webhosting-Paket von 1und1 hab ich TYPO3 in der Version 4.1.6 am laufen - inzwischen ;). Bei der Installation gab es soweit keine Probleme und auch das Backend lief ohne Probleme... doch sobald ich in das Frontend wechselte: 500 - Internal Server Error. Woran könnte das wohl liegen?
Zunächst hab ich mal die Standards überprüft - das ist immer sinnvoll:
So kann's gehen... und damit Ihr nicht so lange suchen müsst hier die Anleitung wie es geht:
Folgende 2 Zeilen am Anfang der .htaccess Datei des Root-Verzeichnis (also dort wo auch die index.php liegt) einfügen:
AddType x-mapp-php5 .php
AddHandler x-mapp-php5 .php
Das ganze findet man auch im 1und1 Hilfe-Center unter : http://hilfe-center.1und1.de/hosting/scripte_datenbanken/php/18.html
Der TYPO3 Installation liegt bereits eine .htaccess Datei bei. Die heißt allerdings noch "_.htaccess" und enthält jede menge Einstellungen vor allem für den Einsatz von RealURL (dazu werd ich bei Gelegenheit mal was schreiben) und einige Einstellungen rund um PHP und den Server im Allgemeinen. Sofern man RealURL nicht einsetzt und sich mit den .htaccess Einstellungen nicht wirklich auskennt, rate ich von der "_.htaccess" Datei die Finger zu lassen und stattdessen eine neue .htaccess Datei mit den 2 Zeilen Code von oben zu erstellen.
Na dann... viel Spaß mit TYPO3!
Zunächst hab ich mal die Standards überprüft - das ist immer sinnvoll:
- Schreibrechte der verschiedenen Ordner (über TYPO3 Install Tool - Basic Configuration oder 'nen FTP-Client): Alles ok.
- max. Laufzeit der PHP Skripte (max_execution_time ebenfalls TYPO3 Install Tool): 50000 Sek. - passt.
- Memory Limit (memory_limit ebenfalls TYPO3 Install Tool): 40 MB - passt auch.
So kann's gehen... und damit Ihr nicht so lange suchen müsst hier die Anleitung wie es geht:
Folgende 2 Zeilen am Anfang der .htaccess Datei des Root-Verzeichnis (also dort wo auch die index.php liegt) einfügen:
AddType x-mapp-php5 .php
AddHandler x-mapp-php5 .php
Das ganze findet man auch im 1und1 Hilfe-Center unter : http://hilfe-center.1und1.de/hosting/scripte_datenbanken/php/18.html
Der TYPO3 Installation liegt bereits eine .htaccess Datei bei. Die heißt allerdings noch "_.htaccess" und enthält jede menge Einstellungen vor allem für den Einsatz von RealURL (dazu werd ich bei Gelegenheit mal was schreiben) und einige Einstellungen rund um PHP und den Server im Allgemeinen. Sofern man RealURL nicht einsetzt und sich mit den .htaccess Einstellungen nicht wirklich auskennt, rate ich von der "_.htaccess" Datei die Finger zu lassen und stattdessen eine neue .htaccess Datei mit den 2 Zeilen Code von oben zu erstellen.
Na dann... viel Spaß mit TYPO3!
Sonntag, 8. Juni 2008
Was gibt's hier zu lesen?
Gut, wie der Name unschwer erkennen lässt geht es hier um TYPO3 - allem voran um Tipps im Umgang damit. Und wie kommt's? TYPO3 war lange Zeit der Schwerpunkt meiner Arbeit. Inzwischen trifft das nicht mehr ganz zu... Meine Schwerpunkte sind jetzt vor allem Suchmaschinenoptimierung und Web-Usability. Dennoch verwende ich TYPO3 vor allem für eigene Projekte immer wieder gerne. Denn, wer sich erst einmal in das System "reingebissen" hat - der Einstieg ist nicht gerade leicht, da sehr umfangreich - wird schnell feststellen, dass es sich um ein geniales Content Management System handelt, mit dem man nahezu alles treiben kann was einem so einfällt! Mit etwas Erfahrung kann man damit sehr schnell neue Seiten hochziehen. Zudem hat man mit der Zeit immer mehr Vorlagen und Code-Schnippsel gesammelt die einem das erstellen neuer Seiten zusätzlich erleichtern.
Wie ich schon geschrieben hab, arbeite ich inzwischen nicht mehr so häufig mit TYPO3 was dazu führt, dass so manche Kniffe die ich mir (mehr oder weniger hart) erarbeitet hab, in einem nicht mehr zugänglichen Bereich meines Hirns verschwinden. Wird ein neues Auto eingeparkt, muss eben ein altes raus... Deshalb werde zukünftig sämtliche Kniffe die auf dem besten Weg sind ausgeparkt zu werden, hier zwischenparken ;). Und ich hoffe - naja, eigentlich bin ich mir sicher - dass das Eine oder Andere für Euch ebenfalls von Nutzen sein wird!
Na, dann... kann's ja losgehen!
Auf gute Tipps, Maddin
Wie ich schon geschrieben hab, arbeite ich inzwischen nicht mehr so häufig mit TYPO3 was dazu führt, dass so manche Kniffe die ich mir (mehr oder weniger hart) erarbeitet hab, in einem nicht mehr zugänglichen Bereich meines Hirns verschwinden. Wird ein neues Auto eingeparkt, muss eben ein altes raus... Deshalb werde zukünftig sämtliche Kniffe die auf dem besten Weg sind ausgeparkt zu werden, hier zwischenparken ;). Und ich hoffe - naja, eigentlich bin ich mir sicher - dass das Eine oder Andere für Euch ebenfalls von Nutzen sein wird!
Na, dann... kann's ja losgehen!
Auf gute Tipps, Maddin
Abonnieren
Posts (Atom)
