Seit TYPO3 4.3 gibt es eine Einstellung in TYPO3, mit der man beim Einbinden von CSS und JavaScript Dateien eine Versionsnummer an die URL anhängen kann. Dies kann man im Install Tool einstellen:

$TYPO3_CONF_VARS['BE']['versionNumberInFilename'] = '1'; // Umstellung für das Backend
$TYPO3_CONF_VARS['FE']['versionNumberInFilename'] = '1'; // Umstellung für das Frontend

Das hat den Vorteil, dass sich die Versionsnummer beim Cache löschen ändert, und somit auch im Quellcode dadurch beim Anfordern der Datei eine neue Nummer mitgegeben wird – somit wird die Datei nicht aus dem Browser-Cache geladen – das ist natürlich besonders praktisch, wenn man etwas am JS oder CSS ändert. Früher musste man den Browser Cache löschen.. damit man die  JS / CSS Änderungen sah.

Mit der Versionisierung gehört dies der Vergangen heit an.

Beim Entwickeln von Extensions wird aber meistens nur der Standardpfad ohne Versionierung in den Header geschrieben…  

Wie man ein JavaScript (gilt auch für CSS) mit der Versionsnummer hintendran in seine Extension einfügt, habe ich in meinem WIKI dokumentiert.

Ein interessanter Artikel über den Umgang mit google Webfonts zu Vermeidung von Fehlern: Avoiding Faux Weights And Styles With Google Web Fonts | Smashing Magazine.

Ich bin auf eine ältere Duropack Zeitschrift mit der Bekanntgabe des neuen Webauftritts ( TYPO3) und einem Interview mit mir (Christian Holzmann) gestoßen – das waren noch Zeiten!

Habe hier einen alten (2007er) Artikel wieder entdeckt, Basics über CSS float left, right etc… und ich dachte, ich poste ihn einfach mal, da es immer wieder vorkommt, dass floats “falsch” verstanden und verwendet werden… oder komplett eine Seite mit position absolute/relativ aufbaut – dabei kann man mit floats so schöne Sachen machen! :

http://coding.smashingmagazine.com/2007/05/01/css-float-theory-things-you-should-know/

Wenn das TYPO3-Backend im Internet Explorer nicht mehr korrekt dargestellt wird, so liegt das daran, dass für den IE hier zu viele CSS Dateien eingebunden werden…

Lösung: Einfach im install tool oder direkt in der Datei typo3conf/localconf.php das Debugging deaktivieren.

[BE][debug]=0

Das behebt den Fehler!

Möchte man in TYPO3 nicht nur die Keywords, die für die aktuelle Seite angegeben sind angeben, sondern Keywords und Description auch auf Unterseiten vererben, hilft folgender TYPOSCRIPT-Code (ich gehe davon aus, dass das Standard-Page Objekt “page” heisst):

page.meta.description {
 data = page:description
 ifEmpty.data = levelfield :-1, description, slide
}
page.meta.keywords {
 data = page:keywords
 ifEmpty.data = levelfield :-1, keywords, slide
}

iPhoto ist nun auch für iPad / iPhone verfügbar – Review folgt bald!:

Normalerweise kann man ja in HTML an geben, wo mein FavIcon liegen soll. Dies funktioniert auch fast in allen
Browsern, nur der Internet Explorer wehrt sich gewaltig gegen ein FavIcon, welches NICHT im ROOT Verzeichnis liegt.
Besonders beim IE9 regen sich viele über das plötzliche Fehlen von FavIcons bei vielen Sites auf.

Ein Ansatz, den ich mir überlegt habe ist Folgender:
Ich gebe dem IE einfach das was er will… mit einem “FaviCon Proxy”

Im HTML sieht es ganz einfach so aus:

 HTML | 
 copy code |
?
 
1
<link rel="icon" type="image/ico" href="favicon.ico" />
2
<link rel="shortcut icon" type="image/x-icon" href="favicon.ico" />

Doch ich habe Apache mit dem mod_rewrite Modul so konfiguriert, dass er
mir einfach JE NACH DOMAIN ein anderes FavIcon zurück gibt…

Dazu braucht man: das mod_rewrite Modul.
Eine .htaccess Datei im root-Verzeichnis (oder man stellt die folgende Configuration in die jeweilige vhost-Config)

In die .htaccess Datei schreibe ich Folgendes:

 Apache configuration | 
 copy code |
?
 
01
# Enable URL rewriting
02
<ifmodule mod_rewrite.c>
03
RewriteEngine On
04
 
05
#Favicon?
06
RewriteCond %{HTTP_HOST} ^.*domain1.*$ [NC]
07
RewriteRule ^favicon\.ico$ http://%{HTTP_HOST}/fileadmin/templates/grafiken/favicondomain1.ico [L]
08
 
09
RewriteCond %{HTTP_HOST} ^.*domain2.*$ [NC]
10
RewriteRule ^favicon\.ico$ http://%{HTTP_HOST}/fileadmin/templates/grafiken/favicondomain2.ico [L]
11
 
12
RewriteCond %{HTTP_HOST} ^.*domain3.*$ [NC]
13
RewriteRule ^favicon\.ico$ http://%{HTTP_HOST}/fileadmin/templates/grafiken/favicondomain3.ico [L]
14
 
15
RewriteCond %{HTTP_HOST} ^.*domain4.*$ [NC]
16
RewriteRule ^favicon\.ico$ http://%{HTTP_HOST}/fileadmin/templates/grafiken/favicondomain4.ico [L]
17
</ifmodule>
18
 
19

Das ist vorerst mal eine Lösung für http, nicht für https (war aber in diesem Fall nicht nötig).

– Main.ChristianHolzmann – 28 Dec 2011

Seit PHP 5.4 alpha 2 bietet PHP die Möglichkeit, Scripte direkt im “hauseigenen” Webserver zu testen.

Wenn man ein Script also schnell mal testen möchte, kann man den Server starten:
Zuerst sollte man in das Verzeichnis gehen, wo die Scripte liegen. Danach ruft man den Server auf, der dann genau dieses Verzeichnis verfügbar macht:
php -S localhost:PORT

Man kann natürlich auch ein Verzeichnis angeben:
php -t VERZEICHNIS -S localhost:PORT

In einem Web-Browser kann dann die URL aufgerufen werden:
http://localhost:PORT/SCRIPTNAME.php

Praktisch: In der Konsole sieht man dann auch gleich die Fehler, die eventuell auftreten (Bilder nicht gefunden…. favicon etc…)

Weitere Infos zur 5.4 beta1 gibts hier: http://www.php.net/releases/NEWS_5_4_0_beta1.txt

Ich bin gespannt, wann die etwas größeren Sites mal mit HTML5 Ersatz-Videoangeboten nachziehen!