Zum Beispiel gibt uns die Seite http://www.domain.tld/index.php?id=39 die selben Inhalte wie http://www.domain.tld/ich-liebe-canonical-urls.html oder auch http://www.domain.tld/ich-liebe-canonical-urls/.

Die Suchmaschine bekommt alle 3 Links und verwaltet diese als 3 verschiedene Seiten. Da die Seite aber die selben Inhalte haben, straft die Suchmaschine die Seite(n) wegen Duplicate Content ab.

Hilfe bekommt man durch einen kleine Zeile im Header der Seite, dem Canonical Tag.
Im TYPO3 gibt man an, welche URL nun die richtige ist und setzt sie in diesen Canonical Tag. Somit weiß die Suchmaschine auch beim Besuch der “anderen” zwei Seiten, dass die wirklich richtige Seite unter der URL im Canonical Tag erreichbar ist.

Schwierig wird dieses Unterfangen, wenn es weitere Parameter in der URL gibt, die z.B. tt_news und andere Extensions benötigen. Man braucht einige Parameter, aber beileibe nicht alle. Im Beispiel tt_news ist der Parameter backPid z.B. unnötig, da er die Inhalte nicht wesentlich beeinflußt.

Da die Extension “canonical” unter der 4.6.8 nicht mehr funktioniert, habe ich mir ein TypoScript-Schnipsel aufgebaut, welches die meisten meiner Fälle abdeckt. Natürlich muss dieses Schnipsel je nach Anforderung angepasst werden, doch das meiste dürfte überall passen:

page.headerData.778 = TEXT
# Aktuelle Seite
page.headerData.778.typolink.parameter.data = TSFE:id
# Gib nur die URL zurück
page.headerData.778.typolink.returnLast = url
# Erstelle eine absolute URL
page.headerData.778.typolink.forceAbsoluteUrl = 1
# Fügt alle GET-Parameter hinzu, wie z.B. tt_news, L und auch cHash
page.headerData.778.typolink.addQueryString = 1
page.headerData.778.typolink.addQueryString.method = GET
# Schliesst bestimmte Parameter aus, z.B. cHash oder auch backPid von tt_news
page.headerData.778.typolink.addQueryString.exclude = cHash,backPid
# Wrappen und mit dem richtigen Tag einbinden. 
# Das Leerzeichen nach dem öffnenden Tag bitte entfernen
page.headerData.778.wrap = < link rel="canonical" href="|" />

Ich hoffe, einige können damit etwas anfangen.
Das TypoScript ist natürlich nicht die eierlegende Wollmilchsau für jede Seite, sondern fordert besonders beim Parameter exclude noch Nacharbeit.
Diese kann übrigens darunter einfach mit folgendem Snippet bearbeitet werden.

page.headerData.778.typolink.addQueryString.exclude := addToList(extParam1, extParam2)

------------------------------------------------------
Dies ist ein Post vom TYPO3 Blog typo3blogger.de!

Seit dem Wochenende gibt es jetzt ein Plugin für PhpStorm, dass TypoScript Unterstützung nachrüstet. Für den Anfang sind das Syntax Highlighting, Code Folding und die Quick Navigation. Soweit ich das bisher testen konnte, funktioniert das Plugin nur mit dem heute erschienenen 4.0.1 RC, nicht aber mit Version 3.0.3 und älter.

Die Installation geht in wenigen Schritten über File => Settings => Plugins =>Browse Repositories und dann nach TypoScript suchen. Am Mac kommt man über PhpStorm => Preferences => Plugins => Browse Repositories zum selben Ergebnis.

Ein großes Dankeschön geht an Alexey Gopachenko und Elena Shaverdova von JetBrains, die diese erste Version entwickelt und kostenlos zur Verfügung gestellt haben. Für die Zukunft ist geplant, das Plugin unter eine Open Source Lizenz zu stellen oder durch die TYPO3 Community weiterentwickeln zu lassen.

Bitte testet das Plugin ausführlich und bewertet es bzw. gebt ein Rating ab. Weiteres Feedback und Bugs können im Issue im JetBrains Bugtracker eingetragen werden. Wenn die TYPO3 Community genügend Interesse an dem Plugin zeigt, wird JetBrains bestimmt gerne weitere Verbesserungen vornehmen!

Update: Danke an Kabarakh für den Hinweis: wenn man unter Settings => File Types => Recognized File Types => TypoScript  noch *.ts einfügt, funktiniert das Plugin auch mit alten Versionen von PhpStorm!

Update 2: Laut Jigal van Hemert kann man die Registered Patterns auch wie folgt erweitern:

*.ts
setup.txt
constants.txt
ext_conf_template.txt
ext_typoscript_setup.txt
ext_typoscript_constants.txt

------------------------------------------------------
Dies ist ein Post vom TYPO3 Blog typo3blogger.de!

Dabei kommt uns eine Extension zugute, die seit TYPO3 4.5 im Core ist. Diese heißt “backend_layout” und als neuer Datensatz heißt er “Backend Layout”:

Backend Layout Datensatz

Ein neues Backend Layout können wir unsere eigene oder vom Kunden gewünschte Inhaltsstruktur mittels des Wizards erstellen. Wir erstellen heute ein Layout, welches in der oberen Hälfte aus zwei Spalten und in der unteren Hälfte aus einer Spalte über die gesamte Breite besteht:

Backend Layout Wizard

Hier sieht man schön die zukünftige Struktur. Man sieht auch, dass ich jeden Bereich mit einer Zahl fest definiert habe. Diese Zahlen müssen wir uns merken für das TypoScript später.

Nachdem wir das Backend Layout gespeichert haben, können wir uns sogleich mal an das TypoScript machen. Merken müssen wir uns noch die UID des Backend Layouts. Und so geht es los:

# Ein CASE Objekt schaut, welcher Fall eintritt und handelt dementsprechend.
temp.contentStructure = CASE
temp.contentStructure {
  # Durch den Key können wir festlegen, auf welches Feld er prüft, in diesem Fall das Feld
  # "backend_layout" im Seiten-Datensatz.
  key.field = backend_layout
  # Falls das Feld leer ist, schaut er rekursiv bis zur Root Page, ob irgendwo das Feld gesetzt ist.
  key.ifEmpty.data = levelfield:-2, backend_layout_next_level, slide
 
  # Die UID des Backend Layout Datensatzes, in unserem Falle die 1
  1 = COA
  1.10 = COA
  1.10.wrap = <div class="maincolumns">|<div class="clear"></div></div>
  # Spalte oben links 
  1.10.10 < styles.content.get 
  1.10.10.select.where = colPos = 1 
  1.10.10.wrap = <div class="column first">|</div>
  # Spalte oben rechts 
  1.10.20 < styles.content.get 
  1.10.20.select.where = colPos = 2 
  1.10.20.wrap = <div class="column second">|</div>
  # Spalte unten 
  1.20 < styles.content.get 
  1.20.select.where = colPos = 3 
  1.20.wrap = <div>|</div>
} 
 
# Wir kopieren das Objekt in die Variable content 
page.10.variables.content < temp.contentStructure

Damit setzen wir für jede Spalte (colPos = vorher gesetzte Spaltennummer) auch direkt das HTML. Mit den verschiedenen Klassen können wir dann auch im Frontend per CSS die Struktur nachbauen, wie wir sie im Backend erstellt haben:

div.first {
  float: left;
  width: 50%;
}
div.second {
  float: right;
  width: 50%;
}
div.clear {
  clear: both;
}

Natürlich hat man Unmengen von Möglichkeiten, um sich mittels der Spalten verschiedene Backend Layouts zusammenzustellen.
Ach, und die Auswahl erfolgt über den Seiten-Datensatz im Backend. Dort gibt es die Möglichkeit ein Backend Layout für die Seite, aber auch rekursiv für alle darunterliegenden Seiten zu setzen:

Backend Layout Auswahl

Viel Spaß beim Probieren!

------------------------------------------------------
Dies ist ein Post vom TYPO3 Blog typo3blogger.de!

Angefangen wird mit dem neuen TypoScript Objekt FLUIDTEMPLATE.

Als Alternative zum Marker Based Templating (richtig Old School) und dem teils gehasstem, teils verehrtem TemplaVoilá gibt es nun seit TYPO3 4.5 das FLUIDTEMPLATE. Es ist keine Installation nötig, man kann es direkt per TypoScript initialisieren:

page = PAGE
page.10 = FLUIDTEMPLATE
page.10.file = fileadmin/template/my_template.html

Hiermit haben wir dem System gesagt, dass das Template my_template.html genutzt werden soll.

Wie üblich, werden verschiedene Elemente des Templates im TypoScript zusammengebaut, wie z.B. verschiedene Menus. Diese speichern wir in temporären Objekten namens temp.mainMenu, temp.subMenu oder auch temp.footerMenu.

Ich gehe jetzt mal davon aus, dass jeder weiß, wie man ein Menu im TypoScript erstellt, daher kopieren wir das fertige Objekt direkt in das FLUIDTEMPLATE:

page.10.variables {
  mainMenu < temp.mainMenu
  subMenu < temp.subMenu
  footerMenu < temp.footerMenu
}

Wir kopieren unsere erstellen Menustrukturen in Variablen im FLUIDTEMPLATE, um sie dann im HTML direkt anzusprechen:

<div id="mainMenu">
  <f:format.html>{mainMenu}</f:format.html>
</div>

Man sieht an dem Tag, dass ein Fluid Tag genutzt wird. “format.html” ist ein ViewHelper, der die Ausgabe in reinem HTML ausgibt. Die vorher definierte Variable wird mittels den geschweiften Klammern {variable} angesprochen, die wir ja vorher im TypoScript mit einem MENU Objekt gefüllt haben.

Das Gesamte kann jetzt natürlich mit allen möglichen TypoScript Objekten gefüllt werden. Auch Partials und Sections sind nutzbar, doch der Einfachheit halber soll dieses Beispiel ausreichen.

Natürlich kann man auch das HTML je nach TypoScript Objekt abhängig machen, indem man die Wenn-Abfrage von Fluid nutzt. So kann ich die HTML-Struktur abhängig von einem möglichen zweiten Menu machen und die Ebenen jeweils benennen:

<f:if condition="{submenu}">
  <f:then>
    <div id="content_wrap">
      <div id="submenu">
        <f:format.html>{subMenu}</f:format.html>
      </div>
      <div id="content">
        <f:format.html>{content}</f:format.html>
      </div>
    </div>
  </f:then>
  <f:else>
    <div id="content_wide">
      <f:format.html>{content}</f:format.html>
    </div>
  </f:else>
</f:if>

Im zweiten Teil erkläre ich, wie man die backend_layouts nutzen kann, um den Content Bereich gemütlich mit verschiedenen Layouts zu füttern.

------------------------------------------------------
Dies ist ein Post vom TYPO3 Blog typo3blogger.de!

Ablauf der Abmeldung
Im Formular ist nur die E-Mail Adresse anzugeben, die aus dem Newsletterverteiler entfernt werden soll. Nach dem Absenden wird die eingetragenen E-Mail Adresse zunächst validiert (Tx_Formhandler_Validator_Default (gültige E-Mail Adresse und ob sie in der Tabelle tt_address existiert)) und bei Erfolg wird in der Tabelle tt_address für den existierenden Datensatz, basierend auf der angegebenen E-Mail Adresse, das Feld hidden auf 1 gesetzt (Finisher_DB).

Alle weiteren Schritte, wie versenden von E-Mails an User und Admin, habe ich in diesem Tutorial weggelassen, da sie genau wie im Tutorial Newsletteranmeldung, umgesetzt werden können.

plugin.Tx_Formhandler.settings.predef.newsletter {
	# Common configuration
	name = Newsletterabmeldung
	addErrorAnchors = 1
	templateFile = fileadmin/templates/formhandler/newsletter_unsubscribe.html
	langFile.1 = fileadmin/templates/formhandler/newsletter_unsubscribe.xml
	cssFile.1 = fileadmin/css/my.css
	formValuesPrefix = formhandler
 
	requiredSign = TEXT
	requiredSign.value = *
	requiredSign.wrap = <span style="color: #DF9707;">|</span>
 
	#isErrorMarker.default = class="errorField"
	isErrorMarker.default =
 
	# HTML wrapping by validation error
	errorListTemplate {
		totalWrap = <div class="error">|</div>
		singleWrap = &nbsp;|&nbsp;
	}
 
	#PreProcessors
	preProcessors {
		1.class = PreProcessor_LoadGetPost
	}
 
	# Validators configuration
	validators {
		1 {
			class = Tx_Formhandler_Validator_Default
			config {
				fieldConf {
					emailunsubscribe {
						errorCheck.1 = required
						errorCheck.2 = email
						errorCheck.3 = isInDBTable
						errorCheck.3 {
							table = tt_address
							field = email
							fields {
								email.mapping = emailunsubscribe
							}
						}
					}
				}
			}
		}
	}
 
	# Finishers configuration
	finishers {
		1.class = Finisher_DB
		1.config {
		  debug = 1
			table = tt_address
			updateInsteadOfInsert = 1
			key = email
			key_value = TEXT
			key_value.data = GPvar:formhandler|emailunsubscribe
			fields {
				hidden.ifIsEmpty = 1
				email.mapping = emailunsubscribe
			}
		}
		2.class = Finisher_Redirect
		2.config {
			redirectPage = 97
		}
	}
}

<!-- ###TEMPLATE_FORM1### begin -->
<div id="formhandler_newsletter_unsubscribe_form">
	<form method="post" action="###REL_URL###">
	<table>
		<tr>
			<td>###LLL:newsletter_intro_unsubscribe###</td>
		</tr>
		<tr>
			<td>
				<table>
					<tr>
						<td class="newsletterlabel">###LLL:emailunsubscribe### ###required_emailunsubscribe###</td>
						<td><input type="text" ###is_error_emailunsubscribe### name="formhandler[emailunsubscribe]" id="emailunsubscribe" value="###value_emailunsubscribe###" size="30" class="newsletterinput"/></td>
					</tr>
			  </table>
			</td>
		<tr>
			<td class="newslettertext">###LLL:required_fields###</td>
		</tr>
		<tr>
			<td class="newslettertext">###LLL:newsletter_text_1###</td>
		</tr>
    <tr>
    	<td>&nbsp;</td>
    </tr>
    <tr>
    	<td><input type="submit" value="###LLL:submit###" ###submit_nextStep###/></td>
	  </tr>
    <tr>
    	<td>###ERROR###</td>
	  </tr>
	</table>
	</form>
</div>
<!-- ###TEMPLATE_FORM1### end -->
 
<!-- ###TEMPLATE_SUBMITTEDOK### begin -->
<table>
  <tr>
    <td>###LLL:emailunsubscribe###</td>
    <td>###value_emailunsubsrcibe###</td>
  </tr>
</table>
<!-- ###TEMPLATE_SUBMITTEDOK### end -->

<?xml version="1.0" encoding="utf-8" standalone="yes" ?>
<T3locallang>
	<data type="array">
		<languageKey index="default" type="array">
 
			<label index="emailunsubscribe">E-Mail</label>
 
			<label index="required_fields">* Pflichtfelder</label>
			<label index="newsletter_text_1">Die Daten werden nicht an Dritte weitergegeben.</label>
			<label index="submit">Formular senden</label>
 
			<label index="error_emailunsubscribe_required">Gültige E-Mail Adresse bitte eingeben.</label>
			<label index="error_emailunsubscribe_email">Gültige E-Mail Adresse bitte eingeben.</label>
			<label index="error_emailunsubscribe_isInDBTable">Diese E-Mail Adresse ist nicht registriert.</label>
		</languageKey>
	</data>
</T3locallang>

Dies ist ein Gast-Beitrag von Alois Rainbacher. Vielen Dank dafür.

------------------------------------------------------
Dies ist ein Post vom TYPO3 Blog typo3blogger.de!

Heute möchte ich eine für den Integrator einfache und für den Redakteur übersichtliche Methode zeigen, um solche Effekte ohne Extension und ohne die teils nervigen Updates nachzubauen.

Einzige Bedingung hierfür ist die TYPO3 Version >= 4.6 und die Extension “gridelements“.
Einfach über den Extension Manager installieren und – nicht vergessen – die statischen Templates einbinden.

Als Beispiel habe ich mir heute den Effekt “Accordion” ausgesucht.

Wir beginnen damit, ein Grid Element anzulegen mit dem redakteursunterstützenden Namen Accordion. Im Wizard für die Elemente sind wir schnell fertig, da wir nur diesen einen Kasten benötigen. Wir geben der “Spalte” auch den Namen Accordion und die Spaltennummer ist die “1″.

Nachdem wir das Grid Element gespeichert haben, müssen wir nur noch das TypoScript einfügen:

tt_content.gridelements_pi1.20.10.setup {
  # ID of gridelement
  1 < temp.gridelements.defaultGridSetup
  1 {
    columns {
      # colPos ID
      1 < .default
      1.wrap = <div class="accordion">|</div>;
    }
  }
}

Die HTML-Grundstruktur haben wir jetzt. Nun brauchen wir das nötige JavaScript. Das finden wir unter http://jqueryui.com. Dort können wir für das Accordion nötige JS zusammenstellen lassen. Dieses müssen wir herunterladen, entpacken und in unsere TYPO3 Instanz hochladen.
Dann die nötigen TypoScript-Befehle:

# CSS von Accordion / Theme ui-lightness
page.includeCSS.accordion = fileadmin/res/css/ui-lightness/jquery-ui-1.8.18.custom.css
# jQuery Source
page.includeJSFooterlibs.jquery = fileadmin/res/js/jquery-1.7.1.min.js
# jQuery UI Accordion Source
page.includeJSFooter.accordion = fileadmin/res/js/jquery-ui-1.8.18.custom.min.js
# jQuery UI Accordion Init
page.includeJSFooter.accordion_init = fileadmin/res/jquery-accordion.js

Die letzte Datei jquery-accordion.js müssen wir selbst erstellen und den initialisierenden Code hineinschreiben:

$(function() {
  $( ".accordion" ).accordion();
});

Da laut Dokumentation der Standard-Header ein <h3> ist, wir in unserem Beispiel aber die css-styled-content Erweiterungen nutzen, müssen wir den Code anpassen:

$(function() {
  $( ".accordion" ).accordion({ header: 'div.csc-header' });
});

Weitere Anpassungen von Accordion kann man auf der Seite von jQuery UI einsehen.

Somit müssten wir jetzt ein schönes Resultat finden, wenn wir Inhaltselement in das Grid Element hineinziehen (Drag’n'Drop möglich):

------------------------------------------------------
Dies ist ein Post vom TYPO3 Blog typo3blogger.de!

------------------------------------------------------
Dies ist ein Post vom TYPO3 Blog typo3blogger.de!

------------------------------------------------------
Dies ist ein Post vom TYPO3 Blog typo3blogger.de!

Zum einen ist Anfang des Jahres Netbeans 7.1 erschienen, welches in der PHP-Version Verbesserungen für die Entwicklung mit sich bringt und aktuelle Standards wie CSS3 und HTML5 unterstützt: Screencast

Zum anderen hat Daniel Franek seit Ende des letzten Jahres ein Netbeans-Plugin zur Verfügung gestellt mit dem Netbeans auch TypoScript versteht.
Unterstützt werden in der aktuellen Version Syntax-Highleighting, Autocomplete, Code- und Datei-Templates. Mit von der Partie sind sind die Macher von „SweeTS“ – die Agentur familie redlich :systeme. Aktueller Stand auf GitHub.

------------------------------------------------------
Dies ist ein Post vom TYPO3 Blog typo3blogger.de!

Hier möchte ich euch gerne mit den häufigst gebrauchten Snippets Abhilfe verschaffen.

Das wichtigste zuerst: sämtliche Konfigurationen der Dateiliste sind per TypoScript im Setup-Teil des Templates vorzunehmen und finden im tt_content.uploads.20 Bereich statt. Dank des mittlerweile standardmäßig vorhandenen TypoScript Editor im Backend sind zwar schon viele Einstellungen per “Suggest Drop-Down” zu erahnen, aber halt doch nicht immer so durchsichtig.

Sinnvolle Dateigrößen-Bezeichnungen einpflegen:

tt_content.uploads.20.itemRendering.30.bytes.labels = Byte | KB | MB | GB

Dateiendung (*.pdf, *.doc, etc.) verstecken:

tt_content.uploads.20.stripFileExtensionFromLinkText = 1

Thumbnail-Generierung beeinflussen:

tt_content.uploads.20.linkProc.iconCObject.file.maxH = 100 #maximale Höhe der Thumbnails
tt_content.uploads.20.linkProc.iconCObject.file.maxW = 100 # maximale Breite der Thumbnails
# etc.

Bestimmen welches Frame eines GIFs bzw. welche Seite eines PDFs angezeigt werden soll:

tt_content.uploads.20.linkProc.iconCObject.file.maxH = 100 #maximale Höhe der Thumbnails
tt_content.uploads.20.linkProc.iconCObject.file.frame = 2 # zweite Seite eines PDFs als Thumbnail generieren

Viel Spaß beim Experimentieren!

------------------------------------------------------
Dies ist ein Post vom TYPO3 Blog typo3blogger.de!

Immer mehr und mehr internetfähige Endgeräte gelangen auf dem Markt und werden mehr und mehr auch zum Surfen im Internet genutzt. Aktuell werden täglich 700.000 Smartphones mit Android aktiviert wie Andy Rubin gestern auf Twitter verkündete. Und auch Peter-Paul Koch schrieb in seinem Blogbeitrag “IE market share”, dass jetzt schon weltweit mehr Websites über mobile Endgeräte angesurft werden, als über IE6 und IE7 zusammen.

Aber Responsive Webdesign ist nicht einfach nur das Anpassen der Styles für mobile Endgeräte, Responsive Webdesign ist eher eine Konzept, eine Herangehensweise an die Gestaltung für den Nutzer – dem Nutzer in jeder Situation das beste Erlebnis mit der Website geben. Auf die Grundlagen zu Responsive Webdesign möchte ich an dieser Stelle auch nicht weiter eingehen, das haben andere Kollegen bereits gut zusammengefasst.

Zugrunde liegt eine Technik die mit CSS3 in modernen Browser implementiert ist, die @media Query-Regeln. Die @media-Regeln sind ja bereits mit CSS2 eingeführt worden und wurden bisher zum Unterscheiden von Ausgabegeräten benutzt, z.B. <link rel="stylesheet" href="css/screen.css" media="screen"> für Bildschirme und z.B. <link rel="stylesheet" href="css/print.css" media="print"> für die Druckausgabe. In CSS3 können nun mit @media-Queries die Endgerät-Eigenschaften abgefragt werden, z.B. Bildschirmgröße oder Auflösung. Auch hier möchte ich nicht zu sehr ins Detail gehen, das hat Michael Jendrischyk in seinen Slides zu Media Queries bereits excellent gemacht. Aktuell nutze ich folgende @media Query-Regeln für meine Projekte:

/* Smaller than standard 960 (devices and browsers) */
@media only screen and (max-width: 959px) {}
 
/* Tablet Portrait size to standard 960 (devices and browsers) */
@media only screen and (min-width: 768px) and (max-width: 959px) {}
 
/* All Mobile Sizes (devices and browser) */
@media only screen and (max-width: 767px) {}
 
/* Mobile Landscape Size to Tablet Portrait (devices and browsers) */
@media only screen and (min-width: 480px) and (max-width: 767px) {}
 
/* Mobile Portrait Size to Mobile Landscape Size (devices and browsers) */
@media only screen and (max-width: 479px) {}
 
/* highres devices */
@media screen and (-moz-min-device-pixel-ratio:1.5),
	screen and (-o-min-device-pixel-ratio:3/2),
	screen and (-webkit-min-device-pixel-ratio:1.5),
	screen and (min-device-pixel-ratio:1.5){}

Responsive TYPO3

Um Responsive Layouts (Flexible Layouts) nun in TYPO3 zu verwenden bedarf es einigen Anpassungen an der Ausgabe von CSS-Styled-Content. Für die kommende TYPO3 Version 4.7 wurden ja bereits umfängliche Änderungen an der Frontend-Ausgabe angekündigt, die zudem der Barrierefreiheit dienen. Hier wurden auch die “Problemfälle” eliminiert, die mit der Ausgabe von Bildern im Responsive Layout zu meistern sind. So müssen u.A. die festen Breiten, die über das style-Attribut in den Wrappern eingebunden sind entfernt werden. Das Layout sollte optimalerweise flexibel angelegt sein, also keine Pixelwerte. Folgende Typoscript-Snippets müssen ins Typoscript-Setup Template eingetragen werden:

tt_content.image.20 {
  imageStdWrap.dataWrap = <div class="csc-textpic-imagewrap"> | </div>
  imageColumnStdWrap.dataWrap = <div class="csc-textpic-imagecolumn"> | </div>
}

Auch beim Rendering selbst muss das style-Attribut entfernt werden.

tt_content.image.20 {
  rendering {
    dl {
      imageRowStdWrap.dataWrap = <div class="csc-textpic-imagerow"> | </div>
      imageLastRowStdWrap.dataWrap = <div class="csc-textpic-imagerow csc-textpic-imagerow-last"> | </div>
      oneImageStdWrap.dataWrap = <dl class="csc-textpic-image###CLASSES###" > | </dl>
    }
    ul {
      imageRowStdWrap.dataWrap = <div class="csc-textpic-imagerow"><ul> | </ul></div>
      imageLastRowStdWrap.dataWrap = <div class="csc-textpic-imagerow csc-textpic-imagerow-last"><ul> | </ul></div>
      oneImageStdWrap.dataWrap = <li class="csc-textpic-image###CLASSES###"> | </li>
    }
    div {
      imageRowStdWrap.dataWrap = <div class="csc-textpic-imagerow"> | </div>
      imageLastRowStdWrap.dataWrap = <div class="csc-textpic-imagerow csc-textpic-imagerow-last"> | </div>
      oneImageStdWrap.dataWrap = <div class="csc-textpic-image###CLASSES###"> | </div>
    }
    simple {
      imageStdWrap.dataWrap = <div class="csc-textpic-imagewrap csc-textpic-single-image"> | </div>
    }
  }
}

Optional kann man auf das HTML5 Markup für Bilder mit Bildunterschrift umstellen.

tt_content.image.20 {
  renderMethod = figure
  rendering {
    figure {
      imageRowStdWrap.dataWrap = <div class="csc-textpic-imagerow"> | </div>
      imageLastRowStdWrap.dataWrap = <div class="csc-textpic-imagerow csc-textpic-imagerow-last"> | </div>
      noRowsStdWrap.wrap = 
      oneImageStdWrap.dataWrap = <figure class="csc-textpic-image"> | </figure>
      imgTagStdWrap.wrap =   |  
      editIconsStdWrap.wrap = <div> | </div>
      caption.wrap = <figcaption> | </figcaption>
      caption.required = 1
    }
  }
}

Das wichtigste ist allerdings, dass zusätzlich Anpassungen am CSS getätigt werden. Für flexible Bilder muss folgende Regel zugewiesen werden:

img, embed, object, video {
  max-width: 100%;
  height: auto;
  width: auto;
}

Die Anweisung legt fest, dass Bilder (sowie embed-, object, und video-Tags) eine max. Breite von 100% haben, also so groß wie die CSC-Konstante styles.content.imgtext.maxW her gibt. Zudem müssen die Höhe und Breite auf auto gesetzt werden.
Desweiteren müssen einige CSS-Styles von css_styled_content mit dem eigenen Stylesheet überschrieben werden:

DIV.csc-textpic-above DIV.csc-textpic-imagewrap,
DIV.csc-textpic-below DIV.csc-textpic-imagewrap,
DIV.csc-textpic DIV.csc-textpic-imagewrap UL LI,
DIV.csc-textpic DIV.csc-textpic-imagewrap DL.csc-textpic-image {
	float: none;
}

Cross-Browser-Kompatibilität

Da es sich um eine Technik für die modernen Webentwicklung handelt, wird es nicht verwundern, dass @media-Queries nicht im IE8 oder IE7 funktionieren. Meiner Meinung nach, ist es zudem fraglich, ob sie das sollten. Wer diese Browser trotzdem mit @media Queries unterstützen muss, dem hilft respond.js. Die Library ist mittlerweile auch in modernizr integriert.

Links

CSS3 & Responsive Web – mein Vortrag beim MMT28 (Slides & Video)
mediaqueri.es – tolle @media Queries Galerie
Responsive Webdesign Testing

Die aufgeführten Änderungen für die Frontend-Ausgabe mit CSS Styled Content sind nur ein paar Grundlagen und hat keine Anspruch auf Vollständigkeit. Wenn ihr Ergänzungen habt, schreibt gern eure Meinung in den Kommentaren dazu.

------------------------------------------------------
Dies ist ein Post vom TYPO3 Blog typo3blogger.de!

1. Backend-Layout anlegen

Als erstes im System-Ordner, den man bei “Allgemeine Datensatzsammlung” der Root-Seite angegeben hat, einen neuen Datensatz vom Typ “Backend-Layout” anlegen. Man vergibt einen Titel (z. B. Startseite oder Unterseite) und  öffnet über “Konfiguration” den sog. “Grid wizard”. Dort lässt sich dann ein Backend-Layout zusammen klicken, das in meinem Fall auch die Ausgabe im Frontend widerspiegelt.

Die einzelnen Bereiche lassen sich noch benennen und mit Spaltennummern (colPos) versehen.

2. Backend-Layout auswählen

Nach dem Speichern, kann dieses Backend-Layout bereits in den Seiteneigenschaften einer Seite ausgewählt werden. Dazu einfach den Reiter “Erscheinungsbild” anklicken.

Man kann das Backend-Layout für die aktuelle Seite und für deren Unterseiten einstellen. Nach der Auswahl zeigt das Backend direkt die vorher getroffene Konfiguration an – und zwar in korrekter Spalten- und Zeilen-Aufteilung.

Somit wäre das Backend schon mal fertig konfiguriert. Bei Bedarf kann man sich natürlich noch weitere Backend-Layouts bzw. Seiten-Templates anlegen.

3. Die Verknüpfung mit dem Frontend

Um die angelegten Backend-Layouts mit der Ausgabe zu verknüpfen, benötigt man nur folgendes Typoscript Setup:

page = PAGE
page.10 = FLUIDTEMPLATE
page.10 {
	file.stdWrap.cObject = CASE
	file.stdWrap.cObject {
		# slide the template
		key.data = levelfield:-1, backend_layout_next_level, slide
		key.override.field = backend_layout
		# default template file
		default = TEXT
		default.value = fileadmin/templates/index.html
		# template file for backend-layout with ID 2
		2 = TEXT
		2.value = fileadmin/templates/subpage.html
	}
}

Im obigen Beispiel wird abhängig vom gewählten Backend-Layout, eine entsprechendes Template-Datei verwendet. Ich habe ein Standard-Template (default) angegeben und ein Template für das Backend-Layout mit der ID 2. Bei weiteren vorhanden Backend-Layouts, kann diese Liste natürlich erweitert werden. Dazu nur die korrekte ID benutzen.

4. Inhalte für die Ausgabe im Template bereitstellen

Wer von Templavoila kommt, dürfte z. B. die Navigation immer per “TypoScript Object Path” eingebunden haben. Die gute Nachricht: diese können beibehalten und direkt im Template aufgerufen werden. Aber wie kommt man an die Inhaltsbereiche? Mit Templavoila wurden diese als “Content Elements” gemapped. Jetzt benötigt man hier ein wenig Typoscript. (Ich gehe davon aus, dass CSS Styled Content benutzt wird.)

lib.field_content < styles.content.get
lib.field_content.select.where = colPos = 2

Hier auf die korrekte Angabe der colPos achten. Je nach Anzahl der Inhaltsbereiche, muss diese Anweisung natürlich “vervielfältigt” werden.

5. Die Template-Datei

Die Template-Datei, die im “fileadmin” liegt, beinhaltet dann vom Prinzip nur noch den Inhalt des <body> Bereichs. Den Rest baut TYPO3 ja automatisch drum herum. Das HTML-Template könnte dann z. B. so aussehen:

<div id=”header”>
<f:cObject typoscriptObjectPath=”lib.field_navmain” />
</div>
<div id=”content”>
<f:cObject typoscriptObjectPath=”lib.field_content” />
</div>

In diesem Beispiel benutze ich nur den <f:cObject> View-Helper von Fluid, um direkt auf die im Typoscript angelegten Content-Objekte zuzugreifen. Fluid aber auch Fluidtemplate bieten natürlich noch viele weitere Möglichkeiten, mit denen man sein Template anreichern kann.

Und hier sind wir schon am Ende. Mehr ist nicht nötig.

Fazit

Im Vergleich zu Templavoila bin ich mit dieser Template-Methode um einiges schneller, da das aufwändige Mapping wegfällt. Und das Anlegen der extra Backend-Layouts für Templavoila-Templates spart man sich dadurch auch.

------------------------------------------------------
Dies ist ein Post vom TYPO3 Blog typo3blogger.de!

Im folgenden Tutorial werden wir kaum Angaben im Plugin vom Formhandler machen. Alles was wir benötigen sind 4 Dateien und eine Zeile TypoScript. Vor- und zugleich Nachteil von Formhandler ist, dass jegliche Konfiguration in Dateien ausgelagert werden muss/sollte, was dann aber wiederum den Vorteil hat, dass diese Konfiguration sehr schnell auf ein anderes System portieren kann. Nach der Einbindung der TypoScriptzeile erscheint im Plugin ein neuer Eintrag in der Selectbox für “Vordefinierte Formulare”. Einfach auswählen. Fertig.

Ich werde hier nicht auf jede einzelne Option von Formhandler eingehen, das würde den Rahmen sprengen. Wenn es Euch interessiert, dann könnt Ihr die Webseite von Formhandler oder auch mein erstes Tutorial lesen, dass ich auf meiner Webseite präsentiere: Stefans TYPO3-Seite.

Ablauf der Anmeldung

Wir erstellen eine Seite mit einem Formular auf dem sich die beiden Felder name und email befinden. Nach dem Absenden werden die eingetragenen Daten zunächst validiert (Tx_Formhandler_Validator_Default) und bei Erfolg in die Tabelle tt_address abgespeichert (Finisher_DB). Hier setze ich die Spalte hidden per default auf 1, damit der User nicht sofort aktiv ist. Natürlich wäre auch eine Speicherung in fe_users möglich, aber dann müssten wir dem Datensatz noch eine Gruppe, einen Benutzernamen und ein Passwort zuordnen. Zu viel für meinen Geschmack. Nach der Speicherung wird aus den gesammelten Daten ein AuthCode erstellt (Finisher_GenerateAuthCode) und per Mail an der User und als Info auch an den Admin geschickt (Tx_Formhandler_Finisher_Mail). Klickt der User den Link mit dem enthaltenen AuthCode an, wird der PreProcessor aktiv (PreProcessor_LoadGetPost) und läd sich die benötigten Daten aus der URL in den Speicher. An Hand dieser Daten kann der AuthCode-Validator aktiv werden (PreProcessor_ValidateAuthCode). Dieser überprüft, ob der AuthCode gültig ist und setzt den Datensatz bei einer erfolgreichen Überprüfung automatisch auf visible (hidden=0). Außerdem können hier je nach Gültigkeit Page-UIDs angegeben werden auf die weitergeleitet wird.

newsletter.ts

plugin.Tx_Formhandler.settings.predef.newsletter {
	# Common configuration
	name = Newsletterregistrierung
	addErrorAnchors = 1
	templateFile = fileadmin/templates/formhandler/newsletter.html
	langFile.1 = fileadmin/templates/formhandler/newsletter.xml
	cssFile.1 = fileadmin/templates/formhandler/newsletter.css
	formValuesPrefix = formhandler
 
	requiredSign = TEXT
	requiredSign.value = *
	requiredSign.wrap = <span style="color: #DF9707;">|</span>
 
	isErrorMarker.default = class="errorField"
 
	# HTML wrapping by validation error
	errorListTemplate {
		totalWrap = <div class="error"><ul>|</ul></div>
		singleWrap = <li>|</li>
	}
 
	#PreProcessors
	preProcessors {
		1.class = PreProcessor_LoadGetPost
		2.class = PreProcessor_ValidateAuthCode
		2.config {
			redirectPage = 234
			errorRedirectPage = 235
			hiddenField = hidden
		}
	}
 
	# Validators configuration
	validators {
		1 {
			class = Tx_Formhandler_Validator_Default
			config {
				fieldConf {
					name {
						errorCheck.1 = required
					}
					email {
						errorCheck.1 = required
						errorCheck.2 = email
					}
				}
			}
		}
	}
 
	# Finishers configuration
	finishers {
		1.class = Finisher_DB
		1.config {
			table = tt_address
			key = uid
			fields {
				email.mapping = email
				name.mapping = name
				pid.ifIsEmpty = 57
				hidden.ifIsEmpty = 1
				module_sys_dmail_html.ifIsEmpty = 1
			}
		}
		2.class = Finisher_GenerateAuthCode
		2.config {
			table = tt_address
		}
		3.class = Tx_Formhandler_Finisher_Mail
		3.config {
			limitMailsToUser = 5
			admin {
				to_email = AdminEmailAdresse
				to_name = DeinNamw
				subject = Neue Newsletterregistrierung auf [webseite]
				sender_email = webmaster@xxx
				sender_name = Webmaster
				htmlEmailAsAttachment = 0
			}
			user {
				to_email = email
				to_name = name
				subject = Dein Anliegen von [webseite]
				sender_email = webmaster@xxx
				sender_name = Webmaster
				replyto_email = DeineEmailAdresse
				replyto_name = TEXT
				replyto_name.value = Deine Name
				htmlEmailAsAttachment = 0
		 	}
		}
		4.class = Finisher_Redirect
		4.config {
			redirectPage = 233
		}
	}
}

newsletter.xml

<?xml version="1.0" encoding="utf-8" standalone="yes" ?>
<T3locallang>
	<data type="array">
		<languageKey index="default" type="array">
			<label index="name">Name</label>
			<label index="email">E-Mail</label>
			<label index="submit">Send</label>
			<label index="is_error">One or more errors occoured while filling the form!</label>
			<label index="error_name_required">Enter your name!</label>
			<label index="error_email_required">Enter your E-mail address!</label>
			<label index="error_email_email">E-mail address must be valid syntax!</label>
			<label index="required_fields">Fields marked with * are required!</label>
		</languageKey>
		<languageKey index="de" type="array">
			<label index="name">Name</label>
			<label index="email">E-Mail</label>
			<label index="submit">Absenden</label>
			<label index="is_error">Beim Absenden des Formulars sind ein paar Fehler aufgetreten:!</label>
			<label index="error_name_required">Bitte gib Deinen Namen an!</label>
			<label index="error_email_required">Bitte gib Deine E-Mail-Adresse an!</label>
			<label index="error_email_email">Die eingetragene E-Mail-Adresse ist ungültig!</label>
			<label index="required_fields">Felder mit * sind Pflichtfelder!</label>
		</languageKey>
	</data>
</T3locallang>

newsletter.html

<!-- ###TEMPLATE_FORM1### begin -->
<div id="formhandler_newsletter_form">
	###ERROR###
	<form method="post" action="###REL_URL###">
		<p>###LLL:required_fields###</p>
		<input type="hidden" name="formhandler[submitted]" value="1" />
		<dl>
			<dt><label for="name">###LLL:name### ###required_name###</label></dt>
			<dd><input type="text" ###is_error_name### name="formhandler[name]" id="name" value="###value_name###"/></dd>
		</dl>
		<dl>
			<dt><label for="email">###LLL:email### ###required_email###</label></dt>
			<dd><input type="text" ###is_error_email### name="formhandler[email]" id="email" value="###value_email###"/></dd>
		</dl>
		<dl>
			<dd><input type="submit" value="###LLL:submit###" ###submit_nextStep###/></dd>
		</dl>
	</form>
</div>
<!-- ###TEMPLATE_FORM1### end -->
 
<!-- ###TEMPLATE_EMAIL_USER_PLAIN### begin -->
Hallo ###value_name###,
 
Du hast Dich soeben für meinen Newsletter auf [webseite] angemeldet.
Bitte klicke auf den folgenden Link, um die Registrierung abzuschließen:
 
###value_authCodeUrl###
<!-- ###TEMPLATE_EMAIL_USER_PLAIN### end -->
 
<!-- ###TEMPLATE_EMAIL_USER_HTML### begin -->
<p>Hallo ###value_name###</p>
<p>Du hast Dich soeben für meinen Newsletter auf [webseite] angemeldet.<br />
Bitte klicke auf den folgenden Link, um die Registrierung abzuschließen:</p>
<p><a href="###value_authCodeUrl###" target="_blank">Newsletteranmeldung bestätigen</a></p>
<!-- ###TEMPLATE_EMAIL_USER_HTML### end -->
 
<!-- ###TEMPLATE_EMAIL_ADMIN_PLAIN### begin -->
Hallo Admin,
 
Soeben hat sich ###value_name### (###value_email###) für den Newsletter auf [webseite] angemeldet.
 
Dein Server
<!-- ###TEMPLATE_EMAIL_ADMIN_PLAIN### end -->
 
<!-- ###TEMPLATE_EMAIL_ADMIN_HTML### begin -->
<p>Hallo Admin,</p>
<p>Soeben hat sich ###value_name### (###value_email###) für den Newsletter auf [webseite] angemeldet</p>
<p>Dein Server</p>
<!-- ###TEMPLATE_EMAIL_ADMIN_HTML### end -->
 
<!-- ###TEMPLATE_SUBMITTEDOK### begin -->
<table>
  <tr>
    <td>###LLL:name###</td>
    <td>###value_name###</td>
  </tr>
  <tr>
    <td>###LLL:email###</td>
    <td>###value_email###</td>
  </tr>
</table>
<!-- ###TEMPLATE_SUBMITTEDOK### end -->

newsletter.css

#formhandler_newsletter_form {
	width: 100%;
}
 
#formhandler_newsletter_form .error ul {
	margin: 0;
}
 
.errorField {
	background-color: #FF0000;
}

Die eine Zeile TypoScript

<INCLUDE_TYPOSCRIPT: source="FILE:fileadmin/templates/formhandler/newsletter.ts">

------------------------------------------------------
Dies ist ein Post vom TYPO3 Blog typo3blogger.de!

Also habe ich nach einer Möglichkeit gesucht, die Icons zu verändern, ohne den TYPO3 Core dafür ändern zu müssen, um so die Updatefähigkeit von TYPO3 zu erhalten. Per TypoScript lässt sich das Ziel erreichen.

Zunächst habe ich in fileadmin einen eigenen Ordner “fileadmin/filelist/icons” erstellt und dort meine eigenen Icons abgelegt. Alle Dateien haben als Dateinamen die entsprechende Dateiendung, also z.B. pdf.png, xls.png, xlsx.png, mov.png und so weiter.

TYPO3 4.6

Für TYPO3 4.6 gibt es eine recht einfache Möglichkeit, das Problem zu lösen: Für stdWrap wurde die neue Eigenschaft “replacement” eingeführt. Dadurch lassen sich Zeichenketten leicht ersetzen. Auch Reguläre Ausdrücke (RegEx) sind möglich.

tt_content.uploads.20.itemRendering.10 {
	stdWrap {
		replacement {
			10.search = typo3/sysext/cms/tslib/media/fileicons
			10.replace = fileadmin/filelist/icons
 
			20.search = .gif
			20.replace = .png
		}
 
		HTMLparser = 1
		HTMLparser {
			allowTags = a,img
			tags.img.fixAttrib.width.set = 32
			tags.img.fixAttrib.height.set = 32		}
	}
}

In meinem Codebeispiel wird zum einen der Pfad, der von der von CSS Styled Content mitgelieferten UserFunc stammt, durch meinen eigenen Pfad ersetzt, zum anderen ändere ich die Dateiendung von .gif auf .png ab. Über den HTML Parser ändere ich die ursprünglich generierten Größenangaben auf 32 Pixel. Um das Code Beispiel auf eigene Projekte anzuwenden, muss also nur der Pfad, die Dateiendung und die Größe der Icons angepasst werden. Der zweite Screenshot zeigt die Veränderung.

TYPO3 4.5 und älter

In TPYO3 4.5 und älteren Versionen ist die Änderung wesentlich komplizierter, da hier nicht auf stdWrap.replacement zurückgegriffen werden kann. Aber auch hier gibt es eine Lösung:

tt_content.uploads.20.itemRendering.10 >
tt_content.uploads.20.itemRendering.10 = IMAGE
tt_content.uploads.20.itemRendering.10 {
	file {
		import = fileadmin/filelist/icons/
		import {
			data = register:fileExtension
			wrap = |.png
		}
 
		width = 32
		height = 32
	}
 
	stdWrap.ifEmpty.cObject = IMAGE
	stdWrap.ifEmpty.cObject {
		file = fileadmin/filelist/icons/default.png
		file.width = 32
		file.height = 32
	}
 
	stdWrap {
		typolink {
			parameter.stdWrap {
				wrap = uploads/media/
				data = register:linkedLabel
				HTMLparser = 1
				HTMLparser.allowTags =
			}
		}
 
		wrap = [td class="csc-uploads-icon"]|[/td]
	}
 
	if.isPositive.field = layout
}

Als erstes muss die ursprüngliche Programmierung von CSS Styled Content zurückgesetzt werden. Danach wird das Icon komplett neu aufgebaut. Über file.import wird das passende Icon zur Dateiendung gerendert. Falls es für die gewünschte Dateiendung kein Icon im angegebenen Ordner geben sollte, wird mit stdWrap.ifEmpty.cObject ein Default Icon gerendert. Als letztes wird das Icon noch auf die eigentliche Datei verlinkt. Über den HTML Parser wird etwas getrickst und der eigentlich komplette HTML Code aus der UserFunc, bestehend aus a Tag und img Tag gelöscht, so dass nur der eigentliche Dateiname übrig bleibt. Der td Wrap am Schluss gehört natürlich in spitze Klammern. Der Code wird hier im Blog aber leider nicht korrekt angezeigt.

Beide TypoScript Schnipsel können in einer Text Datei runtergeladen werden.

Fazit

Mit TypoScript lässt sich mal wieder viel erreichen, ohne den TYPO3 Core dafür anfassen oder auch nur eine Zeile PHP Code schreiben zu müssen.

Es gibt bestimmt noch andere, elegantere Wege, die Datei Icons in Dateilisten zu ersetzen. Ich bin auf eure Kommentare gespannt.

------------------------------------------------------
Dies ist ein Post vom TYPO3 Blog typo3blogger.de!

Die Google Wetter API ist leider nicht dokumentiert, ist eigentlich auch nur für die Weather-Widgets in iGoogle gedacht. Die Standard-API liefert zudem nicht unbedingt hübsche Icons. Vorteil ist allerdings, dass Sie eine Wetter-Vorhersage über mehrere Tage liefert. Glücklicherweise ist es nicht so schwer die Wetter-Vorhersage auf der eigenen TYPO3-Website anzuzeigen und dazu eigene Symbole zu verwenden.

Man kann natürlich extra eine kleine TYPO3-Extension schreiben, ist aber unnötig, da ja keine Daten (in der Datenbank) gespeichert werden müssen. Es genügt, wenn man eine sogenannte User-Function schreibt und diese per Marker in die Website einfügt. Unsere User-Function ist auch schon so vorbereitet, dass man eigene Wetter-Icon verwenden und die Location einfach im TYPOscript editieren kann, aber dazu später mehr.

Schritt 1: Marker in HTML-Template einfügen

An die Stelle wo später das Wetter-Modul ausgegeben werden soll, wird ein Marker im Template angelegt, z.B.:

<div>###WETTER###</div>

Schritt 2: Marker im TYPOscript enbinden

In dem Tutorial verwenden wir ein klassisches TYPO3 Marker-Template und fügen den Marker im page-Objekt hinzu, in meinem Fall:

page.10 = TEMPLATE
page.10 {
  ...
  marks {
    WETTER < lib.weather
    ...
  }
}

Schritt 3: Die PHP User-Funktion für die Google-Wetter API Abfrage

Zwingend notwendig für das Einbinden einer eigenen PHP-Datei über eine User-Function in TYPO3 sind folgende 3 Punkte:

•    Dateiname beginnt mit “user_”
•    Die PHP-Datei enthält eine Klasse die mit “user_” beginnt
•    die PHP-Funktion übergibt mit “return” die Inhalte an TYPO3

Schritt 4: User-Function in TYPO3 einbinden

Die User-Function wird jetzt in TYPO3 eingebunden und über die Variablen konfiguriert

/**
* lib.weather
* @description:    wetter ausgabe in html
*/
includeLibs.weather = fileadmin/scripts/user_weather.php
 
lib.weather = USER
lib.weather {
  userFunc = user_weather->get
  poi = Hamburg
  path = /fileadmin/templates/img/wetter-icons/
  png = 1
}

Im cObject USER können wie schon erwähnt Variablen definiert werden. Für die Location, für den das Wetter über die Weather-API abgerufen werden soll, füllt man die Variable “poi” mit dem Ort, in unserem Fall “Hamburg”. Zudem kann man in “path” den Pfad zu den eigenen Wetter-Symbolen angeben. Ist die Variable nicht gefüllt, werden die Standard Wetter-Symbole von Google verwendet.

Folgende Wetter-Zustände kennt die Google Wetter API (Quelle: www.web-spirit.de):

chance_of_rain
sunny
mostly_sunny
partly_cloudy
mostly_cloudy
chance_of_storm
showers
rain
chance_of_snow
cloudy
mist
storm
thunderstorm
chance_of_tstorm
sleet
snow
icy
dust
fog
smoke
haze
flurries

Wir haben unsere eigenen Wetter-Icons als PNG-Grafiken mit Alpha-Transparenz abgespeichert. In diesem Fall muss die Variable “png” auf 1 gesetzt werden, weil dann die Wetter-Dateiendungen von GIF auf PNG in der user_weather.php umgeschrieben wird.

Ein schönes Wetter-Icon Set findet man bei graphicriver.net.

Demo-Screenshot

Nachdem das fertige Wetter-Modul mit CSS gestaltet wurde, sieht es so aus:

Download

PHP-Datei als TXT-Version zum Download: user_weather.php.txt

Hinweis

Da es keine offizielle Google API ist, ist es nicht sicher wie lange die API noch zur Verfügung steht und ob die Verwendung für die eigene Website erlaubt ist. Bisher sind im Web dazu weder positive noch negative Meinungen zu finden. Wer dazu mehr weiß, kann gerne einen Kommentar posten. Habt ihr die Google Weather API schon in Projekten eingesetzt? Wer Verbesserungsvorschläge für die PHP-Userfunc hat, bitte kommentieren! Ich hatte dabei Unterstützung von Anja, danke dafür!

------------------------------------------------------
Dies ist ein Post vom TYPO3 Blog typo3blogger.de!