Damit wären Nicht-Facebook-Mitglieder von der Betrachtung der Page ausgeschlossen. In diesem Fall muss die Konfiguration der Facebook Page abgeändert werden. Genau dafür muss sich in Facebook eingeloggt werden und auf der Page folgende Änderungen vorgenommen werden:

1. Auf der Facebook Page einfach auf “Edit Page” klicken
2. In der Dropdown-Liste, der nachfolgenden Seite, ist das Land zu entfernen UND
3. danach die Restriktionen abzuändern, sodass nur noch “Select Age Restrictions” in dem zweiten Dropdown-Menü steht.
4. Zum Schluß sind diese Änderungen zu speichern.

Mit diesen Änderungensschritten an der Konfiguration, kann die Page auch von Nicht-Facebook-Mitgliedern angesehen werden.

 

Zu diesem Zweck hat Clemens Schleiwies ein hervorragendes Video erstellt, in dem der Stellenwert von Facebook sehr schön visualisiert wird. Weiterhin beschreibt Clemens, wie die Fanpage individualisiert und für neue Besucher eine eigene Startseite eingerichtet werden kann. Um neue Fans für die Fanpage zu generieren, kann es hilfreich sein, einen Premium-Content für Fans einzurichten.

www.youtube.com/watch?v=RF1C3r6Fj50

 

myquizpoll erlaubt viele Quiz-Varianten zu realisieren, angefangen von einem Wissens-Test á la “Wer wird Millionär” mit “einer” richtigen Antworten bis zu einer konkreten Punkteverteilung pro Frage. Doch in der Erklärung zu einer Antwort gab es bisher ein kleines Manko, dass wir in Projekten feststellen mussten: In der Extension konnte nur ein Erklärungstext pro Antwort hinterlegt werden, egal ob die Antwort des Teilnehmers nun falsch oder richtig war.

Nachdem Kurt von dem Problem erfuhr, war auch kurzerhand eine Lösung gestrickt, die genau auf die Lösung dieses Problems abzielte. Die Version 1.4.2 von myquizpoll ermöglicht nun einen Erklärungstext für falsche Antworten und einen für richtige Antworten zu hinterlegen (Achtung: die Version ist nicht über den TER zu finden). An dieser Stelle von meiner Seite ein großes Dankeschön an Kurt für die schnelle Hilfe.

 

Die Grid-View

Eine der wichtigsten neuen Features ist die Grid View, mit der es nun möglich ist, das Layout im Frontend auch im Backend darzustellen. Insofern besteht die Möglichkeit, das Layout im Backend genauso wie im Frontend zu gestalten. Um ein Layout für eine Seite zu gestalten, unterstützt ein Wizard bei der Einrichtung und erlaubt damit komplexe Layouts zu realisieren. Zu diesem Zweck wählt man einfach ein “Grid Record” aus und weist dies der Seite zu. Neben dem Wizard besteht auch die Möglichkeit, händisch über TypoScript das Layout zu programmieren.

Der Wizard erlaubt die Auswahl verschiedener Layouts

Vorteil: Langzeit-Support

Das TYPO3 Projekt-Team produziert aktuell alle 6 Monate ein neues Major Release. Das führte dazu, dass ältere Versionen nicht mehr schneller unterstützt wurden. Die neue TYPO3 Version ist nun erstmals eine “LTS” Version (LTS steht für “Long Term Support”) und bedeutet, dass diese für die kommenden drei Jahre unterstützt und gepflegt werden. Insofern ist die neue Version auch eine Investition in einen sicheren Betrieb der Website. Doch die LTS Version bietet mehr als eine Support-Garantie für 3 Jahre.

Sichere Sache: Noch nie wurde eine TYPO3 Version länger unterstützt

Workspace: Unternehmensanforderungen besser unterstützt

Vollständig wurde in dieser Version auch der Workspace von TYPO3 überarbeitet. Dahinter steckt ein vollwertiges Workflow-System, mit dem Website-Inhalte in einer kopierten Instanz verändert werden können und somit vom restlichen System unabhängig sind. Auf diese Weise kann an einer “Kopie” der Website gearbeitet werden, ohne dass die “aktiven” Inhalte davon betroffen sind. Wenn alles vom Vorgesetzten abgesegnet ist, kann schließlich die Kopie per Knopfdruck “live” gestellt werden. Mit der neuen LTS Version ist der gesamte Workspace-Prozess noch übersichtlicher geworden.

Fazit: Lohnendes Update

Summa summarum ist die vom TYPO3 Core-Team herausgegebene neue Version ein Update Wert. Wer auf hohe Sicherheit und auf ein CMS-System Wert legt, das dem aktuellsten technischen Stand entspricht, sollte nicht zögern. Kunden, die bisher eine TYPO3 Version haben, die älter als 4.3 ist, sollten unbedingt ein Update vornehmen lassen.

 

1

<link http:wwwdomainde="" _blank="" >hier klicken</link>

Wie könnte man nun bei dieser Problemstellung vorgehen?

Prinzipiell ist es nun denkbar die parseFunc des RTE für tt_news zu verwenden und gibt dort für die tt_news Konfiguration folgende Anweisung an:

1
2
3

plugin.tt_news {
     displaySingle.content_stdWrap.parseFunc < lib.parseFunc_RTE
}

Im Grunde auch ein guter Gedanke, aber leider führte auch das bei dem vorliegenden Fall nicht zu einem sauberen und funktionierenden Link. Der einzige Weg der tatsächlich funktioniert, war die parseFunc für das displaySingle wie folgt zu manipulieren:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

displaySingle {
content_stdWrap.wrap >
subheader_stdWrap.wrap = |
content_stdWrap.parseFunc {
     makelinks = 1
     makelinks.http.keep = path
     makelinks.http.extTarget = _blank
     makelinks.mailto.keep = path
     tags {
          link = TEXT
          link {
               current = 1
               typolink.extTarget = _blank
               typolink.target = {$cLinkTagTarget}
               typolink.parameter.data = parameters : allParams
               }
          }
     }
}

Die Funktion makelinks erzeugt aus einer Internetadresse einen echten Link. Die weiteren Anweisungen bewirken unter anderem, dass die Adresse hinter dem Link in einem neuen Browserfenster geöffnet wird (_blank). Das Ergebnis dieses Code Snippets führt dann zu einem W3C validen Link.

 

Der verantwortliche Designer für die Änderungen in der derzeit aktuellen Version, Lars Zimmermann, entwickelte ein neues Gewand für das Backend, das Install Tool und das Login Screen.

Nicht zuletzt existiert mit der neuen Version ein Kompressions-Tool für JavaScript und CSS-Dateien, dass das Arbeiten im TYPO3-Backend beschleunigt. Ebenso sind dem Backend Sprites spendiert worden, dass das Laden zusätzlich beschleunigen soll.

Mehr Sicherheit

Mit der neuen Version sind mehrere Sicherheitslücken geschlossen worden. Am heutigen Tag (05.10.2010) ist bekannt geworden, dass “sicherheitskritische” Fehler von dem TYPO3 Entwicklerteam entdeckt worden sind. Ab morgen werden die Lücken geschlossen sein und neue Packete bereitgestellt werden. Sicherheitsrelevante Probleme sind auch über das Computer-Magazin ct Ende Juli bekannt geworden. So sind XSS-Lücken sowie ernsthafte SQL-Injections im System möglich gewesen, die mit einem Update auf die aktuelle Version 4.4.3 geschlossen werden können. Das solche Meldungen ernst zu nehmen sind, haben wir in früheren Artikel bereits darauf hingewiesen.

Besseres Aufgabenmanagement im Backend

Mit der neuen Version 4.4.3 wird auch ein neues Task-Center zum Verwalten und Erstellen von Aufgaben für alle TYPO3 Backend-Benutzer bereitgestellt werden. Somit können Autoren Notizen von Inhalten an andere schicken und die Dokumente, die sie kürzlich bearbeitet haben, schneller finden.

Auf einem Blick

Zusammengefasst sind folgende Änderungen mit der Version 4.4.3 verbunden:

• Mehr Sicherheit des TYPO3 Systems gegenüber Angriffen
• Verbesserung des Look & Feels vom Backend
• Besserer Rich-Text-Editor (RTE)
• Neues Aufgabenmanagement (Task-Center)
• Einführung des Introcution Packages (für eine schnelle Einrichtung von TYPO3)

Wer bis jetzt noch kein Update seiner alten TYPO3 Installation vorgenommen hat, sollte dies unbedingt tun bzw. uns diesbezüglich ansprechen. Wir helfen Ihnen gerne weiter.

Update (06.10.10): Sicherheitsupdate heute veröffentlicht

Das als kritisch eingestufte Sicherheitsupdate von der TYPO3 Association ist heute veröffentlicht worden. Wir empfehlen allen unseren Kunden, das Update vorzunehmen, bei dem folgende Fehler im Systemkern behoben werden:

• Cross-Site Scripting: Hier wird eine Sicherheitslücke in den älteren TYPO3 Versionen genutzt, um an sensible Benutzerdaten zu gelangen.
• Remote File Disclosure: In einigen PHP-System-Dateien ist ein unautorisierter Zugriff von Angreifern durch einen speziellen Anfrageparameter möglich.
• Denial of Service: Gewisse System-Funktion (Funktion: “filter_var()”) können durch lange Eingabeparameter (Strings) zum Absturz gebracht werden. Damit kann die Website nicht erreichbar sein.

 

So meldet der deutsche Provider Syseleven um 13:40 Uhr, dass die .de Domains Namensserver die TLD-Zone nicht vollständig geladen haben und es daher zu Fehlern kommt. 4 Minuten später meldete dann auch domainfactory, dass man von einem Problem auf Seiten des Betreibers der Top-Level-Domain “.de” ausgeht. Um 14:40 Uhr bestätigt die Denic dann auch über Golem, dass 6 Root-Server ausgefallen seien.

Wie Skurril die Ursachenforschung auf Twitter von statten geht, kann man noch am ehesten mit der Suche nach “#Denic” unter Twitter nachvollziehen. So gehen die Vermutungen von einem Terroranschlag bis zu einem Praktikantenfehler bei der Denic. Wir vermuten ja immer noch, dass eher ein Zusammenhang mit der Aschewolke bestehen könnte, die sich nun im Internet ausbreitet.

Jetzt, um 15:10 Uhr, sind mittlerweile einige unserer Kundenprojekte wieder erreichbar und die Denic scheint das Problem also wieder in den Griff zu bekommen.

Für einige sollte dieser Ausfall aber sich zu einem früheren und verlängerten Wochenende führen. In diesem Sinne: Viel Spass beim Vatertag .

 

Nicht selten ist dort die folgende Fehlermeldung aufzufinden, die sich dann alle paar Minuten wiederholt:
Core: Error handler (FE:sad: PHP Warning: fopen() [function.fopen]: Filename cannot be empty in /kunden/.../typo3cms/typo3_src-4.3.0/t3lib/class.t3lib_div.php line 5420

Wirklich sorgenbereitend ist diese Meldung nicht, denn TYPO3 arbeitet im Frontend ohne erkennbare Störung. Richtig Zeit den Fehler zu ergründen hatten wir bisher nicht, aber wem eine schnelle Lösung ohne Grund genügt, der soll einmal folgendes versuchen:

1. Die localconf.php öffnen (liegt im Unterordner typo3conf) und danach
2. die Zeile [SYS][systemLog] = ...... auskommentieren.

Danach sollte der Spuk behoben sein.

 

1. Die Startseite wird angezeigt, aber nachdem ein Navigationspunkt angeklickt wird, erscheint eine 404 Fehlermeldung. Woran liegt das?
   Ursache:  Anscheinend ist die .htaccess nicht richtig konfiguriert worden. Steht zum Beispiel “RewriteBase /” in der .htaccess und die zu erreichende index.php von TYPO3 liegt aber im Unterordner xyz, erscheint ein solcher Fehler. Dann muss auch in der .htaccess “RewriteBase /xyz” gesetzt werden.
2. Ich habe meine TYPO3 Installation geupdatet und nun werden Seiten auf der zweiten und dritten Ebene nicht mehr angezeigt. Gibt es dafür eine Lösung?
   Ursache: Mit manchen neuen TYPO3 Version wird auch Simulatestatic geupdated (zuletzt in der TYPO3 4.3 Version). Die RealURL Konfigurationen werden dann überschrieben. Aus diesem Grund muss RealURL deinstalliert (nicht updaten!) und danach wieder neu installiert werden.
3. Ich möchte RealURL mit mehren Domains nutzen, aber die Standard Konfiguration funktioniert einfach nicht. Was ist da los?
   Ursache: Kommentiere die “RewriteBase /” aus und verwende stattdessen eine RewriteRule, die dann so aussehen könnte:
   Hat man mehrere Domains für eine TYPO3 Installation, empfiehlt es sich eine Rewriterule zu schreiben
   RewriteCond %{HTTP_HOST} deine.domain$ [NC]
RewriteRule ^$ /index.php?id=foo
   Der Wert von id ist natürlich nicht foo, sondern die Pid innerhalb der TYPO3-Seiten. In der localconf der TYPO3-Installation muss dann folgendes ergänzt werden:
   $TYPO3_CONF_VARS['EXTCONF']['realurl']['deine.domain'] =
$TYPO3_CONF_VARS['EXTCONF']['realurl']['_DEFAULT'];
$TYPO3_CONF_VARS['EXTCONF']['realurl']['meine.domain']['pagePath']['rootpage_id'] = foo;

4. Ich habe mehrere Domains in TYPO3 hinzugefügt. Alles scheint zu funktionieren, nur realurl zeigt im Pfad Page-IDs an, z.B.: http://www.meinedomain.de/263/
   Dies entsteht dadurch, dass die neue Domain nicht in der realurl_autoconf.php konfiguriert ist. Zu diesem Zweck muss man einfach diese Datei von realurl “neu” schreiben lassen. Und dazu wechselt man in den Extension Manager und klickt unter realurl auf “Information” und auf der Folgeseite auf den Button “Update”. Danach sollte es funktionieren. Häufig fehlt nach der Neuinstallation von realurl auch schlichtweg die Konfigurationsdatei für realurl, nämlich die “realurl_conf.php” im Ordner typo3conf/. Fehlt diese können auch keine sprechenden URLs erzeugt werden.
5. Wie kann ich den Fehler “Segment … was not a keyword for a postVarSet as expected!” verhindern?
   Ursache: Der Ursachenforschung hat sich einmal René Nitzsche angenommen. Eine schnelle Lösung ist aber Realurl kurzfristig über Typoscript mit “config.tx_realurl_enable = 0″ abzustellen. Danach sich aus dem Backend auszuloggen, die einzelnen Seiten im Frontend besuchen und dann wiederum den Cache leeren im Backend. Zu guter letzt natürlich RealURL wieder  anschalten. Danach sollte es wieder funktionieren. Erscheint der Fehler immer noch, könnte die Ursache an einem TYPO3 Update liegen.

 

Der Usability-Experte Jacob Nielsen schrieb vor mehr als 3 Jahren in seiner Alertbox über das Thema „Screen Resolution and Page Layout“ und stellte hier heraus, dass man „heutzutage“ seine Website für eine Bildschirmauflösung von 1024×768 optimieren sollte. Welche Bildschirmauflösung derzeit die Aktuelle ist, kann sehr gut an öffentliche Statistiken und natürlich an den Web-Statistiken des Kunden abgelesen werden. Letzteres sollte natürlich vorgezogen werden. Die Grundaussage in Nielsen’s Artikel ist, dass die Website fehlerfrei dargestellt werden muss, auch wenn diese mit einer kleinen Bildschirmauflösung betrachtet wird. Das Layout der Website muss sich also an die Bildschirmauflösung anpassen.

Kriterien nach J. Nielsen für das Seitenlayout

Doch allein mit der Wahl der richtigen Bildschirmauflösung ist es nicht getan. Es gibt nach Jacob Nielsen drei wesentliche Kriterien, die für die Darstellung unbedingt sichergestellt werden sollten:

• Initial visibility: Dies ist der sichtbare Bereich auf dem Bildschirm des Besuchers, in dem alle Schlüsselinformationen der Website bereitgestellt werden müssen. Das bedeutet im Klartext: Surfen ohne horizontales Scrollen.
• Aesthetics: Ist die Darstellung und das Layout der Website gewahrt, wenn die Auflösung stark variiert? Ist die grundlegende Gestaltungsästhetik sichergestellt? So darf zum Beispiel der Abstand zwischen Bild und Text oder der Abstand zwischen zwei Spalten nicht variieren.
• Readability: Ist der Text, trotz variierender Auflösung noch gut lesbar? Ist beispielsweise bei Spalten der “width” Parameter definiert?

Richtige Betrachtung der “Auflösung”

Was Nielsen hier richtigerweise gut ausformulierte, stellt allerdings nicht genügend das eigentliche Problem heraus oder gibt Handlungsempfehlungen, wie die obigen Kriterien sichergestellt werden können. Denn im Grunde muss bei Betrachtung der Auflösung unterschieden werden nach:

• Bildschirmauflösung,
• Browser-Fenstergröße (actual browser size) und
• Content Area

Jasper Rønn-Jensen formulierte diese wichtige Feststellung in seinem Artikel “Design for Browser Size — Not Screen Size“. Ferner verdeutlicht er, dass für die Gestaltung einer Website die Bildschirmauflösung weniger bedeutend ist (ganz im Gegensatz zu Nielsen). Aus seiner Sicht ist die Browser-Fenstergröße entscheidend, was aus meiner Sicht auch die richtige Betrachtung ist.

Jasper begründet dies damit, dass die Größe des Browserfensters meistens geringer ist als die tatsächliche Bildschirmauflösung des Users. Mac-User wissen, was er meint, denn auf dem Mac gibt es keine Funktion zum Maximieren der Fenster, wie bei Windows. Somit ist zum Beispiel mein Browser Fenster beim Surfen bei einer Auflösung von 1440×900 px nie maximiert. Weiterhin müssen von der Browser-Fenstergröße die horizontale und vertikale Scrollbar sowie die Symbolleiste des Browsers abgezogen werden. Erst danach erhält man die Content Area, für die die Website gestaltet werden muss.

Content Area bzw. Actual Browser Size

Und an diesem Punkt wird es interessant! Wie kann man nun die Content Area bei den vielen verschiedenen Browsern ermitteln? Jasper Rønn-Jensen hat Durchschnittswerte für Scrollbar, Statusleiste und Symbolleiste ermittelt und auf dieser Basis die Content Area berechnet. Die folgende Tabelle zeigt – neben der Content Area pro Bildschirmauflösung – dass immer seltener das Browserfenster bei steigender Bildschirmauflösung maximiert wird:

Zusammenfassung

Im Grunde ist es aus meiner Sicht wichtig sicherzustellen, dass sich eine Website an die Fenstergröße der Browser anpasst und der User nicht nachhelfen muss, um alles lesen zu können (durch Maximieren des Fensters oder durch Scrollen). Um hier das Optimum sicherzustellen, sollte man sich an obige Tabelle von Jasper orientieren.